传统接口请求两秒钟可以用 Spinner，AI 任务可能需要检索文档、调用工具、分析数据、生成结果甚至等待外部系统。用户真正焦虑的不是“等十秒”，而是不知道系统有没有卡住、还要多久、能不能离开。
01 先区分“很快返回”和“真正长任务”
一两秒内完成的请求不需要复杂进度动画；几十秒甚至数分钟的 Agent 工作则需要阶段状态。
所有任务统一一个 Spinner，会让长任务看起来像系统无响应。任务时长不同，反馈策略也应不同。
02 Streaming 适合让内容提前可见，但不等于真正进度
文本逐字出现会让用户感觉系统正在工作，并能提前阅读。但 Streaming 只能说明输出正在生成，不能告诉用户后台检索或工具执行完成了多少。
对于复杂 Agent，应把“正在搜索资料、正在分析 8 个文件、正在生成报告”等阶段反馈和最终文本流分开。
03 阶段状态应该是用户语言，不是链路日志
“tool_call_7 executing”“vector search batch 3”对开发有用，对普通用户没有。可以翻译成“正在查询知识库”“正在核对最新政策”。
不要为了展示“AI 很聪明”把完整 Chain-of-Thought 当进度。用户只需要足够理解当前工作和下一步。
04 预计时间不确定时，不要伪造精确进度条
AI 任务常受模型、文件大小、外部 API 影响，显示“73%”却卡在那里两分钟会降低信任。
如果无法可靠估算，可以使用阶段式进度、已完成数量或“通常需要约一分钟”的范围，而不是虚假精确。
05 长任务应该允许取消、离开或后台继续
用户不应该因为生成一份报告被迫盯着页面。可以支持“后台继续，完成后通知我”，并在任务中心查看。
如果取消不能真正停止外部动作，按钮必须准确表达，例如“停止后续步骤”而不是让人以为已经撤回已发送邮件。
06 部分完成比一次性失败更有价值
Agent 处理 20 个文件，第 18 个失败时，如果前 17 个结果可以保留，就不要整项显示失败。可以列出完成、失败和待重试项。
这与批量上传类似：恢复粒度越细，用户重复成本越低。
07 错误发生后要说明在哪一步和还能怎么继续
“任务失败，请重试”无法帮助判断。更好的提示是“已读取 6 个文件，但 CRM 连接已过期。重新授权后可从当前步骤继续”。
高成本 AI 工作应该支持续跑，而不是每次从头消耗时间和费用。
08 进度设计最终是对系统能力边界的诚实表达
Microsoft HAX 强调在互动过程中提供与当前任务相关的信息。好的 AI Progress 正是在告诉用户：系统正在做什么、什么时候需要你、出现了什么异常。
它不需要炫技动画，核心是减少不确定性，让等待变得可理解、可控制。
09 进度信息也要控制频率，避免状态文字不停跳动
每 0.2 秒刷新“正在思考、正在规划、正在继续思考”只会制造视觉噪音。可以在阶段真正变化时更新，保持文案稳定。
长任务里用户更需要“6/20 个文件已完成”这种可量化反馈，而不是拟人化状态表演。
10 完成通知要和用户当前上下文匹配
用户仍停留在任务页，可以直接展示结果；已经离开，则用站内消息、系统通知或邮件提醒。
不要对一个 20 秒任务同时发邮件和 Push，通知渠道应根据预计时长和用户偏好选择。
11 成本高的任务可以在开始前给出范围提示
如果一次生成可能处理 300 个文件、消耗大量额度或持续十分钟，开始前说明范围能帮助用户决定是否继续。
这也是 HAX“传达用户行动后果”的实际应用：时间和成本本身就是后果。
常见问题
AI 文本 Streaming 就足够了吗？
简单生成任务可能足够，复杂检索和 Agent 执行还需要阶段或工具状态。
AI 可以显示准确百分比进度吗？
只有能可靠估算时才适合，否则阶段状态或完成数量更诚实。
长任务一定要支持取消吗？
能取消时非常有价值；若部分操作不可撤销，应准确说明取消影响范围。
用户离开页面任务还能继续吗？
复杂长任务最好支持后台运行，并提供任务中心或完成通知。
需要展示 AI 的完整思考过程吗？
通常不需要。用户需要可理解的工作状态和证据，而不是内部推理细节。
相关服务与进一步咨询
链接复制成功
