想象一个再普通不过的上午：邮箱里躺着一封需要转发的通知，日历上有一个待改期的会议，文档里有一处需要同步的修改。你把这几件事交给一个智能体，期待它一口气做完。几分钟后，它确实做完了，却在转发前停下来问你：这封通知是否要抄送外部联系人？这个停顿，可能比自动完成更值得注意。
会做事，不等于会收尾
过去谈自动化，常把重点放在“能不能执行”。点按钮、填表单、跨应用搬运信息，这些能力在演示里很直观。但放到真实工作流里，任务常常没有清晰终点：一封邮件该不该发、一个日程该不该改、一份文档该不该覆盖，背后有权限、关系和上下文。智能体如果只会往前冲，效率会变成风险。
所以，停顿不是能力不足，而是设计的一部分。它至少包含三层判断：这件事我有没有权限做；做完之后谁会受影响；不确定时该向谁确认。前两层偏规则，第三层更接近协作。把这三层拆开，才能讨论自动化到底能走多远。
权限边界比任务清单更难写
很多任务说明写得很细：读取邮件、提取时间、创建日程、发送通知。看上去完整，但真正难写的是边界条件——哪些邮件不能自动转发，哪些日程改动需要对方同意，哪些文档只能建议不能直接改。清单能描述动作，却很难穷举场景。
- 动作权限：能读、能写、能发，还是只能生成草稿。
- 影响范围：只改自己的日历，还是触碰他人的安排。
- 不确定处理：遇到模糊指令时，是猜测、跳过，还是请求确认。
这三项不复杂，却决定了它是工具还是代办者。工具等人下指令，代办者要替人判断。后者更省事，也更需要克制。我的判断是，短期内更现实的方向不是让智能体包办一切，而是让它把不确定的部分显式交还给人。省掉机械步骤，保留关键确认。
把确认做得轻一点
一提到确认，很多人会想到弹窗。弹窗太多，自动化就退化成提醒器。好的确认应该尽量轻：只在影响外部关系、覆盖原始内容、产生不可逆结果时出现；确认信息要具体，比如“将把这封邮件转发给外部联系人，并附上原附件”，而不是笼统地问“是否继续”。前者让人一眼判断，后者只会训练人盲目点“是”。
另一个容易被忽略的点是记录。智能体做了什么、为什么停下、人改了什么，这些痕迹不必复杂，但要能回看。没有记录，停顿就只是一次打断；有了记录，停顿才可能变成可复用的规则。自动化的成熟，往往不是动作越来越多，而是边界越来越清楚。
回到开头那个上午。如果它能在转发前停一下，在改期前确认一句，在覆盖文档前给出差异，它未必显得更聪明，却更像一个可以共事的角色。自动化的下一步，也许不是把人的判断全部拿走，而是把判断放在更该出现的位置。停顿一下，有时正是为了少出一次错。