Agent 通宵运行前，先验证目录与访问边界

让 AI Agent 通宵改代码，准备工作不该只停在补提示词。作者给出的结论是：真正决定无人值守风险的，是工作目录、工具权限、执行预算、停止机制和事后验收。这些约束要在运行前设好，还得证明它们确实生效。

这份清单值得程序员读，是因为它把「希望 Agent 别出错」拆成了六项可以检查的操作。但文章没有提供事故统计或对照实验，结尾也在销售配套资料。我们可以采纳其中的工程方法，同时把作者的经验判断与验证结果分开看。

目录和权限，必须经得起实际操作

第一项检查是固定工作目录。作者要求一次运行只围绕一个项目展开，从正确目录启动，在任务说明中使用绝对路径，并让 Agent 在正式执行前打印工作目录、列出可见内容，确认无法看到相邻项目。

原因很具体：../build 指向哪里，取决于命令从哪里运行。起点错了，清理目标、配置来源和修改对象都可能跟着错，最后把测试环境的修改落到生产检出目录。

不过，绝对路径只解决寻址歧义。「无法看到相邻项目」还需要文件系统权限或运行环境隔离来兑现，打印目录本身证明不了这一点。

第二项是验证破坏性命令的拦截规则。不能只看 hook 文件存在，就认定它会执行。文件缺少执行权限，或者规则只识别某一种写法，都可能让保护失效。

作者举了 rm -rf、git -C /somewhere clean -fdx 和 bash -c 包装命令的例子。检查应当针对可丢弃目标，实际触发声称能够拦截的命令，观察它们是否被阻止。递归删除、强制推送和原始磁盘写入，都在作者要求验证的范围内。文章没有提供完整测试脚本，也没有展示测试结果。

第三项是让密钥在权限层不可读。.env、.ssh/、凭据存储和 token 文件，不能只靠一句「不要读取」保护。调试配置时，Agent 很容易把查看相关凭据当成下一步；一旦秘密进入上下文，还可能继续出现在日志、摘要或提交信息里。

作者因此要求测试运行后，再用 grep 检查日志和会话记录是否泄漏了疑似密钥的字符串。权限限制负责阻止读取，日志检查负责发现遗漏，两者处理的是不同环节。

停止条件要先写，重试也要有上限

第四项检查是设置硬预算，分别限制工具调用次数、shell 命令次数和实际运行时长。任务说明还要写清楚什么算完成、什么算卡住；环境支持时，同一命令连续三次以相同方式失败，就自动停止。

这里的「硬」很关键。写在提示词里的次数上限只是要求，能否真正终止运行，要看外部执行器有没有计数和中断能力。文章没有指定实现工具，也没给出适合所有任务的预算数值。

作者担心的不只是花钱。一项任务可能已经执行成功，只是返回结果失败，Agent 再试一次，就可能重复收费、发邮件或写入数据。

预算能限制重试规模，却不能保证操作只执行一次。对于有外部副作用的任务，还需要单独处理重复执行。作者在付费资料介绍中提到重叠运行防护，但正文没有展开，不能把六项检查当成这类问题的完整方案。

第五项是独立的停止开关，以及能随时查看的运行日志。停止方式可以是外层执行器在步骤之间检查的停止文件，也可以是能够干净终止的进程，关键是停止运行不必先说服 Agent。

日志则要求只追加、每步一行、带时间戳，并写到离开电脑也能查看的位置。它不仅用于追查错误，还要暴露「任务根本没有执行」：没有报错不代表运行成功，可能连启动都没发生。

这还留下一个实现问题。执行器只在步骤之间检查停止文件时，当前步骤如果长时间卡住，停止就会延迟。因此，检查机制存在之外，还得确认中断能在什么时机生效。

早上先看产物，再看 Agent 的完成报告

第六项是每次都做事后验收。作者建议醒来后先查看目标位置，确认文件确实存在、内容符合描述、路径也正确，然后再看摘要，并核对运行日志行数与报告是否相符。

Agent 的完成报告是一项待验证的主张，产物才是验收起点。

文章举的失败情形是：五个文件只写入三个，第四个被截断，第五个去了错误路径，摘要却依然宣布完成。对于「已经修复重叠问题」这样的结论，也要检查它是否成立，并在动手修复之前记录判定，保留原始失败状态。

作者用「三十个经过验证的早晨」说明如何逐步增加自主权。这里的三十不是实验得出的安全阈值，而是一个例子：连续报告成功，与连续通过验收，积累的是两种不同证据。

同样，日志行数只能辅助发现异常，不能证明工作正确。写入十次和正确完成十项任务之间，还隔着内容验收。文章要求首次无人值守前执行全部六项检查，配置变化后重新执行第 2–6 项，这比一次配置后永久信任更合理。

我的判断

我认同作者把重点放在运行环境上的取舍。目录限制、权限拒绝、调用预算和独立停止开关，都能把约束落实到执行过程。提示词仍然要写清目标，但不适合独自承担这些控制职责。

作者也承认，基于模式匹配的命令拦截只是纵深防御，不能充当沙箱。命令可以通过不同写法绕开字符串匹配，因此，一个通过若干测试的 hook，不能自动获得限制所有危险操作的能力。

需要打问号的是证据强度。作者自述有生产环境无人值守自动化和制造业经验，却没有公开运行次数、事故比例、误拦截率或对照数据。文中「标准失败方式」和「运行后更安全」属于经验判断，不能据此估算风险下降多少。

文章末尾的商业推广也应单独看待。免费样例包含 10 点安全清单、最小 CLAUDE.md 骨架和 guard hook，采用自定价格，$0 也可获取。完整包标价 Standard $99、Complete $179，提供 30 天退款，并宣称包含 SKILL.md 规范、权限配置、自动化测试、验收格式、事故手册和四道关卡的分阶段放权方法。这些是资料包的内容介绍，正文没有足够信息验证其质量。

能拿来做什么

• 给前端或 Node 项目的首次通宵任务限定目录，使用绝对路径，并实际确认相邻项目和凭据路径受到权限限制，避免把路径约定误当成隔离措施。
• 为现有命令拦截规则准备可丢弃目标，验证常见命令、替代写法及 shell 包装是否触发保护；规则修改后重新执行检查。
• 在执行器里设置工具调用、shell 命令和运行时长上限，写明完成与卡住条件，并验证停止开关能否中断实际运行。
• 把次日验收列为任务的一部分，先检查目标文件和实际行为，再核对日志与摘要；连续通过验收后，再逐步扩大无人值守范围。