周一早上，协作工具里出现一串自动消息：一个流程先查了资料，又改了表格，随后在群里连续询问“是否继续”。没有人被明确点名，消息却悬在那里。流程没有报错，事情也没有做完。
这类停顿常被当成故障。其实它暴露了 AI Agent 的一个边界：会调用工具，不代表知道何时收手。它能读日历、发邮件、改工单，也可能在信息不足时继续往前推。真正麻烦的地方，往往不是它不会做，而是它太愿意做。
会做事，不等于会收手
从技术上看，AI Agent 通常要完成几件事：理解目标、拆解步骤、调用工具、根据结果调整。演示里，这些环节连起来很顺；放进真实协作，问题会出现在缝隙里。比如目标里少了一个限定条件，工具返回了模糊结果，或者动作的影响范围超出了当前任务。此时继续执行，看起来是在推进，实际是在替人做没有授权的判断。
一个能读日历、发邮件、改工单的系统，如果没有明确的权限边界，很容易把“可以操作”当成“应该操作”。可逆的动作或许还能撤回，涉及对外发送、他人可见、流程状态变化的动作，就需要提前设卡。卡在哪里，不能只靠提示词临场发挥。
“问一句”也是能力
能长期协作的 AI Agent 会把“问一句”当成动作的一部分，而不是失败后的补丁。它需要在几个节点上停下来：信息是否足够支撑下一步；动作是否可逆；影响范围是否超出当前任务；有没有更合适的确认对象。停下来不是拖延，而是把判断交还给该负责的人。
- 信息不足时，先说明缺什么，而不是猜一个答案。
- 动作不可逆时，给出将要发生的变化，再等待确认。
- 影响他人时，明确告知范围，而不是只留一条系统消息。
这些判断不该全部藏在提示词里。产品层需要把权限、确认、回滚和记录做成可见的流程。否则每次停顿都像意外，每次继续都像冒险。
把停顿留在流程里
团队引入 AI Agent 时，容易先看它能跑多少流程、省多少步骤。这些当然重要，但另一个问题同样关键：它什么时候停，停给谁，停完留下什么记录。没有这些，自动化会把模糊地带推给群里的人，让确认变成新的负担。
自动化的可靠，不只看跑得多快，也看能不能在关键处慢下来。AI Agent 的价值，也许不只在替人完成动作，还在把“该不该继续”这个问题，放回流程里一个清楚的位置。