A2UI 1.0 为智能体统一跨端交互界面

AI Agent 能替你查资料、拟计划，却常把需要比较和确认的事情变成一长串文字。Google 发布的 A2UI 1.0 想解决这个交互问题：让 Agent 返回表单、图表和可操作的卡片，再由应用用自己的组件渲染。

它值得前端和全栈开发者关注的地方，是把模型生成界面的自由度收进组件和协议的边界。不过，协议进入稳定版，不代表各端都已跟上，也不代表原文宣称的低延迟和可靠性已经有对照数据支撑。

Agent 描述界面，应用掌握组件

A2UI 是生成式界面（Generative UI）的开放协议。Agent 描述界面应该展示什么，应用接收 A2UI 消息，再用本地注册的组件绘制出来。

这套分工很关键。模型只能选择和配置开发者注册的组件，因此品牌样式、交互行为和组件实现仍由应用控制。对于已有设计系统的团队，接入的重点是把现有组件开放给 Agent 使用。

原文用生病请假的场景说明价值：预约视频问诊、调整会议、通知团队、开启自动回复、安排接孩子、订汤，涉及六个应用。如果 Agent 只返回文字，用户还得多轮解释要改哪些事项；如果它把六件事放在同一视图里，用户可以点选调整，确认后再执行。

A2UI 解决的是计划如何展示和修改，真正执行任务仍要靠开发者构建的 Agent。

另一个例子是把晚餐改到周五：界面同时展示日历、餐厅空位和网约车价格，让用户直接比较。A2UI 提供描述视图、组合不同应用组件和跨平台渲染的框架，但应用接入、权限与执行逻辑仍需要团队完成。原文没有展开这些部分的实现。

1.0 稳定了什么，各端又跟到了哪里

A2UI 1.0 新增双向函数调用。例如航班或预订选择器，可以在交互过程中即时检查可用性，不必每次都重新进入一轮文字对话。协议还增加了无障碍支持，以及承载额外元数据的扩展机制。

渲染端覆盖面很广：Web 支持 React、Angular 和 Lit；Flutter 覆盖移动端、Web 和桌面端；iOS 使用 SwiftUI；Android 使用 Jetpack Compose。

但版本需要逐项核对。Jetpack Compose 当前支持 v0.9.1，v1.0 尚未推出；Gemini 当前支持 A2UI 0.9.1；Gemini Enterprise 已能使用 A2UI，升级到 1.0 的工作仍在进行。ByteDance 于 2026 年 6 月发布 Lynx 渲染器，当前支持 A2UI 0.9，正在适配 1.0，其默认组件基于 lynx-ui。

A2UI 和 MCP Apps 也可以配合。前者负责描述界面，后者提供在支持它的 AI 助手中承载应用界面的方式。Web 和 Flutter 渲染器可以运行在 MCP Apps 内，Alation 已用这套组合把数据卡片和图表展示在 Claude 对话中。

因此，选型时要分别确认协议版本、目标渲染器版本和宿主支持情况。不能看到「1.0 稳定版」，就默认整条链路已经同步升级。

更快、更可靠，靠的是限制生成和服务端绑定

Agent SDK 支持 Python、TypeScript 和 Dart，可帮助接入现有 Agent 框架，承担生成 skills、转换消息和纠错等工作。对使用 TypeScript 的前端或 Node 团队，这提供了现成入口，但原文没有给出完整接口或接入代码。

生成方式也不止一种。原文提到 A2UI Express，以及「system one」决策模型：后者通过选择组件组织界面，减少持续生成文本的需要。SDK 还提供可替换的推理格式，用于降低延迟；Python 的 A2UI Macros 则支持以程序方式展开组件和绑定数据。

另一项设计是把数据与子组件的绑定放在服务端，使敏感值不必进入模型，同时让界面随 Agent 的工作逐步流式呈现。模型负责组织展示结构，真实数据由服务端补入，这对需要显示业务数据的界面很有吸引力。

不过，「敏感值不进入模型」有适用边界：它依赖数据确实通过这条绑定路径处理。原文没有说明完整的权限、日志和工具调用策略，不能把这一点扩大成整个系统的安全保证。

落地案例展示了几种用法。Jira 中的 Agent 缺少信息或需要决策时，可以在工作项里发出交互卡片；Alation 的图表可以展示背后的 SQL 和数据；Gemini Notebook 先让用户选择演示文稿类型和重点，再通过可编辑的审核卡片确认格式与视觉风格。

这些案例证明了交互形态有实际用途，却没有给出延迟、错误率或任务完成率的对照数据。

我的判断

我认可它把组件控制权交回应用的方向。对产品团队而言，模型可以临时组织界面，但按钮如何执行、图表如何显示、表单如何校验，仍需要稳定且可审查的实现。A2UI 为两者建立了协议边界。

它也有明确前提：团队需要组件库、数据接口和任务执行能力。如果这些基础尚未准备好，接入协议不会自动消除工程成本。跨应用组合尤其如此，原文里的六应用视图是场景示例，不能当作开箱即用的能力清单。

与固定表单或预设卡片相比，A2UI 更适合任务结构会变化、需要 Agent 临时组合信息的场景。如果业务流程始终固定，一套普通页面可能更容易测试和维护。与让模型直接生成页面代码相比，它限制了表达自由，也让组件行为更容易控制。

原文展示了架构选择和产品案例，没有证明它在所有任务上都更快、更可靠。

模型选择组件的准确率、纠错次数，以及流式渲染中的异常状态，仍需要团队自己验证。官方 SDK 对 Jev 等决策模型的支持还在路线图中，也应和已交付能力区分开。

能拿来做什么

• 从一个需要反复确认的任务开始试验，例如让 Agent 生成可编辑的计划审核卡片。比较用户修改计划需要多少轮交互，再决定是否扩大范围。
• Web 或 Node 团队可以先用 React、Angular、Lit 渲染器和 TypeScript Agent SDK 验证闭环，把组件注册、消息转换、用户操作回传和执行确认串起来。
• 有跨端需求时，先核对目标端支持的 A2UI 版本，再评估组件映射与交互差异。涉及 Jetpack Compose、Lynx 或 Gemini 时，尤其要检查 0.9、0.9.1 与 1.0 的兼容情况。
• 需要在 Claude 或 Gemini 中展示业务界面时，可以评估 A2UI 与 MCP Apps 的组合；测试时同时检查数据绑定、权限和失败处理，不要只验证卡片能否显示。