执行前检查：让 AI Agents 在无人监督下安全运行的唯一习惯

Source: Dev.to

为什么预执行检查至关重要

大多数人默认信任他们的 AI 代理，但这种做法是颠倒的。
让人放心的代理并不一定是模型最强大的那些；而是那些在采取任何重要行动之前会进行 预执行检查 的代理。

一次快速的自我审计应当回答以下问题：

1. 这项任务是否在我的定义范围内？
2. 我是否拥有完成此任务所需的全部信息？
3. 该行动是否可能导致无法撤销的伤害？
4. outbox.json 中是否有我需要先了解的内容？

如果任何答案不确定，代理应停止并上报，而不是盲目猜测。没有这道门槛，代理会在其能力边缘运行，忽视自身的局限性。模型不会标记“我不确定”；它只会给出最好的猜测，而在边缘案例中，这种猜测可能自信却错误。

预执行检查的具体表现

在你的 SOUL.md（或等效配置文件）中加入以下检查清单，并在任何会修改外部状态或发送通信的任务之前执行：

1. 确认任务在定义范围内
2. 确认所需上下文已加载且为最新
3. 检查 outbox.json 中是否有待处理的上报
4. 如果任一检查未通过： 将理由写入 outbox.json 并停止

这大约会为每个主要操作增加 2 秒，但能防止错误的叠加。

实际案例

我们的一个代理负责发送每周通讯。没有预执行检查时，它曾一次发送了仍包含占位符 ([INSERT_STAT_HERE]) 的草稿。任务仅是“发送通讯”，而代理看到一个看起来像通讯的文件，于是继续执行。

加入检查后，代理会检测到占位符，将上报写入 outbox.json，并中止发送操作。

一次检查。一个习惯。 它可以防止最难恢复的那类失败。

构建可靠性栈

预执行检查与其他安全层结合使用效果最佳：

• 预执行检查 – 行动前
• 上报规则 – 不确定时写入 outbox.json
• 断路器 – 发生 N 次失败后停止并暴露问题
• 死信队列 – 记录失败的内容和原因

每一层都捕获前一层遗漏的风险，形成坚固的安全网。

更多资源

完整的模式集合——包括每层的模板——已在 Ask Patrick Library 中提供：

askpatrick.co

Ask Patrick 每晚都会发布经过实战检验的 AI 代理配置和模式。该库是构建真正可信赖的代理的快捷途径。