停顿不是故障，是边界的形状
一次内部资料更新演示里，智能体很快完成了检索、摘录和邮件草稿。到了真实协作中，它却在“由谁确认”这一行停住。没有人觉得它坏了，只是流程里多出一个需要人接手的空档。这个空档常被演示剪掉，却决定了自动化能否继续。
我们习惯把自动化想成一条连续流水线：识别、判断、执行、反馈。工具调用让前几步看起来顺滑，确认却把问题推回组织本身。谁有权批准，哪类改动需要留痕，出现冲突时先找谁，这些答案不在模型里，而在流程的约定里。智能体可以生成下一步动作，却很难替组织决定谁该承担后果。
能调用工具，不等于能承担任务
很多讨论把重点放在能力清单上：会不会搜索，能不能写代码，是否记得上下文。真实场景更在意停顿之后发生什么。一个动作发出去，失败了有没有重试边界；调用外部系统超时，是继续等还是转人工；用户改了口径，之前的计划要不要作废。缺少这些约定，系统越主动，周围人越紧张。
我倾向于把这类问题称为“可退出性”。不是让系统随时放弃，而是让每一步都有清楚的出口：在什么条件下停，停完交给谁，交接时保留哪些信息。没有出口的自动化，容易把一次小异常拖成一场排查。
先把等待写进设计里
如果要把等待变成可控环节，不妨在动手编排之前先写几行朴素规则：
- 任务边界：哪些操作允许自动执行，哪些必须经过确认；确认人不在时，流程停住还是转交。
- 状态可见：当前在等什么，等了多久，等待是否已超出约定；这些信息要让接手的人看得见。
- 异常出口：失败后最多尝试几次，什么情况下停止，停止后保留哪些上下文。
- 退出与回滚：已经产生的草稿、通知或记录，能否撤销，撤销后如何说明。
这些规则不酷，也不适合放进演示视频。它们却决定了智能体在真实流程里是“帮一段忙”，还是“接住一整件事”。演示追求顺畅，生产环境需要可解释的停顿。两者之间的差距，往往不是模型能力，而是流程设计愿不愿意承认不确定性。
一种可操作的做法，是让智能体先承担边界清楚的小段任务：整理材料、生成草稿、检查缺项，再把确认和执行留给明确的人。等流程里的等待位置被记录、被理解，再逐步延长自动化的链条。这样做不够戏剧化，却让协作有迹可循。自动化要解决的，可能不只是速度，还有该停的时候能否停得明白。