在 Agent 技术圈，A2UI 和 AG-UI 大概是 2026 年最容易被混淆的两个名字：都指向「智能体与界面」，都来自大厂生态，缩写只差一个字母。但把它们放进架构图就会发现，两者根本不在同一层：一个规定「界面长什么样」，另一个规定「事件怎么流」。理解这一层区别，才能判断自己的项目需要谁、或者两个都要。
一、一句话结论：管道与载荷
AG-UI 是管道，A2UI 是图纸。AG-UI 关心「Agent 发生了什么、事件怎么送到前端」；A2UI 关心「前端应该把界面画成什么样」。一个管传输与状态，一个管结构与渲染。
为了记住这个区别，可以想象寄快递：AG-UI 是快递网络——负责把包裹准时、可追踪地送到目的地；A2UI 是包裹里的图纸与零件清单——告诉收件方该组装成什么。没有快递，图纸送不到；没有图纸，收到的只是一堆无法组装的零件。
二、核心差异对比
| 维度 | A2UI | AG-UI |
|---|---|---|
| 定位 | Agent 驱动的 UI 描述协议（UI 蓝图 / 载荷层） | Agent 与前端的事件交互协议（管道 / 传输层） |
| 主导方 | Google 创建，Apache 2.0 开源，CopilotKit 与社区共建 | CopilotKit 发起并维护的开放协议 |
| 首次发布 | 2025 年 12 月 | 2025 年 5 月 |
| 当前版本 | v0.9.1 生产版本，v1.0 候选版 | 1.0 稳定版（2026 年 9 月 30 日） |
| 核心抽象 | Surface、组件邻接表、数据模型与绑定、动作（Action） | 8 类 31 种类型化事件（运行/文本/工具/推理/状态/活动/子 Agent/自定义） |
| 解决的问题 | Agent 如何安全、跨端地声明可交互界面 | Agent 运行时如何与前端实时、双向通信 |
| 传输方式 | 不绑定传输层，可经 MCP、WebSocket、REST、AG-UI、A2A 等通道 | SSE（主流）、WebSocket、二进制 protobuf |
| 状态模型 | 界面数据结构 + 数据绑定，增量更新数据模型 | 快照 + JSON Patch 增量（STATE_SNAPSHOT / STATE_DELTA） |
| 渲染侧 | Angular、Flutter、Lit、Markdown、Jetpack Compose 等渲染器 | CopilotKit 客户端（React / Angular / Vue / React Native）或自研客户端 |
| 典型场景 | 动态表单、审批看板、Agent 生成的可交互结果页 | 流式对话、工具过程可视化、状态同步、人工审批中断 |
三、为什么容易混淆
混淆通常来自三个地方，厘清之后就不容易再弄错：
- 都解决「Agent 到用户」这一段：但一个是内容层（UI 描述），一个是连接层（事件语义）；
- 命名相近：A2UI 与 A2A（Agent-to-Agent）只差一个字符，前者面向界面，后者面向 Agent 协作；AG-UI 与 A2UI 又都带「A」和「UI」，实际上缩写来源完全不同；
- 生态互相引用：A2UI 官方把 AG-UI 列为标准传输绑定，AG-UI 生态也提供 A2UI 渲染集成——关系太近，反而让人以为是一回事。
四、组合方式：AG-UI 传输，A2UI 渲染
两者不仅不冲突，组合起来才是完整方案。一次完整的交互大致经过六步：
用户输入「帮我准备下季度的采购计划」，前端 SDK 按 AG-UI 规范构建运行输入（RunAgentInput）。
Agent 启动运行，返回 RUN_STARTED；前端进入加载态，准备接收后续事件。
工具调用、步骤进度、状态变更分别以 TOOL_CALL、STEP、STATE_DELTA 等事件流向前端。
Agent 判断需要收集信息，生成 A2UI 的 surface 与组件树，通过事件流中的消息或自定义事件送到前端。
A2UI 渲染器从可信组件目录取出 Card、TextField、Button，按描述组装成原生界面。
用户提交表单触发 A2UI 动作，前端将其包装为 AG-UI 事件回传，Agent 更新数据模型或进入下一轮推理。
这个组合的价值在于职责清晰：AG-UI 让前端「看得见过程」，A2UI 让前端「画得出界面」。传输协议与 UI 描述解耦后，更换 Agent 框架不影响界面能力，更换渲染端也不影响后端事件模型。CopilotKit 1.61.2+ 在客户端向 Provider 传入 catalog 时会自动启用 A2UI 渲染，官方集成已把这条链路做到开箱即用。
五、放进完整的协议版图
把 A2UI、AG-UI 与 MCP、A2A、MCP Apps 放在一起，可以看出每一层各司其职：
| 协议 / 方案 | 连接关系 | 解决的核心问题 |
|---|---|---|
| MCP | Agent ↔ 工具 / 上下文 | Agent 如何安全地调用外部能力、读取数据 |
| A2A | Agent ↔ Agent | 任务发现、委托与多 Agent 协作 |
| AG-UI | Agent ↔ 用户应用 | 事件语义、流式输出、状态同步、人机协同 |
| A2UI | Agent → 界面 | 声明式描述可交互 UI，由客户端原生渲染 |
| MCP Apps | 工具 ↔ 内嵌应用 | 工具自带完整 Web 界面（沙箱 iframe 运行） |
记住了这个版图，再看到新的「Agent + UI」概念，就可以先问一句：它连接的是工具、Agent、前端，还是界面描述本身？
六、怎么选：三个问题做决策
需要流式输出、工具过程、状态同步、人工审批，但界面仍由前端预先开发——选 AG-UI 就够了。
需要动态表单、看板、跨端一致的交互结果，且希望界面受组件目录约束——引入 A2UI，并评估现有渲染器与组件目录成本。
既要过程可观测，又要界面可生成——采用「AG-UI 传输 + A2UI 渲染」组合，这也是当前最完整的落地路径。
如果需求是「某个工具随附一个完整小应用」，可以评估 MCP Apps；它更重，但自由度高，与 A2UI 的定位不同。
无论选哪种，建议都从小场景试点：先在内部工具验证组件目录、事件契约与权限边界，再逐步扩展到客户侧主链路。协议解决的是标准化问题，业务价值仍取决于场景选择与流程设计。
常见问题
Q1：A2UI 和 AG-UI 是竞争关系吗？
不是。两者解决不同层次的问题：AG-UI 是事件管道，标准化 Agent 与前端之间的通信语义；A2UI 是 UI 载荷，标准化界面如何被描述与渲染。可以组合使用——AG-UI 负责传输，A2UI 负责描述，这也是业界推荐的搭配方式。
Q2：可以只用 A2UI 不用 AG-UI 吗？
可以。A2UI 不绑定任何传输层，A2UI 消息可以经由 A2A、自定义 HTTP 接口或其他消息通道传递。AG-UI 只是最顺手的标准传输绑定之一。如果现有系统已有稳定的消息通道，直接承载 A2UI 消息即可。
Q3：两个名字这么像，怎么快速记住区别？
记八个字：AG-UI 是管道，A2UI 是图纸。AG-UI 关心「Agent 发生了什么、怎么把事件送到前端」；A2UI 关心「前端应该把界面画成什么样」。一个管传输与状态，一个管结构与渲染。
如果还想分别深入了解，可以继续阅读《什么是 A2UI（Agent-to-UI）》与《什么是 AG-UI（Agent-User Interaction Protocol）》，再结合《什么是 AI Agent》理解智能体本身的规划执行机制。鲸点无疑的 FDE 团队正在帮助客户把 Agent、协议与前端体验整合进真实业务系统——了解我们的 AI 落地服务。