智能体的渐进式披露界面

实战手册 · 智能体体验与人机交互

把下一步要做的决定摆在用户面前，而不是把智能体产生的所有东西都倒出来。

只把用户下一步需要做的决定摆在他面前——什么时候展开思考链、工具调用、diff，什么时候继续折叠。它与审批与确认体验并肩：后者讨论的是该确认什么，本文讨论的是确认时该露出多少。

STEP 1

如今智能体一次回合往往会同时吐出：规划轨迹、工具调用参数清单、观察结果、半成品 diff、有时还有后续计划，以及最后那段自然语言回复。把这些全部铺到界面上，等同于把 console.log 留在了生产环境里——那是写给开发者的调试输出，却挤占了用户真正要评估的那一件事：眼前这个待决定的动作。

渐进式披露的纪律，就是把以上每一类工件都视为可折叠而非必显示。默认收起；用户有理由时才展开。智能体不该仅仅因为产出了字节，就理所当然占据用户的注意力。

STEP 2

好用的智能体界面大都会收敛到大致四层：

A 层——正在请求或正在执行的动作。始终显示，永不折叠。一句话就够：「向 Acme 发送 4218 号发票，金额 12,300 美元。」这正是要让用户评估的那件事。
B 层——结构化载荷。一次点击之内可见。准确的 diff、工具参数或目标地址。当 A 层含糊或风险偏高时，用户会主动去看它。
C 层——推理过程。两次点击之外，或默认关闭。计划、思考链、智能体所依赖的检索上下文。它适合用来核验信任，而不属于日常流程。
D 层——原始轨迹。仅供调试。token 级日志、模型原始输出、内部草稿。藏在开发者开关之后，永不出现在用户默认视图里。

这个顺序不是出于美学——它对齐的是每一层多大概率改变决定。A 层总是会改变。D 层几乎永不改变。默认视图上的版面，就该按这个顺序分配。

STEP 3

"什么都给你看"的孪生失败模式，是"什么都让你批"。一个面板同时让用户批准草拟邮件、确认日程邀请、授权退款，其结果一定是：其中一项得到注意，另外两项被条件反射点过。渐进式披露也适用于决策队列：先呈现一个关键关卡，让用户处理完，再呈现下一个。

这并不是要藏住工作——智能体完全可以在后台并行执行安全动作，把人工检查点排到队列里。渐进式披露禁止的，是把毫不相关的决策叠加进同一个确认界面。每个受控动作都该有自己专注的视图，配上各自从 A 到 D 的四层结构。

把「全部批准」作为默认按钮，恰恰是渐进式披露在结构上的反面。它存在的唯一目的，就是让用户不看就清空队列。要么把那些动作分级到本来就不需要审批，要么给每一个动作单独的关卡——不能两头都要。

STEP 4

渐进式披露是合适的默认，而不是放之四海皆准的法则。三个合理的出口：

处在热路径上的高信任专家用户。一个每小时审 80 条智能体 diff 的工程师，反而希望 B 层（diff）默认展开——只有 A 层时每条都浪费一次点击。这要做成按用户的偏好设置，绝不能对所有人一起翻过去。
批量工作流。一次性审 50 条分类决策，与处理一个重大动作完全是两种任务；这种场景下，一个更密、每行暴露更多信息的表格视图才物有所值。
调试 / "把所有东西都给我看"模式。一个为当前会话打开 C、D 两层的开关，留给正在排查"智能体为什么干了件奇怪事情"的用户。默认关闭，主动启用，会话结束即复位。

这三种情况里，用户都是明确地选择了更密的视图。反模式则是替他们做了这个选择。

STEP 5

三种反复出现的形态，不防它们就会反过来咬你：

超载的模态框。一个确认对话框里塞着 diff、推理过程，再附带一个追问——结果是用户一项都不看。把它拆成 A 层 + 一个能展开 B 层的入口。
只有聊天、藏起 diff 的界面。聊天记录里写一句「我更新了三个文件」却不展示具体改了哪些行，看起来很简洁，本质上却是不透明的。B 层必须能从那条聊天回合直接打开，而不是被埋进另一个面板。
默认展开的思考链。把每一段内心独白都默认显示，结果会训练用户养成"滚动跳过"的习惯，紧接着他们也会滚动跳过真正的动作。推理被安排在 C 层，正是为了让用户学会——在他需要的时候、也仅在那个时候——才去展开它。

检验方法很简单：问一下，用户屏幕上的第一件事是不是那个下一步决定，剩下的一切是不是都在标注清晰的一次点击之外。答案为否，你就有一个渐进式披露的缺陷，无论版式看上去多漂亮。