MCP vs A2A vs UCP vs AP2 vs A2UI：智能体协议栈详解

AI 智能体协议正在迅速增多：MCP、A2A、UCP、AP2、A2UI 以及相关标准越来越频繁地出现在同一张架构图中。它们常被描述为相互竞争的协议。但在实践中，它们大多是在不同边界上解决不同的互操作性问题。真正有用的问题不是“哪个协议会胜出？”，而是“系统中的哪种关系需要被标准化？”

核心错误：比较位于不同边界的协议

协议之所以有用，是因为两个独立实现的系统需要稳定的契约。只有当边界清晰时，这个契约才有意义。智能体与数据库对话，和智能体将工作委托给另一个智能体、购物者授权购买，或远程智能体请求原生应用渲染表单，所面临的互操作性问题并不相同。

Google 2026 年的开发者指南明确将 MCP、A2A、UCP、AP2、A2UI 及相关 UI 协议呈现为一组互补标准的栈。同一个示例工作流可以同时使用其中多个协议：用工具处理库存，用远程智能体处理供应商，用商业协议处理下单，用支付授权处理支出，用 UI 协议处理交互。

协议责任栈

1. MCP：将智能体连接到能力

模型上下文协议（Model Context Protocol）是一项开放标准，用于将 AI 应用连接到工具、数据和可复用资源所在的外部系统。服务器暴露能力；MCP 主机连接到该服务器，并使这些能力可供模型或应用使用。

当前的 MCP TypeScript v2 文档正是用这些术语描述该协议：服务器暴露工具、资源和提示词，而开发环境或自定义应用等主机连接到它们。这使得 MCP 主要是一种能力集成协议。

在以下情况使用 MCP

• AI 应用需要对工具或 API 的标准化访问。
• 你希望一个能力服务器能够与多个兼容的 AI 主机配合工作。
• 你需要对数据或资源的结构化访问，而不必将每个集成硬编码到每个智能体中。
• 外部系统是能力提供者，而不是自主的对等智能体。

2. A2A：连接独立智能体

Agent2Agent（A2A）专为独立且可能不透明的代理系统之间的通信而设计。其当前的 v1.0 规范侧重于能力发现、消息传递、任务、工件、多模态内容以及长时间运行的协作，而无需一个代理向另一个代理暴露其内部工具、记忆或实现。

这种不透明性正是重要的边界。调用代理无需知道远程代理在内部使用的是 MCP、自定义工具、专有规划器、其他模型供应商还是人工升级。它需要的是一份用于发现能力和委派工作的契约。

A2A v1.0 还标准化了版本协商，并围绕通用数据模型支持多种绑定。其发布的 Agent Card 机制为客户端提供了一个标准发现点，用于了解代理的能力、支持的协议、身份验证要求和技能。

在以下情况下使用 A2A

• 一个自主代理需要将工作委派给另一个自主代理。
• 远程系统应保持不透明，隐藏于能力契约之后。
• 任务可能是长时间运行的、异步的，或需要人工参与交互。
• 代理使用不同的框架、语言、供应商或由不同组织构建。

MCP 与 A2A：垂直集成与水平协作

A2A 项目本身现在将这种区别描述为水平与垂直：MCP 将代理连接到内部工具和数据库，而 A2A 则实现跨代理系统的点对点协作。

3. UCP：标准化代理商务

通用商务协议（Universal Commerce Protocol）不是一种通用代理协议。它标准化了消费者界面、商家和支付提供商之间的商务流程。Google 的实现已经通过版本化配置文件和 API 支持购物车创建、结账、履约和订单生命周期等能力。

商家可以在 /.well-known/ucp 下发布 UCP 配置文件，描述服务、协议版本和能力。这种发现模式很重要，因为代理界面不应为每个商家都需要定制的结账契约。

UCP 也有意设计为可组合的。Google 的技术概述指出，它可以通过 API、A2A 和 MCP 集成，并与 AP2 兼容以实现代理支付授权。

在以下情况下使用 UCP

• 工作流涉及商家产品、购物车、结账、履约或订单生命周期。
• 你正在构建一个应与代理购物体验配合使用的商家界面。
• 集成需要商务特定的语义，而不是通用工具调用。
• 你想要一份可与 MCP、A2A 和支付协议共存的互操作商务契约。

4. AP2：证明代理被允许消费

代理商务引入了一个普通结账流程不必以同样方式解决的问题：代理可能在人类没有实时点击最终按钮的情况下进行交易。代理支付协议（AP2）解决了代理主导支付的授权、真实性和问责问题。

Google 的 2026 协议指南通过类型化授权来描述 AP2，这些授权捕获用户意图、支出约束和正在授权的具体交易。AP2 可以作为扩展与 UCP 一起工作：UCP 描述商务交易，而 AP2 提供代理有权执行支付的证据。

这种区别很重要。结账协议可以告诉商家应该购买什么。但它本身并不能证明谁授权代理消费、在什么限额下、针对哪个商家、持续多长时间，或者最终购物车是否仍在该授权范围内。

UCP 与 AP2：交易语义与授权

5. A2UI：让代理描述界面，而不拥有你的前端

代理到用户界面（A2UI）解决了另一个边界问题：远程或本地代理如何向宿主应用传达丰富的交互界面。A2UI 不发送任意的 HTML、CSS 和 JavaScript，而是使用声明式数据，由宿主通过其自己受信任的组件目录进行渲染。

这保留了宿主应用的设计系统和安全模型，同时仍然允许代理请求动态界面。A2UI v0.9 特别强调框架无关的 UI 意图以及跨 Web、移动端和其他客户端的流式更新。

Google 后来的 A2UI + MCP Apps 工作也表明，这些 UI 模型不一定互斥。声明式原生 UI 和更丰富的嵌入式应用体验可以根据任务共存。

在以下情况使用 A2UI

• 远程代理需要请求表单、卡片、控件或其他交互式 UI。
• 宿主应保留其原生组件、样式和安全边界。
• 你不希望远程代理发布任意可执行的前端代码。
• 同一代理定义的 UI 意图应能在不同的客户端框架中工作。

协议选择测试

不要从缩写开始。从需要互操作的关系开始。

一个现实的多协议工作流

为什么一个通用代理协议不太可能取代所有协议

一个通用协议听起来更简单，直到它必须编码每个领域的语义。工具发现、长时间运行的代理协作、结账、支付授权和原生 UI 都有不同的生命周期、安全和正确性要求。

Web 本身也是通过分层协议演进的，而不是为每个问题使用一种消息格式。新兴的代理堆栈似乎正朝着同一方向发展：通用的水平原语、专门的领域契约以及明确的发现/版本控制。

因此，架构挑战从“哪个协议胜出？”转变为协议如何在不重复身份、授权、状态和审计语义的情况下干净地组合。

协议组合会产生新的故障模式

协议选择不能替代应用架构

开放标准降低了集成耦合，但它们并不决定你的领域模型、授权策略、事实来源、重试策略或验收标准。MCP 工具仍可能暴露错误的能力。A2A 代理仍可能返回糟糕的产物。UCP 结账仍可能包含过期的商家数据。AP2 授权仍可能被应用逻辑误用。

将协议视为独立演进组件之间的契约。将领域事实和重要策略保留在拥有它们的应用层中，然后使用协议使边界可互操作。

什么会改变这个答案？

如果协议趋同、一个标准正式吸收另一个标准，或者供应商跨多个边界标准化共享的身份和授权层，那么技术栈就会改变。UCP 已经通过支持 API、A2A 和 MCP，并与 AP2 集成而非取代它们，展示了组合能力。

答案也会因应用范围而变化。一个小型内部代理可能只需要 MCP。一个多公司工作流可能需要 A2A。一个商家可能需要 UCP 而不需要 A2UI。一个委托采购代理可能需要所有这些。使用能代表真实边界且不压平领域语义的最小协议集。

局限性

这里讨论的协议处于不同的成熟度水平，并具有不同的治理模型。A2A 已达到稳定的 v1.0 规范，而其他标准仍在快速演进。生态系统在不同供应商和框架之间的采用也不均衡。

本文关注架构责任，而非实现完整性。具体的认证方法、传输绑定、模式和扩展机制必须取自每个协议的当前规范。

结论

当把 MCP、A2A、UCP、AP2 和 A2UI 视为面向不同关系的协议，而不是五种试图标准化“代理”的竞争性尝试时，它们就更有意义。

MCP 暴露能力。A2A 协调独立代理。UCP 为商务提供自己的机器可读契约。AP2 增加可验证的支付授权。A2UI 为代理提供进入用户界面的安全声明式路径。因此，新兴的代理式网络并不是用 AI 取代协议；它是在 AI 周围创建新的协议栈。

常见问题

术语表

主要来源与延伸阅读