架构

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 模块模式作为使工具调用安全的受治理层。