A2A vs MCP：為代理通訊選擇正確的協定

大多數生產代理系統需要兩個協定，而不是一個。Model Context Protocol (MCP) 讓代理存取工具和資料來源 — NetSuite 記錄、HubSpot 聯絡人、供應商目錄、Redshift 查詢。Agent2Agent Protocol (A2A) 讓代理能夠將工作委託給其他代理 — 報價代理向目錄代理請求替代零件，採購代理請求合規代理驗證 GMP 認證。混淆兩者會導致脆弱的架構：用 A2A 呼叫資料庫，或用 MCP 協調兩個獨立代理，會產生與自身協定設計相衝突的系統。

2026 年 8 月 1 日，OpenAI 確認了 Astra — 其下一個主要模型系列，明確為長時間執行的多代理任務設計，這些任務需要數小時或數天才能完成。一個內部版本解決了數學和理論電腦科學中十個先前未解決的開放問題，總 token 成本約為 $2,000。Astra 在較長時間內協調多個代理，這正是 A2A（代理間委託）和 MCP（代理與工具間存取）必須協同工作的模式。模型層現在正為雙協定模式而建構。

本文是面向在 A2A 和 MCP 之間做選擇的團隊的決策框架 — 或者更常見的是，決定每個協定在多代理系統中放在哪裡。假設你了解每個協定的基礎知識。如果你需要整合指南，A2A Hermes Agent 橋接 和 MCP + A2A 協定堆疊概覽 涵蓋了實作方面。

一句話區分

MCP 連接代理與工具。A2A 連接代理與代理。 MCP 是工具呼叫協定 — 代理請求資源或呼叫函式，伺服器以結構化資料回應。A2A 是任務委託協定 — 代理向另一個代理發送工作單元，接收串流輸出，並透過狀態機追蹤任務。生產模式（在 150+ A2A 組織和 10,000+ MCP 伺服器中確認）是：代理之間用 A2A，代理與工具之間用 MCP。

每個協定的適用位置

維度	MCP	A2A
連接對象	代理 → 工具、資料來源、API	代理 → 代理
工作單元	工具呼叫（請求/回應）	任務（有狀態生命週期）
協定主體	Anthropic（開放規範，2026-07-28 最終版）	Google（開放規範，Linux Foundation，150+ 組織）
傳輸	STDIO、Streamable HTTP（SSE 已棄用，12 個月 Sunset）	JSON-RPC 2.0 over HTTP、SSE 串流
發現	伺服器註冊工具；客戶端發現	/.well-known/agent-card.json 處的 Agent Card
狀態	無狀態（2026-07-28 規範）；狀態存在於客戶端	有狀態任務機：submitted → working → input-required → completed/failed/canceled
串流	工具結果是�一回應	message/stream 用於即時 token 和成品交付
人工介入	不是一等概念	INPUT_REQUIRED 是一等任務狀態
認證	每伺服器；規範中 OAuth 2.1，實踐中 bearer tokens	每代理；Agent Card 宣告認證方案，閘道處理執行
採用	10,000+ 伺服器，4 個 Tier 1 SDK（TypeScript、Python、Go、C#）	150+ 組織，Linux Foundation 治理

該表回答了大多數團隊問的第一個問題：如果你的整合是「代理需要查詢 NetSuite 取得客戶記錄」，那是 MCP。如果你的整合是「採購代理需要定價代理評估三個供應商報價並返回建議」，那是 A2A。區別在於另一端是否有自己的推理能力，還是只是一個回應結構化查詢的資料來源。

決定分工的五個問題

1. 另一端是推理還是回應？

NetSuite MCP 伺服器不會推理。它接收工具呼叫（get_customer、search_items），查詢 API，返回結構化 JSON。呼叫它的代理做推理。A2A 定價代理確實會推理 — 它接收任務（「根據歷史定價和供應商可靠性評估這三份報價」），執行自己的模型推理，可能呼叫自己的 MCP 工具，並返回附帶推理的建議。

如果另一端是資料來源或 API，用 MCP。如果另一端是有自己模型、自己工具和自己決策能力的自主代理，用 A2A。實際測試：你呼叫的東西有自己的 prompt 嗎？如果有，用 A2A。如果沒有，用 MCP。

2. 你需要串流輸出嗎？

MCP 工具呼叫是請求/回應。伺服器處理請求並返回單一結果。沒有中間狀態，沒有逐 token 串流，沒有部分成品。這對於查詢資料庫或取得記錄來說沒問題 — 你要的是完整結果，不是片段流。

A2A 支援 message/stream，在 token 增量和成品產生時交付。一個需要 30 秒評估三份報價的定價代理可以在工作時串流傳輸其推理，這樣呼叫代理（和觀察的人類）可以看到進度、及早發現錯誤，並在推理偏離時取消。如果你的工作流隨時間產生輸出且需要對部分結果採取行動，A2A 是原生支援此功能的協定。

3. 有人工審批門嗎？

MCP 沒有人工介入的一等概念。你可以在呼叫 MCP 工具的代理中建構審批邏輯 — 代理暫停，請求人工，然後繼續 — 但協定本身不編碼這個。審批狀態存在於你的應用程式碼中，不在協定中。

A2A 將 INPUT_REQUIRED 定義為一等任務狀態。當代理達到需要人工批准的決策 — 採購授權、報價審批、資料存取決策 — 它將任務轉換為 INPUT_REQUIRED。呼叫代理（或其背後的人工操作員）看到的是標準協定狀態，不是框架特定的細節。當人工回應時，任務恢復。如果你的工作流包含跨代理邊界的審批門，A2A 透明地傳輸這些門。Hermes Agent A2A 橋接將 Hermes 的原生審批請求對映到 A2A 的 INPUT_REQUIRED 狀態，因此代理委託鏈可以包含人工檢查點，無論每個代理執行在哪個框架上。

4. 工作需要多長時間？

MCP 工具呼叫設計用於短的同步操作 — 查詢 API、取得記錄、執行計算。2026-07-28 規範使 MCP 明確無狀態，意味著伺服器不維護呼叫之間的對話上下文。狀態存在於客戶端（代理）中，不在伺服器中。這對工具來說是正確的設計：NetSuite 伺服器不應該記得你五分鐘前查詢了某個客戶。

A2A 任務設計用於具有顯式生命週期管理的較長時間工作。任務經過 submitted → working → completed（或 failed、canceled、input-required）。狀態機是協定的一部分。需要兩分鐘的定價評估、需要一小時的合規檢查、或需要一天的多代理研究任務 — 這些都適合 A2A 的任務模型。OpenAI 的 Astra 於 8 月 1 日確認，專為需要數小時或數天的任務而建構。Astra 的多代理協調模式直接對映到 A2A 的任務生命週期，而不是 MCP 的無狀態工具呼叫模型。

5. 你在呼叫一個系統還是在協調多個代理？

如果你的代理需要與 NetSuite、HubSpot 和 BigCommerce 通訊，那是三個 MCP 伺服器。每個伺服器暴露工具；代理按需呼叫。代理做協調 — 決定呼叫哪個工具、何時呼叫、以什麼順序。MCP 伺服器之間互不知道。

如果你有一個需要委託給目錄代理、定價代理和合規代理的採購代理 — 每個都有自己的模型和工具 — 那是三個 A2A 端點。採購代理發送任務，接收串流結果，協調委託鏈。目錄、定價和合規代理可能各自使用 MCP 存取自己的資料來源。兩個協定在不同層運作：A2A 處理代理間委託，MCP 處理每個代理內的代理與工具間存取。

何時同時使用兩者：生產模式

生產模式（由 tyk.io 企業指南確認，在 150+ A2A 組織中可見）是雙層架構：

每個專用代理是一個 A2A 端點（暴露 Agent Card，接受任務，串流傳輸結果）。每個專用代理也使用 MCP 連接自己的資料來源。編排代理永遠不直接與 NetSuite 通訊 — 它委託給定價代理，定價代理使用 MCP 查詢 NetSuite。這種分離使每個代理的工具表面受治理且可稽核，而 A2A 層處理代理間協調。

Hermes Agent A2A 橋接參考實作演示了這種模式：閘道處理 A2A 協定表面（Agent Card、JSON-RPC 分發、SSE 串流傳輸、任務狀態機），可插拔的 handler 將 A2A 任務語意轉換為每個框架的原生 API。新增新的代理框架意味著編寫一個 handler 類別 — 協定、閘道和狀態機是共享基礎設施。同一個閘道可以路由到 Hermes Agent、OpenClaw 或任何未來的 handler，而無需更改 A2A 客戶端表面。

何時單代理足夠

並非每個系統都需要 A2A。Princeton NLP 研究發現，單個代理在 64% 的基準測試任務上匹配或優於多代理系統 — 多代理配置成本為 2 倍。如果你的工作流是單個代理查詢 NetSuite、起草報價並提交審批，你需要 MCP（用於 NetSuite 連接）和應用級審批門。你不需要 A2A。

當你有具有不同模型、不同工具表面或不同所有權邊界且需要協調的代理時，A2A 變得必要。採購團隊的採購代理和財務團隊的合規代理由不同群組擁有，可能執行在不同基礎設施上，有不同的模型選擇。A2A 給它們一個協定來委託和追蹤工作，而不需要共享程式碼庫或部署。如果你所有的代理都是同一模型在同一基礎設施上由同一所有者執行，單個代理配 MCP 工具更簡單且更便宜。

MCP 2026-07-28 規範最終版：對此決策的改變

MCP 規範於 2026 年 7 月 28 日發布為最終版。所有四個 Tier 1 SDK（TypeScript、Python、Go、C#）支援 2026-07-28。規範使 MCP 明確無狀態 — 伺服器不維護呼叫之間的工作階段狀態。12 個月的 SSE 棄用政策已啟動：Streamable HTTP 傳輸替代 SSE，現有 SSE 部署需在 2027 年 7 月前遷移。

對於 A2A 與 MCP 的決策，規範最終版確認了分層：MCP 是無狀態工具協定。如果你在使用 MCP 工作階段來維護代理對話狀態，規範說要停止 — 狀態屬於代理（MCP 客戶端），不屬於伺服器。這使 A2A 層更加明確地必要：代理間長時間執行的、有狀態的協調不是 MCP 設計要承載的。A2A 的任務狀態機填補了這一空白。

關於傳輸重疊的說明

兩個協定都使用 HTTP 和 SSE，這可能引起它們是否競爭的困惑。它們不競爭 — 傳輸重疊是表面的。MCP 使用 HTTP 進行工具呼叫（請求 → 回應），正在從 SSE 遷移到 Streamable HTTP 進行伺服器發起的通知。A2A 使用 JSON-RPC 2.0 over HTTP 進行任務分發，使用 SSE 進行串流任務輸出。傳輸是管道設施；協定語意是不同的。MCP 傳輸工具呼叫。A2A 傳輸任務生命週期。你可以在同一個閘道上執行兩者 — 參考實作正是這樣做的，閘道為兩個協定處理 HTTP 和 SSE，而橋接層轉換為每個框架的原生 API。

這對你的架構意味著什麼

如果你在建構 B2B 代理系統 — RFQ 自動化、採購工作流、帶知識圖譜的客戶支援、資料管道編排 — 協定決策遵循工作流形狀：

• 一個代理，多個資料來源 → 僅 MCP。代理使用 MCP 模組連接 NetSuite、HubSpot、BigCommerce 和供應商目錄。不需要 A2A。
• 多個代理，同一所有者，同一基礎設施 → MCP 用於工具，應用級協調用於代理間工作。如果協調邏輯變得足夠複雜以至於協定級狀態機會簡化它，考慮 A2A。
• 多個代理，不同所有者或不同基礎設施 → A2A 用於代理間委託，MCP 用於每個代理的工具存取。這是分散式代理系統的生產模式。
• 帶人工審批門的長時間執行任務 → A2A 用於任務生命週期和 INPUT_REQUIRED 狀態，MCP 用於每個任務內的工具呼叫。審批門作為 A2A 狀態轉換跨代理邊界，而不是作為自訂應用程式碼。

OpenAI 在 8 月 1 日確認 Astra 使長時間執行的多代理模式成為前沿模型設計方向。Astra 專為需要數小時或數天工作的任務而建構，在較長時間內協調多個代理。支援這種模式的協定堆疊是 A2A 用於協調和 MCP 用於工具存取 — 本文描述的雙協定架構。

---

一個中型經銷商需要一個報價代理與目錄代理通訊，目錄代理與合規代理通訊 — 每個由不同模型支援，每個由不同團隊擁有，每個透過 MCP 模組連接不同系統。A2A 給這些代理一個共享協定用於委託和串流傳輸。MCP 給每個代理對其資料來源的受治理存取。橋接模式讓 Hermes Agent、OpenClaw 和任何其他框架參與 A2A 網路而無需重寫其內部實作。

請求一個範圍確定的建構

一週的探索。你獲得系統清單、工作流圖和固定範圍 — 無論你是否與我們合作。