A2UI：当 AI Agent 开始直接生成界面
内容提要
A2UI是Google提出的开放协议，使AI Agent能通过声明式JSON消息生成动态界面，而非纯文本。它支持跨平台渲染，分离结构与数据，通过Catalog控制组件能力。文章结合B站实践，介绍了五层工程链路：能力协商、动态Catalog、双重校验、独立事件通道和稳定渲染器，并强调渐进式落地，适合边界清晰的场景。
延伸解读
协议版本差异需注意
A2UI 协议仍在快速演进，v0.9.1 为 Current，v1.0 仍是 Candidate。网上不少案例基于 v0.8，消息命名和结构有差异。生产接入应锁定协议与 Catalog 版本，避免因版本升级导致渲染失败。
能力协商与动态 Catalog
通过能力协商，Agent 可根据客户端（如 Web 或手机）声明可用的组件，防止生成无法渲染的消息。动态 Catalog 按业务场景组装组件白名单，既控制模型能力边界，又减少 Prompt 长度，提升生成准确性。
双重校验与降级策略
模型输出 JSON 不能直接信任，需结构校验和语义校验。结构校验确保消息格式合法，语义校验确保组件和 action 在 Catalog 内。校验失败时优先降级为普通文本，避免因强行渲染导致界面错误。
渐进式落地更务实
B 站实践表明，将 A2UI 作为新消息类型接入现有 AI 助手，通用交互走 A2UI，复杂业务组件仍由开发者实现，比追求全界面生成更稳妥。适合从边界清晰的场景（如数据展示、表单提交）开始，逐步扩展。
Q&A
A2UI是什么？它主要解决什么问题？
A2UI是Google发起的开放协议，旨在让AI Agent通过声明式JSON消息生成动态界面，而非纯文本。它解决了纯文本在数据对比、信息收集、地点推荐等场景下的表达瓶颈，使Agent能声明此刻最合适的交互界面。
A2UI与让模型直接生成前端代码相比，有什么优势？
A2UI采用声明式JSON，客户端决定如何渲染，比执行模型生成的JavaScript更安全。同时，通过Catalog控制组件能力，Agent只能请求已注册的组件，不能执行任意脚本，因此更适合跨信任边界。
A2UI协议中，结构和数据是如何分离的？
A2UI通过updateComponents管理结构，updateDataModel管理状态。价格等数据变化时只更新数据，绑定该路径的组件会自动刷新，无需重发整个界面。
在A2UI中，Catalog的作用是什么？
Catalog是Agent与客户端之间的组件合同，客户端声明支持的组件（如Text、Card、DatePicker），未注册的组件不会进入渲染链路。这决定了Agent能请求哪些组件，从而控制能力边界。
A2UI的工程落地通常需要哪五层链路？
五层链路包括：能力协商（请求携带业务和客户端能力信息）、动态Catalog（根据业务组装可用组件）、双重校验（结构校验和语义校验）、独立事件通道（如SSE双通道）和稳定渲染器（处理surfaceId等）。
A2UI适合哪些场景？哪些场景暂时不适合？
适合边界清晰的场景，如广告诊断、活动报名、地点推荐等。暂时不适合整套应用导航、长链路编辑器或任意前端代码生成，复杂组件应由开发者实现后注册到Catalog。
A2UI与A2A、AG-UI、MCP等协议是什么关系？
A2UI不绑定传输层，可以运行在WebSocket、A2A、AG-UI或MCP之上。它更像Agent与现有组件库之间的UI合同，与这些协议互补。
B站商业广告团队在落地A2UI时采用了什么渐进式路线？
B站团队没有推翻已有AI助手，而是将A2UI作为一种新消息类型接入；通用交互走A2UI，复杂业务组件继续由业务方开发。这比追求“一切界面都让模型生成”更适合当前阶段。
