一个常见的演示是这样的：用户说一句话，屏幕上的AI Agent就开始拆任务、查资料、调用工具，最后生成一份结果。整个过程顺畅得像一条流水线。但把同样的流程放进真实业务，问题常常不在它会不会做，而在它什么时候该停。
停顿不是能力不足，而是系统设计的一部分。它意味着系统承认信息可能不完整、动作可能不可逆、工具可能失败。把这些不确定性暴露出来，比假装一切顺利更接近可用状态。
会执行，不等于会等待
AI Agent通常由目标、计划、工具调用和状态记忆组成。它可以围绕一个目标连续行动，但连续行动也会放大误判。比如用户说“月底前处理一下”，这句话缺少对象、范围和完成标准。如果系统直接补全意图并执行，后面可能需要更多人工返工。此时合适的动作不是继续推理，而是标记待确认，或者提出一个具体问题。
另一类停顿来自副作用。查询信息可以重试，发送通知、修改记录、提交表单却未必能撤回。对这类动作，系统需要区分“准备执行”和“已经执行”，并在不可逆步骤前设置检查点。检查点不是给自动化拖后腿，而是把责任边界写清楚。
把“停”写进流程
- 状态要可见：任务是在等待确认、等待外部结果，还是失败待处理，不能只显示“运行中”。
- 工具调用要有契约：输入输出、权限范围、失败返回都应明确，避免系统靠猜测继续。
- 不可逆动作前留确认：确认内容要具体到对象和影响，而不是一句笼统的“是否继续”。
- 重试要有上限：遇到超时或空结果时，系统应知道何时停止并交还给人工。
边界感也是产品能力
讨论AI Agent时，注意力容易放在它能完成多少步骤。但在真实流程里，可预期比步骤数量更重要。一个会在权限不足时说明原因、在信息缺失时提问、在动作不可逆前请求确认的智能体，可能不显得机灵，却更适合进入业务系统。
停顿的位置，决定了自动化的边界。把等待、确认和失败处理设计清楚，AI Agent才不只是一个会往下点的按钮，而是一个能被托付一段流程的协作者。