A2A 與 MCP 差在哪裡？智能體間通訊為何需要獨立協定，兩者又為何都不選 gRPC

引言

「我想讓智能體彼此協作，用 MCP 接起來不就好了嗎？」

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

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

為什麼需要兩個協定、MCP 到底缺了什麼、以及為什麼兩者都選 HTTP 當基礎，本文會依序把這幾個問題拆開來看。

A2A 與 MCP 各自的守備範圍

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

	MCP	A2A
全名	Model Context Protocol	Agent-to-Agent Protocol
負責領域	智能體 ↔ 工具/資料來源	智能體 ↔ 智能體
關係	客戶端-伺服器（主從）	對等、雙向
典型操作	`tools/call`, `resources/read`	`tasks/send`, `tasks/get`
提出者	Anthropic	Google

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

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

跨組織的智能體整合，看起來會是這個樣子。

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

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

工具操作（MCP）與智能體之間的協商（A2A），角色分得很清楚。

為什麼光靠 MCP 不足以支撐智能體間通訊

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

1. 沒有對等性

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

MCP:  智能體(client) → 對方智能體(server，當成工具)
A2A:  智能體 ←→ 智能體（對等）

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

2. 沒有能力發現機制

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

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

3. 非同步任務管理

MCP 基本上是同步的請求-回應協定。它不適合管理「配送安排中，三小時後確認」這種長時間任務的狀態。

A2A 內建任務狀態轉換（submitted → working → input-required → completed / failed），並且能透過 SSE 或推播通知把進度推出去。input-required 是智能體為了繼續處理而要求補充資訊的狀態。

4. 跨組織的認證與信任

跨越組織邊界時，智能體之間需要身分驗證與權限協商。MCP 並未預期這類跨組織認證。

簡單來說

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

傳輸層的設計選擇：為什麼是 HTTP

有意思的是，MCP 與 A2A 在傳輸層做了相似的選擇。

	MCP	A2A
訊息格式	JSON-RPC 2.0	JSON-RPC 2.0
本機通訊	stdio	—（以跨組織為前提）
遠端通訊	Streamable HTTP（舊稱 HTTP + SSE）	HTTP + SSE
gRPC	不採用	不採用

兩者都沒有採用 gRPC。明明有 gRPC 這種高速的二進位通訊可用，為什麼選 HTTP 與 JSON？

為什麼沒選 gRPC 與 WebSocket

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

技術	不採用的理由
gRPC	無法從瀏覽器直接呼叫。跨組織共用 proto 定義很麻煩。與防火牆和代理伺服器的相容性不如 HTTP
WebSocket	容易被企業代理伺服器切斷。長連線會消耗伺服器資源。在負載平衡器上的路由很複雜。斷線後還要處理重新連線

為什麼選了 HTTP + SSE

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

設計上的最高優先事項是把跨組織的互通性最大化，而 HTTP 是達成這個目的摩擦最小的選擇。

話說回來，如果是單一組織內部的即時智能體通訊，gRPC 或 WebSocket 反而可能更合適。協定的選擇還是看使用情境。

總結

面向	MCP	A2A
角色	智能體存取工具/資料	智能體之間通訊與協商
關係	主從（client → server）	對等（雙向）
傳輸	Streamable HTTP / stdio	HTTP + SSE
能力發現	工具綱要（輸入/輸出型別）	Agent Card（`/.well-known/agent.json`）
訊息格式	JSON-RPC 2.0	JSON-RPC 2.0

MCP 與 A2A 是互補而非競爭關係。如果 MCP 是智能體的「手和眼」，A2A 就是它的「嘴」
智能體不是工具。正因為它會自主判斷，才需要一套有別於工具協定（MCP）的智能體協定（A2A）
選擇 HTTP 是為了相容性，不是為了速度。在跨組織這個使用情境下，這是把既有基礎設施摩擦降到最低的設計判斷

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

引言