AG-UI 与 A2UI：名字像，但干的事完全不一样

AI代理生态中的两个关键协议：AG-UI和A2UI，分别解决了不同层面的问题。AG-UI是通信协议，负责代理与应用间的双向数据传输，支持事件驱动和流式交互；A2UI是UI描述规范，定义代理如何以JSON格式声明UI结构，确保安全可控。两者互补而非竞争，AG-UI作为传输管道，A2UI作为内容格式。典型场景中，AG-UI可单独用于简单文本交互，而复杂UI需求可结合A2UI实现动态渲染。这一架构分离了

qhvssonic

217人浏览 · 2026-02-04 09:03:51

qhvssonic · 2026-02-04 09:03:51 发布

前言

最近 AI agent 生态里冒出来两个协议：AG-UI 和 A2UI。名字只差一个字母，很容易混淆。

但它们解决的问题完全不同：

AG-UI 是通信协议，管的是代理和应用之间怎么传数据
A2UI 是 UI 规范，管的是代理返回的 UI 描述长什么样

一个是管道，一个是内容。搞清楚这个区别，后面的东西就好理解了。

一、AG-UI：代理和应用之间的通信协议

AG-UI 全称是 Agent-User Interaction Protocol，由 CopilotKit 团队主导开发。

解决什么问题

传统的 HTTP 请求是一问一答模式：客户端发请求，服务端返回响应，结束。

但 AI 代理不一样。代理可能需要：

边生成边返回（流式输出）
中途调用工具，等工具返回结果
更新内部状态，前端需要同步
遇到问题需要用户确认

这些场景需要一个支持双向通信、事件驱动的协议。AG-UI 就是干这个的。

核心设计

AG-UI 定义了一套事件类型，覆盖代理执行的各个阶段：

// 生命周期事件
RUN_STARTED      // 代理开始执行
RUN_FINISHED     // 代理执行完成
RUN_ERROR        // 出错了

// 文本消息事件
TEXT_MESSAGE_START    // 开始输出文本
TEXT_MESSAGE_CONTENT  // 文本内容（流式）
TEXT_MESSAGE_END      // 文本输出结束

// 工具调用事件
TOOL_CALL_START   // 开始调用工具
TOOL_CALL_ARGS    // 工具参数（流式）
TOOL_CALL_END     // 工具调用结束
TOOL_CALL_RESULT  // 工具返回结果

// 状态管理事件
STATE_SNAPSHOT    // 状态快照
STATE_DELTA       // 状态增量更新

这些事件通过 SSE、WebSocket 或 HTTP Streamable 传输。前端收到事件后，根据类型做相应处理。

关键特点

传输层协议：AG-UI 不关心传输的内容是什么格式，只管把数据从 A 点送到 B 点
事件驱动：所有通信都是事件，有统一的结构
双向通信：用户操作可以回传给代理
框架无关：不绑定任何前端或后端框架

二、A2UI：代理描述 UI 的 JSON 规范

A2UI 全称是 Agent-to-User Interface，由 Google 主导开发，目前处于 v0.8 公开预览阶段。

解决什么问题

AI 代理擅长生成文本和代码，但生成 UI 就麻烦了。

直接让模型生成 HTML 或 React 代码？有安全风险。返回的代码要是包含恶意脚本怎么办？

A2UI 的思路是：代理只返回 UI 的声明式描述，不返回可执行代码。

这样做的好处：

安全：数据格式，不是代码，没法执行恶意操作
可控：前端只渲染白名单里的组件
跨平台：同一份 JSON 可以在 React、Flutter、Angular 等不同框架渲染

消息格式

A2UI 使用 JSONL 格式，包含三种消息类型：

1. surfaceUpdate - 定义组件结构

{"surfaceUpdate":{
  "surfaceId": "booking-form",
  "components": [
    {"type": "text-field", "id": "name", "label": "姓名"},
    {"type": "date-picker", "id": "date", "label": "日期"},
    {"type": "button", "id": "submit", "text": "提交"}
  ]
}}

2. dataModelUpdate - 填充数据

{"dataModelUpdate":{
  "surfaceId": "booking-form",
  "path": "/",
  "contents": {
    "name": {"value": "张三"},
    "date": {"value": "2024-03-15"},
    "submit": {"disabled": false}
  }
}}

3. beginRendering - 触发渲染

{"beginRendering":{
  "surfaceId": "booking-form",
  "root": "form-container",
  "styles": {...}
}}

代理按顺序发送这三个消息，前端就能渲染出一个预约表单。

设计理念

A2UI 的核心设计原则：

安全优先：代理只能请求渲染预定义的组件，不能执行任意代码
LLM 友好：扁平化的组件列表 + ID 引用，模型容易生成
增量更新：不用每次发完整 UI，可以只发变化的部分
框架无关：UI 结构和实现分离，同一份 JSON 可以在不同框架渲染

三、两者关系：管道 vs 内容

这是最关键的一点：A2UI 和 AG-UI 是互补关系，不是竞争关系。

+-------------------+
|      A2UI         |  ← 定义 UI 描述格式（内容）
| (JSON 规范)       |
+--------+----------+
         |
         | A2UI JSON 作为 AG-UI 事件的 payload
         v
+--------+----------+
|      AG-UI        |  ← 定义传输协议（管道）
| (事件流)          |
+--------+----------+
         |
         v
+--------+----------+
|   前端应用        |
| (解析 + 渲染)     |
+-------------------+

实际工作流程：

代理决定要显示一个表单
代理按 A2UI 规范生成 JSON
JSON 通过 AG-UI 的 CUSTOM 事件传输
前端收到事件，解析出 A2UI payload
前端的 A2UI 渲染器把 JSON 变成 UI

代码示例：

// AG-UI 事件，携带 A2UI 内容
{
  type: "CUSTOM",
  name: "a2ui_surface_update",
  value: {
    surfaceUpdate: {
      surfaceId: "weather-widget",
      components: [
        {type: "card", id: "card"},
        {type: "text", id: "temp", text: "25°C"},
        {type: "text", id: "city", text: "北京"}
      ]
    }
  }
}

AG-UI 负责把这个事件传到前端，A2UI 渲染器负责把 components 渲染成真实的卡片。

四、详细对比表

对比项	AG-UI	A2UI
定位	通信协议	UI 描述规范
来源	CopilotKit	Google
解决的问题	代理和应用怎么通信	UI 描述什么格式
关注点	怎么传	传什么
数据格式	事件流 (JSON)	JSONL
传输方式	SSE / WebSocket / HTTP	需要依赖其他传输层
双向通信	原生支持	支持（事件回传）
流式传输	原生支持	支持（增量更新）
安全模型	传输层安全	白名单组件机制
状态管理	STATE_SNAPSHOT / STATE_DELTA	dataModelUpdate
框架绑定	无	无
成熟度	已发布	v0.8 预览版

五、使用场景

只用 AG-UI

适合这些场景：

代理只输出纯文本
使用预定义的 React 组件（代理只传数据，组件写好了）
需要状态同步、工具调用等基础能力

// 前端注册一个天气卡片组件
useFrontendTool({
  name: "show_weather",
  render: ({ result }) => <WeatherCard data={result} />
});

代理调用 show_weather 工具时，前端渲染 WeatherCard。组件是开发者写好的，代理只提供数据。

AG-UI + A2UI

适合这些场景：

代理需要动态定义 UI 结构（不是从预定义组件里选）
跨平台渲染（Web + Flutter + Native）
复杂表单、仪表盘等需要灵活布局的 UI

// 前端使用 A2UI 渲染器
import { createA2UIMessageRenderer } from "@copilotkit/a2ui-renderer";

<CopilotKitProvider
  renderActivityMessages={[createA2UIMessageRenderer({ theme })]}
>
  {children}
</CopilotKitProvider>

代理返回 A2UI JSON，前端自动渲染。代理有更大的自由度来设计 UI 结构。

只用 A2UI（理论上可行）

如果你有自己的传输层，可以只用 A2UI 的 JSON 格式。

但实际上 A2UI 官方推荐配合 AG-UI 或 A2A (Agent-to-Agent) 协议使用。单独用 A2UI 意味着你要自己处理传输、状态同步这些事情。

六、生态定位

把整个 AI agent 生态里的协议画出来：

+------------------+     +------------------+     +------------------+
|       MCP        |     |       A2A        |     |      AG-UI       |
| (工具/资源协议)  |     | (代理间通信)     |     | (代理-用户通信)  |
+--------+---------+     +--------+---------+     +--------+---------+
         |                        |                        |
         +------------------------+------------------------+
                                  |
                   +--------------+--------------+
                   |        Generative UI        |
                   |  (A2UI / Open-JSON-UI 等)   |
                   +-----------------------------+

MCP：代理调用工具、访问资源
A2A：多个代理之间的通信
AG-UI：代理和用户界面之间的通信
A2UI / Open-JSON-UI：代理返回 UI 的具体格式规范

AG-UI 和 A2UI 不在同一层。AG-UI 是传输层，A2UI 是应用层的内容格式。

七、总结

问题	答案
AG-UI 是什么？	代理和应用之间的通信协议，定义事件类型和传输方式
A2UI 是什么？	代理描述 UI 的 JSON 规范，定义组件结构和数据格式
它们是竞争关系吗？	不是，是互补关系。AG-UI 负责传输，A2UI 负责内容
可以单独使用吗？	AG-UI 可以单独使用；A2UI 需要配合传输协议
CopilotKit 支持哪个？	两个都支持，是 A2UI 的官方发布合作伙伴
实际开发中怎么选？	基础场景用 AG-UI 就够；需要动态 UI 结构时加上 A2UI