A2A vs MCP：为智能体通信选择正确的协议

大多数生产智能体系统需要两个协议，而不是一个。Model Context Protocol (MCP) 让智能体访问工具和数据源 — NetSuite 记录、HubSpot 联系人、供应商目录、Redshift 查询。Agent2Agent Protocol (A2A) 让智能体能够将工作委托给其他智能体 — 报价智能体向目录智能体请求替代零件，采购智能体请求合规智能体验证 GMP 认证。混淆两者会导致脆弱的架构：用 A2A 调用数据库，或用 MCP 协调两个独立智能体，会产生与自身协议设计相冲突的系统。

2026 年 8 月 1 日，OpenAI 确认了 Astra — 其下一个主要模型系列，明确为长时间运行的多智能体任务设计，这些任务需要数小时或数天才能完成。一个内部版本解决了数学和理论计算机科学中十个 previously 未解决的开放问题，总 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 网络而无需重写其内部实现。

请求一个范围确定的构建

一周的发现。你获得系统清单、工作流图和固定范围 — 无论你是否与我们合作。