智能体加载状态难题：为 45 秒的 UX 深渊进行设计

你的产品在第 10 秒到第 45 秒之间存在一个“空洞”，在这个时间段内，你设计的任何东西都不再起作用。用户在 10 秒左右就会放弃无响应的 UI —— Jakob Nielsen 在 90 年代就确定了这个阈值，现代的眼动追踪研究显示的偏差也不过一两秒。现代智能体（Agent）的工作通常需要 30 到 120 秒。多步规划、检索、几次工具调用，可能在最终输出前还要经过一轮反思 —— 延迟预算不再只是预算，而是一个巨大的深渊。

大多数团队在第一次发布智能体功能并查看会话录像时都会发现这一点。用户疯狂点击提交按钮。他们将查询粘贴到第二个标签页中。他们关闭窗口并从头开始重试，坚信系统已经崩溃。功能本身没问题，但等待过程出了问题。“加载动画出现”与“答案送达”之间的空白地带是 AI 产品设计中最被忽视的环节，而它正是决定用户认为你的智能体是聪明还是死机的关键。

随手放一个通用的加载动画是一种本能，但这种本能会毁掉你的产品发布。加载动画从未被设计用来承载 30 秒的“重量”。它告诉用户页面是活的，但它没有告诉用户智能体是在思考、搜索、等待缓慢的 API，还是已经挂起。当所有状态看起来都一样时，用户会假设最坏的情况，因为他们唯一的信号就是自己不断上升的焦虑。

为什么当智能体需要 60 秒时，10 秒规则依然重要

Nielsen 的三个阈值对于对话式 AI 依然非常适用。在 100 毫秒时，系统感觉是瞬间响应的；在 1 秒以内，用户的思维流能保持连贯；超过 10 秒后，用户的注意力就会转移到其他事情上，当响应最终送达时，他们甚至需要重新适应才能开始阅读。

10 秒规则最初是为页面加载制定的，但其背后的认知限制是注意力层面的，而非技术层面的。它并不关心你是在等待数据库查询还是一个执行三个步骤的工具调用智能体。短期记忆容量和持续注意力是人类的常数。在一个只提供加载动画的 UI 中发布一个耗时 30 秒的智能体，无异于要求用户去维持系统拒绝为他们维持的状态。

一个有用的思考方式是：超过 10 秒后的每一秒，都是用户产生怀疑的一秒。我表达错了吗？这东西坏了吗？我该换个工具吗？UI 在 10 秒后的任务主要不是为了娱乐 —— 而是为了吸收怀疑，并用进度的证据取而代之。该原则之下的所有东西都只是实现细节。

四个延迟区域及其所需的模式

一个有效的思维模型将智能体 UX 分为四个延迟区域，每个区域都需要不同的处理方式。将所有区域简化为一个加载动画是导致“深渊”的错误。

区域一（0 到 2 秒）： 用户期望输入得到近乎瞬间的确认。一个输入指示器或禁用的提交按钮就足够了。不需要规划预览，不需要运行轨迹（trace）转储，任何会将注意力从他们刚刚输入的查询中转移开的东西都不需要。

区域二（2 到 10 秒）： 经典的加载动画区域。一个简单的动画指示器是可以接受的，但加载动画不应孤立存在 —— 请为它配上一行描述正在发生的事情的状态字符串。如“正在读取你的文件”、“正在搜索文档”、“正在调用 API”。为工作命名，可以将焦虑的等待转变为有叙事的等待。

区域三（10 到 60 秒）： 这就是深渊。环境状态徽标、流式推理、中间工具调用摘要、规划预览 —— 无论哪种披露模式适合你的产品，屏幕上必须发生一些事情，将用户的注意力与智能体的进度联系起来。这个区域是顶尖团队拉开产品差距的地方，因为在这个区域，平庸的产品会让人感觉彻底崩溃。

区域四（60 秒及以上）： 将其视为后台任务，而非前台等待。用户应该可以自由切换任务，看到进行中工作的环境徽标，并在需要输入或完成时收到引起注意的通知。在这里使用全屏加载状态是一种反模式 —— 用户在智能体运行时需要继续其他工作。

大多数产品团队的本能是针对区域一和区域二进行校准的，因为经典的 Web 应用就存在于那里。区域三和区域四需要不同的能力，而这正是目前大多数智能体用户停留时间最长的地方。

什么该流式传输，什么不该

一旦团队意识到需要展示进度，往往会倾向于将整个智能体运行轨迹（trace）全部推送到屏幕上。工具参数、检索结果、推理 Token，每一个中间想法都完整呈现。这通常比加载动画更糟糕。原始轨迹是噪音，只有在开发智能体的工程师看来才代表能力；对于用户来说，它是令人生畏的文字墙，放大了迷失感。

问题不在于是否进行流式传输，而在于流式传输什么、在什么维度以及以什么节奏。

**规划预览（Plan previews）**是你能进行流式传输的最具杠杆效应的东西。如果智能体已将请求分解为三个或四个步骤，请在执行开始前显示这些步骤。用户现在对即将发生的事情有了模型。随着每个步骤的完成，它们可以依次亮起，将一分钟的等待转变为一个可见的进度清单。这种模式是智能体工作中与进度条最接近的等价物，也是能确实让用户留在标签页中的模式。

具名工具调用是下一个层级。“正在搜索过去 30 天的日志”是有信息的；而包含函数名和参数转储的原始 JSON Payload 则不然。内部工具调用与面向用户的状态字符串之间的转换层通常只需一个 10 行的 Prompt，这是团队能做的回报率最高的 UX 工作之一。对于前 10 或 20 个工具调用，手动映射比从函数名自动生成更值得；生硬的自动文本往往比没有文本更糟。

流式推理，或“思考” Token，是最具争议的一层。当它起作用时，它传达了智慧和动力；当它失败时，它读起来像是废话，暴露了内部 Prompt 结构，偶尔还会泄露令人尴尬的中间推理过程。实际的指导建议是：仅在推理过程简短且可展示时才进行流式传输，并始终放在渐进式披露的交互件中 —— 默认折叠，对需要的用户可展开。永远不要强迫用户通过阅读轨迹来理解正在发生的事情。

最后，中间结果（如果可用）是黄金标准。逐步渲染部分答案 —— 先是食谱名称，然后是配料，最后是步骤 —— 极大地降低了感知延迟，因为用户在完整响应就绪之前就已经开始获取价值。并非每种智能体架构都支持流式传输中间结果，但如果你的架构支持，它就是击败所有其他模式的选择。

最快破坏信任的反模式

有几种加载状态模式实际上比诚实的旋转加载图标（spinner）更糟糕，因为它们会让用户养成不信任产品信号的习惯。

虚假进度条 —— 无论实际状态如何，都以固定速率移动的进度指示器 —— 在底层任务卡住之前感觉还好。在那一刻，进度条继续前进，而系统却处于闲置状态，当用户最终超时时，进度条仍声称完成了 80%。一旦发生这种情况，用户对整个产品进度指示器的信任就会永久崩溃。

通用的“思考中...”旋转图标 —— 不加区别地应用于每次等待，这会告诉用户该指示器毫无意义。如果“思考中...”既出现在不到一秒的查询中，也出现在两分钟的研究运行中，用户就会失去校准预期的能力，转而完全忽视该指示器。

过于写实的追踪信息转储 —— 转储原始的 JSON 工具调用、未过滤的检索块或未格式化的推理 Token —— 将 Agent 的追踪信息视为进度指示器，而它实际上是调试输出。工程师喜欢它；但其他所有人都会感到恐慌。

静默重试 是最残酷的反模式。当 Agent 遇到频率限制（rate limit）或临时故障并静默重试时，用户会看到 30 秒的空白，并且无法将其与系统死机区分开。如果重试是你架构的一部分，请将它们展示出来 —— “正在重试”、“提供商响应缓慢”，甚至“正在等待频率限制解除” —— 而不是让它们隐形地消耗掉延迟预算。

不允许中断的进度指示器 违反了 Nielsen 几十年前阐明的一条规则：任何超过 10 秒的操作都需要一个明确标注的取消方式。对于 Agent 来说，这一点尤为重要，因为用户经常在长时间运行的中途意识到自己的查询表述不当，并希望重新开始。一个没有取消按钮的运行中任务，就像是一个用户从未同意过的强制契约。

第 0 秒的预期契约

最重要的 UX 决策发生在 Agent 开始工作之前。那就是用户提交查询，且 UI 决定如何展示所需时长以及等待期间可见内容的时刻。

优秀的 Agent 产品会明确设定预期契约。一个轻量级的例子：提交后，UI 显示“这通常需要大约 30 秒”，下方带有计划预览。这个数字锚定了用户的心理时钟。计划预览让他们了解进度的大致情况。两者结合，将等待从一个无底深渊转变为一个有边界的、有叙事的区间。

契约不一定是字面意义上的预计到达时间（ETA）。“三个步骤 —— 搜索、分析、总结”是一个契约。“正在阅读你最后的 20 份文档”也是一个契约。任何告诉用户下一个时间区间“形状”的短语都在起作用。相反的做法 —— 一个不透露任何时长或形式信息的静默旋转图标 —— 会迫使用户在等待中产生自己的假设，而他们的假设几乎总是悲观的。

一个微妙的变体：契约应该反映实际的架构，而不是理想中的架构。如果 Agent 通常在 20 秒内完成，但偶尔会飙升到 90 秒，“这通常需要大约 30 秒”是诚实的；而“这将需要 30 秒”则是一个会被打破并受到惩罚的承诺。保守且基于范围的表述 —— “通常不到一分钟” —— 比精确的单一数字声明更能应对波动。

实践中真正交付的内容

真正重要的加载状态工作是枯燥且机械的，做得好的团队往往会做同样的那几件事。他们为核心工具调用手动编写命名状态字符串，而不是从函数名自动生成。他们在提交后立即渲染计划预览，即使该计划是推测而非生成的。他们将推理追踪折叠在开关后面，默认关闭。他们展示重试和频率限制退避，而不是吞掉它们。他们交付一个真实有效的取消按钮。他们在等待开始前设定时间形状预期，并根据预期等待时间调整指示器的大小，而不是在所有时长中都使用同一种模式。

这一切都不需要模型能力的提升、协议升级或新框架。这是产品工作，主要集中在交互层，每个界面通常不到 50 行代码。那些将 30 到 90 秒的窗口视为设计空间而非必要之恶的团队，交付的 Agent 产品即使底层延迟没有变化，也会让人感觉很快。而那些随便放一个通用的旋转图标并寄予希望的团队，交付的产品会被用户（根据其实际体验正确地）描述为“坏了”。

Agent 的加载状态不是一个等待延迟修复的工程问题。它是一个设计领域，与产品中的任何其他领域一样具有杠杆作用，而且关注它的从业者更少。这既是一个警告，对于任何愿意从事这些枯燥工作的人来说，也是一个机会。