回想一下你用 AI 助手订机票、填报销、查报表的经历：十有八九是在聊天框里来回追问——日期、人数、舱位、成本中心，一问一答十轮才把信息填完。纯文本对话的信息密度太低，而企业业务真正需要的是「能操作的界面」。可是让大模型直接输出 HTML/JavaScript 又有注入与幻觉风险。A2UI（Agent-to-User Interface）就是在这对矛盾中出现的第三条路：让智能体「说」出一份界面描述，客户端用自己的原生组件把它「画」出来。
一、为什么需要 A2UI：纯文本的三个瓶颈
在 A2UI 出现之前，Agent 与用户的交互基本只有两种形态，而它们各有短板：
- 纯文本问答：信息密度低，复杂表单需要多轮澄清；用户看不到结构化结果，更无法直接操作；
- 生成可执行代码（HTML/JS）：灵活但危险，提示词注入、越权操作、样式失控都可能发生，企业环境几乎不可接受。
与此同时，同一套业务在 Web、iOS、Android、桌面端的界面实现各自为政，跨端一致性维护成本很高。A2UI 的官方口号概括得很精准："Safe like data, but expressive like code"（像数据一样安全，又像代码一样有表现力）。它把「界面」降维成一份受控的声明式数据，让 Agent 拥有表达能力，但不拥有执行权限。
二、A2UI 是什么：一份可渲染的「界面蓝图」
A2UI 是 Google 于 2025 年底创建并开源的开放规范（Apache 2.0 许可），CopilotKit 与开源社区共同参与贡献。它的核心定义可以浓缩成一句话：智能体生成声明式 JSON 描述「界面结构 + 数据」，客户端用自己预置的组件库渲染成原生界面。Agent 不发送可执行代码，只能从客户端公开的组件目录（catalog）里挑选组件。
需要说明的是，A2UI 仍处于快速演进的早期阶段：协议从 v0.8（结构化输出优先）走到 v0.9（Prompt-First，引入 createSurface、客户端函数与自定义目录），再到 v0.9.1 与 v1.0 候选版。它的定位不是又一个前端框架，而是 Agent 与现有组件库之间的一份「UI 合同」：约定能表达什么、如何绑定数据、操作如何回传。
三、工作原理：一次完整的 UI 闭环
A2UI 的典型交互是一条六步闭环，每一步都发生在既有系统之上，不需要推翻现有技术栈：
用户在前端应用里输入自然语言，例如「帮我订一张下周三去上海的机票」。
Agent 判断需要收集信息，输出界面描述：创建 surface、更新组件树、初始化数据模型。
v0.9 起传输层被精简：A2UI 消息可经由 MCP、WebSocket、REST、AG-UI 与 A2A 1.0 等通道传输，A2UI 本身不绑定传输层。
渲染器从本地组件目录取出 Card、TextField、Button 等原生组件，按描述组装界面，并继承当前主题。
提交表单、点击按钮触发 action：本地动作前端自行处理，Agent 动作携带参数回传给智能体。
Agent 根据动作结果更新数据模型或组件树，界面增量刷新，进入下一轮交互。
三个核心概念
Surface 是一块可渲染的 UI 界面区域。组件以「扁平邻接表」描述：每个组件有唯一 id，通过 children 引用其他 id。结构扁平、增量友好，特别适合 LLM 逐块生成。
界面结构与业务数据分离：组件通过绑定表达式引用数据模型字段。更新数据只需发送数据变更，不必重建整个组件树，特别适合表格与表单场景。
用户操作分为本地动作（如展开面板）、Agent 动作（提交参数继续推理）与高风险动作（支付、删除、审批）。高风险动作必须由客户端做权限校验与显式确认。
客户端公开的「可信组件白名单」，定义 Agent 能使用哪些组件与属性。它既是能力边界，也是安全边界——目录之外，Agent 什么也画不出来。
下面是一段简化的 A2UI 消息示意（仅用于理解结构，字段以官方规范为准）：
{
"surfaceUpdate": {
"surfaceId": "booking-form",
"components": [
{ "id": "root", "component": { "Card": { "child": "form" } } },
{ "id": "form", "component": { "Column": { "children": ["date", "submit"] } } },
{ "id": "date", "component": { "TextField": {
"label": "出发日期",
"value": { "path": "/trip/date" }
} } },
{ "id": "submit", "component": { "Button": {
"label": "查询航班",
"action": { "name": "searchFlights" }
} } }
]
}
}可以看到，Agent 只是在描述「一张卡片、一列内容、一个日期输入框、一个按钮」，以及它们与数据、动作的关系。真正的输入框长什么样、按钮用什么圆角与配色，全部由客户端决定。
四、四个设计原则
- 安全优先：只传声明式数据，不执行任意代码；组件来自预审批目录，从机制上杜绝 UI 注入；
- 对 LLM 友好：扁平 JSON 结构、支持流式 JSONL 增量生成，模型不必一次性输出完美 JSON，可以边想边画；
- 框架无关：同一份描述可以映射到 Angular、Flutter、Lit、React 乃至原生移动端的组件体系；
- 渐进渲染：界面随生成过程逐步出现，用户看到的是「实时搭建」，而不是长时间等待后的整页刷新。
五、2026 年生态进展：从 Google 内部走向多框架
过去一年，A2UI 的生态已经跨过「概念验证」阶段，出现了几条值得关注的落地信号：
- Google 内部验证：Google 表示内部团队正在用 A2UI 统一 Agent 的界面输出，Opal 团队是核心贡献者；Flutter GenUI SDK 采用 A2UI 作为远程 Agent 与应用之间的 UI 声明格式；
- 渲染器矩阵成型：官方仓库已提供 Angular、Flutter、Lit、Markdown 等渲染器；Android 官方的 Jetpack Compose A2UI 渲染器已支持 v0.9.1 协议版本；
- 与 AG-UI 官方组合：A2UI 官方提供「先搭 AG-UI 应用、再在客户端开启 A2UI 渲染」的路径；CopilotKit 1.61.2+ 在客户端向 Provider 传入 catalog 时会自动启用 A2UI 渲染；行业普遍把 AG-UI 视为 A2UI 的标准传输绑定之一；
- 企业级演示出现：Oracle 等厂商展示了 A2UI + MCP Apps + A2A 的组合方案，覆盖 Gemini Enterprise、ChatGPT、Claude 等宿主环境。
一句话概括：A2UI 正在从「Agent 生成 UI 的提案」变成「Agent 界面的事实标准候选」，但协议仍处于早期阶段，版本演进速度很快，落地时需要锁定版本并关注升级指南。
六、A2UI 与其他协议的分工
Agent 生态的协议栈正在分层，A2UI 与它们不是竞争关系：
| 协议 | 解决的问题 | 一句话类比 |
|---|---|---|
| MCP | Agent 如何访问工具、数据与上下文 | 给 Agent 接上「手和资料库」 |
| A2A | Agent 与 Agent 之间如何发现、通信、协作 | 给 Agent 配上「同事」 |
| AG-UI | Agent 与前端之间的事件流与运行时交互 | 修好 Agent 到界面的「管道」 |
| A2UI | Agent 如何声明可移植、可交互的 UI | 画出 Agent 要渲染的「图纸」 |
记住这句话就够了：MCP 给工具，A2A 给同事，AG-UI 修管道，A2UI 画图纸。想进一步弄清 A2UI 与 AG-UI 的区别和组合方式，可以阅读《A2UI 和 AG-UI 有什么区别》。
七、企业落地场景与三条建议
A2UI 最适合「需要收集结构化信息、又希望保持原生体验」的交互场景：动态表单（报销、预订、准入申请）、审批与运营看板、远程子 Agent 的结果回传、多端一致的后台工具等。落地时建议注意三点：
- 先治理组件目录：把设计系统里稳定、通用的组件开放给 Agent，明确属性与动作边界。目录质量决定 A2UI 的表达上限，也决定安全下限；
- 把高风险动作留在客户端：支付、删除、权限变更等操作必须经过本地校验与显式确认，Agent 只能「提出意图」，不能「代替授权」；
- 从内部工具试点：先在运营后台、数据问答等低风险场景验证，再考虑进入面向客户的主链路。协议仍在演进，锁定 v0.9.1 或 v1.0 RC 并跟踪升级指南。
当然也要看清局限：A2UI 需要宿主实现渲染器与组件目录，组件目录之外的界面无法表达；复杂动画与精细交互仍需原生开发；协议版本变化较快。它是前端能力的放大器，而不是替代品——前端团队依然掌控设计系统、组件质量与权限边界。
常见问题
Q1：A2UI 和 AG-UI 有什么区别？
一句话：AG-UI 是管道，A2UI 是载荷。AG-UI 规定 Agent 与前端之间的事件怎么流、各代表什么语义；A2UI 规定界面长什么样——用声明式 JSON 描述组件树与数据绑定。两者不冲突，常见组合是「AG-UI 负责传输，A2UI 负责描述」，同一份 A2UI 消息也可以走 A2A 或其他自定义通道。
Q2：A2UI 会取代前端开发吗？
不会。A2UI 的渲染依赖客户端的组件目录与渲染器：组件来自设计系统，样式、主题、权限都掌握在前端团队手里。它改变的是「谁来决定界面组装」，而不是「谁来构建组件」。前端工程师的角色会从写死每个页面，转向维护高质量的可渲染组件库与交互规范。
Q3：A2UI 和 MCP Apps 有什么不同？
A2UI 传递的是声明式组件描述，由宿主应用用原生组件渲染，轻量、原生、受组件目录约束；MCP Apps 通常把一整个 Web 应用（HTML/JS）放进沙箱 iframe 运行，自由度高但隔离更重。前者适合让 Agent 在既有设计系统内组装界面，后者适合随工具分发一个完整的小应用。
A2UI 的出现说明了一件事：Agent 的产品形态正在从「聊天框」走向「可操作的界面」。如果你正在规划智能体产品，建议把 A2UI 与 AI Agent、Agent Skills 放在同一张架构图里考虑：Agent 负责规划执行，Skills 固化流程，A2UI 把结果变成用户能直接操作的界面。鲸点无疑的 FDE 团队正在把这些能力带进真实业务现场——了解我们的 AI 落地服务。