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

> 從對等性、Agent Card 能力發現與非同步任務管理，說明 MCP 單獨為何不足以支撐智能體間通訊，並解析兩個協定為何都選擇 HTTP 作為基礎。

- Source: https://oharu121.com/zh-tw/blog/a2a-mcp-complementary-agent-protocol-design/
- Published: 2026-07-13T12:00:00+09:00
- Tags: MCP, AI 智能體, 生成式 AI

---
## 引言

「我想讓智能體彼此協作，用 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 是智能體的「嘴」**（與其他智能體對話與協商）。

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

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

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

1. **庫存智能體**透過 MCP 查詢庫存資料庫，判斷出「商品 X 只剩 10 個，需要補貨」
2. 庫存智能體**透過 A2A 向配送智能體提出請求**：「商品 X 500 個送到 A 倉庫，明天可以到嗎？」
3. **配送智能體**透過 MCP 呼叫 GPS API 與路線最佳化工具，確認有沒有空檔
4. 配送智能體**透過 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 整合」分開來想，是很重要的。