架構

MCP + A2A：每個生產級智慧代理 AI 系統背後的兩個協定

作者：IdeaBosque最後更新：2026年7月21日

關鍵要點

MCP 擁有 10,000+ 個已發布伺服器、9700 萬月度 SDK 下載量和 300+ 個客戶端 — Anthropic 生態系統更新（2025 年 12 月）確認了 OpenAI、Google、Microsoft 和 Cursor 的跨廠商支援。
A2A 在第一年就超過了 150 個組織 — Linux Foundation 公告（2026 年 4 月），在 Google、Microsoft 和 AWS 平台上已有生產部署。
Google 明確將 A2A 定位為 MCP 的補充 — MCP 連接代理與工具；A2A 連接代理與代理。兩者現均在 Linux Foundation 治理下。
23% 的組織擁有活躍的 AI 代理試點 — Capgemini，2026 年。協定問題不再是理論性的；它是一個架構決策。
Stacklok 2026 年調查顯示 41% 的軟體組織在有限或廣泛生產中使用 MCP 伺服器 — 企業級立足點是真實的，而非推測性的。

兩個協定在六個月內相繼發布，重塑了 AI 代理的連接方式。Anthropic 於 2024 年 11 月發布了 Model Context Protocol (MCP)，作為連接 AI 代理與工具和資料的開放標準。Google 於 2025 年 4 月發布了 Agent2Agent Protocol (A2A)，作為連接 AI 代理彼此的開放標準。兩者現均在 Linux Foundation 治理下。兩者均為開源。兩者均被競爭巨頭採用 — OpenAI、Google、Microsoft 和 Anthropic 均支援兩者。

流傳的類比是：MCP 是 AI 的 USB-C。A2A 是代理的 HTTP。本文解釋它們如何在一個生產級智慧代理 AI 系統中協同工作，採用數據說明了生態系統的現狀，以及在 B2B 部署中組合它們的架構模式。

兩層協定堆疊

該圖展示了雙層堆疊：A2A 在頂部（代理間協調），MCP 在中間（代理到工具的存取），外部系統和專用代理在底部。代理透過 A2A 接收任務，透過 A2A 將子任務委派給其他代理，並使用 MCP 呼叫存取 NetSuite、HubSpot、BigCommerce 或任何 10,000+ 個 MCP 伺服器的工具。

MCP：工具存取層

MCP 解決了 M×N 整合問題。在 MCP 之前，每個 AI 模型都需要為它呼叫的每個工具編寫客製化整合程式碼 — M 個模型 × N 個工具 = M×N 個整合。MCP 用 M+N 方案取代了這一點：工具提供商建立 N 個 MCP 伺服器，AI 應用開發者建立 M 個 MCP 客戶端，任何客戶端都可以透過標準化協定呼叫任何伺服器。

採用數據不再是推測性的：

指標	數值	來源
活躍的公開 MCP 伺服器	10,000+	Anthropic 生態系統更新，2025 年 12 月
月度 SDK 下載量	97M+（Python + TypeScript）	Anthropic，2025 年 12 月
MCP 客戶端	300+	多個生態系統追蹤器
GitHub 上 mcp-server 主題的儲存庫	15,926	GitHub Search API，2026 年 5 月 24 日
企業生產（有限或廣泛）	41% 的軟體組織	Stacklok State of MCP 2026 調查
官方註冊表伺服器記錄	9,652	MCP Registry API，2026 年 5 月

MCP 2026 年 7 月 28 日的發布候選版本使協定層變為無狀態 — 移除工作階段握手，引入用於有狀態工作流程的顯式控制代碼，並強制使用 OAuth 2.1 with PKCE。對於 B2B 部署，這意味著沒有黏性工作階段、沒有共享工作階段儲存，以及可在普通輪詢負載均衡器後實現無狀態水平擴展。

A2A：代理協調層

A2A 填補了 MCP 未覆蓋的空白。MCP 連接代理與工具。A2A 連接代理與另一個代理。需要專用能力的代理 — 定價邏輯、目錄搜尋、RFQ 處理 — 可以將工作委派給透過 A2A 端點暴露該能力的遠端代理，將結果作為 A2A 任務接收，並繼續自己的工作流程。

Linux Foundation 公告（2026 年 4 月 9 日）確認了：

150+ 個組織 在第一年支援該標準
生產部署 覆蓋 Google、Microsoft 和 AWS 平台
50+ 個發布合作夥伴，包括 Salesforce、PayPal、Atlassian、Accenture、BCG、Deloitte、McKinsey 和 PwC
深度整合 到 Google Cloud（Vertex AI、Agent Engine、Agent Development Kit）

A2A 定義了三個核心原語：

Agent Card — 位於 /.well-known/agent-card.json 的 JSON 文件，描述代理的身份、能力和端點。這是代理相互發現的方式。
Task — 工作單元，透過 message/send（非串流）或 message/stream（串流）發送。任務透過狀態轉換：submitted、working、input-required、completed、failed、canceled。
Artifact — 任務執行期間產生的結構化輸出，在可用時串流傳輸給客戶端。

互補架構

Google 明確將 A2A 定位為 MCP 的補充："A2A 是一個開放協定，補充了 Anthropic 的 MCP。" 這一定位很精確 — 它們在不同層運作：

維度	MCP	A2A
連接對象	代理到工具/資料	代理到代理
方向	縱向（代理向下到系統）	橫向（代理橫向到代理）
發現	工具列表（`tools/list`）	Agent Card（`/.well-known/agent-card.json`）
工作單元	工具呼叫（`tools/call`）	Task（`message/send`、`message/stream`）
輸出	工具結果（JSON）	Artifact（串流、結構化）
傳輸	STDIO、Streamable HTTP	基於 HTTP/SSE 的 JSON-RPC 2.0
認證	OAuth 2.1 + PKCE（7 月 28 日強制）	Agent Card 認證（框架定義）
狀態	無狀態（7 月 28 日 RC）+ 顯式控制代碼	任務生命週期（submitted 到 completed）
支援方	Anthropic	Google
治理	Linux Foundation（Agentic AI Foundation）	Linux Foundation
採用	10,000+ 伺服器，97M 下載量	150+ 組織，50+ 發布合作夥伴

在 B2B 部署中組合它們的架構模式：

專用代理（例如 RFQ 處理代理）透過 A2A Agent Card 暴露其能力。其他代理發現它並向其委派任務。
RFQ 代理使用 MCP 呼叫存取 NetSuite（目錄搜尋、報價建立、可用性預留）、HubSpot（客戶細分查找）和 BigCommerce（產品目錄）的工具。MCP 模組模式提供型別化 schema、速率限制、稽核日誌和用於有狀態工作流程的顯式控制代碼模式。
編排代理 透過 A2A 接收高層任務，透過 A2A 將子任務委派給專用代理，每個專用代理使用 MCP 與底層系統互動。編排器從不直接接觸 NetSuite — 它委派給 RFQ 代理，RFQ 代理再委派給其 MCP 工具。

這是現有的 A2A 橋接文章所展示的模式：如何將框架的原生 API 暴露為 A2A Agent Card。大多數部署中缺失的部分是底層的 MCP 層 — 使工具呼叫安全、可稽核且受治理的型別化模組。

為什麼兩個協定對 B2B 都很重要

僅使用 MCP 的 B2B 部署擁有可以呼叫工具但無法相互協調的代理。每個工作流程都是單代理單體。僅使用 A2A 的部署擁有可以委派任務但無法在沒有為每個工具編寫客製化整合程式碼的情況下存取外部系統的代理。兩個協定都是必需的。

Capgemini 2026 研究報告發現 23% 的組織擁有活躍的 AI 代理試點。Anthropic 2026 State of AI Agents Report 發現 46% 的組織將整合視為第一採用障礙。這兩個協定恰好解決了這一障礙：MCP 標準化工具整合，A2A 標準化代理協調。它們共同將整合負擔從 M×N 個客製化連接減少到 M+N 個標準化連接。

對於構建生產代理系統的中端市場 B2B 公司，協定問題不是「選哪個？」 — 而是「它們如何協同工作？」答案是雙層堆疊：A2A 用於代理間委派，MCP 用於代理到工具的存取，MCP 模組模式作為使工具呼叫安全的受治理層。