让 AI 帮忙排一个日程，收到一份文字方案后，往往还得继续补充：“把周三换成周四”“删掉第二项”“这个时间再晚一点”。如果方案直接带着日期选择器和几个可修改的选项，许多来回确认其实可以省掉。
Google 在 2026 年 11 月 11 日发布的 A2UI 1.0，就在处理这类问题。这是 A2UI 开放式生成界面协议的首个稳定版本：Agent 描述需要展示什么，应用负责把这些描述呈现为用户能操作的界面。
它面向的是开发者。普通用户不会因为协议发布，就立即在所有 AI 应用里看到同一套新功能；产品团队还需要把它接进自己的业务。
界面由 AI 组织，组件仍由应用掌握
A2UI 把界面描述和实际绘制分开。Agent 输出结构化消息，说明要使用哪些组件、显示哪些数据；应用中的渲染器再用对应的界面框架，把它们画出来。
开发者会先定义一份组件目录，列出 Agent 可以使用的控件、属性和函数。Agent 可使用的界面能力由这份目录限定，输出还要经过校验。应用已有的按钮、卡片和选择器，因此可以继续沿用原来的外观和行为。
这种做法对已有产品比较友好。团队不必为了加入 AI，就让用户在熟悉的应用和风格完全不同的生成页面之间来回切换。哪些能力能够开放给 Agent，也有了具体的配置位置。
不过，组件范围受到约束，只能解决其中一部分问题。用户能读取哪些业务数据、某个按钮是否有权提交操作，仍需要应用自己的权限判断。
1.0 让界面和 Agent 的交互更完整
此次更新的一项重点是双向函数调用。Agent 和渲染器可以向对方发起函数请求，再接收执行结果或错误信息。开发者若实现了查询函数，日期选择器就可以据此请求更新可用时间，而不用把每次修改都改写成一句聊天消息。
1.0 还允许在同一个界面中组合多个组件目录的内容，但这些目录需要使用相同的 A2UI 规范版本。无障碍支持也有所扩展，包括动态内容更新提示、隐藏内容属性，以及渲染器应遵循的要求。
已经使用 0.9 的项目，升级时需要检查实际消息和交互流程。官方迁移指南列出了消息名称、目录定义和保留字段的变化，并提醒不要对某些数据字段做不加区分的全文替换。只更新依赖版本，未必就能完成迁移。
各个平台并没有同时到达 1.0
按当前官方 SDK 文档，React、Angular、Lit、Flutter 和 SwiftUI 已列出 1.0 支持；Agent 端提供 Python、TypeScript 和 Dart SDK。
但几个常见入口还存在版本差异。发布公告注明，Jetpack Compose 当前支持 0.9.1，1.0 尚待推出；字节跳动的 Lynx 渲染器目前支持 0.9，正在适配新版本。Google 自己的 Gemini 接入也仍标注为 0.9.1，Gemini Enterprise 的 1.0 升级仍在推进。
因此，准备接入时要同时看三件事：使用哪个渲染器、它支持哪个协议版本，以及最终运行它的宿主支持到哪里。不能仅凭“已经有 Android 或 Gemini 支持”，就认为所有 1.0 能力都能直接使用。
它也可以与 MCP Apps 配合
如果目标宿主支持 MCP Apps，却没有直接集成 A2UI 渲染器，可以把 Web 渲染器放进 MCP App。A2UI 消息在宿主的隔离框架内变成界面，用户操作再通过 MCP Apps 的工具调用通道传回。
这为接入提供了另一条路径，但沙箱、内容安全策略和版本兼容仍然需要处理。官方指南也区分了较旧的社区示例与新版实现说明，照着示例接入前，要先看清它实际使用的协议版本。
更适合从一个具体操作开始
对开发团队来说，可以先挑一段已经让用户觉得费劲的流程，例如修改一份计划、比较几个候选方案，或者确认提交内容。值得观察的是：来回修改有没有减少，数据更新后用户是否还能看懂当前状态，工具调用失败时能否顺利恢复。
官方快速入门使用了旅行规划示例，由 Python 服务端配合 React 和 Flutter 客户端。文档明确说明，它是学习示例，并非可以直接上线的旅行服务。真实业务里的账号、权限、外部 API 和交易处理，仍要由开发者完成。
项目仓库采用 Apache 2.0 许可，但部署 Agent 时，模型调用、服务器和外部服务仍可能产生费用，不能把开源理解为整套应用运行免费。
A2UI 1.0 提供了一种值得尝试的交互方式：用户可以直接修改 AI 给出的内容，而不必把每个调整都重新描述一遍。它究竟能减少多少操作，需要放进具体产品里验证。
本文依据截至 2026 年 11 月 12 日可读的官方公告和文档整理，未进行实际接入或性能测试。