【A2UI】Agent 开始“说界面”

你让 Agent 检查一批投放计划的异常。

它可以返回一段文字：哪些计划消耗下降、可能是什么原因、建议先处理哪几个。信息没有错，但你还得记住计划名，再追问时间范围、筛选条件和调整方式。

它也可以直接给出一块操作面：上方是日期和账户筛选，中间是异常计划对比，右侧可以查看原因，底部有“加入处理清单”和“提交复核”。筛选条件变化后，图表和建议同步更新。

后者看起来像 Agent “画”了一个页面。A2UI 处理的正是这一步，但它的做法不是让大模型临时写一段网页代码。

本文的核心判断是：A2UI 是 Agent 使用的一门受控界面语言。Agent 描述想呈现什么，客户端决定具体怎么画，业务系统决定用户的动作是否真的成功。

上面的投放场景只是机制示例，不代表智投已有对应线上功能。

A2UI 先解决“界面怎么说”

A2UI 是 Agent to UI 的缩写。按官方定义，它是一套基于 JSON、支持流式传输、与前端框架和传输方式解耦的声明式 UI 协议。

几个词拆开看：

• 声明式：Agent 描述“这里需要一个选择器，选中值绑定到某份数据，点击按钮触发某个动作”，而不是给出组件内部怎么实现。
• 流式：Agent 不必等整棵界面结构生成完再发送。客户端可以先显示已经收到的部分，再逐步补齐。
• 框架解耦：同一份界面描述可以由不同 Renderer 翻译成 React、Flutter 或其他端的原生组件。
• 传输解耦：A2UI 定义消息里如何表达 UI，不限定消息必须走 SSE、WebSocket、REST、AG-UI 还是其他通道。

可以把它压缩成三方分工：

Agent：决定展示什么组件、数据和动作
Renderer：决定这些内容在当前客户端如何可靠呈现
业务系统：决定取数、权限和写操作是否真正成功

这条边界很重要。按钮变成“已完成”，只说明界面状态变了；只有业务服务返回权威结果，任务才算完成。A2UI 提供 UI 表达和交互回传的基础，不替产品处理长期记忆、任务状态机、权限、审计和业务数据。

五个对象，组成 Agent 的界面词汇

理解 A2UI，不需要先读协议字段。先记住五个对象。

1. Catalog：Agent 能说哪些“界面词”

Catalog 是 Renderer 提供的组件、函数、样式能力及其说明。它可以包含 Text、Button、Select 等基础组件，也可以包含账户选择器、投放计划表格、预算确认卡等业务组件。

它不是一套全球统一的组件库，更像双方约定的能力合同：客户端说“我能稳定渲染这些东西”，Agent 只能在这个范围内选择和组合。

因此，Catalog 同时决定了表达上限和安全边界。成熟企业通常会把它映射到自己的设计系统、权限模型和业务组件，而不是让 Agent 自由发明控件。

2. Surface：这次交互发生在哪里

Surface 是 Agent 创建、Renderer 管理的一块 UI 区域。

它可以是一张对话卡片，也可以是一段表单、一个看板或一套分步流程。Surface 让动态界面拥有独立身份：哪些组件属于它、数据更新到哪里、用户动作对应哪次任务，都能被关联起来。

3. Component：界面的结构单元

Component 是 Catalog 里的可组合单元。Agent 用组件 ID 和引用关系描述结构，而不是把所有内容塞进一棵很深的嵌套树。

A2UI 采用“扁平列表 + ID 引用”的方式，主要是为了适应生成式场景：某个子组件还没到达时，Renderer 可以先放占位；更新一个组件时，也不必重发整棵树。这比等待一份完全闭合的巨大 JSON 更适合流式输出。

4. Data Model：这块界面的临时状态

每个 Surface 都可以有独立的数据模型。组件通过数据路径绑定输入值、选中项、加载状态或展示结果。

结构和数据分开后，选项变化不一定要重建整块界面。Agent 可以更新数据，用户操作也可以推动数据变化，Renderer 根据绑定关系刷新相关组件。

5. Action：用户操作之后发生什么

Action 把“用户点了什么”变成下一步处理。

有些动作要发回 Agent，例如提交选择、请求解释或继续流程；有些动作适合由客户端本地执行，例如必填校验、字段显隐和格式化。后者如果每次都调用模型，界面会慢，也会引入没有必要的不确定性。

五个对象放在一起，A2UI 的工作方式就很清楚了：

Catalog 限定能力
→ Agent 创建 Surface
→ Component 描述结构
→ Data Model 提供和更新数据
→ Action 把用户操作送入下一步

一次交互是怎样跑完的

假设用户让 Agent 推荐竞品，并在确认后保存。

1. Agent 理解任务，选择当前客户端支持的 Catalog。
2. Agent 创建一个 Surface，下发说明文字、候选列表、选择器和确认按钮。
3. Renderer 用本地可信组件开始渲染；组件和数据可以分批到达。
4. 用户勾选竞品。本地校验立即执行，选中结果写入 Data Model。
5. 用户点击确认，Renderer 将 Action 和必要上下文回传。
6. Agent 或业务服务处理保存动作，返回权威结果。
7. Surface 更新为完成态，展示实际保存结果，而不是只把按钮变灰。

这里的“推荐竞品”同样是假设示例。它用于说明协议闭环，不是某个产品已上线能力的证明。

这套路径中，A2UI 负责第 2 到第 5 步的主要表达契约，也为后续更新提供基础。任务如何编排、保存是否幂等、失败后如何恢复、历史里保留表单还是结果摘要，仍要由 Agent 产品和业务系统设计。

它和普通聊天、传统前端差在哪

最容易混淆的不是协议字段，而是边界。

方式	运行时主要传递什么	谁决定界面	前端主要工作
普通聊天输出	文本、Markdown、附件	消息容器基本固定	渲染消息与少量固定内容类型
传统固定前端	API 数据和业务状态	产品与研发预先设计	实现具体页面、流程和组件
A2UI	声明式组件、数据与动作	Agent 在 Catalog 内运行时组合	建设 Renderer、Catalog、绑定与动作契约
任意 HTML 生成	可执行页面代码	Agent 同时参与设计和实现	提供沙箱、隔离与运行环境

A2UI 不是传统前端的替代品。它把一部分“这次任务需要什么界面”的决定推迟到运行时，但组件怎么实现、品牌是否一致、键盘能否操作、数据能否查看、动作有没有权限，仍由客户端和业务系统负责。

也不能把“接口返回 JSON，前端渲染卡片”都叫 A2UI。如果后端只能在几个固定页面之间切换，没有面向 Agent 的 Catalog、增量生成、能力协商和双向交互，它更接近传统 Server-Driven UI 或固定组件映射。

反过来，大模型直接生成 HTML、CSS 和 JavaScript，也不等于 A2UI。那是自由度更高的开放式生成路线，安全、性能和一致性需要另一套治理。两者的差别不是页面看起来是否动态，而是谁拥有可执行实现的控制权。

“JSON 渲染组件早就有了”，这条批评说对了一半

A2UI 没有凭空发明声明式 UI。服务端下发 Schema、客户端按协议渲染，早已有 Server-Driven UI 和低代码平台的实践。

但 Agent 成为发送方后，约束发生了变化：

• LLM 可能一边生成一边发送，结构并不一次完整；
• 输出需要解析、校验，失败时还要修复或重试；
• 不同客户端提供的组件和函数能力不同，需要协商；
• 用户输入、客户端动作和 Agent 更新要双向流动；
• 同一份描述希望跨 Web、移动端和桌面端落到原生组件；
• UI 要跨越 Agent 与客户端之间的信任边界。

因此，A2UI 的增量价值不在于“第一次用 JSON 描述界面”，而在于为这些 Agent 场景形成一套公共契约。

这套契约也不是越自由越好。Catalog 会限制长尾表达，但换来了更稳定的组件行为、更一致的品牌体验、更明确的验证方式和更小的代码注入面。对于预算调整、外发、删除、跨账户操作等高风险任务，这种限制是产品选择，不是“AI 味不够”。

同时要避免过度承诺：Catalog 白名单只能减少任意代码执行风险，不能自动阻止错误数据、越权参数、隐私泄露或错误审批。UI 生成权不等于业务执行权，权限、校验、审计和必要的人工确认仍在业务层。

A2UI 已经能用，但还不是“问题都解决了”

根据统一源材料记录的官方状态，截至 2026 年 7 月 28 日：

• A2UI v0.9.1 是官方标记的 current production release；
• A2UI v1.0 仍是 Candidate，规范最后更新于 2026 年 6 月 8 日；
• 官方稳定 Renderer 已覆盖 React、Lit、Angular、Flutter 和 Lynx；
• 无障碍、复杂交互、全应用 UI、缓存和多 Agent 共享 Surface 等仍有规划项，具体可见官方 Roadmap。

这意味着产品可以开始验证真实场景，但不应把“协议能渲染”写成“生产问题已经解决”。规范版本、Catalog 兼容、状态恢复和跨端一致性都需要单独治理。

智投内部方案中的九类 UI 指令，可以看作业务组件目录的雏形：自然语言表达意图，Skill 和业务规则推进流程，结构化指令描述交互，前端通用组件负责呈现。现有材料只能证明方案和规范存在，不能证明九类组件已经全部上线。本系列第 05、06 篇再展开工程路线和交付边界。

产品经理需要多设计四样东西

过去做一个页面，产品经理通常关注信息架构、字段、按钮和流程。进入 A2UI 后，还要把四类对象写进方案：

1. 能力边界：Agent 能调用哪些基础组件和业务组件，哪些场景必须降级到固定流程。
2. 数据状态：哪些是界面临时值，哪些来自业务权威数据，何时才算操作成功。
3. 动作语义：动作在本地执行、发给 Agent，还是调用业务服务；失败、重复提交和取消怎么处理。
4. 生命周期：Surface 何时创建、更新、完成、失效和恢复，旧版本如何兼容。

所以，判断一个 A2UI 方案，不要先看它能生成多少种卡片。先问三件事：Agent 是否在说一套声明式界面语言？客户端是否保留可信组件和执行控制权？用户操作能否收敛到真实业务结果？

这三件事成立，Agent 才不只是“回复了一段带按钮的消息”，而是在和产品一起完成任务。

---

A2UI 系列 · 第 01/09 篇

上一篇：无（系列首篇）

下一篇：【A2UI】Agent 如何“说界面”（02-generative-ui-paths）