要用一隻 A2A agent，第一步是抓它的卡。

Agent Card 是一份 JSON，放在固定路徑 /.well-known/agent-card.json(部分實作用 /.well-known/agent.json，我在 Cloud Run 上實測時打的是後者)。這個「固定路徑」的設計跟 robots.txt、security.txt 是同一個傳統：不需要註冊中心，知道網域就能拿到說明書。

卡裡有什麼

實際抓下來大致長這樣：

card.name = "burger_seller_agent"
card.description = "Helps to create burger orders"
card.skills = [...]

三個關鍵欄位：

• name：識別用的名字
• description：一句自然語言，說明這隻 agent 做什麼
• skills：更細的能力清單，每項也有自己的描述

另外還有端點 URL、支援的協定版本、輸入輸出模態這些。我實測時 Cloud Run 上那張卡的 protocolVersion 是 0.2.6。

orchestrator 啟動時做什麼

orchestrator 啟動時對每一個已知的 remote agent 打一次 GET /.well-known/agent.json，把拿回來的 name 跟 description 塞進自己的 system prompt。

注意這個動作的時間點：啟動時，不是每次委託時。所以你改了 remote agent 的卡，orchestrator 要重啟才會知道。這個特性在除錯時會咬人，明明改好了但行為沒變，先想想是不是沒重啟。

一個可以直接量測的副作用

既然 agent card 的內容進了 system prompt，那它就會被計費。

orchestrator 第一次呼叫時的 prompt_token_count 裡就含所有 agent card 的內容，agent 掛越多這個底噪越大。這是一筆固定成本，每一次對話都付一次，跟你有沒有真的用到那隻 agent 無關。

所以「先把公司所有 agent 都掛上去，反正用不到也不會怎樣」這個想法是錯的。用不到也會怎樣，它每一輪都在收錢，而且會稀釋路由判斷的準確度。