A2A 協定：讓 Agent 學會交朋友——五個名詞看懂 Agent 間的協作標準
前言
9 月我們聊過 MCP——Agent 時代的「USB-C」，讓 Agent 接上工具和資料；10 月談過多智能體編排，知道一個厲害的系統往往是好幾個 Agent 分工。但一個問題一直沒被解決：來自不同團隊、不同框架的 Agent，要怎麼互相說話？
Google 在 2025 年 4 月 9 日給出答案：Agent2Agent 協定（A2A），並在同年 6 月捐給 Linux 基金會成為中立開放標準，目前已到 1.0 版。如果說 MCP 給了 Agent 一雙「手」，A2A 給的就是「同事」——一套 Agent 之間發現、委託、協作的共通語言。
為什麼需要 A2A？
在 A2A 出現之前，Agent 間的協作是每個團隊自己發明的私房菜：LangGraph 的做法跟 CrewAI 不同，內部系統的 Agent 更不可能跟合作廠商的 Agent 溝通。這就像每一家都做自己的插頭，插頭再漂亮也插不進別人家。
A2A 的核心洞察是：協作介面應該跟內部實作解耦。兩個 Agent 合作時不需要知道對方用什麼模型、有什麼工具、記憶怎麼存——就像打電話不需要知道對方的手機品牌。A2A 規定了「怎麼打電話」，不管背後是誰家的 Agent 都能接得通。
五個名詞，看懂整個協定
A2A 的設計走的是「無聊但可靠」路線：HTTP(S)＋JSON-RPC 2.0＋Server-Sent Events＋OAuth 2.0，全是 Web 世界已經打過無數仗的標準。整個協定可以用五個名詞講完：
1. Agent Card（名片）：Agent 對外發布的 JSON 文件，通常放在 /.well-known/agent-card.json。上面寫了我是誰、會什麼技能（skills）、支援什麼傳輸方式、需要什麼認證。這就像餐廳門口的菜單，client Agent 在聯絡前可以先看菜單決定要不要進來。
2. Client Agent／Remote Agent（兩種角色）：發起委託的是 client，被委託做事的是 remote。注意這是角色不是身分——一個 Agent 可以同時是別人的 client 和另一個人的 remote。
3. Message（訊息）：溝通的基本單位，裡面是 Parts——可以是文字、二進位、URL 或結構化 JSON。一個 Message 可以開一個新任務，也可以是既有任務中的往來對話。
4. Task（任務）：有狀態的協作單位，帶著明確的生命週期：submitted（已提交）→ working（執行中）→ completed（完成）／failed（失敗），中間還可以 input-required——做一半發現缺資料就回頭問委託方，不是火燒完就跑。長任務可以選輪詢（polling）、SSE 即時串流，或用 webhook 推送回來。
5. Artifact（產出物）：任務的成果，可以分段增量送回。報告寫到一半就先把前面章節送出來，client 不用等到最後。
發現→傳訊息→開任務→串流更新→收產出物，如圖一。五個名詞，一套乾淨的流程。
A2A vs MCP：不同層，不打架
最常見的誤會是把 A2A 當成 MCP 的對手。實際上它們在不同層（如圖二）：
- MCP 是垂直的：Agent↔工具／資料。解決「我的 Agent 怎麼用資源」。
- A2A 是水平的：Agent↔Agent。解決「我的 Agent 怎麼跟別的 Agent 共事」。
Google 官方的說法是「better together」。一個典型企業場景：行程規劃的 concierge Agent 接到使用者請求，用 A2A 把找機票、訂飯店、租車分給三個專門 Agent；每個專門 Agent 再用 MCP 接自己的工具（航空公司 API、飯店資料庫、金流）。MCP 管縱向的工具連接，A2A 管橫向的同儕協作，兩者都是 Linux 基金會旗下的開放標準。
實作要點：先寫名片，再開任務
想動手的話，建議分三個階段：
階段一：先發布 Agent Card。這是最便宜的一步——寫一份 JSON 說明自己的技能和認證需求，掛到 well-known 路徑。這一步本身就在為未來的協作鋪路，也逼你把 Agent 的能力邊界說清楚。
階段二：實作 server 端的任務處理。能接收 Message、開 Task、走生命週期、回傳 Artifact。串流用 SSE 就好，長任務再加 webhook 推送通知。
階段三：實作 client 端的委託能力。讓你的 Agent 會讀別人的 Agent Card、會發委託、會追蹤遠端任務狀態。
幾個工程上的提醒：對等但不透明（opaque）是 A2A 的設計原則——協作雙方不互換記憶、工具和內部邏輯，只透過標準介面打交道；這讓跨組織協作的安全邊界變得很乾淨，但也意味著你不能假設對方看得到你的內部狀態。安全上用 OAuth 2.0／JWT 做認證，技能層級可以設不同的存取權限。採用面上已經開花：Google ADK、Microsoft Copilot Studio、Azure AI Foundry、Amazon Bedrock AgentCore 都支援。最後一個提醒：這份規格還在快速演進（早期草案的 well-known 路徑和欄位名都改過），動手前務必對照 a2a-protocol.org 的最新版本。
結論：什麼時候該用 A2A？
問自己三個問題：你的系統裡有超過一個 Agent 嗎？它們來自不同團隊或框架嗎？你希望把「委託一個專門 Agent」當成調用服務一樣標準化嗎？三個都答是，A2A 就是你的答案。
MCP 讓 Agent 的世界從「孤島」變成「有工具的孤島」；A2A 讓這些孤島之間搭起橋。Agent 的下一個十年，大概率不是更聰明的單一 Agent，而是更會協作的 Agent 生態系——而生態系的第一塊磚，就是一套大家都願意講的共通語言。
來源：
Google Developers Blog, "A2A: A new era of agent interoperability"（2025-04-09）：https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
A2A 官方規格：https://a2a-protocol.org/
沒有留言:
張貼留言