MCP 篇把「Agent 怎麼接工具」講清楚了；本篇換一層——當兩個（或多個）Agent 要彼此委派工作時，它們要講什麼共同語言。

《Model Context Protocol（MCP）深度解析》解決的是 M 個 Agent × N 個工具 的插拔問題：每個應用講 MCP、每個工具用 MCP server 暴露，整合成本從 M × N 收斂成 M ＋ N。但真實系統很快會碰到下一層爆炸——不是「Agent 接工具」，而是「Agent 委派給另一個 Agent」：客服 Agent 要把訂單爭議丟給帳務 Agent、研究 Agent 要把法規審核丟給合規 Agent、編排 Agent 要把跨系統流程拆給多個專責 Agent。

若每一對 Agent 都各自約定 API、狀態碼與回報格式，成本又會逼近 K × K（K 個可互操作 Agent）。Agent-to-Agent Protocol（A2A）就是為這一層設計的開放標準：讓不同框架、不同語言、不同供應商做出來的 Agent，能用同一套「發現能力 → 委派任務 → 追蹤狀態 → 取回產物」的契約協作。它由 Google 於 2025 年提出並開源，後續移交 Linux Foundation 維護；核心承諾同樣一句話：

同一條業務流程裡兩層常同時出現：編排 Agent 用 A2A 委派給專責 Agent；專責 Agent 內部再用 MCP 呼叫工具。本篇只展開 A2A 那一層。

先記住這四條「不是」：A2A 是對等 Agent 之間的發現與委派協定，一層薄契約，專門解「跨框架、跨廠商怎麼一起做事」。

在委派之前，你得先知道對方是誰、能做什麼、怎麼連。Agent Card 就是這張「對外名片」。

A2A 的入口是一份 JSON 中繼資料，稱為 Agent Card。習慣上掛在可預測的 well-known 路徑（常見為 /.well-known/agent.json 或同等的 Agent Card URL），讓呼叫端只要知道對方的網域或 Card URL，就能拉回這份自我描述。它扮演的角色，很像 REST 世界的 OpenAPI：不執行工作本身，但把「能做什麼、怎麼認證、端點在哪」講清楚。

{
  "name": "compliance-agent",
  "description": "審核合約條款是否符合內部政策",
  "url": "https://agents.example.com/compliance",
  "version": "1.2.0",
  "skills": [{
    "id": "review-contract",
    "description": "對合約 JSON 做政策檢查，回傳 pass/fail 與理由",
    "inputModes": ["application/json"],
    "outputModes": ["application/json", "text/plain"]
  }],
  "authentication": { "schemes": ["bearer"] },
  "capabilities": { "streaming": true, "pushNotifications": true }
}

真實 Card 欄位會依規格版本更細；重點是「可被機器讀取的自我描述」，不是給人類看的 README。

A2A 把每一次跨 Agent 工作包成一個有明確狀態的 Task——這是它與「打一次 RPC 就結束」最大的差異。

在 A2A 裡，互動的單位不是「一次 request／response」，而是一個有 id、有狀態、可長跑的 Task。呼叫端送出委派後，遠端 Agent 回的是 Task（或其串流事件），狀態沿一條定義好的狀態機前進。這讓「查一下天氣」與「審核一份要跑兩天的合規流程」能共用同一套契約。

stateDiagram-v2
    state "auth-required" as authReq
    state "input-required" as inputReq
    [*] --> submitted
    submitted --> working: 開始執行
    submitted --> authReq: 需授權
    submitted --> rejected: 拒收
    authReq --> working: 補授權
    working --> working: 進度／產出
    working --> inputReq: 缺資料
    inputReq --> working: 補資料
    working --> completed: 交卷
    working --> failed: 失敗
    working --> canceled: 取消
    completed --> [*]
    failed --> [*]
    canceled --> [*]
    rejected --> [*]

看兩個地方：authReq／inputReq 都有一條回到 working 的箭頭——它們是可恢復的中斷，不是終態；而四個終態只出得去（[*]），沒有任何箭頭回到中間態，這就是「終態不可變」的圖形化寫法。

狀態如何回報？A2A 支援幾種模式，呼叫端依 Agent Card 的 capabilities 選擇：

三種模式共用同一套 Task 狀態語意；差在「狀態怎麼送到呼叫端」，不是另一套生命週期。

狀態機告訴你「走到哪」；真正承載工作內容的，是 Message 與最終的 Artifact。

跨 Agent 交換的內容被拆成幾個清晰物件：

一條典型委派時序（也是第 5 節 Demo 要逐步走的路徑）大致如下：

1. 發現：Client Agent 取得 Remote Agent 的 Agent Card，確認有目標 skill。
2. 送出委派：對 Remote 端點送 message/send（或串流變體），帶上初始 Message（例如「請審核這份合約」+ DataPart）。
3. 建立 Task：Remote 回傳 Task，狀態進入 submitted／working。
4. 狀態回報：透過同步結果、SSE 事件或 push，更新 TaskStatusUpdateEvent。
5. （可選）中斷補料：若進入 input-required，Client 再送一則同 taskId 的 Message 補資料。
6. 交卷：終態 completed，並附上 Artifact（或失敗時的錯誤資訊）。

狀態機不是拿來看的，是拿來撞的：同一個事件在不同狀態下合不合法、合法時帳目怎麼變。

場景設定：Orchestrator Agent（Client）把「審核合約 CTR-2048」委派給 Compliance Agent（Remote）。下面這台模擬器沒有劇本——你先設定條件（回報通道、輪詢間隔、remote 預計工時、此 skill 是否需要額外授權），然後自己決定每一步要注入哪個事件。事件是否合法由轉移表判定；狀態、耗時、三種回報通道各需幾次請求，全部即時算出。

什麼時候該用 A2A、什麼時候其實只需要 MCP 或內部函式呼叫？把選型邊界講死，面試才答得乾淨。

選型口訣：工具邊 → MCP；對等 Agent 邊 → A2A；同進程邊 → 別硬上協定。

把本篇壓成一張心智圖，接上 ACP 互通篇那張三協定對照表時才站得穩。

讀完本篇，你應該能在白板上快速畫出：

1. 兩層邊界：Agent↔Agent 用 A2A；Agent↔工具用 MCP。
2. 發現：先拉 Agent Card（well-known／目錄），對齊 skills、auth、capabilities。
3. 委派：message/send 建立 Task；用 Message／Parts 傳意圖與資料。
4. 生命周期：submitted → working，可經 input-required 恢復，終態不可變並以 Artifact 交卷。
5. 回報通道：同步／SSE／push 共用同一套狀態語意。

下一篇《ACP 與 Agent 互通協定對照》會把 MCP／A2A／ACP 放在同一張選型表——本篇請把「A2A 這一格」記牢：它解決的是對等 Agent 如何發現彼此、委派任務、回報狀態，而不是工具插拔，也不是單一 runtime 怎麼跑。