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

文章目录

• [1 -> 引言](#1 -> 引言)
• [2 -> 先从通信对象理解协议](#2 -> 先从通信对象理解协议)
• [3 -> MCP：把工具和上下文暴露给 Agent](#3 -> MCP：把工具和上下文暴露给 Agent)
• [4 -> A2A：让独立 Agent 互相委派](#4 -> A2A：让独立 Agent 互相委派)
• [5 -> AG-UI：把 Agent 运行过程带到用户界面](#5 -> AG-UI：把 Agent 运行过程带到用户界面)
• [6 -> A2UI：让 Agent 描述可渲染界面](#6 -> A2UI：让 Agent 描述可渲染界面)
• [7 -> UCP 与 AP2：Agent 进入商业和支付](#7 -> UCP 与 AP2：Agent 进入商业和支付)
• [8 -> 一个端到端案例：餐厅供应链 Agent](#8 -> 一个端到端案例：餐厅供应链 Agent)
• [9 -> 协议选型的六个问题](#9 -> 协议选型的六个问题)
• • [1. 双方是什么关系](#1. 双方是什么关系)
  • [2. 谁拥有身份](#2. 谁拥有身份)
  • [3. 数据经过哪里](#3. 数据经过哪里)
  • [4. 是否有副作用](#4. 是否有副作用)
  • [5. 如何失败和恢复](#5. 如何失败和恢复)
  • [6. 是否真的需要协议](#6. 是否真的需要协议)
• [10 -> 协议不能替代语义契约](#10 -> 协议不能替代语义契约)
• [11 -> 常见误区](#11 -> 常见误区)
• • [把所有集成都叫 MCP](#把所有集成都叫 MCP)
  • 认为标准协议天然安全
  • [一开始就构建多 Agent 网络](#一开始就构建多 Agent 网络)
  • 忽略取消与幂等
  • [让模型生成任意 UI 和代码](#让模型生成任意 UI 和代码)
• [12 -> 架构检查清单](#12 -> 架构检查清单)
• [13 -> 结语](#13 -> 结语)

---

1 -> 引言

随着 Agent 从单一聊天窗口进入企业系统，它必须读取数据库、调用业务 API、与其他 Agent 协作、向用户展示进度，并在交易与授权时保留控制。不同厂商如果各自定义连接方式，团队会重复维护大量适配器。

因此，2026 年的 Agent 技术栈出现了一组快速发展的协议：MCP、A2A、AG-UI、A2UI、UCP、AP2 等。Google 的开发者指南已经将这些协议放在同一条业务流程中解释，说明行业正在从"单个模型如何回答"转向"多个系统如何协作"。

协议能够降低集成成本，却不会自动解决身份、权限、语义一致性和业务可靠性。理解每一层解决什么，以及它不解决什么，是架构设计的起点。

2 -> 先从通信对象理解协议

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

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

3 -> MCP：把工具和上下文暴露给 Agent

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

适合 MCP 的场景：

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

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

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

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

4 -> A2A：让独立 Agent 互相委派

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

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

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

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

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

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

它适合：

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

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

6 -> A2UI：让 Agent 描述可渲染界面

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

适合动态表单、结果卡片、审批界面和面向任务的临时工具。关键安全原则是：

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

7 -> UCP 与 AP2：Agent 进入商业和支付

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

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

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

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

8 -> 一个端到端案例：餐厅供应链 Agent

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

流程可以是：

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

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

9 -> 协议选型的六个问题

1. 双方是什么关系

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

2. 谁拥有身份

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

3. 数据经过哪里

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

4. 是否有副作用

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

5. 如何失败和恢复

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

6. 是否真的需要协议

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

10 -> 协议不能替代语义契约

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

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

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

11 -> 常见误区

把所有集成都叫 MCP

工具调用、Agent 委派、界面事件和支付授权是不同问题。

认为标准协议天然安全

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

一开始就构建多 Agent 网络

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

忽略取消与幂等

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

让模型生成任意 UI 和代码

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

12 -> 架构检查清单

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

13 -> 结语

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

MCP、A2A 和 AG-UI 等协议会继续演进，但可靠系统的基本原则不会变化：最小权限、结构化契约、可观察状态、人工控制和可恢复执行。协议让连接更容易，治理决定连接是否值得信任。

---

感谢各位大佬支持！！！
互三啦！！！