引言：Agent 时代的 UI 困境
想象这样一个场景——你对一个 AI 助手说："帮我订一张明天晚上 7 点的两人桌。" 如果 Agent 只能回复文本，接下来将是一连串低效的对话："请问哪一天？""什么时间？""几位？"……一个本可以用一个表单瞬间解决的事情，变成了五六个回合的文字乒乓球。
更好的方式显然是：Agent 直接生成一个表单界面，带有日期选择器、时间选择器、人数输入框和确认按钮。用户在 UI 上操作，一次提交，搞定。
但这件"显然更好"的事情，在技术上却极其棘手。Agent 可能运行在远程服务器上，甚至跨越组织的信任边界。它不能直接操控你的 UI，只能发送消息。传统的方案——在 iframe 中嵌入 Agent 返回的 HTML/JavaScript——不仅笨重、风格割裂，还引入了严重的安全隐患。
Google 发起的开源项目 A2UI（Agent-to-User Interface） 就是为了解决这个问题而生的。它定义了一种让 Agent "说 UI" 的通用语言：Agent 发送声明式的 JSON 消息来描述界面的意图，客户端应用用自己原生的组件库来渲染。安全如数据，表达如代码。
一、A2UI 是什么？一句话理解核心理念
A2UI 是一个声明式 UI 协议，而不是一个框架。它的核心思想可以拆成三层：
Agent 生成一段 JSON，描述"我想展示一个标题、一个日期选择器和一个按钮"。这段 JSON 通过任意传输通道（A2A 协议、WebSocket、SSE 等）到达客户端。客户端的 A2UI 渲染器读取 JSON，将抽象的组件描述映射为自己代码库中的原生组件——可以是 Flutter Widget、Angular Component、Lit Web Component 或 React 组件。
这意味着同一份 A2UI JSON 可以在 Web、移动端和桌面端被不同的渲染器渲染为风格统一、性能原生的界面，同时 Agent 完全无法执行任何代码——它只能从客户端预先批准的"组件目录"中选取组件来组合界面。
二、为什么需要 A2UI？三大设计支柱
安全优先。 A2UI 是一种声明式数据格式，不是可执行代码。Agent 不能注入 JavaScript，不能操纵 DOM——它只能请求渲染客户端目录中已经存在的、预先审核过的组件（如 Card、Button、TextField）。安全性由客户端完全掌控。
LLM 友好且支持增量更新。 UI 被表示为一个扁平的组件列表，组件之间通过 ID 引用来建立父子关系，而不是深层嵌套的 JSON 树。这种"邻接表"模型让 LLM 可以逐步生成组件、流式发送，客户端可以渐进式渲染——用户看到界面逐步构建，而不是盯着转圈等待。当需要更新时，只需发送带有已有 ID 的新定义即可，无需重新生成整个 UI。
框架无关且可移植。 Agent 发送的是对组件树和数据模型的抽象描述。渲染的责任完全在客户端。同一份 JSON 可以被 Lit 渲染为 Web Component，被 Flutter 渲染为原生移动控件，被 Angular 渲染为 Angular 组件，甚至未来被 SwiftUI 或 Jetpack Compose 渲染为 iOS 和 Android 原生视图。
三、核心概念详解
3.1 Surface（画布）
Surface 是 A2UI 中承载组件的容器，可以理解为一个完整的 UI 单元——一个对话框、一个侧边栏或一个主视图。每个 Surface 有唯一的 surfaceId，拥有自己的组件树和数据模型。Agent 通过创建、更新和删除 Surface 来管理界面的生命周期。
3.2 组件与邻接表模型
这是 A2UI 最独特的设计决策。传统的 UI 描述通常使用嵌套树结构，但 LLM 生成深层嵌套 JSON 时很容易出错，且难以流式传输和增量更新。A2UI 采用了扁平的邻接表模型：所有组件排成一个列表，每个组件有唯一 ID，通过 ID 引用子组件。
举个例子，一个包含标题和两个按钮的简单界面，在 v0.9 中是这样描述的：根组件 Column 声明子组件列表为 ["greeting", "buttons"]，greeting 是一个 Text 组件，buttons 是一个 Row 组件再引用两个 Button。所有组件平级排列，通过 ID 建立层次关系。
A2UI 提供了一套标准组件目录，按用途分为布局类（Row、Column、List）、展示类（Text、Image、Icon、Divider）、交互类（Button、TextField、CheckBox、DateTimeInput、Slider、ChoicePicker）和容器类（Card、Tabs、Modal）。
3.3 数据绑定
A2UI 将 UI 结构与应用状态分离。每个 Surface 拥有一个 JSON 数据模型，组件通过 JSON Pointer 路径（如 /user/name、/cart/items/0/price）绑定到数据模型中的值。
这种分离带来了强大的响应式更新能力：当 Agent 更新数据模型中的某个路径时，绑定到该路径的所有组件自动更新显示内容，无需重新发送组件定义。同时，交互组件（如 TextField）支持双向绑定——用户输入立即写入本地数据模型，当用户点击提交按钮时，按钮的 Action 从数据模型中解析出最新值发送给 Agent。
动态列表是数据绑定的一个精彩应用：一个模板组件绑定到数据模型中的数组路径，数组中每增加一个元素就自动渲染一个新实例，且模板内的路径自动限定到当前数组元素的作用域。
3.4 消息类型与生命周期
以 v0.9 为例，Agent 与客户端之间通过四种核心消息通信。createSurface 创建画布并指定使用的组件目录。updateComponents 定义或更新 UI 组件。updateDataModel 更新应用状态。deleteSurface 移除一个界面。
一个典型的餐厅预订流程是这样的：Agent 先发送 createSurface 创建画布，然后通过 updateComponents 定义表单结构（标题、人数输入框、提交按钮），再通过 updateDataModel 填充初始数据（日期、人数）。用户修改人数，客户端自动更新本地数据模型。用户点击确认，客户端将按钮 Action 中引用的数据路径解析为当前值，封装为 action 消息发送给 Agent。Agent 处理后可以更新界面或删除 Surface。
3.5 Catalog（组件目录）
Catalog 是 A2UI 安全模型的关键枢纽。它是一个 JSON Schema 文件，定义了 Agent 可以使用的所有组件、函数和主题。客户端告诉 Agent 自己支持哪些 Catalog，Agent 在创建 Surface 时选择一个 Catalog 并锁定。之后 Agent 生成的所有 JSON 都会在双端被验证——Agent 端在发送前验证，客户端在接收后再验证。如果验证失败，客户端会发送 VALIDATION_FAILED 错误，Agent 可以据此自我纠正。
A2UI 团队维护了一个"Basic Catalog"作为起步用的通用组件集，但大多数生产应用会定义自己的 Catalog 来反映自己的设计系统。你可以从零开始定义，也可以导入 Basic Catalog 中的部分组件再扩展自定义组件（如图表、地图、股票行情组件）。Catalog 之间通过 URI 作为唯一标识符进行协商和版本管理。
3.6 传输层
A2UI 是传输无关的——任何能传递 JSON 的机制都可以工作。目前与 A2A 协议和 AG UI 有成熟的集成，REST、WebSocket 和 SSE 在路线图中。消息通常以 JSON Lines（JSONL）格式流式传输，每行一个完整的 JSON 对象。在 A2A 绑定中，A2UI 消息被编码为 DataPart，MIME 类型为 application/json+a2ui。
四、v0.8 → v0.9：从"结构化输出优先"到"提示词优先"
A2UI 的版本演进体现了对 LLM 生成能力更深层的理解。v0.8 被设计为通过 LLM 的"结构化输出"模式生成，依赖深层嵌套和特定的包装结构。v0.9 则做了一次哲学性的转变——为"嵌入系统提示词"而优化。
最直观的变化是组件格式从嵌套键变成了扁平判别器。v0.8 写作 "component": { "Text": { "text": { "literalString": "Hello" } } }，v0.9 则简化为 "component": "Text", "text": "Hello"。数据模型更新从键值对数组变成了标准 JSON 对象。子组件列表从 {"explicitList": [...]} 变成了简单的数组。这些改动大幅减少了 token 消耗，也更符合 LLM 天然擅长生成的 JSON 模式。
v0.9 还引入了几个重要的新能力：createSurface 消息要求指定 catalogId，使目录协商变得显式；新增了 sendDataModel 标志，允许客户端在每条消息的元数据中自动附带完整数据模型，实现"无状态 Agent"模式；引入了 formatString 函数支持字符串插值；以及结构化的 VALIDATION_FAILED 错误反馈机制，让 LLM 可以在"生成-验证-纠正"循环中自我改进。
五、双向交互：Action 与数据同步
A2UI 不只是单向的 UI 推送，它支持完整的双向通信。交互组件（如 Button）可以定义 Action，分为两种：Server Event 发送到 Agent 处理（如提交表单），Local Function Call 在客户端本地执行（如打开 URL、格式化字符串、输入验证）。
Action 中的 context 是一个精心设计的机制——它允许按钮在触发时从数据模型中"摘取"特定路径的当前值，封装成一个简洁的上下文对象发送给 Agent，避免 Agent 需要解析整个数据模型。
v0.9 的 Data Model Sync 更是支持了一种优雅的"口头提交"模式：当 sendDataModel 启用时，用户甚至不需要点击按钮——只要说"好的，提交吧"，客户端会将当前完整数据模型附在消息元数据中，Agent 从元数据中读取所有表单值即可完成处理。
在多 Agent 架构中，协调器（Orchestrator）需要维护 Surface 到子 Agent 的所有权映射，确保用户的 Action 被路由回正确的子 Agent，并且在转发消息时剥离其他 Agent 的数据模型，防止跨 Agent 的数据泄露。
六、生态系统与真实应用
A2UI 不是一个纸上协议——它已经在多个 Google 产品和合作伙伴项目中投入使用。
Google Opal 使用 A2UI 驱动 AI 小应用的动态生成式 UI 系统，让数十万用户可以用自然语言创建、编辑和分享 AI 应用。Flutter GenUI SDK 在底层使用 A2UI 作为服务端 Agent 与 Flutter 应用之间的通信协议，实现跨 iOS、Android、Web、桌面的原生渲染。Google ADK（Agent Development Kit）内置了 A2UI v0.8 标准目录的原生渲染支持。CopilotKit / AG UI 提供了 A2UI 的 Day-zero 兼容，AG UI 作为传输层，A2UI 作为 UI 内容格式，形成互补。
A2UI 与同类方案的定位也值得理解：MCP Apps 让远程服务器通过 iframe 提供完整的 UI 体验，适合服务器完全掌控 UI 的场景；AG UI 是一个前后端连接的传输协议；A2UI 则是 UI 负载本身的格式标准。三者可以组合使用——A2UI + AG UI 用 AG UI 做管道、A2UI 做内容，A2UI + A2A 用 A2A 协议在多 Agent 系统中传递 A2UI 消息。
七、动手试一试
体验 A2UI 最快的方式是运行仓库自带的餐厅查找器 Demo。克隆仓库、设置 Gemini API Key、进入 samples/client/lit 目录运行 npm run demo:all，就能在浏览器中看到一个由 Gemini 驱动的 Agent 实时生成交互式 UI 的完整流程。
如果你想更深入地开发，有三条路径可选：前端开发者可以将 A2UI 渲染器集成到自己的应用中（目前支持 Lit、Angular，React 在路线图中）；后端开发者可以使用 Google ADK 构建生成 A2UI 响应的 Agent；或者直接使用 AG UI/CopilotKit 或 Flutter GenUI SDK 等已内置 A2UI 支持的框架。
结语
A2UI 的出现代表了 Agent 交互范式的一次重要进化——从"Agent 只能说文字"到"Agent 可以说 UI"。它用声明式数据格式解决了安全问题，用邻接表模型解决了 LLM 生成和流式渲染的问题，用框架无关的抽象解决了跨平台问题，用 Catalog 协商机制解决了可扩展性问题。
作为 Google 发起、Apache 2.0 许可的开源项目，A2UI 目前处于 v0.8（稳定）和 v0.9（草案）阶段，正在积极向 v1.0 迈进。如果你正在构建 AI Agent 驱动的应用，无论是对话式界面、企业工作流还是多 Agent 系统，A2UI 都值得关注和尝试。
