寫過 agent 的人大概都有這個經驗：在本機跑 adk web 或 python main.py，對話順暢、工具呼叫正確、demo 給人看也很有面子。然後有人問一句「這個可以給別人用嗎」，整件事就卡住了。

卡住的地方不是模型不夠強，是這隻 agent 從一開始就被寫成「只在我這台電腦上存在」的東西。

三個具體的斷點

本機跑的 agent 是一個 process，別的程式要用它只能 import 它。一旦要讓另一台機器上的服務呼叫，得先決定它用什麼協定對外講話，HTTP？自訂 JSON？每個人都自己發明一套，結果三隻 agent 三種介面，誰也接不了誰。這是第一個斷點：它沒有位址。

第二個斷點藏得比較深，它沒有身分。本機的對話歷史存在記憶體裡，重啟就沒了。上線之後同一個使用者的兩句話可能打到不同的容器實例，「我要兩個」這種依賴前文的句子就會失效。誰持有對話身分、由誰傳遞，在本機時期完全不用想。

第三個是帳單。本機跑再久也不花錢，雲端不是。我在跑 codelab 的時候照抄了一行含 --min 1 的部署指令，那個參數會保留一個實例常駐來消除冷啟動，代價是沒有流量的時段照樣計費。教學文件為了 demo 體驗流暢預設帶著它，但沒提清理步驟，這跟 Cloud Run「零流量零費用」的直覺剛好相反。

這個系列要做的事

我打算用 30 天把一隻本機 agent 一路推到雲端，並且讓它能跟別的 agent 互相呼叫。用到的東西有三層：

• 協定層：A2A(Agent2Agent)，解決「agent 之間怎麼講話」
• 框架層：ADK 與 LangGraph，解決「單一 agent 內部怎麼編排」
• 平台層：Cloud Run，解決「它住在哪、誰付錢、出事怎麼查」

素材來自我 2026 年 8 月跑 Google Cloud 留下的筆記，加上實際部署時撞到的坑。