Cloudflare 安全审计 Skill 最值得抄的设计：独立验证 Agent

Cloudflare 开源了一个安全审计 Skill，它内部发现漏洞的 harness 就以此为基础构建。MIT 协议，不到三个月斩获 5,500 颗星。

它不是一个扫描器。它是一个 Skill——一个结构化指令文件夹，编码 Agent 加载后按指令行事。你把 Claude Code、Codex 或 Cursor 对准某个仓库，让它做安全审计，它就会通过六个阶段运行一批相互隔离的子 Agent。

安全这部分做得不错。真正值得抄的设计原则只有一条。

检查者和发现者不是同一个 Agent

问模型审查自己的输出，结果如何大家心里都有数。

一个刚用 4,000 token 力证某段代码存在漏洞的模型，下意识就会继续自证。让你 double check，它也只是在"验证"——以一种强化既有结论的方式。你得到的不是验证，而是同一观点的二次起草，而且因为已经"检查过"了，写得比第一次更有底气。

大多数项目用 prompt 里加一句"要保持批判性"来敷衍这个问题。这个项目直接封死了这条路。验证者是一个独立 Agent，全新 spawn，对产生候选结果的那场 hunt 毫无记忆。它不可能被一段从未见过的推理所 primed。

这是架构设计而不是指令注入，是"祈求严谨"和"强制严谨"的分水岭。如果你正在构建任何形式的 Agent 流水线，把这个抄过去。只要是一个 Agent 产出判断、另一个 Agent 负责验证的场景，验证者就应该冷启动。

三个判定，中间那个有它存在的理由

大多数扫描器给你一个 finding 或者沉默。这个系统给出三种状态：

needs_validation 是诚实系统对未竟之作的归处。一套工具只吐确认或什么都不吐，就必须在每个边界 case 上做沉默判决，而你是否漏掉了哪个永远无从得知。在这里，未完成的工作是可见的，且不携带任何 severity，所以它不会把报告撑到证据撑不起的程度。

保留 rejected 同样重要。重新运行时不会再烧掉一批 Agent 去重新发现同一个死胡同。

我把完整流程全部梳理了一遍——六个阶段、覆盖台账（coverage ledger）、攻击类库（attack class library），以及大多数人可能会跳过的 OS 级沙箱要求：Cloudflare's Security Audit Skill: an AI auditor built to disprove itself。

读 Agent 输出时我常开着两个工具：一个 JWT 解码器（用于 auth 类 finding），一个 JSON compare（用于对比两次运行之间的 finding 差异——这样就能看第二次审计实际新增加了什么）。