Agent 不该只会回文本：A2UI 把界面变成一种可验证的协议

Agent 不该只会回文本：A2UI 把界面变成一种可验证的协议

9 月 2 日的 Google Cloud Wednesday Build Hour 把 A2UI 放进了一个很具体的演示：用 Agent Development Kit 构建 Agent，再把普通数据输出转换成由 18 个核心 UI 原语组成的结构化 JSON，最后在 ADK Web 界面里实时渲染和交互。它让 Agent 面对不同任务时生成表单、列表、卡片和操作按钮，同时避免模型直接向浏览器注入任意代码。

纯文本适合解释，不适合所有操作。让用户确认一笔采购、筛选多个候选项或修正结构化字段时，按钮状态、输入约束和错误反馈都比一段 Markdown 更可靠。过去团队通常为每种结果单独写前端，Agent 只能在预先固定的页面里填数据。A2UI 试图把“需要什么界面”变成协议消息，使 Agent 能描述布局和数据绑定，客户端则决定这些描述在 Web、移动端或桌面端如何落地。

JSON 描述界面，客户端掌握最后决定权

A2UI 的核心约束是声明式组件目录。Agent 发送客户端认可的抽象组件和属性，而非 JavaScript；渲染器再把它们映射为本地控件。企业可以只开放文本、按钮、表格和日期选择器。模型即使请求了目录外的类型，客户端也可以拒绝或降级显示，不必执行陌生代码。

这种分工给前端留下了必要的控制面。无障碍属性、品牌样式、输入校验、权限提示和埋点都由客户端实现，Agent 只负责表达意图和数据。Google 的活动介绍强调 18 个核心 UI 原语，但生产系统不该把“支持多少组件”当成成熟度指标。更重要的是每个组件有没有稳定 schema，未知字段怎样处理，旧客户端遇到新消息时能否保持可用。

声明式也不等于天然安全。若 Agent 把工具返回的恶意文本放进链接地址、图片源或富文本区域，渲染器仍可能产生跳转和内容注入风险。组件目录要为 URL、HTML、文件下载和外部资源设置白名单，敏感操作要显示明确的对象与后果，并由客户端发起最终确认。界面协议缩小了执行面，却没有取消输入验证。

A2UI 与 MCP、A2A、DASP 不在同一层

[A2UI 协议文档](https://github.com/a2ui-project/a2ui/blob/main/specification/v1_0/docs/a2ui_protocol.md)描述的是 Agent 与用户界面之间的消息；[Google Cloud 活动页](https://cloud.google.com/resources/wednesday-build-hour)展示的是 ADK 和 A2UI SDK 如何把输出转成布局。MCP 关注模型或 Agent 调用工具和上下文，A2A 关注 Agent 之间的发现与协作。三者可以同时出现在一条链路上：Agent 通过 MCP 查库存，通过 A2A 委派报价任务，再用 A2UI 向用户呈现可选择的方案。

DASP 处理的又是会话持续性。一个审批界面在网络中断后能否恢复、事件是否重复提交、长任务完成后怎样回到原会话，不由组件 schema 单独解决。A2UI 消息可以通过不同传输发送，但传输顺序、重连和幂等仍要由会话或通信层约定。需要持久 Agent 会话的团队，可以把界面事件与[DASP API 参考](/dasp/reference)中的会话标识和事件语义结合起来设计。

真正的工程量在版本、事件和回退

A2UI 仓库中的规范仍在演进，团队应把支持版本写进握手或能力协商，避免假定两端永远同步。消息需要通过 schema 校验，渲染器要记录未知组件和未知属性；当客户端能力不足时，至少回退为可读文本与安全的取消操作。涉及付款、删除或外部发送的动作，事件中还应携带幂等键，防止重连后重复执行。

A2UI 值得关注，是因为它把 Agent 产品里长期被当成定制前端的问题公开成了协议问题。AnyAIS 可为 Agent 提供统一的模型 API 和模型切换，A2UI、MCP 与 DASP 则分别补上界面、工具和持久会话。把这些边界保留下来，团队才能在更换模型或客户端时继续复用已经验证过的交互规则。