A2A 與 MCP 差在哪裡？AI 代理間通訊為何需要獨立協定，又為何只有 A2A 加入了 gRPC

從對等性與拒絕能力、Agent Card 的能力發現、任務狀態三個面向，說明為何單靠 MCP 不足以支撐 AI 代理間通訊，並解析 A2A v1.0 為何提供 gRPC，MCP 卻仍守著 HTTP。

更新

白色卡片上的藍色 Agent2Agent 的 A-2-A 圓形標誌與字樣
本頁目錄

引言

「我想讓 AI 代理彼此協作，用 MCP 接起來不就好了嗎？」

隨著 AI 代理開發熱度升高，這是很多人都會碰到的疑問。MCP（Model Context Protocol）正以工具整合標準的姿態普及，而在它旁邊還出現了另一份規格：Google 提出的 A2A（Agent-to-Agent）協定。

先講結論，兩者的守備範圍不同。MCP 是 AI 代理的「手和眼」，A2A 則是它的「嘴」。工具用的協定沒辦法頂替 AI 代理用的協定，因為工具無法拒絕請求，而 AI 代理可以。

為什麼需要兩個協定、MCP 到底缺了什麼、以及為什麼 A2A 加入了 gRPC 而 MCP 仍守著 HTTP，本文以 A2A v1.0 與 MCP 2026-07-28 版規格為準，依序把這幾個問題拆開來看。

A2A 與 MCP 各自的守備範圍

先把兩者的角色整理出來。

MCPA2A
全名Model Context ProtocolAgent-to-Agent Protocol
負責領域AI 代理 ↔ 工具/資料來源AI 代理 ↔ AI 代理
關係客戶端-伺服器（主從）對等、雙向
典型操作tools/call, resources/readSendMessage, GetTask
提出者AnthropicGoogle

一句話總結：MCP 是 AI 代理的「手和眼」（使用工具、讀取資料），而 A2A 是 AI 代理的「嘴」（與其他 AI 代理對話與協商）。

具體例子：物流與庫存管理

跨組織的 AI 代理整合，看起來會是這個樣子。

AI 代理之間走 A2A，連往工具走 MCP兩個企業方框並排。每個方框內有一個 AI 代理，向下透過 MCP 連往該企業自己的三項工具。兩個 AI 代理之間以雙向的 A2A 連線橫向相連，只有這條連線跨越企業邊界，任一 AI 代理都不會碰到對方的工具。物流企業AI配送 AI 代理自主判斷配送計畫與路線最佳化MCP工具群配送資料庫GPS API路線最佳化引擎合作企業AI庫存 AI 代理自主追蹤庫存並判斷補貨時機MCP工具群庫存資料庫訂購 API倉儲管理系統AI 代理間通訊A2A

只有 A2A 這條連線跨越企業邊界，任一 AI 代理都不會碰到對方的工具。

  1. 庫存 AI 代理透過 MCP 查詢庫存資料庫，判斷出「商品 X 只剩 10 個，需要補貨」
  2. 庫存 AI 代理透過 A2A 向配送 AI 代理提出請求：「商品 X 500 個送到 A 倉庫，明天可以到嗎？」
  3. 配送 AI 代理透過 MCP 呼叫 GPS API 與路線最佳化工具，確認有沒有空檔
  4. 配送 AI 代理透過 A2A 回覆：「明天 14:00 可送達，已指派 B-12 貨車」

工具操作（MCP）與 AI 代理之間的協商（A2A），角色分得很清楚。

為什麼光靠 MCP 不足以支撐 AI 代理間通訊

「把對方的 AI 代理註冊成一個 MCP 工具不就好了？」這個想法很自然。但它有幾個根本性的問題。

1. 沒有對等性

MCP 是客戶端-伺服器模型。一邊是客戶端（呼叫方），另一邊是伺服器（被呼叫方）。

MCP: AI 代理(client) → 對方 AI 代理(server，當成工具)
A2A: AI 代理 ←→ AI 代理（對等）

AI 代理是會自主判斷的存在。把它當工具從屬化，等於忽略對方的自主性，包括它說出「這種條件我無法接受」的能力。

A2A 把這種拒絕寫進了協定。TASK_STATE_REJECTED 是一個終止狀態，代表 AI 代理決定不執行這項任務。它可以在任務建立時就出現，也可以在 AI 代理處理到一半、判斷自己無法或不願繼續時出現。

MCP 沒有對應的機制。2026-07-28 版規格把請求的方向講得更明白：伺服器不會主動發出 JSON-RPC 請求，被呼叫的一方永遠只負責回答。

2. 沒有能力發現機制

MCP 有公開工具綱要（輸入與輸出的型別定義）的機制，但那不足以表達一個 AI 代理的能力、政策或當前狀態。

A2A 用的是稱為 Agent Card 的機制，每個 AI 代理把自己的能力與政策公開在 /.well-known/agent-card.json。對方能做什麼、以什麼條件接下工作，都可以事先發現。

3. 非同步任務管理

MCP 的核心是請求-回應。像「配送安排中，三小時後確認」這種長時間的工作，要交給需要主動啟用的 Tasks 擴充功能處理：伺服器不直接回傳結果，而是回傳一個任務控制代碼，客戶端再用 tasks/get 輪詢，或訂閱狀態通知。

在 A2A 裡，任務是核心協定的一部分。任務從 TASK_STATE_SUBMITTED 進入 TASK_STATE_WORKING，最後以 TASK_STATE_COMPLETED、TASK_STATE_FAILED、TASK_STATE_CANCELED 或 TASK_STATE_REJECTED 結束。途中也可能暫停在兩個狀態：TASK_STATE_INPUT_REQUIRED 代表 AI 代理在要求補充資訊，TASK_STATE_AUTH_REQUIRED 代表它在等待認證。進度可以透過 SSE 串流、Webhook 推播通知或輪詢取得。

A2A 任務生命週期A2A 任務的狀態圖。SUBMITTED 進入 WORKING。任務可以從 WORKING 暫停在 INPUT_REQUIRED（AI 代理要求補充資訊）或 AUTH_REQUIRED（等待認證），之後都會回到 WORKING。任務最後以四個終止狀態之一結束：COMPLETED、FAILED、CANCELED 或 REJECTED，其中 REJECTED 代表 AI 代理拒絕了任務。進行中SUBMITTED已提交WORKING處理中終止狀態：任務在此結束COMPLETED已完成FAILED失敗CANCELED已取消REJECTEDAI 代理拒絕了任務暫停：會回到 WORKINGINPUT_REQUIREDAI 代理要求補充資訊AUTH_REQUIRED等待認證

狀態名稱省略了 TASK_STATE_ 前綴。四個終止狀態中，只有 REJECTED 代表 AI 代理自己決定拒絕這項工作。

4. 跨組織的認證與信任

跨越組織邊界時，AI 代理之間需要身分驗證與權限協商。MCP 的授權是一套針對 HTTP 傳輸、可選用的 OAuth 2.1 流程，設計前提是客戶端代表資源擁有者去呼叫伺服器。

A2A 則把這些要求放進 Agent Card。securitySchemes 欄位會宣告對方要的是 API 金鑰、HTTP 認證、OAuth 2、OpenID Connect 還是雙向 TLS。呼叫端的 AI 代理在送出第一個請求之前，就已經知道對方組織有哪些要求。

簡單來說

MCP:  「執行這個工具」→ 結果                          （主從關係）
A2A:  「這件事你接得下嗎？」→ 協商 → 同意 → 執行 → 回報  （對等關係）

傳輸方式的選擇：A2A 與 MCP 在 gRPC 上分道揚鑣

兩個協定一開始都是在 HTTP 上跑 JSON-RPC 2.0，並用 SSE 做串流。A2A 在 v0.3 加入了 gRPC 繫結，到了 v1.0 更把 Protocol Buffers 定義訂為正式的資料模型，每一種繫結都必須能完整承載它。MCP 則走了相反的方向。它的 2026 年路線圖寫著「we are not adding more official transports this cycle」（這個週期不再新增官方傳輸方式）。

MCP（2026-07-28）A2A（v1.0）
訊息格式JSON-RPC 2.0Protocol Buffers 資料模型，以 JSON-RPC 2.0、gRPC 或 HTTP+JSON 承載
本機通訊stdio—（以跨組織為前提）
遠端通訊Streamable HTTP：每則訊息是一個 HTTP POST，回應為 JSON 或 SSE 串流HTTP 上的 JSON-RPC、HTTP+JSON（REST）或 gRPC
gRPC不是官方傳輸方式。SEP-1352 仍在提案階段，只能當成自訂傳輸使用自 v0.3 起為可選繫結

MCP 路線圖明白表示，把傳輸方式維持在少數幾種，是基於設計原則刻意做出的決定；這個週期的重心則放在讓伺服器不必保存狀態也能水平擴充。

為什麼 gRPC 不是跨組織通訊的預設選項

A2A 的主戰場是跨組織通訊。它的前提和內網 LAN 上的微服務通訊不一樣。

技術不是預設選項的理由
gRPC無法從瀏覽器直接呼叫。與防火牆和代理伺服器的相容性不如 HTTP
WebSocket容易被企業代理伺服器切斷。長連線會消耗伺服器資源。在負載平衡器上的路由很複雜。斷線後還要處理重新連線

A2A v1.0 公開了一份正式的 a2a.proto，兩個組織不必再自行協調 proto 定義。不過 gRPC 在網路層面的問題依然存在。

A2A 如何保留 HTTP，同時提供 gRPC

Agent Card 會在 supportedInterfaces 裡列出 AI 代理支援的每一種繫結。每個項目都寫明 protocolBinding（JSONRPC、GRPC 或 HTTP+JSON）與 URL。雙方都支援時，客戶端就用 gRPC，其他情況則走 HTTP。

HTTP 的優點說明
基礎設施相容性企業的防火牆、代理伺服器與負載平衡器早就是照著 HTTP 建起來的
生態系OAuth 認證、速率限制、稽核日誌、API Gateway 等成熟工具可以直接沿用
可發現性Agent Card 可以用 HTTP GET 從 /.well-known/agent-card.json 取得
可擴充性無狀態，每個請求自我完備。容易水平擴充
串流SSE 能做到即時通知，而且可以穿過代理伺服器

設計上的最高優先事項是把跨組織的互通性最大化，而 HTTP 是達成這個目的摩擦最小的選擇。不論後面用哪一種繫結，Agent Card 本身都是透過 HTTP 取得。

在單一組織內部、雙方都掌控網路的情況下，AI 代理可以在 JSON-RPC 之外一併公開 gRPC，讓支援它的客戶端走更快的路徑。

總結

面向MCPA2A
角色AI 代理存取工具/資料AI 代理之間通訊與協商
關係主從（client → server）對等（雙向），而且可以拒絕任務
傳輸Streamable HTTP / stdio；gRPC 只能當成自訂傳輸JSON-RPC、HTTP+JSON 或 gRPC，列在 Agent Card 中
能力發現工具綱要（輸入/輸出型別）Agent Card（/.well-known/agent-card.json）
訊息格式JSON-RPC 2.0Protocol Buffers 資料模型；JSON-RPC 繫結使用 JSON-RPC 2.0
長時間工作需要主動啟用的 Tasks 擴充功能任務生命週期內建於核心協定
  • MCP 與 A2A 是互補而非競爭關係。如果 MCP 是 AI 代理的「手和眼」，A2A 就是它的「嘴」
  • AI 代理不是工具。正因為它會自主判斷，才需要一套有別於工具協定（MCP）的 AI 代理協定（A2A）
  • HTTP 是確保相容性的基礎，A2A 則為了速度另外提供 gRPC 作為選項。MCP 則沒有把 gRPC 列為官方傳輸方式

設計多 AI 代理系統時，把「每個 AI 代理用 MCP 接哪些工具」和「哪些 AI 代理之間用 A2A 整合」分開來想，是很重要的。

參考連結

分享這篇文章

更多

更多