设想一个很普通的下午：你让智能体把一份会议纪要整理成待办，并顺手安排到日历。它读完文本，却停下来问：“第三条没有截止时间，要放在本周还是下周？”这一秒的停顿，值得多看一眼。
会停下来，不等于不够自动
过去的自动化更像一条固定轨道：步骤写死，输入符合预期就一路跑完。智能体面对的是半开放的任务，它要读材料、判断顺序、调用工具，还要在信息缺口处做选择。若把连续执行当成目标，错误也会被连续放大。停下来追问，是把不确定性暴露在动作发生之前。
这种停顿并不浪漫。它可能打断节奏，也可能让用户觉得麻烦。但许多任务真正难的地方，不在生成一段文字，而在决定这段文字该不该进入下一步。一个智能体如果从不确认，表面上流畅，实际上把判断成本推给了事后补救。
停顿放在哪里，决定了谁来承担后果
值得讨论的不是要不要停，而是停在哪里。可逆操作可以放手，不可逆操作应保留确认；信息缺失时可以追问，信息充足时不必反复打扰。对智能体来说，确认点是一种产品设计，也是一种责任分工：哪些决定由系统做，哪些后果需要人点头。
- 涉及对外发送、删除、覆盖等内容时，先展示将发生什么，再等待确认。
- 遇到时间、对象、范围含糊时，提出具体选项，而不是泛泛询问“是否需要帮助”。
- 执行后留下可读的记录，让人知道它读了什么、改了哪里、为何停下。
这些做法不追求让交互显得聪明，而是让过程可以被检查。智能体的能力越像助手，边界就越需要说清楚。否则，用户看到的是连续对话，实际得到的却是一串难以追溯的动作。
上下文之外，还有状态
谈智能体时，人们常把注意力放在上下文长度上，仿佛记得够多就能完成任务。实际使用中，状态是否清楚，常常决定任务能否继续：进行到哪一步，哪些信息已确认，哪些工具调用失败，下一步依赖什么。没有这些，长上下文也可能只是更长的混乱。
所以，评估一个智能体，不妨先看它什么时候停、向谁确认、留下什么记录。会执行是基本功，会说“稍等”才让协作有了起点。