Google 发布 A2UI 1.0，让 AI 回答变成可操作的表单
2026 年 11 月 11 日，Google 发布生成式界面开放协议 A2UI 的首个稳定版 1.0，让 AI Agent 可以用交互界面回应用户。对正在做 AI 助手、企业工作台和移动应用的开发者，这意味着回答里可以出现能修改、能确认的表单。本文用一个行程规划场景，解释它怎样工作、当前适合接到哪里，以及团队还要完成哪些开发工作。来源：Google 发布公告
原创 AI 概念插画，用于解释交互形式，非产品截图。
[配图建议：一段行程说明展开为可修改的表单，保留清晰的确认按钮 + 纸雕质感科技编辑插画]
一、AI 选择组件，应用负责把界面画出来
想象用户说“帮我安排周末两天的旅行”。一段完整回答可能包含目的地、日期、人数和交通安排。只要其中两项需要调整，用户就得再输入一轮自然语言，等助手重新组织答案。
A2UI 给开发者提供了另一种交互组织方式。Agent 描述要显示的组件与数据，应用里的渲染器把它们呈现为界面。日期可以放进输入控件，人数可以用选择器，方案可以配一个确认按钮。用户能直接修改明确的字段，助手再围绕这些选择继续工作。这里的行程表单是机制示例，具体功能由应用团队实现。
双方事先共享一份组件目录，也就是 catalog。它声明允许使用的组件、属性、函数和使用说明；Agent SDK 根据这些定义组织提示并校验输出，渲染端把组件对应到本地实现。一个团队若已设计好“行程卡片”，就可以把它加入目录，让 Agent 在约定范围内组合界面。来源：组件目录文档
这对产品设计的价值在于，把可变的内容和布局留给任务，把字号、交互反馈与组件行为交给应用维护。对于已有设计系统的团队，可复用的工作包括按钮、输入框和业务卡片；新工作则是为这些组件补齐可供 Agent 使用的契约，以及输入不完整时的处理方式。
[配图建议：Agent 从组件目录选择日期框、人数选择器和按钮，应用把它们组合成行程卡片 + 扁平流程示意图]
二、改一个日期以后，哪些步骤需要重新问模型
界面出现只是开始。真正决定体验的是，用户修改日期后，数据怎样流转。
A2UI 的界面数据模型与组件布局分开。输入框等控件可以把值绑定到数据路径；用户输入或切换选项时，渲染器立即更新本地数据模型。后端也能直接更新数据，例如将查询结果写入界面，无须先让语言模型重新生成一遍这些数值。来源：数据绑定文档
继续看行程例子。用户把人数从一人改成两人，字段先在本地变化；点击“查询余位”，可以调用已注册的后端函数；需要助手重新权衡方案时，再发送事件，进入下一轮 Agent 处理。官方文档明确区分这两条路径：事件推动 Agent 响应并更新界面，函数执行确定的逻辑，可以在渲染端或 Agent 端运行，无须开启新的 Agent 对话轮次。来源：动作与函数文档
1.0 加入的双向函数调用，使界面与 Agent 之间可以交换调用及返回结果。对业务表单来说，这给余位查询、字段校验等离散操作提供了协议表达。函数由谁调用、返回什么，也需要在目录和运行时实现中处理。来源：1.0 演进指南
团队可以据此划分交互：字段编辑留在本地，事实查询走业务接口，带有取舍的计划调整交给 Agent。预计能减少多少等待，仍要用真实任务观察。更值得先量的是，一次改动后用户是否看得懂状态、失败是否能恢复、确认时提交的内容是否与屏幕一致。
[配图建议：以修改旅行人数为例，分别画出本地更新、后端余位查询和 Agent 调整方案三条路径 + 白底交互时序图]
三、接入前先核对版本，已有项目也需要迁移
协议进入稳定版，具体平台仍有自己的支持进度。按 Google 11 月 11 日公告，选型时至少要区分以下几组。
| 接入位置 | 公告列出的支持范围 | 选型含义 |
|---|---|---|
| 自有 Web、Flutter 或 iOS 应用 | React、Angular、Lit、Flutter、SwiftUI 渲染器 | 结合项目框架核对对应 SDK 与组件实现 |
| Android Jetpack Compose | 当前支持 0.9.1，1.0 即将支持 | 接入前核对后续版本，预留适配工作 |
| Gemini 与 Lynx 现有集成 | 公告分别列为 0.9.1 与 0.9，升级仍在推进 | 按宿主当前协议版本设计消息 |
平台清单说明了生态覆盖，也说明了生成端、目录与渲染端需要一起对齐版本。不能只升级 Agent 依赖，就默认宿主能理解新消息。来源：Google 发布公告
已有 0.9 项目的一个具体迁移点是字段含义。1.0 的数据绑定指令使用 @path，但 updateDataModel 消息里的 path 仍保留原名。迁移指南专门提醒，不能把所有 path 一键替换。组件目录本身也存在结构变化，需要随运行时校验。来源：1.0 演进指南
这些成本适合在接入预算里提前体现。已有成熟组件库、业务 API 和明确表单流程的团队，更容易确定第一批目录；界面形态尚未稳定的项目，则可能同时维护产品设计、目录定义和多端实现。只有纯文本总结需求的功能，可以先保留现有交互，等出现明确的编辑或确认需求再评估。
[配图建议：一张版本对照卡展示 Web、移动端与宿主集成的进度，日期注明 2026-11-11 + 简洁文档信息图]
四、用一个能完成的小任务开始试用
官方快速入门提供 Travel A2UI 行程样例，由 Python 服务端配合 React 和 Flutter 客户端。文档明确它用于学习；应用导航、聊天界面和业务逻辑仍由开发者负责，调用模型与工具的 Agent 代码也在 SDK 之外。来源：官方快速入门
建议先照着样例走通“填写目的地、调整人数、确认方案”这一条路径，再替换成自己的一个业务任务。先固定少量组件，容易看清错误发生在哪一层。
- 先写验收任务。例如用户修改日期后，页面保留已填人数，并能重新查询候选方案。验收依据是完整操作结果。
- 记录三份信息：模型给出的界面描述、校验后的协议消息、用户修改后的数据状态。这样可以分别检查生成错误、目录不匹配和数据流问题。
- 让空结果、超时和重复点击也进入试用。查询失败时显示什么、重试后保留什么，都需要应用给出确定行为。
- 只扩展一个业务组件。例如加入自有的行程卡片，观察复用它比逐个拼基础控件是否更容易维护，再决定目录规模。
对独立开发者，这轮试用的产出可以很小：一张能够编辑并提交的卡片，加上一份操作记录。先确认这个界面确实让用户少解释了一次，再投入多端适配。A2UI 提供了描述和渲染界面的共同语言，实际任务完成率仍由数据、工具和应用实现共同决定。
[配图建议：样例试用台旁排列输入任务、消息记录与最终表单，标注空结果和重试观察点 + 工程笔记风格插画]
总结：先找一个需要用户确认的回答
A2UI 1.0 值得 AI 应用团队关注的，是把“读完回答再重新输入”变成“在回答中修改并确认”的可能性。已有组件与业务接口的团队可以先做小范围原型，纯文本需求则可暂缓。今天就挑一个经常追问日期、人数或选项的流程，用官方样例验证编辑与回传是否顺畅。你的产品里，哪个回答最适合先变成一张可操作的表单？
[配图建议：一张保留待确认日期与人数的行程卡片，旁边写下首个试用任务 + 留白充足的产品草图]
资料核查于 2026 年 11 月 12 日。本文依据官方公告与文档分析，未进行安装和性能实测；行程示例用于解释机制，封面为原创 AI 概念插画。
