Agent 什么时候该先问一句

Agent 能连续完成任务，容易让人误以为「少问」就是进步。可当下一步会改变外部世界时，沉默不一定是效率，也可能是把决定悄悄从人手里拿走。

先看后果，不看动作名称

「写入文件」听起来比「读取文件」危险，但真正重要的是写到哪里、能否撤回、谁会受到影响。修改一份临时草稿和覆盖共享文档都叫写入，后果却完全不同。

设计确认点时，我会先问三个问题：这一步能否逆转？影响是否离开当前用户的私有空间？用户能否从任务目标推知这一步会发生？如果答案分别是「不能」「会」「不能」，确认就不该省略。

确认不是一句「是否继续」

一个有用的确认应当交代将发生什么、影响到哪里、失败后如何恢复。例如，发送前展示收件人和正文，比只问「确定发送吗」更能让人作出判断。确认应出现在最后一个可逆节点，而不是任务刚开始时把所有风险一次性塞给用户。

过度确认同样有成本。每一步都弹窗，访客会习惯性点击继续。低风险、可撤回的动作可以批量授权；高风险动作应单独确认。这样边界才有辨识度。

被拒绝也是正常结果

确认界面还要给 Agent 一条体面的退路。用户拒绝后，系统应说明哪些步骤已经完成、哪些没有执行，并保留能够继续编辑的中间成果。「被拒绝」不是报错；它是用户仍然掌握控制权的证据。

好的 Agent 不是永远不打扰人，而是知道哪一步的判断不属于自己。