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

随着 Agent 从单一聊天窗口走向企业系统，MCP、A2A、AG-UI、A2UI、UCP、AP2 等协议构成了 2026 年的 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

用户提出需求：

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

完整流程如下：

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

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

实施过程

协议选型的六个问题

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, 智能体协议栈