许多 AI agent 产品看起来“像挂了”，并不是因为真的挂了，而是因为它对用户说的话过于含糊。界面永远只会显示“处理中”“请稍候”“正在为你生成结果”，哪怕后台其实早就知道当前 run 是在排队、等待人工 review、被 policy 阻断，或者只是在做慢吞吞的环境 provision。用户看不到这些差别，于是系统无论多努力，最终给人的感受都还是不透明。
这件事不是文案优化，而是状态建模问题。因为 run status 一旦进入界面、通知、客服和审计记录，它就成了一种承诺。如果系统明明只是“还没开始”，却告诉用户“正在执行”；如果明明需要人工 review，却仍显示“处理中”；如果 ETA 根本没把不确定性算进去，却给出一个很精确的 3 分钟倒计时，用户就会在最不该失去信任的时候失去信任。
好的状态语义不是让产品看起来更高级，而是让用户和系统对同一件事有相近的理解。只有这样，等待、补充信息、人工接力和失败恢复才不会全被翻译成一种模糊的“稍后再试”。
建议配合 AI agent TTFT 与冷启动优化、AI agent Human Review Console 设计、AI agent Deadline 与超时预算 和 AI agent Prompt Contract 设计 一起看。
先把对外状态和对内状态分开
| 对外状态 | 对用户真正意味着什么 | 用户此时该做什么 |
|---|---|---|
| waiting | 任务已接受，但还没获得执行资源 | 可以等待，不必重复提交 |
| running | 系统已进入实际执行 | 等待阶段性反馈或结果 |
| needs_input | 系统缺少必要信息，继续跑下去只会瞎猜 | 补充输入 |
| needs_review | 结果已接近完成，但需要人工确认才能继续 | 等待审批或自己介入 |
| blocked | 当前被 policy、权限或外部条件阻断 | 查看原因，决定是否解除 |
| completed | 可交付结果已经稳定落地 | 使用或导出结果 |
这张表最重要的不是命名，而是“用户此时该做什么”。因为用户真正要从状态里获得的是行动信号，而不是系统内部的技术细节。
ETA 最怕的不是不准，而是假装很准
很多产品喜欢给一个具体倒计时，好像这样用户就更安心。但 AI agent 的 ETA 往往天然不稳定：模型推理、队列排队、人工 review、外部 API 波动、浏览器 runner 冷启动，都会让时间预估大幅摆动。这个时候如果还给用户一个“预计 2 分 13 秒”，本质上是在制造比沉默更糟的失望。
更诚实的做法通常是用区间或阶段表达：
- 预计数十秒内开始执行
- 还需数分钟，当前在等待人工 review
- 已进入最终提交阶段，通常很快结束
这类表达少了点炫技感，但更接近系统真实不确定性。它的价值不是更“好看”，而是让用户知道时间的不确定来自哪里，而不是误以为系统在随机漂移。
Needs review 和 blocked 必须是两种不同体验
很多系统把这两个状态混着用，结果用户分不清到底是系统在等人，还是系统根本过不去。其实它们完全是两种语义：
needs_review的核心是系统已经做到了当前自动化边界，需要一个人做判断blocked的核心是系统在当前约束下无法继续，除非外部条件发生变化
把它们混在一起的后果很直接：用户会把所有暂停都理解成错误，支持团队也会把所有暂停都当成 bug。时间久了，产品会被迫回到最偷懒的状态文案：“处理中，请稍后”，因为没人敢把真状态露给用户。
真正有用的状态，不该只告诉用户“发生了什么”，还要告诉用户“为什么停在这”
用户看到 blocked 并不够，他们还需要知道是：
- 缺权限
- 缺输入
- 超过套餐边界
- 需要等待外部回调
- 命中了安全策略
当然，这个“为什么”不该暴露系统内部敏感细节，但至少要给用户一个可理解的原因层级。否则他们只会不断点击刷新、重复提交，或者找客服问一句永恒的问题：“它到底有没有在做事？”
一个很典型的事故：状态文案太乐观，支持团队被问爆
某个代码修改 agent 在进入人工 review 时，前端仍显示“正在为你生成修复方案”。团队本来觉得这样更平滑，不想让用户看到“需要人工 review”显得像系统没能力。结果上线后两周，客服工单激增，原因很直接：
- 用户看到持续 15 分钟的“生成中”，以为系统卡住
- 实际上任务早在第 2 分钟就进入 review 队列
- 用户不断重新提交，造成重复 run
- 重复 run 又进一步推高 review 队列长度
最后问题并不是 review 流程太慢，而是状态语义太假。修复后，团队直接把状态拆开显示：正在等待人工复核，通常需要 5-20 分钟。这句话听上去没那么“全自动”，但它第一次让用户知道当前等待的是谁、为什么等、该不该重试。
真正要守住的，是状态和承诺之间的一致
如果你现在要补 run status，最值得先做的不是设计更多 loading 动画，而是把 waiting、running、needs_input、needs_review、blocked 这几个状态的用户语义说清楚。只要状态还在同时承担“安抚用户”和“表达事实”两种冲突职责，界面就迟早会说谎。
AI agent 最终赢得信任的方式，不是永远显得很聪明，而是让用户在等待、暂停、补充信息和人工接管这些不那么完美的时刻，仍然能看懂系统现在到底站在哪一步。
延伸阅读：
