Google 开源 A2UI 1.0：Agent 按应用登记的组件生成能点、能改的界面

病假早晨的六件事，收进一张能改的卡片

Google 发布了 A2UI 1.0，这是该协议首个稳定版本，按 Apache 2.0 许可开源。协议约定 Agent 怎样描述一块界面：用哪些组件、绑哪些数据、哪些动作可以回传。应用用自己登记的组件把这份描述画出来，用户在里面选择、修改、确认。

官方演示从请病假的早晨开始。预约视频问诊、挪开会议、通知同事、开启邮件自动回复、请家人接孩子、订一份汤，六件事分散在六个应用里，每一件都不复杂，来回找入口、核对时间却很费神；交给只会回文字的 Agent，往往又变成一轮轮追问和确认。演示把这些安排放进同一张卡片，问诊选哪个时段、午餐吃什么都能直接改，确认之前一直停在计划状态。真正接通日历、问诊和订餐服务的工作，仍要由应用开发者完成。

这张卡片分几次画出来。已有内容先出现，后面的结果再填进去；改动其中一个时间，相关摘要跟着变化，具体先后顺序由 Agent 和各服务的返回节奏决定。晚餐改期的演示把同一套能力用在另一件事上：把和 Priya 的晚餐挪到周五，日历空档、餐厅订位和打车价格并排摆在一张综合视图里，判断哪一组安排合适变得容易。同一份描述随后分别出现在手机和笔记本上，样式由各端自己负责。

在这些能力之上，1.0 加入了双向函数调用、无障碍支持和扩展机制；配套的 Express 与 Agent SDK 用来减少生成和接入的工作量。

有了 DESIGN.md，为什么还要组件目录

DESIGN.md 这类文档把字体、间距、颜色和布局写成规则，让编程 Agent 在写代码阶段生成符合品牌的页面；规则越充分，模型临场发挥的空间越小。Vercel 的一次测试里，带规则生成的页面出现 39 项失败，无规则时是 91 项，这份设计文件经过超过 200 次运行和反复审查才逐渐完善。两个数字说明规则文档有价值，也说明维护它要持续投入。

问题出在运行阶段。用户正在操作应用时，团队希望按钮的触控范围、暗色对比、屏幕阅读器标签和日期本地化直接沿用已有实现，而规则文档可能遗漏，也可能和实际组件慢慢脱节。

A2UI 用 catalog.json 处理这件事：它列出 Agent 可以调用的组件，每种组件接受什么参数也写在里面。设计团队可以只开放少量大组件，也可以开放更多细粒度组件；Agent 决定怎样组合、填什么参数，组件本身的外观和行为仍由应用掌握。

开发阶段继续用 DESIGN.md 构建组件，运行阶段通过目录把可用范围交给 Agent，两段可以接在同一条工作流程里。目录里列什么、列多细，实际就是团队愿意让 Agent 触到哪一层界面。

模型输出不能直接改页面，只能提交声明式数据

一封外部日历邀请就能说明风险。邀请里夹带提示注入，如果模型生成的 HTML、CSS 和 JavaScript 能直接进入已登录的应用页面，外部文本就可能影响页面实际执行的内容。仅删掉脚本标签还不够，样式和页面结构同样能改变用户点击的位置，或者把信息带出去。

A2UI 把模型输出限制成声明式数据。消息只能引用目录内的组件和允许的函数，塞不进脚本和原始 CSS；应用先验证这些数据，再交给自己的组件处理。界面能做什么，权限留在应用定义的目录与函数规则里。

1.0 给客户端函数加了两个字段：allowedCallers 规定谁可以调用，requiresUserActivation 要求某类操作必须由用户真实点击触发。打开外部页面、写剪贴板这些动作，不会因为后台流入一条消息就自动发生。

这套边界能减少直接执行模型输出的风险。业务系统仍要自己配好函数权限、数据权限和提交确认，组件目录也得由开发者审查和维护。

iframe 留给独立画布，聊天里的小卡片沿用应用组件

iframe 像在页面里嵌入另一张独立网页，对第三方提供的完整画布、3D 查看器或复杂看板很合适，因为这些内容本来就需要自己的运行区域。MCP Apps 提供的就是这种嵌入机制，A2UI 1.0 也能通过 @a2ui/catalog-mcp 把 MCP Apps 放进界面。

换成聊天里连续出现的许多小卡片，代价就不一样了。每张卡各开一个独立网页，文档上下文和框架代码都要单独占内存；使用不透明来源的沙盒还会限制 cookie 和本地存储，下拉菜单可能被边界裁掉，焦点切换需要协调，高度变化要靠消息通信告诉外层页面，手机上滚动也容易受影响。

取舍落在职责上：自己掌握的表单和卡片沿用应用组件，需要独立画布的内容再选 iframe。实际开销取决于实现，官方没有给出多少张卡片一定会卡的通用阈值。

按自由度分四种，选哪一种取决于组件归谁

同一个界面需求可以有不同的生成方式。让 Agent 从做好的整块界面里挑一个，最快也最受控；让它从组件目录组合，更能贴合当前任务；允许它临时生成完整代码或画面，灵活性最高，也最需要验证和运行管理。官方把这几种做法列成四项，多出来的一项讲界面出现在哪里——把自己的页面嵌进别人的聊天。这一项与前三层并不互斥，一个预制工具可以嵌进聊天，组件目录组合出的 A2UI 界面也能放进 MCP App。

官方那张四格图把这条线画得更细：Controlled 一格里模型只写一行，选中已有的航班卡片；MCP Apps 一格里 A2UI 消息交给宿主原生渲染；Declarative 一格里模型按目录组合，Express 提速、Macros 保稳；Open-ended 一格里编程 Agent 带着 A2UI 技能，用你的目录和设计语言直接搭新界面。

选择型模型站在受控这一端。Jev 这类 System 1 模型面对有限组件或选项时可以直接做选择，省掉长文本生成。它是可选的生成路径，A2UI 本身负责共同的界面描述与渲染约定；官方路线图把决策模型的正式 SDK 支持列在后续方向。

已看到的演示还不等于整套官方支持走完。选型的判断落在两件具体的事上：组件目录由谁维护，界面出现的位置由谁决定。

Express 把组件写成一行函数调用，54 个样本的输入 Token 中位数降 45.4%

让模型直接写完整 JSON，token 有很大一部分花在字段名、引号、括号和层层嵌套上。模型真正要表达的可能只是「一个选择器，三个时间，当前选中十点二十」，却要为格式写出不少额外内容。

OpenUI 项目的 OpenUI Lang 给这条路径提供了参考：紧凑的逐行格式减少重复结构，系统能逐步识别已生成的内容，更早开始流式处理；深层嵌套的 JSON 容易受尚未闭合的外层括号影响。A2UI Express 用同样的思路，把组件表达成函数调用，用 /visit/slot 这样的路径绑定数据；模型写完组件和数据关系，Agent SDK 再翻译成标准消息。Express 已经是 1.0 的 Python、TypeScript 和 Dart Agent SDK 默认推理格式。

官方在 54 个样本组成的 core_v1_0 基准上，用 gemini-3.8-flash、温度 0.0 测了一组数字：提示输入的 token 中位数从 10,980 降到 6,000，减少 45.4%；生成 UI 代码的 token 在关闭思考时减少 63.2%，在不设上限的思考设置下减少 67.3%。45.4% 统计的是提示输入这一侧，后两个比例统计生成 UI 代码的 token；三者都不等于端到端响应时间的缩短，也没有独立复现。

另有一个客户的临床仪表盘案例：改用 Express 后延迟从 10 秒降到 5 秒。这是单个案例，和 54 个样本的基准是两组证据。Soverius AI 演示了另一条路，微调本地 Gemma 4 在浏览器里直接输出 Express，说明生成端可以换实现。

推理格式可以换，客户端只认标准 JSON

如果网页、iOS 和 Android 客户端各自解析 Express，服务端哪天换一种更好用的模型写法，就得等各端升级。A2UI 因此把模型使用的推理格式和实际传输的协议分开：服务端的 A2uiGenerator 把 Express 编译成 1.0 的 JSON 或 JSONL 消息，客户端只解析经过验证的标准 JSON。数据可以走 SSE、WebSocket、A2A、AG-UI 或 MCP，这些通道负责连接和传送，A2UI 约定的是送过来的界面内容。

协议把更新拆成三条消息。createSurface 创建一块界面，可以同时带上初始组件和数据；updateComponents 按 ID 更新扁平的组件列表，避免反复比较深层树结构；updateDataModel 用 JSON Pointer 指出要改的数据路径，例如 /visit/slot。

晚餐演示能看清这个顺序：应用先画出日历与订位区域，等餐厅结果返回再填卡片，打车报价随后更新到对应位置。组件和数据分开之后，改一个时间不用重新生成整张卡，变的只是绑定的值；用户按下确认时，再取当前数据组成操作请求。

Python Macros 把一部分步骤交给确定性程序：开发者可以在服务端展开预制组件、绑定数据库里的值，既省掉模型重复生成复杂结构，也能让敏感值绕开模型提示词。保护范围取决于数据路径怎么设计，采用 A2UI 不会自动让所有数据避开模型。

1.0 补上双向函数调用，确认按钮在 0.9.1 就有了

双向函数调用是 1.0 的主要增量。界面可以请求 Agent 端的函数，例如查询剩余座位或可预约时段，再接收结果；Agent 也可以请求执行组件目录允许的客户端函数，并取回结果。两侧能调用什么，都按目录与权限约定走。

用户点确认后发送操作事件是另一种机制，0.9.1 已经具备，不能算进 1.0 的新增项。1.0 同时加入无障碍支持和携带额外元数据的扩展机制，具体体验由应用组件与业务服务实现。

Agent SDK 把这些能力接到现有框架里。Python、TypeScript 和 Dart 的工具链可以生成供 Agent 使用的技能、转换消息、处理生成错误，Python 另有 Macros。这里的技能和 SDK 是接入工具，标准协议才是各方共同遵守的消息约定。

渲染端覆盖得更宽：网页端有 React、Angular 和 Lit，Flutter 面向手机、网页与桌面，SwiftUI 面向 iOS；Web 与 Flutter 渲染器也能用于 MCP Apps。每一项是否都完成了 1.0 支持，官方没有公布逐端清单。

Jira、Alation、Lynx 和 Gemini 已经接上，版本要逐项看

Atlassian 正把 A2UI 带进 Jira。团队把工作项分派给 Agent，Agent 需要补充信息或需要人做决定时，就在工作项里给出交互卡片，成员当场回答。演示里的问题是测试要覆盖到什么程度，从最少到全面列了四档，也允许自己填答案。

Alation 的 AIOS 用 A2UI 生成由指标卡和图表组成的信息流，每张图还能展开背后的 SQL 和数据。用户在 Claude 里问哪些产品更赚钱，得到的分析和 Alation 产品内的那一份内容相同、布局接近，同一份界面因此能跨宿主复用。

ByteDance 为跨平台框架 Lynx 提供了 A2UI 渲染器，默认组件基于 lynx-ui。京都两日游的示例一侧是逐条到来的消息，一侧是手机里的行程视图；Lynx 当前支持 0.9，团队正在和 A2UI 一起适配 1.0。

Gemini Notebook 的演示先确认成品长什么样。请它生成幻灯片后，界面先问要演讲型还是详细型、重点讲哪些主题，随后出现审阅卡让用户调整格式、重点和视觉风格，确认后才开始生成，网页和手机上的视频概览也走这套卡片流程。组织可以在 Gemini 里注册自己的 Agent，让它返回 A2UI 消息，由 Gemini 的组件图库负责呈现。

把发布说明提到的入口和渲染端排在一起，版本状态差别不小。

Bloomberg 等团队也在使用这个方向，另有尚未推出的内部产品在做相关功能。这些是官方演示和版本状态，渲染一致性与性能还没有第三方复现。

从 Playground 或一条安装命令开始

想先看效果，可以打开 A2UI Playground，看同一段描述怎样变成可操作界面，再到快速入门挑一个符合现有技术栈的渲染器；已有的设计系统和 Agent 框架都能继续用。

接入有两条路径。用 Antigravity、Claude Code、Codex 或 Cursor 这类编程 Agent，先添加 A2UI 技能（npx skills add a2ui-project/a2ui），让它知道组件与消息格式；自己接项目，就按技术栈装 SDK，Python 用 pip install a2ui-agent-sdk，TypeScript 端安装 @a2ui/agent、@a2ui/react 和 @a2ui/web_core。

要把界面放进 Claude、Gemini 等支持 MCP Apps 的助手，可以走 @a2ui/catalog-mcp 的集成指南。已有 0.9 实现的项目，先按版本演进指南逐项检查变更，确认目标宿主与渲染器停在哪一版，再决定升级节奏。

官方另给了六个行业演示入口：Homeward 的房产与搬家、Investing companion 的投资助手、Alder 的穿搭、GenUI Clinic 的医疗记录、Riviera Home 的智能家居和 Vital Loop 的体征追踪。这些是合作伙伴的演示项目，适合参考交互方式。