异步智能体需要收件箱，而非聊天框

对话隐喻有一个引信，大约在 30 秒左右就会燃尽。超过这个时间，加载动画不再是进度指示器，而变成了一种承诺机制——做出承诺的是你的用户，而他们中的大多数人都会选择放弃。你可以在会话回放中看到这一幕：正在输入指示器出现，用户等待，在 12 秒左右切换标签页，其中一半人再也没有回来。产品团队看到一个已完成的 Agent 运行，而另一端没有人类在场，便将其记录为一次成功。这不叫成功。这是一个碰巧完成了的、被遗弃的产物。

这是一个结构性问题的初步显现，大多数 Agent 产品都用加载动画和流式文本来掩盖它：对话界面是为回合制的人类和快速模型设计的，当这两个前提中的任何一个失效时，它就会悄无声息地失败。如果你的 Agent 需要几分钟才能运行完，那么你交付的就不是一个等待时间较长的对话功能。你交付的是一个不同的产品，它需要一种不同的 UI 原语。

这种原语就是收件箱。

30 秒断崖不是性能漏洞

产品团队一直试图用工程技巧来修复长耗时的 Agent——更快地流式传输 Token、展示模型的“思考过程”、预加载骨架屏、插入进度消息。当延迟在个位数秒时，这些在边缘上是有帮助的。但当实际时间超过 30 秒时，这一切都无济于事；超过大约两分钟后，UX 曲线就会发生反转：你流式传输的细节越多，提取的注意力就越多，用户坐在那里观看时的生产力就越低。你把一个后台任务变成了一个认知囚笼。

关于延迟的原始 UX 研究已被重复多次，足以成为常识：1 秒感觉到瞬时，10 秒保持注意力，超过这个时间，用户在心理上就会离开。而不常被引用的是返回时的代价——重新聚焦成本（refocus cost）。当用户回到一个耗时三分钟完成的 Agent 响应时，他们不只是阅读它；他们还要重建所提问题的上下文、原因，以及答案是否依然重要的心态。对于简单的查询，这没问题。但对于有意义的工作，你是在要求用户重新进入一个他们已经付出了构建成本、随后又选择离开的心智状态。

对话界面假装这个问题不存在。它们通过将视口冻结在加载动画上来让用户“留在”对话中。同步 UI 的假设——用户在等待、用户想要等待、用户在结果出现时能识别答案——是支撑整个设计的支柱，但通常是错误的。

什么是真正的收件箱

“收件箱”不仅仅是一层外壳。它是对三种产品保证的承诺，而对话框无法做到这些。

持久性（Durability）。 运行（run）拥有一个比会话寿命更长的 ID。用户可以关闭标签页、切换设备、分享链接，或者被叫去处理紧急任务，一小时后再回来，而这个运行结果是可寻址的。这个 ID 就是产物。对话框的线程范围身份意味着“关闭标签页”和“丢失工作”是同一个动作——用户学会了这一点并停止关闭标签页，这就是为什么你的浏览器中会塞满那些运行着长达数小时 Agent 且没人敢动的固定标签页。

可通知性（Notifiability）。 当运行结束时，系统会主动联系用户。推送、邮件、Slack、系统托盘——具体的渠道并不重要，重要的是“完成”是产品触发的一个事件，而不是需要用户负责轮询的状态。对话框反转了这一点：用户通过盯着看来进行轮询。收件箱将人类视为一种稀缺资源，应在完成时予以中断，而不是一个永远在线的注意力抽水机。

结果导向而非过程导向的框架（Result-over-progress framing）。 收件箱的主要视图是结果列表——“已起草身份验证重构的 PR”、“已分析第一季度流失客群”、“已回答客户工单 #4812”。进度是可以查看的，但是次要的。对话框则相反；对话记录就是产品，最终答案只是其中的最后一行。这种倒置是大多数团队在“添加收件箱”时犯的错误，最后结果证明那只是一个对话历史查看器。

你可以从人们描述工作的方式中感受到区别。收件箱型 Agent 产品的用户谈论的是“发起运行”和“查看结果”。对话框型 Agent 产品的用户谈论的是“等着它完成”。一个是授权（delegation），另一个是监督（supervision）。你选择的产品隐喻决定了你的用户会学会哪种行为。

指标的转变

当团队做出这种转变时，衡量体系也必须随之移动。在对话框中看起来不错的指标会变得具有误导性，而收件箱中重要的指标通常在开始时并没有被监测。

不再有意义的对话指标：

• 首个 Token 响应时间 (TTFT)。 在收件箱模型中，当第一个 Token 到达时，用户已经离开了。TTFT 对于类似对话的子任务仍然值得优化，但它不再与长尾任务的满意度相关。
• 会话时长。 在对话框中，较长的会话是好事，因为它意味着参与度。在收件箱中，一个花费两分钟启动了五个运行并离开的用户，比一个坐着看完 20 分钟流式输出的用户获得了更多的价值。
• 单次会话消息数。 优化该指标的对话产品测量的是囚禁（captivity），而不是效用。

加载中…