A2UI

• 1. 简介
• 2. 架构设计 (Architecture Design)
  • 2.1 生成层 (Generation Layer) - 代理端
  • 2.2 传输层 (Transport Layer) - 协议端
  • 2.3 渲染层 (Rendering Layer) - 客户端
• 3. 核心功能模块 (Core Functional Modules)
  • 3.1 可信组件目录 (The Trusted Catalog)
  • 3.2 结构与状态分离 (Separation of Structure and State)
  • 3.3 交互事件循环 (Interaction Loop)
• 4. 工作原理
  • 4.1 端到端交互流程
  • 4.2 流式渲染机制
• 5. 实际应用中的优势 (Advantages)
• 6. 挑战与局限 (Challenges & Limitations)
• 总结

1. 简介

A2UI (Agent-to-User Interface) 是由 Google 开发并于 2025 年 12 月发布的开源协议（v0.8 预览版）。它旨在解决 Agent 与用户交互时的核心痛点：如何让 AI 不仅仅是生成文本，而是能够动态构建丰富、原生且安全的用户界面（UI）。

传统的订机票场景中，你可能需要与 AI 进行多轮对话，AI 问你出发地、目的地、日期等信息，这样效率低下且体验割裂。而 A2UI 则允许 AI 直接生成一个交互式界面，用户可以在界面上选择日期、目的地等，大大提升了交互效率和用户体验。

A2UI 的核心理念是 "Native-First Generative UI"（原生优先的生成式 UI）。与传统的生成 HTML/JavaScript 代码的方式不同，A2UI 让代理生成一份描述 UI 意图的声明式 JSON 蓝图，然后由客户端应用程序使用其自身的原生组件进行渲染。这种方式在保证安全性的同时，确保了 UI 与宿主应用在视觉和交互上的一致性。

2. 架构设计 (Architecture Design)

A2UI 的架构设计采用了严格的分层模式，将 UI 的 创建（Creation） 与 渲染（Rendering） 解耦。

2.1 生成层 (Generation Layer) - 代理端

• 核心角色：由大语言模型（LLM，如 Gemini）驱动的 AI 代理。
• 功能：代理根据用户的需求（例如“帮我订一张去纽约的机票”），推理出所需的交互界面。
• 输出：代理不编写可执行代码，而是生成一个符合 A2UI 规范的 JSON 对象。这个 JSON 描述了界面的结构和内容（例如“我需要一个包含日期选择器和提交按钮的卡片”）。

2.2 传输层 (Transport Layer) - 协议端

• 数据格式：采用流式友好的 JSON Lines 格式。
• 邻接表模型 (Adjacency List Model)：这是 A2UI 协议的一大创新。与 HTML 的深层嵌套树状结构不同，A2UI 将 UI 组件描述为一个扁平的列表，组件之间通过 ID 相互引用。
  • 优势：这种扁平结构对 LLM 更友好，降低了生成时的语法错误率（如忘记闭合括号），并支持增量流式传输。

2.3 渲染层 (Rendering Layer) - 客户端

• 核心角色：宿主应用程序（Host App），可以是 Web (React/Angular)、移动端 (iOS/Android) 或 Flutter 应用。
• 渲染器 (Renderer)：客户端集成的一个轻量级库，负责解析接收到的 JSON 指令。
• 映射机制：渲染器将 JSON 中的标签（如 type: 'date-picker'）映射到客户端本地已有的 原生组件（如 <MyNativeDatePicker />）。这意味着生成的 UI 完全继承了宿主应用的主题、样式和交互行为。

3. 核心功能模块 (Core Functional Modules)

3.1 可信组件目录 (The Trusted Catalog)

这是 A2UI 的安全基石。客户端维护一份硬编码的“允许使用的组件列表”（白名单）。

• 工作原理：代理只能请求该目录中存在的组件。如果代理“幻觉”出了一个不存在的组件（如 <SuperMaliciousButton />），客户端会直接忽略或报错。
• 安全意义：由于代理无法注入新的 HTML 标签或 <script> 脚本，彻底杜绝了 Prompt Injection 导致的 XSS 攻击或恶意代码执行风险。

3.2 结构与状态分离 (Separation of Structure and State)

A2UI 将静态的 UI 布局与动态的数据模型严格分开。

• Surface Definition：定义 UI 的骨架（行、列、卡片等）。
• Data Model：一个独立的 JSON 对象，存储应用状态（如 {"userName": "Alice", "flightPrice": "$300"}）。
• 数据绑定：组件通过 JSON Pointers（如 /user/name）绑定到数据模型。当数据发生变化时，代理只需发送轻量级的 dataModelUpdate 指令，而无需重新生成整个 UI 布局。

3.3 交互事件循环 (Interaction Loop)

• User Action：当用户在客户端进行操作（如点击按钮）时，客户端会发送 userAction 事件回代理。
• 闭环：代理接收事件，进行推理，然后发送新的 surfaceUpdate 或 dataModelUpdate 来响应用户，形成完整的交互闭环。

4. 工作原理

这一章用一个端到端闭环来说明 A2UI 如何把“Agent 的意图”变成“用户可交互的原生 UI”，并解释其流式渲染为何不会出现半成品闪烁。

4.1 端到端交互流程

1. 用户发起需求：用户向代理发送需求。
2. 代理生成 UI 意图：代理生成描述 UI（结构 + 数据）的 A2UI 消息。
3. 消息传输到客户端：消息以流式方式发送到客户端。
4. 客户端原生渲染：客户端使用本地原生组件渲染界面。
5. 用户进行交互：用户点击、选择、输入等操作在客户端发生。
6. 事件回传与更新：客户端回传交互事件，代理处理后再推送 UI/数据更新，形成闭环。

4.2 流式渲染机制

1）Server Stream（服务端流式推送）

服务端建立 SSE 连接后，持续推送一行行 JSONL（概念示例）：

{"type":"surfaceUpdate", ...}
{"type":"dataModelUpdate", ...}

重点：推送的是结构化消息（UI 意图 + 数据更新），而不是 HTML/JS 代码。

2）Client Buffering（客户端缓冲/组装）

客户端收到流后，会先“缓存/组装”，不急着立刻渲染：

• 把 surfaceUpdate 里提到的组件定义、组件树片段先存起来。
• 把 dataModelUpdate 里提到的数据合并到一个 data model（数据仓库）里。

这样做是为了避免流式内容“逐段到达”时的半成品闪烁（flash of incomplete content）。

3）Render Signal（渲染闸门：beginRendering）

当服务端确认：

• 组件树信息已经足够
• 关键数据也已到位

就发送明确的 beginRendering 信号，意思是：“现在可以开始画了”。

这个闸门的价值：让用户看到的是“完整的一次渲染”，而不是碎片化加载。

4）Client-Side Rendering（客户端本地渲染）

客户端开始真正构建 UI（对应图里的三步）：

1. Build widget tree：从根节点开始把组件树（widget tree）递归组装出来。
2. Resolve data bindings：把组件属性里绑定的数据（例如 title: {{user.name}}）用 data model 填充。
3. Look up widgets in WidgetRegistry：根据组件类型在注册表里查找本地原生组件实现（例如 Button、Table）。

关键点在于分工：

• 服务端表达“意图”（要什么组件、文本是什么、点击后发什么事件）。
• 客户端决定“实现细节”（外观风格一致、无障碍、主题、动效等）。

5）User Interaction（用户交互）

用户在客户端界面上点击、选择、输入。

6）Event Handling（客户端封装 userAction 并回传） 客户端把交互包装成结构化事件并回传（通常命名为 userAction），内容一般包括：

• componentId：操作发生在哪个组件上
• actionType：触发了什么动作
• payload：附带参数（如输入框内容、选中条目）

事件通过“单独的 A2A 消息通道”回传给服务端（图中强调 separate A2A message）。

为什么不走 SSE 回去？SSE 是服务端 → 客户端的单向推送机制；回传更自然的方式通常是 HTTP/WebSocket/另一条双向通道。

7）服务端处理事件

服务端收到 userAction 后：

• 执行业务逻辑（查库、调用工具、Agent 推理、发请求等）
• 生成新的界面结构变化或数据变化

8）Dynamic Updates（继续推送增量更新）

服务端继续通过原来的 SSE 流推更新：

• 新的 surfaceUpdate（新增卡片、切换页面、弹出对话框等）
• 新的 dataModelUpdate（列表更新、状态从 loading → done、错误信息出现等）

客户端收到这些更新后触发 UI rebuild：重新计算绑定并进行局部或整体重渲染（通常是 diff/增量更新，而不是整页重画）。

至此形成闭环：服务端流式发 UI/数据 → 客户端渲染 → 用户操作 → 回传事件 → 服务端处理 → 再推 UI/数据更新。

5. 实际应用中的优势 (Advantages)

1. 安全性 (Security)：

   • 这是 A2UI 最大的优势。通过传输“数据”而非“代码”，消除了 AI 生成恶意脚本的风险。企业可以放心地让 AI 控制关键业务界面。

2. 原生用户体验 (Native UX)：

   • 生成的 UI 不是嵌在 iframe 里的网页，而是真正的原生组件。它拥有与主应用完全一致的字体、颜色、动画和无障碍特性（Accessibility），用户甚至感觉不到这是 AI 临时生成的。

3. 高效性 (Efficiency)：

   • 流式渲染：UI 可以像打字机效果一样，随着代理的思考逐步显示，降低了用户的感知延迟。
   • Token 节省：扁平化的数据结构和状态分离机制，使得更新 UI 所需的 Token 数量远少于重写 HTML。

4. 跨平台一致性：

   • 同一套 JSON 意图可以被发送到 Web、iOS 和 Android 端，各端分别渲染成最适合该平台的原生形态。

6. 挑战与局限 (Challenges & Limitations)

1. 样式控制受限 (Limited Styling Control)：

   • 代理无法像写 CSS 那样精确控制像素（如“向左移动 5px”）。它只能表达语义（“这是一个主要按钮”），具体的视觉呈现完全由客户端决定。这在需要高度定制化视觉效果的场景下是一个限制。

2. 组件目录的约束 (Catalog Restriction)：

   • 代理的创造力受限于“组件目录”。它不能凭空发明一个新的 UI 控件（如一个全新的 3D 交互球），只能像搭积木一样组合现有的组件。

3. 实施成本 (Implementation Overhead)：

   • 开发者必须为客户端构建和维护一个“渲染器”，并手动将每一个 JSON 标签映射到具体的代码实现。这比直接在 WebView 中显示 HTML 要复杂得多。

4. 状态管理复杂性：

   • 在多轮对话中，同步代理的“记忆”与客户端 UI 的“当前状态”是一项复杂的工程挑战，容易出现状态不同步的问题。

总结

A2UI 代表了 AI 用户界面从“生成代码”向“生成意图”的范式转变。它通过牺牲一定的灵活性（样式和组件限制），换取了极高的安全性、原生体验和性能。对于希望在现有产品中深度集成 AI 代理功能的企业来说，A2UI 提供了一个标准化的、企业级的解决方案。