无人值守智能体要用执行约束防误操作

Agent 凌晨 3 点清理构建产物，却多删了上一级目录；定时任务重试后，两个实例同时改同一份状态；夜间任务停了，三周后才发现数据缺失。原文把这些事故归为同一类问题：无人值守的 Agent 缺少运行约束，光靠提示词里的「小心操作」兜不住。

作者给出的解法，是把权限、拦截、验证、调度和上线流程连成一套系统。这套思路值得程序员借鉴，但文中也在销售工具包，必须分清工程原则、作者自述和已经得到验证的效果。

提示词为什么挡不住一次误删

「删除前务必谨慎」只是模型收到的一条要求。它要和上下文中的其他内容竞争，长会话中可能被忽略，也可能被待处理文件里看似合理的指令带偏。

能否执行危险操作，应该由模型之外的机制决定。

作者列出的约束很具体：在命令执行前通过钩子（hook）检查，阻止指向项目外部的递归删除、直接写块设备，以及 curl | sh。权限规则则直接拒绝读取 .env、.ssh/ 和凭据存储，避免 Agent 以「检查配置」为由把秘密读进上下文。

另一类约束针对失控循环：为会话设置工具调用次数、Shell 调用次数和运行时长预算。强制推送、受保护分支操作、生产部署等行为，则应经过确认关卡，不能静默执行。

这里需要区分几种手段。提示词负责说明意图，权限负责限制可访问范围，hook 负责拦截具体调用，预算负责限制失控持续时间。它们解决的问题并不相同，不能靠一份越来越长的规则文件全部承担。

五层运行机制，怎样接住不同的失败

作者把团队运行无人值守 Agent 的经验整理成五层。

第一层是书面原则。把生产数据、秘密、对外发送、资金转移等禁区写进 Agent 实际读取的指令文件，并分别列出读权限和写权限。授权按 read-only → drafting → approval → limited autonomy 推进，也就是从只读、起草，到审批后执行，再到有限自治。升级依据应是运行证据。

第二层是执行约束。作者针对 Claude Code 配置了破坏性命令、秘密访问、Git 与生产操作确认、会话预算四类 guard，并为不同权限阶段提供配置。他们声称在 Claude Code 2.1.309 上做过实际拦截测试，完整套件附带 137 个测试用例。这说明作者给出了测试范围，但原文没有逐项展示测试结果。

第三层是验证。写入后要从目标位置读回，才能确认结果确实落地。对于「这次修改能解决执行重叠」这样的主张，还要在结果出来前写成可评分的预测，事后标记为 HIT、MISS、HOLD 或 INVALID。原文没有展开各状态的具体判定标准，核心要求是不能看完结果再修改预测。

第四层是持续运行纪律。调度要防止任务重叠，并提前约定漏跑后是跳过、补跑一次，还是补齐全部。状态文件采用单一写入者和原子更新，避免多个实例同时改写，也避免半截内容被当成完整状态读取。日志监控还要识别「本该出现的记录没有出现」。

第五层是事故手册和上线关卡。失控运行、重复执行、部分失败、静默失败，都应预先写好事故发生后前 5 分钟的处理步骤。上线经过 Backtest → Shadow → Limited Production → Full Automation，每阶段既有通过条件，也有退回上一阶段的规则。

为什么没报错，也可能已经出事故

误删容易被看见，静默停跑更容易被漏掉。

如果监控只盯错误日志，任务根本没启动时，就可能什么都收不到。作者要求监控运行记录的缺席：预期该跑却没有跑，也是一种需要报警的异常。

重复执行则是另一个方向的问题。第一次运行看起来失败，系统发起重试，但原实例可能仍在写状态。此时「允许重试」和「允许两个实例并发修改」是两回事。

因此，作者把调度、防重叠、单一写入者和原子更新放在同一层。它们不是提示词写法，而是任务执行系统必须提供的能力。对于夜间构建、数据整理这类自动化，模型回答得再准确，也不能替代这些运行机制。

我的判断

我认同作者把安全边界放到模型外部，也认同「写完读回」和「监控漏跑」应该进入验收标准。这些要求能转化成明确的工程检查，比泛泛要求 Agent 谨慎更容易落实。

但「这些都不是模型质量问题」说得过满。模型理解路径、识别敏感信息、判断重试条件的能力，仍会影响错误发生的概率。更稳妥的判断是：模型能力不能承担最后一道安全边界。

作者也明确承认，基于模式匹配的 hook 只是纵深防御，不能当作沙箱。命令可能通过其他形式执行，字符串拦截存在绕过空间。相比仅检查命令，文件系统权限和隔离执行环境更适合承担访问边界；hook 则适合补充项目特有的操作规则。

此外，这是一篇带商品推广的经验文章。免费样例包含 10 项安全检查清单、最小 CLAUDE.md 骨架和破坏性命令拦截 hook，支持按意愿付费，$0 也可获取。完整包分 Standard $99 和 Complete $179，提供 30 天退款。

这些价格、版本和测试数量都很具体，但原文没有给出事故率下降、误拦截率、运行成本或与其他方案的对照数据。因此，可以采纳它的分层方法，不能据此认定购买套件就能获得经过量化验证的安全收益。

能拿来做什么

• 给前端构建清理任务划定明确的可写目录，并在执行前拦截越界删除。把清理范围写进提示词之后，还要验证执行层确实拒绝访问范围之外的位置。
• 给日常 AI 编程项目分别列出可读、可写和禁止访问的路径。尤其检查 .env、.ssh/ 与凭据存储是否能被实际拒绝读取，而不只是出现在注意事项里。
• 给无人值守的 Node 定时任务补上防重叠机制、漏跑策略和缺席告警。重试之前，先明确旧实例是否仍在运行、共享状态由谁写入。
• 把「完成」改成可检查的结果：文件写入后读回，修复主张提前记录验收条件，扩大自治权限前先经过影子运行和有限生产阶段。