清晨打开工单系统，智能体停在一个收件人确认框前。日志没有报错，只写着一句：地址已找到，但收件人不在通讯录里。它没有继续往下点，也没有把任务丢回队列，而是把判断依据、当前动作和待确认项摆在了界面上。
这个停顿值得注意。很多自动化脚本追求的是从头跑到尾，路径写死，遇到异常就退出。智能体在流程里做的事，往往不是一次性动作，而是在计划、调用工具、读取反馈之间来回调整。它会遇到模糊指令，也会遇到工具返回的空结果。能不能停下来，把“为什么做”交代清楚，直接决定人是否敢把下一步交给它。
停顿不是故障
有人把停顿看成能力不足，其实停顿是流程设计的一部分。一个只会在成功路径上奔跑的系统，放到真实业务里很快会撞上例外：地址写法不同、附件缺页、审批人休假。此时，系统若仍按原计划执行，错误会被推到下游；若直接失败，人又得从头排查。可用的做法是让它在不确定处形成待确认项，明确写出目标、依据、已执行动作和可选处理方向，再由人来判断。
这听起来像增加人工，实际是把人工放在需要判断的位置。它不必假装什么都懂。它可以把“我查到了两条地址记录，但收件人姓名对不上”呈现出来，而不是自行选一条。对使用者来说，这种坦白比流畅的执行界面可靠；对维护者来说，日志里留下的推理痕迹，也比一句“任务失败”便于恢复。
把权限切成小段
智能体进入企业流程，容易被当成会自己安排步骤的自动化工具。区别在于，自动化工具通常只被授权做固定动作，它则可能调用搜索、读取文档、发送通知、修改状态等多个工具。权限一旦给得过大，错误动作的半径也会变大。稳妥的方式是按任务阶段切分权限：查询阶段只读，草稿阶段可写但不可发送，涉及外部通知时再单独确认。
- 目标是否写清楚，避免它自行补全意图；
- 依据来自哪里，能否回看到原始记录；
- 动作是否可撤销，失败后能否回到上一个稳定状态；
- 卡住时谁来接，交接信息是否足够让人继续。
这些问题不新鲜，却常被“能跑起来”的兴奋遮住。一个流程里加入智能体，真正要改的不只是提示词，还包括权限边界、审计记录和失败恢复。否则，演示时顺滑，日常使用中就会变成不断救火。
留一个停顿的位置
从使用者角度看，它是否可靠，不只看完成了多少步，也看它在不该继续时是否停得下来。把“为什么做”说清楚，不是要求它长篇解释，而是让每个关键动作都能对应到目标、依据和确认点。企业流程里，信任往往来自可检查的细节，而不是漂亮的完成率。
下一次看到它停在某个确认框前，不妨先看看它留下了什么。若那几行字能让人迅速判断该放行还是该修改，这个停顿就有价值。这类系统走进日常工作的过程，大概也会由这些不起眼的停顿慢慢塑形。