当 AI 从“嘴强王者”进化为“动手玩家”，A2UI 让 Agent 亲手给你搭界面

过去两年，我们见证了大模型能力的爆炸式进化。

Agent 会规划任务、会调用工具、会写代码、会查资料，甚至还能“自我反思”。但有一个问题始终没解决：

它们大多数时间，还是困在一个聊天框里。

当需要填写多字段表单、选择选项、分步骤确认时，Agent 往往只能输出一大段文字说明——
“请提供姓名、电话、地址，然后确认是否继续……”

聪明是聪明，但交互体验却像回到了 2005 年。

直到 A2UI 出现，事情开始变得不一样。

一、为什么需要 A2UI：Agent 的“最后一公里”问题

生成式 AI 很擅长输出文本、代码、图片。

但当任务变成：

• 订机票
• 填写审批表
• 配置复杂参数
• 走完整业务流程

单纯聊天就变得低效、冗长、易出错。

你可以把这个问题理解成：

Agent 会思考，但不会“搭界面”。

而真实产品世界里，用户习惯的不是对话流，而是：

• 表单
• 卡片
• 按钮
• 列表
• 图表
• 分步骤流程

这就是 A2UI 要解决的核心问题。

二、A2UI 是什么？一句话讲清楚

A2UI = Agent to User Interface。

它不是前端框架，而是一个开放协议 + 渲染体系。

简单理解：

Agent 用 JSON 描述“界面长什么样”，
客户端用自己的原生组件库把它安全渲染出来。

官方资源：

• 官网：https://a2ui.org/
• 官方仓库：A2UI

三、它的核心思想：像数据一样安全，像代码一样灵活

A2UI 的设计理念可以概括为四个关键词：

1️⃣ 声明式，而非执行式

Agent 不生成 HTML / JSX / SwiftUI 代码。

它只生成结构化 JSON，例如：

{
  "components": [
    { "id": "c1", "type": "Card", "children": ["c2"] },
    { "id": "c2", "type": "Text", "text": "为你找到 3 家餐厅" }
  ]
}

{
  "components": [
    { "id": "c1", "type": "Card", "children": ["c2"] },
    { "id": "c2", "type": "Text", "text": "为你找到 3 家餐厅" }
  ]
}

客户端负责：

• 解析
• 校验
• 映射到本地组件
• 渲染

Agent 不碰真实代码。

2️⃣ 安全优先（这是重点）

如果让 LLM 直接生成可执行代码，会有什么风险？

• XSS
• 注入攻击
• 越权调用
• 随意执行脚本

A2UI 的策略是：

Agent 只能请求渲染“白名单组件”。

客户端维护一个 组件目录（catalog）：

• 允许的组件
• 允许的属性
• 属性类型与范围
• 版本控制
• fallback 降级策略

Agent 不能发明新组件，不能执行任意代码。

安全边界牢牢掌握在客户端手中。

3️⃣ 天然支持增量更新（LLM 友好）

A2UI 使用：

• 扁平组件列表
• ID 引用结构

这对 LLM 非常友好。

意味着：

• 可以分段生成
• 可以渐进渲染
• 可以 patch 更新
• 不必一次吐完整棵 UI 树

体验会更接近“流式 UI”。

4️⃣ 框架无关，跨平台渲染

A2UI 不绑定技术栈。

同一份 JSON：

• Web 可用 React / Angular / Lit 渲染
• iOS 用 SwiftUI
• Android 用 Compose
• Flutter 用 Widget

UI 结构和 UI 实现完全解耦。

这点极其关键。

四、A2UI 的架构：生成与执行彻底分离

整个流程可以分为四步：

1️⃣ 生成

Agent 生成 A2UI JSON。

2️⃣ 传输

通过协议发送给客户端（如 A2A、AG UI 等）。

3️⃣ 解析与校验

客户端：

• Schema 校验
• catalog 白名单校验
• 预算校验（节点数、深度等）

4️⃣ 渲染

抽象组件 → 映射到本地真实组件。

这就是它的核心哲学：

UI 的生成权在 Agent
UI 的执行权在客户端

五、典型应用场景

A2UI 不是玩具协议，它针对的是“真实产品场景”。

1️⃣ 动态数据收集

用户说：

我要预订一场生日派对场地。

Agent 自动生成：

• 日期选择器
• 人数滑块
• 预算区间
• 特殊要求输入框

而不是一大段文字说明。

2️⃣ 远程子代理协作

主 Agent 把任务交给专业代理。

例如：

• 旅行预订代理
• 财务计算代理
• 法律文书代理

子代理返回一份 UI 描述，直接嵌入主界面。

3️⃣ 企业审批工作流

动态生成：

• 审批仪表板
• 数据图表
• 可交互报表
• 操作按钮

流程可视化，不再只是“聊天”。

4️⃣ AI Mini App

Google 内部已经在多个方向探索 A2UI。

例如：

• 企业级 Agent 系统
• Flutter GenUI SDK（底层使用 A2UI）
• AI Mini 应用构建工具

它正在成为一种“生成式 UI 规范”。

六、A2UI 和 JSON-Render 有什么不同？

很多人会对比：

• Vercel JSON-render
• A2UI

表面相似：

AI → JSON → Component → UI

但核心差别在于：

可以这样理解：

JSON-render 是厨具
A2UI 是菜谱标准

七、如何快速跑起来？

官方提供了示例项目（餐厅查找 Demo）。

核心步骤：

1. 克隆仓库
2. 设置 Gemini API Key
3. 启动 Agent 后端
4. 构建 Web 渲染器
5. 启动客户端

完整源码地址：

A2UI demo

建议直接跑 Demo，理解流程。

八、为什么 A2UI 可能很重要？

我们正在从：

Chat Interface → Intelligent Workflow Interface

转型。

未来的 Agent 不会只是聊天机器人，而是：

• 任务执行器
• 工作流协调者
• 企业系统前台

而这些都需要：

• 表单
• 操作按钮
• 可视化组件
• 可控安全模型
• 跨端统一规范

A2UI 正在尝试成为这套“UI 语言”。

它像 OpenAPI 之于 API 一样——

不是实现，而是契约。

九、一些值得思考的问题

1. 如果每个 Agent 都有自己的 UI 协议，会发生什么？
2. 未来会不会出现 A2UI 生态市场？
3. catalog 是否会成为新的“设计系统协议层”？
4. 企业是否会定义自己的私有 A2UI 规范？
5. 它是否会成为 AI 应用的“浏览器级标准”？

这些问题，现在没有标准答案。

但可以确定的是：

纯聊天不是终点。

十、总结

A2UI 的核心价值可以用一句话概括：

让 Agent 跨信任边界、安全地生成可交互 UI，同时保留客户端对渲染与品牌的控制权。

它解决的是：

• 交互瓶颈
• 安全问题
• 多端适配
• UI 增量更新
• 协议化治理

当 Agent 开始“自己搭界面”，
AI 才真正进入产品化时代。

相关资源

• 官网：https://a2ui.org/
• 官方仓库：A2UI

如果你正在构建：

• 多 Agent 平台
• 企业级智能工作流
• 可扩展 AI 插件生态

A2UI 值得认真研究。

因为这可能是——

AI 自主交互界面的雏形。