Agent 终于可以"画"界面了：AG-UI 和 A2UI 协议入门

一个真实的问题

假如你让 AI 帮你订一家餐厅。

传统的做法是：AI 问你"哪天去？"，你回答；AI 再问"几个人？"，你回答；AI 又问"几点？"，你回答......光是为了定一个桌子，你来我往聊了七八轮。

累不累？太累了。

更合理的做法是什么？AI 直接显示一个表单：日期、时间、人数，你点一点、填一填，提交，就完成了。

这就是 Generative UI 的核心价值：让 AI 用界面而不是文字来跟你交互。

但是，问题来了——

AI 怎么"画出"这个表单？前端怎么知道 AI 想显示什么？如果每个应用都自己定义一套规则，生态还怎么互通？

这就是 AG-UI 和 A2UI 这两个协议要解决的问题。

AG-UI：一条标准化的"通信管道"

AG-UI 的全称是 Agent-User Interaction Protocol，翻译过来就是"Agent 与用户交互的协议"。

你可以把它理解成一条通信管道。管道这头是 AI Agent，那头是前端界面。AG-UI 规定了它们之间怎么说话。

这条管道传输的不是普通的文本，而是一个个事件：

AG-UI 的设计理念很简单：我不关心你具体想显示什么，我只关心你怎么把这些信息传递给我。

举个例子：AI 要显示一个天气卡片。AG-UI 不管这个卡片是圆形还是方形、有没有动画，它只负责把"这里是天气信息"这件事告诉前端。至于前端怎么渲染，那是前端的事。

这种设计带来了很好的可移植性——同一个 AI 后端，可以接 React 前端，也可以接 Flutter 前端，甚至可以接原生 App。

A2UI：让 AI 学一门"UI 语言"

如果说 AG-UI 是"怎么传输"，那 A2UI 就是"传什么"。

A2UI 的全称是 Agent-to-User Interface，Google 在 2025 年底开源的这个协议，想让 AI 学会一门"描述 UI 的语言"。

想象一下：以前 AI 只能输出文字，现在它可以输出一份 JSON 格式的 UI 描述。前端拿到这份描述，就知道该显示什么组件、怎么布局、数据怎么绑定。

下面是一个简化的 A2UI 消息示例，描述一个餐厅预订表单：

{
  "surfaceUpdate": {
    "surfaceId": "main",
    "components": [
      {
        "id": "header",
        "component": {
          "Text": { "text": "预订餐厅桌位", "usageHint": "h1" }
        }
      },
      {
        "id": "date_input",
        "component": {
          "DateTimeInput": {
            "label": "选择日期和时间",
            "value": { "path": "/reservation/datetime" }
          }
        }
      },
      {
        "id": "confirm_btn",
        "component": {
          "Button": {
            "child": "确认预订",
            "action": { "name": "confirm_reservation" }
          }
        }
      }
    ]
  }
}

前端收到这份 JSON，就知道：要显示一个标题、一个日期选择器、一个按钮。这就是 AI"画"界面的方式。

A2UI 的三个核心设计

1. 声明式，不是可执行代码

AI 输出的是"UI 蓝图"，不是可以执行的代码。前端拿着蓝图，去自己的组件库（叫 catalog）里找对应的组件来渲染。

这样做是为了安全。如果让 AI 直接生成前端代码并执行，那 XSS 攻击之类的问题就来了。

2. 流式生成

UI 可以一边"说"一边显示，就像流式文本输出一样。AI 不用憋出一个完整的 JSON 才让前端渲染，它可以先发送一个框架，再补充细节。

3. 跨平台

同一份 A2UI 描述，Web 前端可以渲染，Flutter 可以渲染，原生 App 也可以渲染——只要它们各自有对应的组件库映射。

它们是什么关系？

这是最容易被混淆的地方。

让我用一个人来打比方：

假设你要装修房子。

A2UI 是装修图纸——它规定了这个房间要有床、那个角落要有书柜。 AG-UI 是运输管道——它负责把这份图纸从设计师那里运到施工现场。 Vercel AI SDK 是设计师的助手——它帮设计师（Agent）画图纸，但不管怎么运输。

换一种说法：

┌─────────────────────────────────────┐
│           你的 AI 应用                │
├─────────────────────────────────────┤
│  A2UI：UI 描述（JSON）                │
│    ↓                                 │
│  AG-UI：事件流传输（SSE/WebSocket）   │
│    ↓                                 │
│  AI SDK：调用模型，生成内容            │
│    ↓                                 │
│  LLM：GPT-4o、Claude 等              │
└─────────────────────────────────────┘

AG-UI 和 A2UI 不是竞争关系，而是互补关系。

• A2UI 定义"UI 长什么样"
• AG-UI 定义"怎么把这个 UI 描述传过去"

它们可以一起用，也可以分开用。AG-UI 甚至可以承载 Open-JSON-U I、CopilotKit 自定义格式等各种 UI 描述语言。

生态中的其他协议

除了 AG-UI 和 A2UI，还有一组协议值得关注：

一个完整的企业级 Agent 应用可能是这样的：

1. 通过 MCP 查询数据库、调用 API
2. 通过 A2A 与其他 Agent 协作
3. 通过 AG-UI 与前端保持状态同步
4. 通过 A2UI 把结果显示为交互式界面

现状与展望

这些协议都还比较新：

• A2UI 目前是 0.8 版本（预览版），还在快速迭代
• AG-UI 由 CopilotKit 主推，已经有了不错的实现
• CopilotKit 已经支持 A2UI，还提供了一个在线的 A2UI Composer，可以可视化生成 A2UI 描述

对于普通开发者来说，我的建议是：

1. 如果你是快速原型开发：直接用 Vercel AI SDK + AI SDK UI，它已经很好用了
2. 如果你需要跨框架、跨平台：考虑引入 AG-UI 作为通信层
3. 如果你想让 AI 更精细地控制 UI：研究 A2UI，它提供了最完整的 UI 描述能力

当然，这些协议还在演进中，不必急于全面拥抱，但值得关注。

总结

AI Agent 与前端的交互，正在从"纯文字对话"向"界面交互"演进。

• AG-UI 解决的是"怎么传"的问题，提供了一条标准化的通信管道
• A2UI 解决的是"传什么"的问题，让 AI 可以描述 UI 结构
• 两者配合，加上 MCP（工具）、A2A（Agent 协作），正在形成一套完整的 Agent 协议栈

当 AI 不再只是"说话"，而是开始"画界面"，人机交互的效率会有质的飞跃。

这些协议，就是让这个飞跃成为现实的基础设施。

参考链接：

• CopilotKit - Generative UI
• A2UI 官方文档
• A2UI Composer 可视化工具