让 Agent 直接生成 HTML，表达能力很强，但生产系统很快会遇到三个问题：远程代码是否可信，生成结果能否遵守产品设计系统，以及同一份界面能否适配 Web、移动端与不同前端框架。
A2UI 给出的答案不是让模型写更多前端代码，而是让它输出一份声明式的“界面意图”。Agent 说明页面需要哪些组件、数据和交互关系，客户端再用自己拥有和信任的组件库完成渲染。
这条边界让生成式 UI 从一次性的代码生成，转向可验证、可移植的运行时协议。
#Agent 描述界面，客户端决定界面如何存在
A2UI 消息不会携带任意 JavaScript。它使用结构化数据描述组件树、属性、数据绑定和动作。客户端预先声明一个组件目录，只有目录中存在的组件才能被 Agent 调用。
例如，Agent 可以表达“显示一张订单卡片，包含状态字段和取消按钮”，但卡片具体使用什么字体、间距、无障碍规则，以及取消动作是否需要二次确认，都由客户端实现决定。
这形成了清晰的信任边界：
- Agent 负责语义与任务编排 ，判断此刻需要什么信息和操作。
- 协议负责传递结构化意图 ，让消息可以验证、流式传输和升级。
- 客户端负责渲染与执行 ，掌握可用组件、品牌规范和权限控制。
同一个远程 Agent 因而可以服务多个客户端。Web 端用 React 组件渲染，移动端使用原生组件，企业内部应用则替换成自己的设计系统，而不需要让 Agent 为每个平台重新生成一套代码。
#v0.9 补的是工程化缺口
A2UI v0.9 不只是调整协议字段。它围绕真实接入补齐了一组关键能力。
基础组件目录提供跨实现的公共起点；Web Core 与 React 渲染器把协议接入前端；Agent SDK 帮助服务端生成消息；缓存减少重复资源开销；客户端定义函数允许界面触发本地能力；客户端与服务端数据同步则让界面不只是一次性展示。
与此同时，协议改进了错误信息和模块化 Schema。对于模型输出的结构化界面，这些能力比表面上的组件数量更重要：错误必须能定位，消息必须能部分接受或修复，协议升级不能让整个页面突然失效。
#一条完整链路分成五步
Google 给出的接入方式可以概括为五个环节。
- 客户端定义允许使用的组件目录。
- Schema 管理器把目录转成模型可以遵循的结构约束。
- 系统提示向模型解释 A2UI 的语义和生成规则。
- Agent 在对话与工具调用中生成界面消息。
- 流式处理器解析、修复并验证消息，再交给客户端渲染。
这条链路的重点是“边生成、边验证、边呈现”。用户不必等完整页面一次性生成完毕，客户端也不必在最后一刻才发现整段结构无效。
流式体验仍需要谨慎设计。组件可能先出现再补数据，动作依赖的字段可能晚于按钮到达，局部错误也不能把已经可用的内容全部清空。协议支持流式只是第一步，产品还要定义占位、回退与原子更新规则。
#生产环境需要协商，而不是假设
客户端与 Agent 可能运行不同版本，也可能支持不同组件。v0.9 因此强调版本协商、动态组件目录和更有韧性的流式处理。
版本协商用来确认双方理解的协议范围；动态目录允许客户端根据用户权限、设备能力或当前页面提供不同组件；韧性处理则要面对消息中断、字段缺失和不受支持的组件。
这里不能把 Schema 验证误认为完整安全。结构合法只说明消息“长得对”，不代表动作应该被允许。涉及文件、支付、账户或外部通信的操作，仍然需要客户端权限检查、用户确认和审计记录。
#A2UI 是界面协议，不是传输协议
A2UI 可以运行在 MCP、WebSocket、REST、AG-UI 或 A2A 等不同通道上。它描述的是“界面意图如何表达”，而不是“Agent 与客户端如何建立连接”。
这个区分能避免生成式 UI 生态里常见的概念混乱：传输层负责消息抵达，工具协议负责能力调用，A2UI 负责可渲染的声明式界面。它们可以组合，却不应该被当成相互替代。
同样，A2UI 也不是设计系统本身。它不会自动决定产品该有哪些组件，而是让现有设计系统成为 Agent 可调用、可约束的能力目录。
#生成式 UI 的生产路线正在收敛
完全自由地生成网页适合开放探索；固定模板适合稳定高频任务；A2UI 位于两者之间：界面结构可以动态变化，但执行范围仍由客户端控制。
这种方案牺牲了一部分任意代码的自由，换来可预测性、跨端复用和安全边界。对大多数需要长期维护的产品，这可能比“每次都生成一个全新网站”更接近生成式 UI 的实际落点。
真正的变化不是 Agent 开始替前端工程师写组件，而是设计系统第一次成为模型可以在运行时调用的语言。