Agent 交互的三层架构

Google 在 2025 年底开源了 A2UI（Agent-to-User Interface）协议，试图标准化 Agent 如何"说出 UI"。这个方向是对的。 但当我把 A2UI 的覆盖范围和我在实践中设计的交互体系放在一起对比时，发现了一个更大的图景：与 Agent 的交互，远不止于 UI 生成。

Chat Wall：纯文本交互的天花板

A2UI 提出的核心问题叫 Chat Wall，翻译过来就是"聊天墙"。

想象一个场景：Agent 需要用户选一个日期、一个时间段、一个偏好选项。 在纯文本模式下，对话会变成"你想哪天？""明天。""几点？""下午三点。""有冲突，换个时间？"。 三轮对话才完成一个本可以用一个表单搞定的事情。

这不只是效率问题。 更深层的矛盾在于：文本是线性的，但人的意图往往是结构化的。 当 Agent 需要收集结构化信息，或者呈现复杂结果时，纯文本的表达力就不够了。

A2UI 的解法很直接：让 Agent 动态生成 UI 组件。 页面不再是预先设定好的，而是在与人互动的过程中，根据不同的上下文场景、用户需要的具体动作以及信息呈现的丰富度，动态构建生成出来。

A2UI 做对了什么

A2UI 的核心理念可以用一句话概括：Agent 发送声明式 JSON，客户端用原生组件渲染。

它定义了一个简洁的交互循环：

几个值得关注的设计决策：

安全性优先。 与直接发送 HTML/JavaScript 不同，A2UI 只传递声明式的组件描述（JSON），不包含任何可执行代码。客户端维护一个"组件白名单"（Catalog），Agent 只能请求渲染白名单内的组件。在多 Agent 协作的场景下，你不能信任每一个远程 Agent 的输出，这个约束就很关键。

框架无关。 同一份 A2UI JSON 可以在 React、Flutter、Angular、SwiftUI 上渲染，各端使用自己的原生组件。Agent 生成一次 UI，到处都能用。

LLM 友好。 组件用扁平的邻接表模型（adjacency list）来描述，而不是嵌套树。这让 LLM 更容易增量生成，也方便流式渲染。

数据绑定。 UI 结构和应用状态分离，通过 JSON Pointer 做响应式绑定。状态变了，组件自动更新，不需要重新生成整棵组件树。

这些设计是经过验证的。Google 的 Opal 平台已经有数十万用户用 A2UI 构建 AI Mini Apps，Gemini Enterprise 在用它渲染企业级的审批面板和数据表单，Flutter 的 GenUI SDK 底层就是 A2UI。

但 A2UI 只解决了 Agent 交互中的一个层面。它提供了一个方向和标准，而更多企业会参考这个标准或思路，去定制化自己业务或领域中需要的组件，实现更丰富的交互形式。

我理解的 Agent 交互架构

在实践中，我把 Agent 与人的交互拆成三个层面：输入层、输出层、反馈进化层。

A2UI 主要覆盖的是输出层中"Agent 动态生成 UI 组件"这一块。对输入层涉及很少，对反馈进化层完全没有涉及。但在实际产品中，三层都不可或缺。

输入侧：不止于打字

A2UI 几乎没有标准化人到 Agent 的输入方式。但在实践中，这一侧的设计空间很大。

批注式追问。 这是我认为最有价值的一种输入范式。在我们内部使用的 Agent 产品中，我们设计了这样一种交互：当 Agent 输出了一份完整的方案后，用户往往只需要对其中某个细节做修改。传统做法是复制那段内容，粘贴到输入框，再写修改意见。更自然的方式是：直接选中 Agent 回复中的某个片段，添加批注，然后带着精确的上下文追问。

用户在这个场景下的角色不是"提问者"，而是"审核者"或"批注者"，对 Agent 输出的方案进行针对性修改。这种交互把上下文的指向精度从"整段回复"缩小到了"某个片段"，大幅减少了 Agent 误解用户意图的可能性。

快捷指令。 类似 Claude Code 的 /command 机制，让用户通过预定义的指令快速触发特定行为，而不是每次都用自然语言描述意图。频繁使用的操作（搜索、翻译、总结）用一个斜杠命令搞定，效率高一个量级。

多模态输入。 文字、图片、语音的混合输入已经是基本能力。但体验差异在细节：拖拽上传、剪贴板粘贴图片、多图并发上传，这些都直接影响使用流畅度。好的多模态输入不是"支持"某种模态，而是让模态切换无感。

审批动作。 当 Agent 提出操作建议（"是否执行这个修改？""选择方案 A 还是方案 B？"），用户需要一种比打字说"好的"更明确的方式来确认。结构化的确认按钮让意图传递更精确，避免了自然语言的歧义，也让 Agent 能更可靠地解析用户的决策。

输出侧：不止于文字

这是 A2UI 的主场。它定义了一套标准组件目录，涵盖布局（Row、Column）、展示（Text、Image）、交互（Button、TextField、Slider）、容器（Card、Tabs、Modal）四大类。通用场景下这个覆盖面够用。

但在实际产品中，有几类输出方式是 A2UI 标准组件之外的刚需。

结构化问卷

Agent 在推理过程中常常需要向用户收集多个维度的信息。一个结构化的表单（支持文本输入、单选、多选，带必填验证）比一连串追问高效得多。用户填完一次性提交，Agent 拿到所有答案继续推理。

在我们的实践中，Agent 可以通过工具调用动态生成一份问卷，前端将其渲染为交互式表单。用户提交后，答案被格式化为结构化消息发回给 Agent。这就是 A2UI 所描述的 Emit-Render-Signal-Reason 循环的一种具体实现。A2UI 的组件目录可以用 TextField + CheckBox 组合来做，但缺少"表单提交"这个原子概念，需要靠客户端自己封装。

可交互图表和数据表格

数据类回答中，可排序的表格、可筛选的列表、可钻取的图表，比一段文字描述直观十倍。A2UI 通过自定义组件扩展可以支持，但标准目录中还没有 DataTable 或 Chart 这类高级组件。

我认为这类组件应该进入标准目录。Agent 输出数据是一个极其高频的场景，而数据的最佳呈现形式几乎从来不是一段文字。

确认操作选项

Agent 提出几个方案让用户选择，每个选项有明确的 label 和 value，用户点击后 Agent 基于选择继续执行。这不是一个简单的"按钮"，而是一个"决策节点"，它改变了对话的分支走向。

工具调用与推理过程可视化

Agent 在背后调用了搜索引擎、分析了图片、查询了数据库。把这个过程透明化展示出来（哪些工具被调用、每步耗时、中间结果），既增强了用户对 Agent 的信任，也帮助用户理解推理路径。同样，展示 Agent 的 thinking chain 也已成行业共识。用户看到推理过程后，能更好地判断结果是否可靠，也能在推理出现偏差时及时纠正方向。

这两类可视化在 ChatGPT 和 Claude 中已经是标配，但 A2UI 没有覆盖。它们严格来说不属于"UI 组件生成"，但属于 Agent 交互中不可或缺的输出内容。

已成共识但未被标准化的范式

除了三层架构内的交互，还有一些范式已经在主流产品中达成共识，但尚未被任何标准覆盖：

这些范式之所以还没被标准化，可能因为它们更贴近具体的产品实现而非协议层面的关注。但当足够多的产品都在做同样的事情时，标准化只是时间问题。

被低估的第三层：Evolve

A2UI 以及目前主流的 Agent 协议（AG-UI、MCP）都解决的是"一次交互循环"内的问题。但一个完整的 Agent 系统还需要跨会话的反馈与记忆。

我把这一层叫做 Evolve。它包括用户对 Agent 输出的评分（stars）、投票（thumbs up/down）、备注（notes）、分享导出（pdf/links），以及完整的对话历史。

这一层的核心价值是：它提供了一条矫正 Agent 行为的反馈路径。

当 Agent 的输出与用户预期差距很大时，一个 1 星评分或一个 thumbs down 能让 Agent 明确地知道当前的输出不符合用户偏好，或者没有解决具体问题。这些强反馈信号在 Agent 自我迭代的过程中就是进化的依据。更进一步，这些信号可以针对特定用户做个性化的偏好适配，让 Agent 越用越懂你。

人和人之间的面对面对话，一些动作和微表情其实是带着反馈信息的。线上与人沟通经常会缺少一些信息，和Agent更是，如何把必要的反馈途径做好，让Agent能够准确理解你的反馈信号这很重要。

备注和标注则提供了更细粒度的反馈。评分告诉 Agent"不好"，备注告诉它"哪里不好"。两者结合，反馈路径才算完整。

对话历史本身也是记忆的一种形式。Agent 能回溯之前的交互，理解用户在不同场景下的偏好模式，这比每次从零开始要高效得多。

目前没有任何标准覆盖这一层。但在企业级 AI 应用中，没有反馈闭环的 Agent 系统就像一个只会说不会听的人，交互效率会随着使用时间递减而不是递增。

我的思考

A2UI 的价值在于，它把"Agent 动态生成 UI"这件事从各家的私有实现推向了一个公开标准。方向是对的。但它更多会是一个参考标准，而不是终态。大多数企业不会原样采用它的组件目录，而是会参考"声明式 JSON + 客户端渲染 + 组件白名单"这套架构思路，去定制化适合自己业务和领域的组件。

A2UI 标准化了 Agent 如何"说出 UI"，但没有标准化人如何高效地"指挥 Agent"，也没有覆盖 Agent 如何通过反馈来"进化"。而这三层加在一起，才构成了 Agent 交互的完整闭环。

更长远地看，Agent 交互的终局不是"更好的聊天框"。在正在发生的人机协作模式转变中，人的角色从"提问者"变成了"审核者"和"决策者"，Agent 的角色从"回答者"变成了"方案提供者"和"执行者"。支撑这种转变的，不是某一层的优化，而是输入、输出、反馈三层的协同进化。

聊天框是 Agent 交互的起点，但不是终点。

参考