通用方法 · 熟练
没人守在旁边时，Agent 该不该等？
等一个人，就是死锁
同一个权限提示，两种情况下的正确答案是相反的。有人在场时，「停下来等你点头」是最稳的设计；没人值守时，同一个「等」就变成了死锁 —— 它等的那个人不在，而它自己又不知道要等多久。这一页给三样东西：一张「有人场 / 无人场」的默认值对照（无人场的默认是拒绝，不是等待）· 一份被拒之后要留下的记录（因为「跑完了」不等于「干成了」）· 一条上机前的自测（你的任务跑完之后，怎么知道它真的做完了）。判据一句：无人值守的默认值只能取「拒绝」或「照旧执行」，⛔ 不能取「等」。
方法 · 一图看懂
1
先判「人会不会在场」 — 分成有人值守 / 无人值守两类：区别不在工具，而在「提示发出去之后有没有人响应」
2
无人场的默认值取「拒绝」 — 需要提示的动作一律判拒（而不是挂着等）；不需要提示的动作照当前权限模式走
3
把「被拒」记成失败，而不是记成完成 — 被拒的提示是一条结构化失败，必须出现在作业日志里，而不是消失在退出码 0 里
4
上机前先问一句「跑完怎么算干成」 — 先写下可核的产物判据（文件在不在、条数对不对），再让它无人值守地跑
原理 · 为什么有效
为什么「等」在无人场里是缺陷而不是保护？因为权限提示的设计前提是「有人会看到它」。这个前提一旦不成立，这套机制就从安全阀退化成死锁源：进程不报错、不退出，会一直挂着，直到被外部超时杀掉 —— 而那一刻你得到的信号是「超时」，不是「有个动作需要你点一下」。
同一批官方变更里还有一条同源的证据：无人值守的第一个非交互轮次，原本会一直等 MCP 服务器连上，后来专门加了一个变量去限制这段等待时长（设为 0 表示不等待）。两条改动指向同一个判据 —— 无人场里，任何「无限期的等待」都要被显式换成一个有界的默认值：要么拒，要么跳过，反正不能站着不动。
代价也写在官方原文里：这样做的后果是「任务可能跑完，但没做成本来要做的事」。所以第二件事必须同时做 —— 把「被拒的提示」当成结果的一部分报出来。否则你只是把「卡住」换成了「安静地少做了几件事」，后者更难发现。
适用场景
适合：夜里 / 周末跑的自动化任务 · CI 流水线里的 agent 步骤 · 定时批处理（周报 / 数据整理 / 巡检）· 任何「启动之后就没人看着它」的场合。
不适合：你在旁边逐步确认的交互式使用（那里「等」是对的，别改）· 危险动作与安全动作混在一步里、无法分开判定的任务（先拆步，再谈默认值）· 还没想清「跑完之后凭什么说它干成了」的任务 —— 那种情况下无人值守只会把问题藏起来，而不是解决它。
自测 · 5 问
我说得出我的任务属于「有人场」还是「无人场」吗？
无人场里，我给它设的默认值是「拒绝」还是「等待」？若是等待，那就是本次要改的那一处
任务跑完之后，我怎么知道它真的做完了？这个判据我写下来了吗
被拒的动作会出现在哪里？日志 / 报告 / 通知，还是哪儿都不出现
有没有哪一步是「等下一个人才会继续」的？我把它单独拎出来了吗
怎么上手 · 验证步骤
照这个顺序做：先在提示词或配置里把无人场的默认值改成「拒绝」（⛔ 不是「等待」），再在输出要求里加一条「凡是被拒的动作，逐条列出：动作是什么 · 为什么被拒 · 建议谁在什么时候补做」，最后跑一遍你日常最依赖的那个任务，看这份清单有没有出现。
做完自己核对三件：① 无人值守跑一遍，进程能自己结束（⛔ 不是被你手动杀掉）② 结束之后，产物判据能一条条核（文件在 · 条数对 · 内容非空）③ 如果有动作被拒，日志里能找到它，并且看得出「这次没做成」。