A2UI 1.0：Agent开始画界面

Google 于 11 月 11 日正式发布 A2UI 1.0，这是这套生成式 UI 开放协议的首个稳定版本。它试图解决一个越来越明显的问题：Agent 已经能调用工具、处理文件和执行工作流，但与用户交互时，往往仍然只会吐出一大段文字。

**A2UI 是一种让 AI Agent 用结构化数据描述交互界面、再由客户端使用原生组件完成渲染的开放协议。**它不要求模型生成 HTML、JavaScript 或 React 代码，而是让 Agent 从应用预先允许的组件目录中，选择文本、按钮、表单、日期选择器、卡片等组件，再把组件结构和数据通过 JSON 消息发送给客户端。

这意味着，当用户让 Agent 比较三款产品、确认一张差旅订单或修改一个项目计划时，最终结果不必再是 Markdown 表格加一串编号，而可以是一张能筛选、编辑和确认的原生界面。

这次发布了什么

A2UI 1.0 的核心变化是把协议从单向的“Agent 画界面”，升级为 Agent、界面和应用功能之间的双向交互。

Google 在此次发布中确认，开发者可以搭配 Web、Flutter、SwiftUI 等开源渲染器，以及 Python、TypeScript 和 Dart 的 Agent SDK 使用 A2UI。Atlassian、Alation、彭博社和字节跳动等公司已经开始基于它开发产品。(developers.googleblog.com)

A2UI 1.0 主要增加了以下能力：

• 双向函数调用：Agent 可以调用客户端渲染器中的函数，客户端也可以调用 Agent 侧注册的函数，并获得结构化返回结果。
• 单消息创建界面：createSurface 现在可以直接携带组件树和数据模型，简单界面不必拆成多条消息才能完成初始化。
• 可访问性支持：组件可以声明标签、描述、动态播报模式和隐藏状态，渲染器再映射到 WAI-ARIA、SwiftUI 或 Flutter 的可访问性能力。
• 扩展元数据：开发者可以添加审计标签、权限信息和遥测标识，同时维持严格的 Schema 校验。
• 组件目录混用：同一界面可以组合不同 Catalog 中的组件，方便企业逐步接入现有设计系统。

根据 A2UI 的 v1.0 规范，双向调用对应 callRendererFunction、callAgentFunction 及其响应消息；所有消息仍需通过 JSON Schema 校验，未知字段默认不能随意混入协议。(github.com)

| 能力 | A2UI 0.9.1 | A2UI 1.0 | |---|---|---| | 协议状态 | 上一代生产版本 | 当前稳定版本 | | 用户操作回传 | 支持 Action 事件 | 支持 Action 与双向函数 RPC | | 首屏创建 | 通常分开发送结构和数据 | 可在 createSurface 中内联组件与数据 | | 可访问性 | 依赖具体实现 | 协议层提供标准属性 | | 扩展数据 | 扩展方式较分散 | 统一放入 metadata.extensions | | Catalog | 单一目录为主 | 支持按组件混用目录 |

Agent 发的不是代码，而是“界面订单”

A2UI 最重要的设计决定，是把 Agent 限制在声明式数据层，而不是让它直接生成和执行前端代码。

可以把它理解成餐厅点单：Agent 负责告诉厨房需要哪些菜、数量和组合方式，但不能跑进厨房随意操作燃气设备。客户端掌握真正的组件实现、品牌样式、权限和执行逻辑。

一个典型的 A2UI 工作流包括六步：

1. 用户向 Agent 提出任务，例如“帮我安排周五晚上的聚餐”。
2. Agent 调用日历、餐厅和出行工具，得到结构化结果。
3. Agent 输出 A2UI 消息，描述日期选择器、餐厅卡片、价格和确认按钮。
4. 客户端把描述映射为自己的 React、Flutter 或 SwiftUI 组件。
5. 用户点击或修改表单，交互事件被发送回 Agent。
6. Agent 根据新状态更新局部组件，而不是重新生成整张页面。

**这种架构的安全性来自能力白名单，而不是期待模型永远不犯错。**客户端只注册允许使用的组件和函数，Agent 即使生成了不存在的组件、非法参数或错误 ID，也会在 Schema 校验或服务端状态验证阶段被拒绝，而不是变成一段直接执行的任意代码。

A2UI 官方仓库将其描述为“用数据而不是代码表达 UI”，并采用 Apache 2.0 许可证。截至 2026 年 11 月 12 日，该项目在 GitHub 已获得约 1.7 万个 Star，说明生成式 UI 已经从小众前端实验进入 Agent 基础设施的主赛道。(github.com)

原生渲染不是一句营销话术

A2UI 所说的原生 UI，不是把一段网页塞进 WebView，而是让宿主应用用自己的组件库重新绘制 Agent 描述的界面。

这件事对企业应用尤其重要。一个银行 App 不可能允许模型临时生成未经审核的转账页面，一个协作软件也不希望 Agent 输出的按钮、间距和交互状态完全脱离产品设计系统。

A2UI 的 Catalog 可以被视为 Agent 可使用的组件合同。前端团队定义哪些组件可以出现、每个组件接受哪些属性、哪些函数可以被调用；Agent 只能在合同范围内组合界面。

| 平台或框架 | 当前支持情况 | 渲染方式 | |---|---|---| | React | 支持 A2UI 1.0 | 映射为 React 组件 | | Angular | 支持 A2UI 1.0 | 映射为 Angular 组件 | | Lit | 支持 A2UI 1.0 | 使用 Web Components 渲染 | | Flutter | 支持 A2UI 1.0 | 覆盖移动端、Web 和桌面端 | | SwiftUI | 支持 A2UI 1.0 | 使用 iOS/macOS 原生组件 | | Jetpack Compose | 当前公开实现主要对应 0.9.1 | A2UI 1.0 支持仍在推进 |

这里有一个容易被新闻标题忽略的细节：A2UI 协议已经进入 1.0，但所有平台的渲染器并没有同时完成 1.0 对齐。Google 的发布说明明确表示，Jetpack Compose 当前仍主要支持 0.9.1，1.0 版本随后提供。(developers.googleblog.com)

换句话说，A2UI 1.0 是协议稳定，不代表整个多平台工具链已经没有版本差异。准备在 Android 大规模落地的团队，仍需检查渲染器的实际线协议版本，而不能只看依赖包名称中的“1.0”。

双向函数调用，让界面真正活起来

双向函数调用是 A2UI 1.0 从展示协议走向应用协议的关键一步。

在旧的生成式 UI 方案中，界面经常只是一次性结果：Agent 生成卡片，用户点击按钮，客户端把整个操作重新包装成一条自然语言消息，再发回模型处理。这条链路不仅慢，也很难保证参数类型和状态一致。

A2UI 1.0 允许界面调用 Agent 端函数，也允许 Agent 请求客户端执行本地函数。例如，一个航班选择器可以在不重建整个页面的情况下查询余票；一个报销界面可以调用本地格式化函数；一个表单可以让 Agent 侧函数完成远程校验，并把结果更新到对应输入框。

**函数调用不等于把客户端权限全部交给模型。**Catalog 可以声明函数允许由 Agent 调用、仅允许渲染器调用，还是双方都能调用；调用参数还必须符合预先定义的 Schema。

这种设计把权限控制从提示词约束下沉到了协议和运行时。模型可以提出调用请求，但是否执行、允许哪些参数、结果如何返回，仍由应用决定。

A2UI、AG-UI 和 MCP 不是同一种东西

**A2UI 主要定义“界面长什么样”，AG-UI 主要定义“Agent 运行过程中发生了什么”，MCP 则主要解决模型和外部工具如何连接。**三者存在重叠，但并不是简单的替代关系。

AG-UI 是 CopilotKit 推动的 Agent 与前端交互协议，它通过 SSE 或二进制传输发送文本增量、工具调用、状态变化和运行生命周期事件。A2UI 更关注组件树、数据绑定、渲染目录和跨平台原生展示。AG-UI 可以承载一次 Agent 运行，而其中的生成式界面仍可使用 A2UI 描述。(github.com)

| 协议或方案 | 主要解决的问题 | 输出重点 | 典型使用场景 | |---|---|---|---| | A2UI | Agent 如何安全描述跨平台 UI | 组件、数据模型、交互和函数 | 表单、仪表盘、审批页、商品比较 | | AG-UI | Agent 如何向前端流式同步运行状态 | 文本、工具调用、状态和生命周期事件 | Agent 对话、任务进度、人机协作 | | MCP | 模型或 Agent 如何连接工具与数据 | 工具、资源、提示及应用能力 | 搜索、数据库、文件和企业系统接入 | | 直接生成 React/HTML | 快速生成特定页面代码 | 可执行前端代码 | 原型、低风险内部工具、代码生成 |

A2UI 也可以运行在 MCP Apps 环境中。Web 和 Flutter 渲染器能够把 A2UI 内容展示在支持 MCP 应用的 AI 助手内，这让同一个 Agent 界面既能出现在企业自己的 App 中，也能进入 Gemini、Claude 等第三方助手。

这也是 A2UI 最有战略价值的部分：企业不必为每一个 Agent 宿主重新开发一套交互页面，而是维护组件目录和渲染器，把 Agent 输出作为可移植的界面描述传递。

性能问题仍然存在，只是有了更明确的解法

**生成式 UI 的最大体验风险，是模型生成一张界面可能比生成一句文字更慢。**组件层级、绑定路径和属性越多，模型需要输出的 Token 越多，首屏等待时间也越长。

Google 在 10 月底公布的 A2UI Express 是一种更紧凑的推理格式。按照官方测试数据，A2UI Express 生成同类 UI 时最多可减少约 3 倍 Token，并将延迟降低至原来的约三分之一；使用 Jev 一类专门做布局决策的模型时，布局决策速度最高可达到传统生成方式的 80 倍。(developers.googleblog.com)

这些数字需要谨慎理解。80 倍指的是特定决策模型进行布局选择的速度差异，并不代表整个 Agent 任务端到端加速 80 倍。真实延迟仍然取决于工具调用、网络、模型推理、Schema 校验以及客户端渲染。

A2UI 的优势是允许开发者替换推理格式。复杂、个性化程度高的界面可以交给大模型生成；高频、结构稳定的页面则可以让轻量决策模型从已有布局中选择。它并不是要求每一个按钮都由大模型现场“思考”出来。

这对开发者意味着什么

A2UI 不会消灭前端开发，反而会把前端工作的重心推向组件合同、状态管理和权限边界。

开发者仍然需要建设可复用组件、定义数据绑定、处理加载和错误状态、保证键盘操作与屏幕阅读器可用，并对不同尺寸的屏幕进行适配。A2UI 只是让 Agent 获得了动态组合这些能力的语言。

真正减少的工作，是为每一种 Agent 结果单独编写页面和条件分支。例如过去为了展示“酒店列表”“航班比较”和“订单确认”，团队可能需要分别定义三套响应结构和前端页面；使用 A2UI 后，可以让 Agent 在同一套受控组件目录中动态组合结果。

**A2UI 最适合结果形态复杂、需要确认或编辑、同时又要求品牌一致性的 Agent 产品。**如果产品只是简单聊天、问答或代码补全，引入完整的组件目录、渲染器和协议状态机，收益可能覆盖不了工程成本。

比较值得优先尝试的场景包括：

• 企业审批、报销和工单处理；
• 电商商品比较与订单确认；
• 数据分析结果和交互式图表；
• 旅行规划、日历和多人日程协调；
• 医疗记录查看与预约流程；
• 智能家居控制面板。

A2UI 1.0 的真正意义

A2UI 1.0 的意义不是让 Agent 自动成为 UI 设计师，而是首次给 Agent 生成界面划出了一套相对清晰的工程边界。

过去的 Generative UI 往往在两个极端之间摇摆：要么只能返回文字和固定卡片，安全但能力有限；要么让模型直接生成代码，灵活但难以审计、难以跨平台，也很难进入金融、医疗和企业软件等高信任场景。

A2UI 选择了中间路线：模型决定界面的内容和组合，应用决定可用组件、视觉实现和执行权限。这个分工不够“魔法”，却更接近能进入生产环境的工程方案。

它当前的问题同样明确。多平台渲染器仍有版本差异；团队必须维护 Catalog 和组件映射；复杂界面依旧会增加推理延迟；协议兼容并不等于不同应用的组件语义完全一致。

但从 A2UI 1.0 开始，“Agent 的回答”不再天然等于一段文本。下一阶段的 Agent 竞争，很可能不只是比较谁回答得更准确，而是谁能把工具结果组织成更快、更安全、也更容易让用户完成操作的界面。

参考来源

• IT之家：Google 发布 A2UI 1.0，字节跳动等公司已开始使用——本次发布事件、合作公司和平台支持信息。
• GitHub：A2UI 官方开源仓库——项目架构、许可证、渲染器和 Agent SDK 说明。
• GitHub：A2UI v1.0 协议规范——双向函数调用、可访问性、数据绑定和扩展元数据定义。
• GitHub：AG-UI 官方仓库——用于对比 Agent 事件流协议与 A2UI 的职责边界。
• 知乎：A2UI 渲染机制与生成式 UI 解析——A2UI 消息、组件映射和流式渲染的中文技术说明。