协议全景：三层拼图的最后一块
过去两年，智能体协议栈的标准化沿着两条线推进：Anthropic 发起的 MCP（Model Context Protocol）标准化了智能体连接外部工具、工作流与数据源的方式；Google 发起的 A2A（Agent to Agent）定义了分布式智能体系统之间的协调与任务共享。但智能体与「人」之间的连接层——长运行任务如何流式呈现到前端、用户如何中途打断或纠偏、前端动作如何回传给智能体——长期依赖各家自建的临时方案。
AG-UI（Agent–User Interaction Protocol）官方文档明确将三者并列，形成一张三层分工表：
| 层次 | 协议 | 发起方 | 解决的连接问题 |
|---|---|---|---|
| 智能体 ↔ 工具与数据 | MCP | Anthropic | 安全连接外部系统、工具、工作流与数据源 |
| 智能体 ↔ 智能体 | A2A | 分布式智能体系统之间的协调与任务共享 | |
| 智能体 ↔ 用户界面 | AG-UI | CopilotKit | 智能体后端与面向用户的前端应用之间的双向实时连接 |
需要澄清一个命名混淆：AG-UI 与 A2UI 是两个不同的东西。官方文档专门做了区分——A2UI 是一份生成式 UI 规范，允许智能体交付 UI 组件；AG-UI 则是智能体与用户之间的交互协议，负责把智能体前端连接到任意智能体后端。两者被描述为「配合良好」而非相互替代。
官方文档列举了四点面向用户的智能体对连接层的特殊要求：智能体长运行且流式输出中间工作，常跨多轮会话；行为非确定性，甚至非确定性地控制应用 UI；同时混合结构化与非结构化 IO（文本、语音、工具调用、状态更新）；需要用户可交互的组合，例如递归调用子智能体。这些特性打破了「请求—响应—渲染」的传统前后端模型，是 AG-UI 存在的直接理由。
架构核心：事件流而非渲染目标
AG-UI 的核心抽象是事件流。官方文档强调：协议描述的是事件流而非渲染目标，因此一个终端、一个移动应用或一个聊天平台都可以作为客户端。这一设计带来了三个直接后果：
- 传输层中立：AG-UI 构建在 HTTP、WebSocket 等 Web 基础协议之上，作为面向智能体时代的抽象层，不绑定具体传输实现；
- 客户端多样性：官方列出的客户端包括 CopilotKit（一方）、终端 + 智能体、聊天平台（Slack、Microsoft Teams，经 Channels SDK）与 React Native；
- 托管服务与协议分离：文档举例说明，一个 Python LangGraph 智能体经 AG-UI 送达 Slack 和 Teams，其平台凭据与消息投递由 CopilotKit Intelligence 这一托管服务处理——「托管服务不是协议的一部分」。
这个「协议与托管分离」的表述值得关注：CopilotKit 既是协议发起方，也在协议之上运营商业化服务。文档通过显式划界来回应潜在的中立性质疑，但发起方的商业身份仍是评估该协议治理结构时不可忽略的因素。
十二个积木块：能力边界一览
官方文档以「积木块（Building blocks）」形式列出了协议当前与规划中的能力集，可以视为 AG-UI 的功能全景图：
| 能力块 | 职责 | 解决的问题 |
|---|---|---|
| 流式对话 | 实时 token 与事件流 | 多轮会话的取消与恢复 |
| 多模态 | 类型化附件与实时媒体 | 文件、图像、音频、转录、来源标注 |
| 生成式 UI（静态） | 模型输出渲染为稳定类型化组件 | 应用侧可控的 UI 生成 |
| 生成式 UI（声明式） | 小型声明式语言 | 智能体提议 UI 树与约束，应用校验后挂载 |
| 共享状态 | 智能体与应用间的类型化存储 | 事件溯源式增量与冲突解决 |
| 思考步骤 | 从轨迹与工具事件可视化中间推理 | 不暴露原始思维链的前提下展示过程 |
| 前端工具调用 | 智能体到前端动作的类型化交接 | 前端执行的工具有返回通道 |
| 后端工具渲染 | 后端工具输出在应用与聊天中可视化 | 副作用作为一等事件发出 |
| 中断（人在回路） | 暂停、批准、编辑、重试、升级 | 流程中途干预而不丢失状态 |
| 子智能体与组合 | 嵌套委托、作用域状态、追踪与取消 | 复杂多智能体编排的前端呈现 |
| 智能体转向 | 实时用户输入重定向执行 | 动态引导智能体行为与结果 |
| 工具输出流式与自定义事件 | 流式工具结果与日志；开放数据交换 | 长运行效果的实时渲染与协议未覆盖场景 |
中断（人在回路）与子智能体组合是这份清单里工程含量最高的两块。前者要求「暂停、批准、编辑、重试或升级」全程不丢状态——这需要事件溯源式的状态管理配合；后者要求嵌套委托时作用域状态、追踪与取消一并传导。业界快讯在报道 1.0 冻结时也特意点名这两个新增能力。对正在做多智能体产品的团队而言，这两块直接决定了「审批流」和「任务树」这类高频企业场景能否低成本落地。
生态版图：一方集成与社区 SDK
AG-UI 的集成页面给出了相当细的生态状态清单，这也是评估一个开放协议成色的直接依据：
| 类别 | 已支持（SUPPORTED） | 进行中（IN PROGRESS） |
|---|---|---|
| 智能体框架（一方合作） | LangChain、CrewAI | — |
| 智能体框架（一方） | Microsoft Agent Framework、Google ADK（含 JS）、Google Antigravity、AWS Strands Agents、AWS Bedrock AgentCore、Mastra、Pydantic AI、Agno、LlamaIndex、AG2 | AWS Bedrock Agents、OpenAI Agent SDK、Cloudflare Agents |
| 协议互通 | A2A Middleware（合作） | — |
| 客户端 | CopilotKit、终端 + 智能体、Slack/Teams（Channels SDK）、React Native | — |
| 社区 SDK | Kotlin、Golang、Dart、Java、Rust、Ruby、C++、.NET | Nim、Flowise、Langflow |
两个观察：其一，Microsoft Agent Framework、Google ADK、AWS Strands 三大厂商框架同时出现在一方集成名单里，与 A2A Middleware 存在合作关系——AG-UI 在主流转型期拿到了跨厂商的入场券；其二，OpenAI Agent SDK 与 Cloudflare Agents 仍标为进行中，头部协议阵营（MCP、A2A、AG-UI）与各厂商框架的接入进度并不均衡。
与 MCP、A2A 的协同而非竞争
AG-UI 在协议栈中的定位决定了它与另外两个协议是互补关系：一个典型的生产级智能体应用可以同时使用三者——MCP 连数据库与内部系统，A2A 把子任务委派给其他团队的智能体，AG-UI 把整个过程流式呈现给业务用户并接住审批与纠偏。官方文档对 A2A Middleware 的支持条目也印证了这种组合式部署的预期。
从工程视角看，三层协议各管一段之后，暴露出来的是边界一致性问题：同一个「工具调用」在 MCP 层与 AG-UI 层如何对应？A2A 任务状态变化如何在 AG-UI 事件流中呈现？目前三份协议各自独立演进，跨协议的映射规范尚不完整。这也是本站此前对 MCP 无状态化与 A2A 1.0 的解构中反复出现的主题——协议栈在快速补齐，但「栈间胶水」仍是开发者自行承担的部分。
批判性视角：1.0 信息源与成熟度短板
- 「1.0 冻结」的时间与版本口径目前主要来自行业快讯单源：2026 年 10 月 2 日的业界日报报道 AG-UI 冻结 1.0 稳定规范，并称 TypeScript、Python 与 .NET SDK 由同一份 JSON Schema 生成。但截至本文撰写，官方文档总览页描述协议能力时并未突出标注版本号，且官方集成页将 .NET 列为社区维护 SDK。版本与 SDK 生成方式的精确口径，建议以官方仓库与变更日志为准。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
- 发起方的商业双重身份：CopilotKit 既是协议维护方又运营基于协议的托管智能体服务，「开放协议 + 商业增值」模式在治理上如何保持中立，仍需时间检验。
- 声明式生成式 UI 尚在演进：官方将声明式生成式 UI 列为积木块之一，但「小型声明式语言 + 应用校验挂载」这套机制的安全边界（例如恶意 UI 树注入）在文档中未见专门的威胁模型章节。
- 评测与性能数据缺位：与 MCP、A2A 一样，AG-UI 没有公开的互操作性测试套件或性能基准，落地效果仍依赖开发者自测。
对开发者的落地建议
- 按层选协议：连接工具用 MCP，跨团队智能体协作用 A2A，前端呈现与人在回路用 AG-UI，不必三选一；
- 优先检查一方集成：若团队已在用 LangChain、CrewAI 或 Microsoft Agent Framework，AG-UI 的一方支持意味着改造成本集中在事件流适配而非框架迁移；
- 把「中断不丢状态」当验收标准：评估任何智能体前端方案时，先测「用户中途批准/编辑/取消后，智能体是否还能从正确状态继续」，这是 AG-UI 类协议的核心价值所在；
- 留意版本口径：1.0 冻结信息目前以快讯为主，生产环境引入前建议核对官方仓库的规范版本与 SDK 变更日志。