我的知識庫

AI · 2026-07-18

閱讀時間約 9 分鐘

A2A(Agent-to-Agent)協定是一套讓不同廠商、不同框架的 AI 代理彼此發現、對話、委派任務的開放標準,把「多代理協作」從各家私有格式拉進共同語言。截至 2026 年 4 月,支持組織已從一年前的 50 多家成長到超過 150 家,涵蓋 AWS、Google、Microsoft、Salesforce、SAP,並自 2025 年 6 月起交由 Linux Foundation 治理、於 2026 年推出 v1.0。它和你熟悉的 MCP 不是競爭關係:MCP 管「代理連工具」,A2A 管「代理連代理」,兩者疊起來才是完整的協作底座。今天就把 A2A 的核心機制拆開來看。

📖 學(核心）

為什麼需要一層「代理對代理」的協定

過去要讓兩個 AI 代理合作,幾乎只能靠私有 API 或硬串程式碼,一旦換框架(LangGraph、CrewAI 各有各的記憶與訊息格式)就得重寫。A2A 的出發點是:代理應該像微服務一樣,能在不共享內部記憶、不暴露內部實作的前提下互相委派工作。它刻意跟 MCP 分工——MCP 把單一代理接上資料庫、API、檔案等「工具」;A2A 則把一個代理接上「另一個能自主決策的代理」。所以在真實系統裡,一顆代理常常同時是 MCP 客戶端(去用工具)又是 A2A 節點(去跟同儕協作)。

Agent Card:代理的「名片」與能力發現

A2A 讓代理被找到的方式是一份 Agent Card,這是一份放在固定網址 /.well-known/agent-card.json 的 JSON 文件。卡片裡宣告了這顆代理的技能(skills)、支援的輸入輸出 MIME 型別、傳輸綁定(transport bindings),以及安全機制(security schemes)。這樣設計的好處是「發現」變成標準化動作:一個發起端代理(client agent)不必事先知道對方細節,只要抓 Agent Card 就能判斷「這顆遠端代理(remote agent)會不會做我要委派的事、要用什麼認證、吃什麼格式」。這等於把服務發現的概念搬到代理世界,能力描述與呼叫方式綁在同一份可讀文件裡。

八狀態任務生命週期:把「委派」變成可追蹤的流程

A2A 的核心資料模型是 Task(任務),而任務有一套明確的八狀態生命週期:submitted(已送出)、working(執行中)、input_required(需要補輸入)、auth_required(需要授權)、completed(完成)、failed(失敗)、canceled(取消)、rejected(拒絕)。這套狀態機讓委派不再是「呼叫完就沒下文」,而是雙方對進度有共同認知。配套有三個生命週期方法:tasks/get 輪詢當前狀態、tasks/cancel 中止任務、tasks/resubscribe 在連線中斷後重新接回事件串流。有了 input_required 和 auth_required 這兩個中間狀態,長流程可以合法地「暫停等人補資料或補授權」,再繼續走完。

傳輸與串流:同步、SSE、Webhook 三檔切換

底層通訊上,A2A 以 JSON-RPC 2.0 為主,也提供 gRPC 與 HTTP+JSON 綁定。關鍵在於它按任務長短切換回應方式:簡單請求毫秒級同步返回;複雜、耗時的請求會升級成 SSE(Server-Sent Events)串流,把部分結果分批推回,讓發起端在幾分鐘的過程中看到中間產出;而「射後不理」型的委派則用 Webhook 推播通知,任務完成再回呼。這三檔的意義是:同一套協定能同時撐住即時互動與長時間背景作業,不必為了長任務另外造輪子。

定位:A2A 與 MCP 的雙層架構

把視角拉高,2026 年逐漸成形的參考模型是「MCP + A2A 雙層」:下層 MCP 負責可靠地接工具與情境,上層 A2A 負責跨代理的團隊協作與分散式流程編排。當你的系統只有一顆代理、只是要接資料庫和 API,MCP 就夠;一旦你營運的是「不只一個 AI 系統」、需要它們互相委派子任務,A2A 才變得必要。業界目前的共識是:多數正式部署會兩者並用,而非二選一。

🧠 記

  • A2A 管「代理對代理」,MCP 管「代理對工具」,兩者互補而非競爭。
  • Agent Card 放在 /.well-known/agent-card.json,宣告技能、輸入輸出格式、傳輸綁定與安全機制,是能力發現的入口。
  • 任務有八個狀態:submitted / working / input_required / auth_required / completed / failed / canceled / rejected。
  • 三個生命週期方法:tasks/get(查狀態)、tasks/cancel(取消)、tasks/resubscribe(斷線重連串流)。
  • 傳輸以 JSON-RPC 2.0 為主,另有 gRPC、HTTP+JSON;回應分同步、SSE 串流、Webhook 推播三檔。
  • 代理間協作「不共享內部記憶」,靠標準化訊息與任務狀態交換,降低框架綁定。
  • 治理者是 Linux Foundation(2025 年 6 月起),2026 年釋出 v1.0,支持組織已破 150 家。
  • input_required 與 auth_required 讓長流程能合法暫停、等補資料或補授權再續。

✍️ 實踐

  1. 先畫出你系統裡的「代理 vs 工具」邊界:哪些是會自主決策的代理(該用 A2A)、哪些只是被動 API(該用 MCP),別把兩者混成一鍋。
  2. 為你的一顆代理手寫一份最小 Agent Card JSON,至少填 skills、輸入輸出 MIME、security scheme,放到 /.well-known/agent-card.json 試著讓另一端抓取。
  3. 用官方 Python 或 JavaScript SDK 起一個 A2A server,實作一個回傳固定結果的技能,驗證從 submitted → working → completed 的狀態流轉。
  4. 刻意設計一個需要 input_required 的技能(例如缺參數就暫停),觀察發起端如何補資料後讓任務續跑。
  5. 把一個耗時任務改成 SSE 串流回傳部分結果,對照同步回應,體會兩者在使用者體感上的差異。
  6. 讓兩顆不同框架(如一顆 LangGraph、一顆 CrewAI)的代理透過 A2A 互相委派一個子任務,確認它們在不共享記憶下仍能完成流程。

🔗 延伸學習

💬 問 AI

我正在設計一個多代理系統,情境是:{描述你的場景,例如「一顆客服代理要把退款子任務委派給財務代理」}。
我目前用的框架是 {LangGraph / CrewAI / 其他},代理數量約 {數字} 顆。

請幫我:
1. 判斷哪些互動該用 A2A(代理對代理)、哪些該用 MCP(代理對工具),並說明理由。
2. 為其中一顆代理設計一份最小可用的 Agent Card(JSON),包含 skills、輸入輸出 MIME、security scheme。
3. 用 A2A 的八狀態任務生命週期,畫出這個委派流程從 submitted 到 completed 的狀態轉移,並標出哪裡會用到 input_required 或 auth_required。
4. 針對耗時的 {某個子任務},建議用同步、SSE 串流、還是 Webhook 推播,並說明取捨。

反向連結