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

对话隐喻有一个引信，大约在 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），而不是效用。

开始变得重要的指标：

• 恢复率（Resumption rate）。 在用户离开期间完成的任务中，有多少比例的用户真正回来查看了结果？这是衡量你的通知是否有效以及你的结果框架是否清晰的真实指标。恢复率低于 60% 意味着你的收件箱是一个坟场。
• 分享率（Share rate）。 完成的运行被分享（复制链接、发送给同事、粘贴到工单）的频率有多高？这是你的“运行即产物”模型正在交付价值的最清晰信号。分享运行还能在你没有构建多人协作功能的情况下，引导出多人使用场景。
• 重复任务启动率（Repeat-task launch rate）。 同一个用户是否在下周回来并启动了类似的任务？在对话框中，这只是“留存用户”。在收件箱中，这意味着委托契约（delegation contract）成立了——用户足够信任输出，从而发起了另一个任务。
• 流失差异化（Abandonment differential）。 不要只追踪单一的流失数字，而要追踪“运行中流失”与“结果产生后流失”。前者在设计上应该接近 100%——你希望用户离开。后者才是需要降低的指标。

这种转变是令人不安的，因为在仪表板上，你的产品看起来粘性变低了。参与度下降。停留时间下降。这并不是倒退。这是用户找回了属于自己的时间。如果你的组织将参与度等同于收入，那么在你发布这个功能之前，你需要重新审视这些指标。

你无法假装不存在的裂缝

Agent 产品往往呈现双峰延迟分布。一部分任务在几秒钟内完成——一个简单的问题、一次工具调用、一个总结。另一部分任务则需要几分钟到几小时——多步调查、代码迁移、涉及数十页抓取的研究。中间地带几乎是真空的，因为一旦加入带有重试机制的工具调用循环，你要么保持在几秒钟内，要么就会直接冲破 30 秒。

这两种模式之间的裂缝是 UX 设计最难的地方，也是大多数团队选择逃避的地方。常见的失败模式是为两者选择同一种 UI。纯聊天产品在长尾任务中折磨用户。纯收件箱产品在短任务中显得迟钝，简单的问题也被变成了一个“运行任务（run）”，最后弹出用户并不想要的通知。两者都不对，因为两者都没有承认这条裂缝的存在。

有效的模式是在产品中让这条裂缝显式化。任务从类似聊天的界面开始，并带有流式输出。如果模型发出信号——或者系统通过已用时间、待处理的工具调用或计划的步骤数检测到——该任务将跨入长时间运行的领域，那么该任务会自动“晋升”。聊天线程折叠成一张卡片：“任务正在收件箱中运行，完成后我们会提醒你。”用户重新获得了光标。该运行任务获得一个稳定的 ID。结果会出现在它该出现的地方。

这不是什么花哨的功能。这是对“交互式工具”和“后台工作者”是共享代码库的不同产品这一事实的认可。让用户去猜测他们处于哪种模式是行不通的。有些产品将其暴露为显式的“异步运行”按钮。这对于高级用户来说没问题；但作为默认设置却很糟糕，因为大多数用户在启动时并不知道模型需要多长时间。模型通常自己也不知道。基于已用时间或计划步骤数的自动晋升将决策权移交给系统，而这正是它该待的地方。

没有后端存储的收件箱只是场戏

一个有效的收件箱所需的基础设施超出了大多数团队的预估。这些保证听起来微不足道，直到你真正交付。每个运行任务都需要持久化状态，以便在用户会话、模型重试和下一次部署中幸存。每个运行任务都需要一个稳定的 URL，无论哪个分片运行了该作业，一周后渲染的内容都必须相同。每个运行任务都需要一个用户可以配置、静音和审计的通知通道。每个运行任务都需要一个可审查、可对比的 Agent 工作呈现——不是思维链转储，不是原始工具追踪，而是一个带有足够引用的摘要，让用户无需重新执行任务即可确认答案。

这是分布式系统专家已经交付了 20 年的事务型收件箱模式，只是换了个新马甲。运行任务连同其输入、中间状态和结果一起被持久化。完成时触发一个持久化事件。该事件驱动通知和 UI 刷新。如果其中任何环节是瞬态的，那么在你的 Pod 中途重启时，收件箱就会退化回聊天界面。用户对你的产品弄丢他们工作的经历记忆犹新。

从聊天转向收件箱的团队值得注意的三个实现陷阱：

• 重试绝不能创建新的运行任务。 如果你的系统在瞬时故障时进行重试，用户应该看到一个具有多次尝试记录的运行任务，而不是三个状态不明的运行任务。这是幂等性的新应用。
• 结果 Schema 必须进行版本化。 你会改变 Agent 总结工作的方式，而你肯定不想让上个月的分享链接失效。存储原始追踪记录并在读取时渲染摘要。
• 通知是有成本的。 如果用户每次启动任务都收到一个“任务已完成”的推送，他们不出一周就会开始无视这些通知。进行批处理、摘要或根据重要性设置条件——一个在 20 秒内完成的任务可能不需要推送通知；但一个在 1 小时后失败的任务绝对需要。

聊天仍然胜出的场景

收件箱不是聊天的替代品。它是委托任务的正确原语，而非对话。头脑风暴、解释说明、实时迭代文章——这些仍然保持聊天形式，因为价值在于反复交流，而非最终状态。错误在于假设所有的 Agent 交互都是对话。大多数高效的 Agent 使用是委托任务，其对话外壳只是 LLM API 看起来像聊天 API 的产物。

随着 Agent 变得更长时程——云端托管的开发 Agent、运行数小时的研究 Agent、对事件流做出反应的后台 Agent——重心将向收件箱移动。首先理解这一点的团队将交付出让用户放心委托工作并确信会有结果的产品。而那些仍在优化加载动画（spinner）的团队，交付的产品只会让用户在一次次被迫中断的运行中明白：AI 并不值得等待。两类产品使用相同的模型。但只有其中一个是真正的产品。

如果你今天正在构建一个 Agent，且你的路线图中将“提速”作为解决长延迟投诉的答案，请停下来。投诉的核心不是速度，而是隐喻。给用户一种交付工作并离开的方式，一种回来寻找结果的方式，以及一种将运行任务作为产物共享的方式。然后再去提速。按这个顺序来。