智能体协议碎片化：为 A2A、MCP 及未来设计

大多数团队在选择智能体协议时，实际上同时做了三个不同的决策——把它们混为一谈，正是为什么许多集成一旦引入第二个框架就会崩溃的原因。

这三个决策分别是：智能体如何与工具和数据交互（纵向集成）、智能体如何与其他智能体协作（横向协调），以及智能体如何向人机界面暴露状态（交互层）。Google 的 A2A、Anthropic 的 MCP 和基于 OpenAPI 的 REST 解决的是这个栈的不同层次。当工程师混淆它们时，要么用多智能体机制过度设计单智能体场景，要么用单智能体工具欠设计多智能体工作流。两种失败在生产环境中重构代价都极高。

协议实际解决的三个层次

在比较协议之前，你需要对智能体接口栈有一个清晰的认知模型。

工具集成层是智能体向外连接数据库、API 和外部服务的地方。这是 MCP 的领域。智能体需要读取向量存储、调用天气 API 或调用代码解释器——MCP 定义了这种客户端-服务器契约。其架构本质上是纵向的：一个智能体，多个工具。

智能体协调层是智能体横向连接其他智能体的地方。这是 A2A 的领域。一个规划智能体将任务分派给专门的代码编写智能体或文档摘要智能体，跟踪任务生命周期并收集结果。其架构本质上是横向的：多个智能体，对等关系。

交互层是智能体向用户界面暴露状态的地方——流式传输中间结果、渲染结构化组件、处理来回澄清。这是 AG-UI 等新兴项目的领域，标准化工作仍处于早期阶段。

对正在解决的问题产生混淆，会让你走上错误的协议路径。把 A2A 当作 MCP 替代品的工程师，最终会为本质上是单智能体工具调用的问题编写智能体协调代码。

MCP 真正优化的是什么

MCP 由 Anthropic 于 2024 年 11 月发布，到 2026 年初月 SDK 下载量达到 9700 万——这个数字说明了生态系统多么需要一个工具集成标准。

MCP 的核心赌注是：工具访问控制比智能体身份更重要。其信任模型是集中式的：宿主应用（运行 LLM 的东西）是权威。当智能体要调用工具时，宿主负责中介该调用、执行用户同意并控制服务器可访问的数据。服务器只在宿主授权的范围内被信任。

这种设计对单智能体场景非常有效——读取文件并执行 shell 命令的编码助手、查询 CRM 的客服机器人。当多个智能体需要共享工具服务器时效果较差，因为信任模型无法干净地处理"哪个智能体的权限适用"这个问题。一些团队通过每个智能体独立的服务器实例来绕过这个问题，功能上可行但运营成本较高。

MCP 的传输栈（JSON-RPC 2.0 over stdio、HTTP 或 SSE）有意保持简单。2025 年 11 月的规范更新增加了异步操作和无状态服务器支持，将其触达范围扩展到更高延迟的工具后端。权衡是 MCP 没有任务生命周期的概念——它处理离散调用，而非长时间运行的委托工作。

A2A 真正优化的是什么

Google 于 2025 年 4 月发布 A2A，拥有 50 多家合作伙伴组织，并于 2026 年初发布 v1.0，现在由 Linux 基金会旗下的 Agentic AI Foundation 与 MCP 共同治理。

A2A 的核心赌注是：智能体身份比工具访问控制更重要。其信任模型是分布式的：智能体通过基于 JSON 的"智能体卡"公告其能力，协商支持的协议，并在无需依赖中央宿主的情况下相互认证。这是点对点身份，而非客户端-服务器授权。

A2A 专为无法查看对方内部的场景设计。当你的规划智能体向另一家公司的第三方智能体分派任务时，你不知道该智能体运行在什么框架上、有哪些工具或如何在内部处理错误。A2A 专门处理这种不透明性——它规定任务生命周期状态（已提交、处理中、已完成、失败）、能力发现和用户体验协商，所有这些都不需要远程智能体暴露内部实现。

IBM 于 2025 年 3 月发布了一个名为 ACP 的竞争性 REST 协议，并于 2025 年 8 月在 Linux 基金会下合并入 A2A。这次合并值得关注，因为它表明行业正在向 A2A 作为横向协调层的标准答案收敛——2025 年初看似不可避免的协议层碎片化并没有在规范层面出现。

OpenAPI：早于两者的通用语言

OpenAPI（现已更新至 v3.2.0）并非为智能体设计，但它以 A2A 和 MCP 都未曾预料到的方式成为协议栈的重要基础设施。

MCP 服务器实现频繁使用 OpenAPI 规范来描述可用工具。A2A 智能体卡引用 OpenAPI 安全方案进行认证。智能体通过在运行时解析 OpenAPI 规范来发现和调用能力——规范成为自然语言推理与结构化软件之间的接口契约。

实际含义是：如果你正在构建一个要向智能体暴露的工具服务器，编写准确的 OpenAPI 规范不是可选项。它是 MCP 和 A2A 都能消费的最低公分母描述层。编写粗糙的 OpenAPI 规范——模糊的描述、缺少参数文档、不一致的错误方案——会直接转化为极难诊断的智能体失败模式，因为失败看起来像模型困惑而非文档腐化。

可移植性与能力之间的权衡

这是协议无关设计必须解决的架构张力：智能体接口越中立于协议，你越会放弃框架特定能力，而这些能力本可以显著提升你的智能体能力。

LangGraph 的流式检查点、CrewAI 的角色分配原语、Semantic Kernel 的规划器抽象——这些都无法通过 A2A 或 MCP 表达。如果你需要它们，就必须编写框架特定代码。问题在于可移植性收益是否值得能力代价。

答案取决于你的部署拓扑：

• 单一框架，内部部署：可移植性不值得能力代价。使用框架的原生原语。采用 MCP 进行工具集成，因为 ROI 高而能力代价低。

• 多框架，内部部署：广泛采用 MCP。在运行不同框架的团队边界考虑 A2A。不要试图让一切都协议无关——只需让交接点如此。

• 跨组织部署：A2A 在集成边界是必要的。你的内部实现可以使用任何框架。协议无关要求适用于你向合作伙伴暴露的表面，而非整个栈。

• 受监管行业：两种协议现在都在 Linux 基金会治理下，这对采购和合规很重要。这显著降低了支持一个被放弃的协议的风险。

最糟糕的模式是围绕协议无关接口设计整个内部智能体架构——将 A2A 视为内部设计模式而非边界协议。这产生了最大的可移植性开销却获得最小的可移植性收益，因为内部代码在切换框架时总是可以重构的。

今天如何设计你的智能体接口层

从生产部署中涌现的实践架构是将协议分层而非在它们之间选择。

在工具层：为智能体需要的每个外部数据源和 API 部署 MCP 服务器。MCP 具有最广泛的支持——到 2026 年初，每个主要 AI 提供商（Anthropic、OpenAI、Google、Microsoft、Amazon）都采用了它，Claude 目录中的 75+ 官方连接器意味着你通常从可用代码开始而非从头构建。设计带有干净 OpenAPI 规范和明确同意边界的 MCP 服务器。

在协调层：只有当你有至少两个需要协作的独立智能体时才引入 A2A，尤其是跨组织或框架边界时。A2A 在单智能体或紧耦合多智能体场景中的开销是真实存在的——智能体卡增加了直接函数调用所没有的发现复杂性。交叉点通常是当你需要将任务委托给你不拥有的智能体，或者任务生命周期跟踪成为可靠性要求时。

在接口边界：将协议视为契约规范而非实现框架。你的内部智能体代码可以使用任何给你最佳能力的框架。协议定义你暴露的表面。当你升级内部实现时，协议表面不必改变。

关于流式传输：MCP 和 A2A 都支持 SSE 进行流式传输。如果你构建任何需要向用户展示增量进度的东西，从一开始就设计你的协议表面以支持流式传输。将流式传输改装到同步协议表面上非常痛苦。

接下来会发生什么

2025 年 12 月 Agentic AI Foundation（AAIF）在 Linux 基金会下成立——由 Anthropic、OpenAI 和 Block 共同创立，Google、Microsoft、AWS、Cloudflare 和 Bloomberg 作为铂金会员——这表明协议碎片化问题在规范层面已基本解决。行业在 A2A 和 MCP 上的收敛速度比大多数人预测的更快。

剩余的碎片化在实现层。两个都声称支持 MCP 的系统可能实现了规范的不同子集，以不同方式处理错误，具有不一致的能力协商行为，并以只在负载下才会暴露的方式无法互操作。规范是稳定的；实现不是。这是 2026 年大多数实际协议痛点所在，也是工程工作的重心。

新兴的 AG-UI 项目标准化了智能体如何向用户界面传达状态，是最可能出现新规范工作的领域。如果 MCP 处理纵向工具集成，A2A 处理横向智能体协调，AG-UI 处理第三层——人类如何与运行中的智能体保持同步。该层还没有稳定的标准，这个缺失在每个拥有用户的生产智能体部署中都是显而易见的。

协议无关设计值得投资于你向外部世界暴露的接口边界。对于内部的一切，使用让你的智能体最有能力的框架——并将协议视为使其可移植的翻译层。