A2UI 1.0 是什么？Agent 动态界面、审批与安全实测

A2UI 1.0 是什么？Agent 动态界面、审批与安全实测

A2UI 1.0（Agent-to-User Interface）是什么？ 它是一套让 AI Agent 通过结构化 JSON 描述交互界面的协议，由宿主应用使用自己批准的组件渲染，而不是让模型随意生成并执行 HTML/JavaScript。它可以让聊天助手展示可更新的卡片、表单和确认按钮；但界面能否安全使用，关键仍是“谁拥有执行权”。AI Agent 能帮用户安排计划，却经常把结果写成一长段文字。涉及确认日程、选择方案、预览报告等任务时，一张可编辑、可确认的界面比文字更合适。但如果界面本身由 Agent 描述，一个重要问题随之出现：Agent 能否借着“生成按钮”获得发送邮件、删除文件或部署系统的能力？

结论先说：不能把界面生成、点击确认和工具授权混成一件事。 A2UI 1.0 把界面描述为结构化消息，宿主应用负责选择可信组件并渲染；用户点击只是交互事件；是否真正执行外部工具，仍由可信执行器的权限策略决定。若宿主没有实现校验，声明式协议也不能自动替它保证安全。

2026 年 11 月 11 日，Google 宣布 A2UI 1.0 稳定协议，提供包括 Web、Flutter 和 SwiftUI 在内的开源 Renderer，并明确 Android Jetpack Compose 的 1.0 适配仍需后续推进。Google 1.0 公告 和 A2UI 协议规范 是版本事实来源。

为避免只改写官方公告，XBSTACK 在 11 月 12 日做了一个不联网、不调用真实工具的最小实验：6 项 Node 规则测试和 1 项真实 Chrome 浏览器综合测试通过，浏览器测试同时覆盖 1280px 桌面和 390px 手机视口。下文区分：官方协议规定的能力、本站确实执行的实验与尚未验证的生产环节。

一、A2UI 1.0 解决的不是“让模型生成网页源码”

A2UI（Agent-to-User Interface）让 Agent 用 JSON 消息描述界面结构和数据，客户端再以自己注册的组件绘制 UI。例如，Agent 可以提议展示一个报告卡片、按钮和更新后的数据，但不应直接把任意 JavaScript 或 HTML 交给浏览器执行。

这有三个实用好处。第一，React、Flutter、SwiftUI 等宿主可以保留各自的设计体系；第二，同一个界面可以随消息流逐步更新，不必每次重新生成完整页面；第三，宿主能够把组件种类、属性和行为限定在显式许可的目录里。

从 AIGC（人工智能生成内容）和 AI 编程的角度看，A2UI 可以用于生成式交互界面：例如，AI 编程助手在完成代码分析后展示测试结果卡片、修复方案选择器或变更确认表单，让程序员检查后再采取操作。但A2UI 不负责生成程序代码、证明代码正确或取代开发者；它只规定 Agent 如何向宿主描述这类界面，真正执行修复仍需应用的工具授权。

但这种架构的安全性取决于具体 Renderer 的实现和工具后端。如果一个宿主把来自 Agent 的字符串直接塞进 innerHTML，或者允许模型声明任何可执行组件，那么“协议是 JSON”也救不了错误的实现。

官方 1.0 除了界面生命周期消息，还引入双向函数调用、扩展元数据和无障碍方面的规范。当前版本与各平台 Renderer 的实际支持范围需要单独对照，不能只看一篇通用发布新闻就认定 Android/iOS 均已验证。官方规格

A2UI 怎么用？从一个 Agent 动态表单开始

如果只想快速理解使用路径，可以把 A2UI 分为三步：先选宿主 Renderer 和它允许的组件目录（例如文本、卡片、输入框和按钮），再让 Agent 发送创建界面与更新数据的 JSON 消息，最后由宿主收集用户输入并向可信业务端传递经校验的事件。比如旅行 Agent 可以先展示多个路线卡片，再随着查询结果更新价格或时间，最后让用户确认选择。整个过程不要求 Agent 自己输出完整的网页源码。

官方支持 React、Angular、Lit、Flutter 和 SwiftUI 等不同 Renderer，但平台与协议版本必须单独核验：截至 2026 年 11 月 12 日，Google 的公告仍将 Jetpack Compose 标为 0.9.1，1.0 待适配。想跑完整的官方入门流程，应优先使用Google A2UI Codelab；本文后面的 Node/Chrome 演示专门测试安全边界，并非官方 SDK 入门工程。

A2UI、AG-UI、MCP Apps、Function Calling 有什么区别？

技术	主要解决的问题	与 A2UI 的关系
A2UI	用 JSON 描述动态界面、数据绑定和组件结构	本文主题：宿主将描述映射到批准的组件
AG-UI	连接 Agent 与应用前端，传输运行事件和状态变化	可以作为承载 A2UI 消息的交互通道
MCP Apps	通过 MCP 交付可嵌入的自定义界面，常以沙盒 iframe 展示	可与 A2UI 配合，侧重更自由的前端实现
Function Calling	模型提出结构化工具调用参数，由应用决定是否执行	解决工具调用，不是界面渲染或自动授权

因此，A2UI 不是 AG-UI 或 MCP Apps 的简单替代品，也不是给工具调用加了个按钮就能越权执行。这个分层来自Google 对 A2UI 与 MCP Apps 的说明及AG-UI 官方协议概览，实际项目也可按需要组合不同层。

二、四种消息怎样决定界面，而不是业务权限？

本文本地实验只模拟了 1.0 消息中的以下四种。实际官方规范还包含双向函数调用等其他消息；不要把我们的最小子集当成完整的 A2UI 1.0 实现。

消息	在界面层做什么	不能据此推断
createSurface	建立一个 surface 和初始组件/数据	不能据此获得读取用户资料的权限
updateComponents	增加或替换组件描述	不能借机注册未知的远程脚本组件
updateDataModel	修改绑定的数据	不能把数据值当作 HTML/JS 执行
deleteSurface	结束这个界面的生命周期	不能等同于删除真实用户文件

A2UI 1.0 和 0.9.1 有什么不同？

升级时至少要核对三类差异。第一，1.0 允许在 createSurface 中同时提供初始 components 和 dataModel，而 0.9.1 的数据初始化流程不同；第二，1.0 的 updateDataModel 删除键应显式使用 value: null，不能照搬旧版省略 value 的写法；第三，1.0 引入双向函数调用，例如 callRendererFunction / callAgentFunction，需要额外校验调用的组件目录、允许的函数和宿主权限。相关格式见 A2UI 1.0 消息参考。

出现“更新后界面不显示”“数据绑定无效”“版本不匹配”时，先检查发消息端、Renderer、Catalog 和 Schema 是否都使用同一个协议版本，再检查 surfaceId、组件引用和数据路径；本文没有复现某个官方 SDK 的上述报错，不将排障路径冒充已证实的上游 Bug。

例如，下面的消息只描述“屏幕上出现一段文本”，并不包含发送电子邮件的指令：

{
  "version": "1.0",
  "createSurface": {
    "surfaceId": "report_preview",
    "catalogId": "https://a2ui.org/specification/v1_0/catalogs/basic/catalog.json",
    "components": [
      {"id":"root","component":"Column","children":["summary"]},
      {"id":"summary","component":"Text","text":{"@path":"/summary"}}
    ],
    "dataModel": {"summary":"拟生成只读站点审计报告"}
  }
}

这里的“Text”“Column”必须出现在宿主允许的组件目录中，数据路径也需要按协议规范解析并进行类型检查。即使 Agent 提供了貌似合法的 JSON，也应由宿主拒绝重复 ID、断开的组件引用、环形引用、未知事件和不支持的属性。

三、一次最小实验：哪些东西确实被拒绝？

我们建立了只接受 Column、Card、Text、Button 的本地目录，并约束按钮事件只允许 request_approval 或 cancel_preview。浏览器侧使用 DOM 节点和 textContent 显示文本，没有把模型输出拼接成 HTML。

公开可复现代码：XBSTACK AI Site Kit — A2UI controlled preview。在仓库目录执行：

git clone https://github.com/xbstack/xbstack-ai-site-kit.git
cd xbstack-ai-site-kit
node --test examples/a2ui-1-0-controlled-preview/core.test.mjs

可选的浏览器测试在本次记录中使用 macOS Chrome 与 playwright-core：

npm install --no-save playwright-core
node --test examples/a2ui-1-0-controlled-preview/browser.test.mjs

浏览器测试中的 Chrome 路径固定为 macOS 系统 Chrome；Windows/Linux 需调整可执行文件路径。上述命令没有调用任何云端模型、付费接口、真实邮箱、文件删除或生产部署。

**2026-11-12 本地验证结果：**六项 Node 规则测试与一项 Chrome 综合测试，7/7 PASS。浏览器综合测试分别在桌面 1280×800 与手机 390×844 视口检查交互；这不是七款浏览器、七台手机或七个商业 Agent 的横向比较。

验证内容	实际验证结论
Surface 创建、数据更新、删除生命周期	在受控状态存储中按预期工作
未授权组件及事件	模拟 RemoteScript 组件和未知事件被拒绝
ID 引用和恶意模型属性	环、缺失引用和原型污染路径被拒绝
HTML 注入文本	img/onerror 字符串以纯文本显示，没有生成 img DOM 节点
用户点击审批	打开本地确认弹窗，只记录事件，外部工具调用次数为 0
浏览器适配	在两种视口完成相同流程，没有测试到的页面错误和非本地请求

其中最容易被误解的是第四项。实验把一段看似 HTML 的文本写入 DataModel，再渲染到页面。因为使用 textContent，浏览器显示字符串而不解析标签。这能证明这份最小 Renderer 对该输入的处理方式，却不能证明任何第三方 A2UI Renderer 都没有 XSS，也不能覆盖复杂 URL、富文本、CSS 或扩展组件的全部攻击面。

四、用户点了“确认”，为什么仍不能执行工具？

请区分三个角色：

1. **Agent / UI 描述层：**提出展示什么、收集什么输入。
2. **Renderer / 交互层：**判断允许什么组件、什么数据、什么事件，收集用户决定。
3. **Tool Executor / 授权层：**根据服务端可信身份、当前租户、Scope、目标资源、参数和风险策略，决定能否产生真实副作用。

假设用户看到一张退款预览卡片并点击“确认”。这个事件证明用户在该界面做过一次选择；它并不证明请求一定属于当前用户、退款对象未被替换、金额仍在授权范围内，或者队列重试不会再退款一次。

正确工程边界是在真正执行之前再次检查身份、资源所有权、参数摘要、授权策略版本，以及幂等键。高风险操作还可能需要二次认证，而不是仅在 UI 上展示一个绿色确认按钮。站内已有的 Agent Tool Authorization：Policy Gate 与逐调用控制 详细讨论这层后端决策；本文的 A2UI 实验并未实现该 Policy Gate。

对于 1.0 的双向函数调用和用户激活要求，应以具体 Renderer 的实现和官方规范逐项验证；不能仅凭事件名叫“approval”就允许任意远程函数运行。CopilotKit 1.0 说明

五、工程落地时，最容易出错的五个地方

一是把未知组件当成默认可渲染。 组件目录必须是白名单而不是黑名单；遇到不存在的组件、危险属性或无法解析的子节点，拒绝比“尽量渲染”更可靠。

二是把 DataModel 数据当成可执行模板。 用户文本、链接、文件路径、富文本都有不同的安全策略。HTML 文本注入通过一次测试，不代表扩展组件的外链与脚本执行自动安全。

三是把界面点击当成业务授权。 人工确认必须与当前请求的身份、目标、参数和有效期绑定。审批通过后若参数发生变化，应重新判定，执行前应继续检查服务器策略。

四是忽视生命周期和流式消息的顺序。 Surface 未创建却收到组件更新、同一 ID 冲突、重复消息重放或删除后旧事件到达，都应有明确的错误和恢复语义，而不是静默承接到错误的页面。

五是把“1.0 协议稳定”写成“所有端已兼容 1.0”。 Google 11 月 11 日公告列出 React、Angular、Lit、Flutter、SwiftUI 等 Renderer，同时明确 Jetpack Compose 当时支持 0.9.1、1.0 待更新。真实跨端项目必须基于具体 SDK 版本、平台控件、无障碍与事件行为独立验收。

六、什么时候应该采用 A2UI？

适合：Agent 需要让用户在可控界面中选择方案、调整参数、预览记录、提交人工决策，而你又希望同一任务能跨多个宿主 UI 框架复用。

暂缓：你的产品只需要一个固定表单；目前没有足够资源维护组件目录、事件审批、业务授权与各端兼容测试；或者把“支持 A2UI”错误理解为允许远程模型直接操作本机权限。

更实际的采用顺序是 单场景原型 → 组件与数据白名单 → 负面输入测试 → UI 交互验收 → 后端授权与幂等 → 官方 SDK 逐端兼容验证。我们目前只完成其中一部分，不能把受控预览当成生产合规证明。

对 XBSTACK 来说，这次实验值得记录，不是因为又多了一个新技术名词，而是它验证了独立开发者经常需要守住的一条边界：界面可以由智能体提出，但执行权必须留在可信宿主手里。

来源与延伸阅读

• Google Developers：A2UI 1.0 公告（2026-11-11） — 新版本与各平台支持范围。
• A2UI 1.0 正式协议规范 — 消息结构、生命周期与扩展。
• Google Codelabs：ADK + A2UI — 官方入门路径，与本站独立实验不同。
• CopilotKit：A2UI 1.0 与用户激活 — 受信函数调用的额外边界。
• XBSTACK 公开可复现实验 — 独立最小协议子集、测试及适用限制。
• 站内：AI Agent 协议选型 与 逐工具授权设计 — 两个不同的长期工程任务。

专题入口 / AI Agent Hub

从单个 Agent 问题继续进入完整生产体系

AI Agent 专题统一组织架构、记忆、工具调用、评测、安全、部署和多智能体协作，让每篇文章都回到明确的主题主页面。

进入 AI Agent 专题 → 查看架构指南 订阅