MCP、A2A、AG-UI：一篇讲清 Agent 协议栈

项目背景

随着 Agent 从单一聊天窗口走向企业系统，它需要读取数据库、调用业务 API、与其他 Agent 协作、向用户展示执行进度，并在交易与授权场景中保留人工控制权。

如果各家厂商各自定义连接方式，团队就要重复维护大量适配器。因此，2026 年的 Agent 技术栈涌现出一组快速演进的协议：MCP、A2A、AG-UI、A2UI、UCP、AP2 等。

Google 开发者指南已将这批协议放进同一条业务流程中解释，说明行业重心正从「单个模型如何回答」转向「多个系统如何协作」。

需要强调的是：协议能降低集成成本，却不会自动解决身份、权限、语义一致性与业务可靠性问题。 理解每一层协议解决什么、不解决什么，是架构设计的起点。

技术方案

1. 从通信对象理解协议

不同协议解决不同通信关系，先看一张总览：

• Agent 与工具/数据：能使用什么能力，参数和结果是什么 → MCP
• Agent 与 Agent：如何发现、委派、更新状态和返回产物 → A2A
• Agent 与前端：如何把进度、事件、人工输入传给界面 → AG-UI
• Agent 与动态界面：如何描述可渲染的生成式 UI → A2UI
• Agent 与商业系统：如何表达商品、购物和交易流程 → UCP
• Agent 与支付授权：如何建立可验证的支付委托 → AP2

这些层次可以自由组合。例如，一个采购 Agent 可以通过 MCP 查询库存，通过 A2A 委派供应商 Agent，通过 AG-UI 在界面显示过程，通过 UCP 表达商品流程，并在 AP2 定义的授权边界下完成支付。

2. MCP：把工具和上下文暴露给 Agent

Model Context Protocol 的目标，是用统一方式连接 AI 应用与外部系统。MCP Server 提供工具、资源和提示模板，MCP Client 负责发现和调用。

适合 MCP 的场景：

• 查询数据库、知识库和文件；
• 调用 GitHub、工单、监控和设计工具；
• 暴露内部业务 API；
• 将结构化资源提供给多个 AI 客户端；
• 减少为每个模型平台单独开发连接器。

使用 MCP 前必须审查：

• 发布者与代码来源是否可信；
• Server 能读取与修改什么数据；
• 身份如何传递、是否支持最小权限；
• 是否会将数据发往第三方；
• 参数和输出是否经过校验；
• 日志是否包含敏感数据；
• 是否有撤销机制。

MCP 不负责决定业务目标，也不自动保证服务器可信。安装一个 MCP Server，相当于给 Agent 增加新的数据源和操作能力，安全审查必不可少。

目前 MCP 已形成庞大生态并被多个主流平台采用；进入 Linux Foundation 旗下 Agentic AI Foundation 后，治理也更趋中立。

3. A2A：让独立 Agent 互相委派

Agent2Agent 协议解决不同 Agent 之间的协作。一个 Agent 可以发现另一个 Agent 的能力、发送任务、接收进度和最终产物，无需了解对方内部模型、框架和工具实现。

A2A 适合组织边界或职责边界清晰的系统，例如：

• 总控 Agent 委派研究、法务和财务 Agent；
• 采购方 Agent 与供应商 Agent 协商；
• 客服 Agent 将技术问题升级到运维 Agent；
• 企业内部平台调用外部专业 Agent；
• 不同团队维护的 Agent 在统一任务中协作。

但「能够通信」不等于「能够互相信任」。A2A 系统必须定义身份、任务授权、数据最小化、状态语义、超时、取消、责任与审计，尤其要避免低权限 Agent 借助高权限 Agent 完成越权操作。

4. AG-UI：把 Agent 运行过程带到用户界面

传统聊天接口只显示消息，而长任务需要展示计划、步骤、工具状态、等待批准、阶段产物和错误。AG-UI 类协议提供 Agent 后端与前端之间的事件流，使界面实时反映运行过程，并把人的反馈送回任务。

适用场景：

• 长任务进度面板；
• 需要暂停、继续和取消的工作流；
• 人工审批与表单补充；
• 流式文本、工具状态和中间产物；
• 多 Agent 的任务树和错误展示。

注意：界面不能只是「进度动画」。 真实状态必须来自执行系统；如果后端已经失败，前端不应继续显示「正在思考」。每个状态需要稳定语义和可恢复标识。

5. A2UI：让 Agent 描述可渲染界面

A2UI 关注 Agent 如何用结构化描述生成界面，而不是输出任意 HTML。宿主应用根据允许的组件、数据和动作进行渲染，可以获得更一致的品牌、安全和可访问性。

适合场景： 动态表单、结果卡片、审批界面和面向任务的临时工具。

关键安全原则：

• 只允许受控组件集合；
• 数据与动作分离；
• 不执行模型生成的任意脚本；
• 高风险操作有明确确认；
• 所有字段遵循宿主权限；
• 生成界面也要满足可访问性。

6. UCP 与 AP2：Agent 进入商业和支付

当 Agent 代表用户寻找商品、比较选项和准备交易时，需要统一表达商品、商家、订单和授权。UCP 聚焦商业交互，AP2 聚焦 Agent 支付中的可验证授权与责任链。

支付协议不能被理解为「让 Agent 自动花钱」。 成熟设计需要：

• 用户明确意图和金额边界；
• 商品、商家和最终价格可见；
• 一次性与持续授权区分；
• 支付凭证与对话隔离；
• 风险控制和强认证；
• 完整审计与争议处理；
• 撤销、退款和失败恢复。

这些协议仍在快速演进，产品名称和支持范围应以最新规范为准，不要把预览能力当作唯一生产控制。

系统架构

端到端案例：餐厅供应链 Agent

用户提出需求：

「为下周活动补充食材，预算不超过两万元，优先现有供应商，任何新供应商和最终付款都要我批准。」

完整流程如下：

1. 总控 Agent 通过 MCP 查询库存、菜单和历史采购；
2. 通过 A2A 委派供应商发现 Agent，获取候选报价；
3. 价格、交付时间和风险以结构化结果返回；
4. AG-UI 将比较表、缺口和异常展示给用户；
5. A2UI 生成受控的供应商选择与数量调整界面；
6. UCP 表达商品、商家和订单草案；
7. 新供应商触发人工审批；
8. 最终金额与原预算比较；
9. AP2 相关授权机制确认支付意图；
10. 结果写回采购系统并保存审计记录。

这个例子说明：协议负责连接和表达，业务系统仍要负责预算、供应商政策、权限和账务一致性。

实施过程

协议选型的六个问题

1. 双方是什么关系？

• Agent 调工具 → 优先考虑 MCP；
• 独立 Agent 委派 → 考虑 A2A；
• 后端与界面事件 → 考虑 AG-UI。

2. 谁拥有身份？

使用用户身份、服务身份还是 Agent 身份？是否允许代表用户继续委派？

3. 数据经过哪里？

协议标准化格式，不代表数据不会离开组织。需要核对部署、日志和第三方处理。

4. 是否有副作用？

只读查询与写入、发送、交易需要不同的审批和审计。

5. 如何失败和恢复？

是否支持超时、取消、幂等、进度和结果重取？

6. 是否真的需要协议？

单一应用内部的简单函数调用不一定需要复杂协议。协议在跨工具、跨团队和跨厂商时价值最大。

协议不能替代语义契约

两个系统都「支持 MCP」并不代表对字段、错误和权限有相同理解。团队仍然需要：

• 明确输入输出 Schema；
• 定义错误码和重试语义；
• 版本兼容和弃用政策；
• 定义业务不变量；
• 测试夹具与契约测试；
• 速率和资源限制；
• 审计、追踪和数据保留规则。

协议解决连接方式，契约决定连接之后能否可靠合作。

常见误区

误区一：把所有集成都叫 MCP

工具调用、Agent 委派、界面事件和支付授权是不同问题，不能用一套协议包打天下。

误区二：认为标准协议天然安全

协议无法替你选择可信服务器，也不能自动阻止越权和数据外送。

误区三：一开始就构建多 Agent 网络

如果一个 Agent 加几个可靠工具可以完成任务，多 Agent 只会增加状态和故障点。

误区四：忽略取消与幂等

长任务断线重试时，可能重复订单、消息和付款。

误区五：让模型生成任意 UI 和代码

生成式界面应由受控组件渲染，不能直接执行不可信脚本。

架构检查清单

• ✅ 已明确每条连接是工具、Agent、界面还是交易关系；
• ✅ 协议选择与通信边界匹配；
• ✅ 身份、授权和再委派规则清楚；
• ✅ 每个 Server 或 Agent 的来源经过审查；
• ✅ 数据路径、外送和保留政策可解释；
• ✅ 只读与写入能力分离；
• ✅ 高风险动作需要人工确认；
• ✅ 输入输出使用结构化 Schema；
• ✅ 超时、取消、幂等和恢复已经设计；
• ✅ 有契约测试和版本策略；
• ✅ 前端状态来自真实执行事件；
• ✅ 支付凭据不进入普通对话上下文；
• ✅ 简单场景没有为了追逐协议而过度设计。

应用价值

Agent 协议栈的价值，是让模型、工具、其他 Agent、界面和商业系统能够在明确边界内协作。最重要的不是记住所有缩写，而是识别当前连接的两端是谁、交换的是什么、谁有权限、失败怎样处理。

MCP、A2A 和 AG-UI 等协议会继续演进，但可靠系统的基本原则不会变化：最小权限、结构化契约、可观察状态、人工控制和可恢复执行。

协议让连接更容易，治理决定连接是否值得信任。

SEO关键词

MCP, A2A, AG-UI, Agent协议, Agent互操作, UCP, AP2, A2UI, 智能体协议栈