背景：要解决的不是能力，是噪声
把大模型接到代码仓库上去找漏洞，这件事的困难点在过去两年被反复讲错。多数讨论集中在「模型能不能看出这个越界」，而工程现场的真实抱怨是另一句：看出来了，但十次里有九次是看错了。
Google 安全团队在介绍 Mantis 时把这个前提摆到了台面上：草率的 AI 代码扫描会产生幻觉漏洞，真阳性率不足 7%。这个数字的含义值得展开——它意味着如果一个仓库被扫出 100 个问题，审阅者要投入 100 次判断成本去筛出不到 7 个真问题。当验证成本高于发现成本，扫描器就不再是提效工具，而是一台把审阅者时间转成废纸的机器。
第二个驱动来自攻防侧。Anthropic 团队的公开说法是，他们做扫描器部分原因是攻击者已经在用模型找可利用的缺陷；Google 在 Mantis 文章的开头也指出，模型现在已经能在很少人工帮助的情况下发现并利用漏洞。也就是说，防守方引入智能体的动机不是「比人快」，而是「对手已经在用」。
这两个驱动合起来，导出了一条与通用编码智能体很不一样的架构路线。通用编码智能体的目标是尽快产出可运行的改动，因此强调自主性与工具广度；漏洞智能体的目标是尽量少产出不可信的结论，因此强调职责分离与证据强度。这是同一批底层模型在两种目标函数下的两种工程形态。
漏洞智能体的成功指标不是「找出多少」，而是「审阅者愿意信多少」。因此它们的优化方向与常规智能体相反：宁可少报，不可错报。理解了这一点，就能解释为什么四家都不约而同地给系统加了一层专门用来否定的组件——在一个以精确率为目标的系统中，证伪者的产出比发现者更值钱。
收敛的形状：发现、证伪、修补
四家产品的流水线长度不同，但骨架一致，可以抽象成三段：
| 阶段 | 承担者 | 产出 | 关键约束 |
|---|---|---|---|
| 发现 | 一个或多个狩猎智能体，按架构单元或覆盖率账本分片 | 候选清单，含位置、类型与初步理由 | 可以是弱的，允许大量假阳性 |
| 证伪 | 独立于发现方的验证智能体，或确定性引擎 | 确认、需人工确认、驳回三态 | 验证方不能是发现方；无沙箱时降级为需人工确认 |
| 修补 | 补丁智能体，在副本或临时分支上起草 | .patch 文件、拉取请求草稿或修复建议 | 不自行提交、不自行合并；人工批准是硬门槛 |
这套结构在人类安全研究里早已存在：一个人标记可疑点，另一个人负责把它打穿，通过了才投入修复工时。2026 年的变化是把它写进了智能体的角色定义，并且用许可证、运行位置与证据要求把三段的边界固化下来。
值得注意的是，证伪这一阶段并不总是用模型完成。Semgrep 的做法是把确定性污点分析与前沿模型配对；Snyk 的 Evo 让智能体驱动确定性引擎作为工具；Google 的 PageBreak 用非 AI 的验证器把每个利用脚本打向运行中的应用。这提示一个更一般的规律：在需要证据的环节，确定性组件承担证明，模型承担推理。
为什么证伪者必须换一个智能体
Cloudflare 在 README 里写下的规则是四家中最直白的一句：验证方永远不是发现问题的那个智能体。这句话看似是流程洁癖，实际有可验证的理由。
如果同一个上下文既包含「我为什么认为这里有漏洞」的推理链，又需要回答「这里到底有没有漏洞」，那么前后两个判断会共享同一套前提假设。模型在后一项任务上会倾向于延续自己在前一项任务上已经建立的结论，这在工程上表现为确认偏误被编码进了上下文。换一个干净的验证方，等于强制丢弃发现阶段的推理痕迹，只保留候选位置与必要的代码上下文。
Cloudflare 的做法更进一步：发现阶段与分诊阶段使用不同的模型，让模型互相检查。这相当于把「换上下文」升级为「换判断主体」，代价是要承担两套模型的调用成本与口径差异。
这里有一个可操作的推论：如果你的团队在自建类似流水线，那么验证步骤的价值主要来自上下文隔离，而不是来自验证者的能力。用更强的模型去验证，收益不如用干净的上下文去验证。这一点在 Cloudflare 自己公布的遥测里也能找到旁证——他们改善精确率的关键动作是加强侦察阶段的上下文，把首轮拒绝率从 40% 压到 11%，而不是把验证模型换大。
Claude Security：跑在会话里的多智能体扫描器
Claude Security 以插件形式运行在 Claude Code 会话内部，是 Anthropic 托管版 Claude Security 产品的本地形态。安装只需一行：在插件市场安装 claude-security@claude-plugins-official，然后调用 /claude-security。菜单提供三项作业——扫描代码库、扫描改动、建议补丁。
它的多智能体分工是：先有智能体绘制架构、建立威胁模型，再有智能体跨各组件狩猎，最后对每个发现做独立验证。这里出现了本栏目反复看到的模式：把「绘制全局」与「逐点攻坚」拆开，前者为后者提供上下文，后者不共享彼此的推理链。
输出侧有两处值得注意的设计。其一是同时产出 Markdown 报告与 SARIF 2.1.0 文件，后者可直接被 GitHub 代码扫描消费，这让智能体的结论进入了既有的工程管道，而不是停留在对话框里。其二是补丁以 F<n>.patch 形式落在临时副本上，插件自身从不提交、从不推送、也从不自行开拉取请求。把「产出补丁」与「应用补丁」切成两个动作，是这个领域里成本最低的一道安全阀。
成本与访问条件上，Claude Security 自身不发起模型调用，因此不需要额外 API Key，扫描计入用户既有套餐额度。这在四家里是接入摩擦最低的一个，代价是能力被绑定在 Claude 模型上。时间线方面：2026 年 2 月以 Claude Code Security 之名开启限量预览，托管版随后对企业客户在 Claude Opus 4.7 上进入公测，插件于 7 月 22 日进入测试，8 月托管扫描器迁移到 Claude Mythos 5。
Codex Security：把扫描做成 CI 管道
OpenAI 的形态是 CLI 加 TypeScript SDK，包名为 @openai/codex-security。它可以扫描整个仓库、指定路径或一次 Git 差异，deep 模式会并行启动多个发现工作器。除验证候选、生成补丁外，它还能验证既有修复是否真的生效，这一项在回归场景下比找新漏洞更有实用价值。
管道化是它与其他三家拉开差距的地方。输出支持 SARIF、JSON、CSV 与威胁模型，可以直接发布到 Linear；能导入 GitHub 代码扫描告警并从 Git 历史里推测责任人；GitHub Action 支持定时或拉取请求触发，且发现默认只报告不阻断。这套设计明显面向「让安全结论进入既有工作流」，而不是「让人来看一份报告」。
有一个细节很有代表性：cs policy 命令会起草一份 SECURITY.md，用来告诉后续扫描「在这个项目里什么才算漏洞」。这是把组织的判断标准显式化，让每次扫描都继承同一套口径。在多项目、多团队的场景下，这类策略文件的价值往往高于单次扫描的准确率。
访问条件是它最容易被误读的部分：客户端以 Apache-2.0 许可发布，但背后的扫描器不是。DevOps.com 指出 CLI 与 SDK 仍处于面向批准客户的限量测试；README 列出的提供方包括 OpenAI、Amazon Bedrock、OpenRouter 与 Fireworks AI；运行需要 Node.js 22.13 以上与 Python 3.10 以上。换句话说，「开源客户端」不等于「可自建服务」，这一点在采购评估时需要单独确认。
Cloudflare 的六阶段：覆盖率账本与两次独立验证
Cloudflare 的形态是一个 MIT 许可的技能包，约 450 行，2026 年 6 月 18 日随《Build your own vulnerability harness》一文发布。它不绑定模型，要求宿主是一个支持工具调用与并行子智能体的编码智能体，另外需要 Node.js 运行校验脚本。目前它在四家中星标最高，为 47.5K。
它的六个阶段构成本文认为最完整的一份流水线设计：
| 阶段 | 动作 | 产出 |
|---|---|---|
| 1 侦察 | 绘制架构、信任边界与输入面 | architecture.md 与覆盖率账本 |
| 2 覆盖率驱动狩猎 | 隔离的狩猎者各领账本单元，覆盖率批评者找缺口 | 候选集 |
| 3 候选验证 | 全新的验证方尝试证伪每一条各不相同的候选 | 三态判定 |
| 4 结构化输出 | 确认、需人工确认、驳回写入 findings.json 并按 schema 校验 | findings.json |
| 5 独立记录验证 | 新智能体重新核对每条最终来源声明 | 已核验记录 |
| 6 目标中立报告 | REPORT.md 与明细文件由已核验记录导出 | REPORT.md |
两处设计值得单独拎出来。其一是覆盖率账本：它把「扫了什么」变成一份可检查的清单，由专门的批评者找缺口。这解决了狩猎型流水线最典型的失败——扫得很热闹，但大片组件从来没被任何智能体领走。其二是两次独立验证：阶段三验证候选本身，阶段五重新核对报告里的每条来源声明，两者由不同的新智能体完成。多数自建流水线只做前者。
环境要求上，它明确希望有一个操作系统强制的沙箱且不通外网；没有沙箱时，线索会停留在「需人工确认」而不是被执行。这是把安全边界写进了能力开关：宁可少做，不可在无隔离环境里跑可利用的验证。输出默认落在仓库之外的 ~/security-audit-skill/<repo-name>/run-<N> 目录，避免审计产物污染被审项目。
128 个仓库的遥测：从 20,799 到 7,245
Cloudflare 公布的内部数据是本次核对中信息量最大的一组。约 450 行的技能包衍生出的内部 harness，目前已扫描 128 个仓库。公布的累计数字为：
| 环节 | 数量 | 口径 |
|---|---|---|
| 发现阶段的原始候选 | 20,799 | 累计 |
| 通过验证的候选 | 约 12,057 | 累计 |
| 共享分诊池中的发现 | 13,841 | 跨 145 个仓库，含另一 harness 的输出 |
| 作为重复项折叠 | 5,442 | 累计 |
| 判为错仓或低风险而转出 | 1,154 | 累计 |
| 送交工程团队的可行动发现 | 7,245 | 累计 |
这组数字有一处容易误读：20,799 与 13,841 不是同一个池子的进出两端，不能直接相除。13,841 是跨 145 个仓库的共享分诊池，且明确包含另一个 harness 的输出；20,799 是 Cloudflare 自身发现阶段在 128 个仓库上的原始候选。真正可以做的算术在分诊池内部：13,841 减去 5,442 减去 1,154 等于 7,245，与公布的可行动数完全一致。也就是说，分诊池这一段的账是平的——重复折叠与错仓转出两项之和恰好解释了入池与出池的全部差额，没有留下未说明的损耗。
另外两项改善数据同样值得记：更好的侦察上下文把首轮拒绝率从 40% 压到 11%；Cloudflare 用不同模型分别承担发现与分诊，让模型互相检查。
把侦察阶段的上下文做扎实，比把验证阶段做得更严苛更划算。首轮拒绝率从 40% 降到 11% 意味着：在没有改验证逻辑的前提下，仅靠更好的架构与输入面理解，就让近三成的无效候选从源头消失。对于自建流水线的团队，这是投入产出比最高的一个改动点。
Mantis：沙箱复现与攻击自己的补丁
Google 的 Mantis 以 Apache-2.0 许可发布，是一套安全审阅技能加上一个基于 ADK 的参考 harness。它同时也是 Google 内部发现与修复漏洞的方式之一。安装方式是克隆仓库后把任意编码智能体指向它，或直接运行 ADK harness，后者支持 --focus 提示词（例如「专门找 IDOR」）与 --max-tokens 花费上限。
它在上下文管理上有一个具体做法：读取仓库历史，从过往的安全修复中学习，并构建层次化摘要树——把文件压缩为目录级摘要，再压缩为根级摘要。Google 团队称这一步把 token 开销降低了 85% 以上。这是本栏目在多个架构解构里见过的同一思路：用结构化摘要换取长上下文预算，代价是可能丢失细节。
真正把 Mantis 与其他三家区分开的是复现环节。它尝试为每一个漏洞做复现，从静态的利用草图一路做到单元测试或模拟服务；修补时用对抗式循环攻击自己的修复；还按评分标准校准严重级别，以避免出现「成千上万个严重项」。配套的 mantis-advise 技能把学到的东西回流到代码生成环节。
Google 明确建议把它隔离运行。这与 Cloudflare 的沙箱要求指向同一件事：验证环节会执行不可信代码，执行边界必须由环境而非提示词来保证。
四家横向对照
| 工具 | 许可证 | 运行位置 | 模型绑定 | 证明步骤 | 补丁 |
|---|---|---|---|---|---|
| Security Audit Skill（Cloudflare） | MIT | 任意支持并行子智能体的编码智能体 | 无 | 全新智能体证伪；再做一次独立记录验证 | 否 |
| Codex Security（OpenAI） | 客户端 Apache-2.0，托管扫描器非开源 | CLI、SDK、GitHub Action | OpenAI 侧受限，支持 Bedrock / OpenRouter / Fireworks | 验证候选；验证既有修复 | 是 |
| Mantis（Google） | Apache-2.0 | 任意编码智能体或 ADK harness，需隔离环境 | 无 | 沙箱内复现；对抗式补丁循环 | 是 |
| Claude Security（Anthropic） | 官方插件市场插件 | Claude Code 会话内 | Claude 模型 | 独立验证者组 | 是，以 .patch 文件形式 |
把这张表按「你愿意放弃什么」来读会更清楚。选 Claude Security 是放弃模型自由换接入便利；选 Codex Security 是放弃自建自由换 CI 成熟度；选 Cloudflare 是放弃补丁能力换无锁定与完整流水线；选 Mantis 是放弃易用性换最深的证明链。
另外十余款：同一循环的不同外壳
四家之外，2026 年至少有十余款同类工具发布或公开，几乎都重复同一条「发现后独立验证」的循环。它们分成两类：可自行运行的开源 harness，与商业或内部平台。
| 工具 | 来源 | 时间 | 值得注意之处 |
|---|---|---|---|
| Visa Vulnerability Agentic Harness | Visa | 6 月 10 日 | 四阶段十一段流水线，带策略闸门与人工审阅；支持 Claude 或 OpenAI 兼容模型；后续补上修复与修复验证 |
| OpenHack | Hadrian | 5 月 25 日 | MIT；状态全部保存在纯文件中，可跑在 Claude Code、Codex 或 Cursor 里；专家智能体证明或驳回场景，独立分诊智能体定稿 |
| deepsec | Vercel Labs | 5 月 4 日 | MIT；正则预筛选安全相关文件，智能体调查后再做第二轮复核；扫描可扇出到 1,000 余个并发沙箱 |
| Signal Agentic Fix | Black Duck | 10 月 28 日 | 扫描、分诊、修复、验证、提交；与编码智能体并肩工作，每处改动都交给人 |
| Continuum for code vulnerabilities | AWS | 10 月 22 日正式可用（6 月 17 日预览） | 两个美国区域；对照实际 AWS 配置检查可利用性并开修复拉取请求；每处修复需人工批准 |
| Evo Agentic AppSec | Snyk | 10 月 15 日预览 | 智能体把 Snyk 的确定性引擎当工具调用；Snyk 自己的 VulnBench 发现纯大模型审阅的发现有 49.7% 在下一轮就消失了 |
| PageBreak | Google Product Security | 9 月 24 日披露 | 仅内部使用；在 Google 自有 Web 应用中发现 500 余个已验证 XSS；由独立的非 AI 验证器把每个利用脚本打向运行中的应用 |
| Agentic Workflows | Semgrep | 7 月 28 日公测 | 九个预置工作流覆盖 70 余类 CWE；确定性污点分析与前沿模型配对 |
| Patch the Planet | OpenAI 与 Trail of Bits | 6 月 22 日启动 | 工程师用 Codex Security 与 GPT-5.5-Cyber 覆盖 19 个开源项目；首周 64 个拉取请求与 51 个议题 |
| MDASH | Microsoft | 5 月 12 日扩展预览 | 100 余个智能体跑在模型集成上；发现 16 个新的 Windows 漏洞，其中 4 个为严重远程代码执行 |
| Red Agent | Wiz | 4 月 22 日预览后正式可用 | 不读源码，从外部攻击运行中的 API 与应用 |
| Xint Code | Theori | 4 月 29 日披露 | 约一小时扫描发现「Copy Fail」（CVE-2026-31431），一个存在九年的 Linux 提权漏洞；CISA 已列入在野利用清单 |
这份名单里有一条比单点数据更重要的信息：Snyk 自己的 VulnBench 发现纯大模型审阅的发现有 49.7% 在下一轮就消失了。也就是说，即使不引入任何对抗手段，同一模型对同一份代码的判断在两次运行之间就有近一半不重合。这个数字可以作为「为什么必须加证伪环节」的一条独立证据，且与 Google 给出的真阳性率不足 7% 相互印证。
本文六条推算
以下六条均由上文公布的读数推得，原文未直接给出。
| 编号 | 推算 | 过程 | 含义 |
|---|---|---|---|
| 1 | 通过验证的存活率约 57.97% | 12,057 除以 20,799 | 验证环节剔掉约 42.03%，即 8,742 条候选；这说明验证是一道重过滤器，而不是一道校验章 |
| 2 | 分诊池内部账目完全配平 | 13,841 − 5,442 − 1,154 = 7,245 | 入池与出池的差额被重复折叠与错仓转出两项完整解释，没有未说明的损耗 |
| 3 | 首轮拒绝率的相对降幅约 72.5% | （40 − 11）除以 40 | 等价于通过率从 60% 提到 89%，绝对提升 29 个百分点；改善来自侦察上下文而非验证强度 |
| 4 | 分诊池的仓库数比扫描仓库数多约 11.7% | （145 − 128）除以 145 | 多出的 17 个仓库来自另一 harness；跨 harness 合并分诊是这个领域已经出现的做法 |
| 5 | Mantis 的 token 开销被压缩到原规模的约六分之一以下 | 降幅 85% 以上，即剩余不足 15% | 层次化摘要树把长仓库历史的成本降下来，代价是细节可能被摘要吞掉 |
| 6 | 可行动发现占原始候选约 34.8% | 7,245 除以 20,799 | 这一条需谨慎使用：分子与分母来自不同池子，实际比率应更低；列出它是为了说明口径混用的风险 |
第 6 条要特别说明。7,245 出自跨 145 个仓库的分诊池，20,799 出自 128 个仓库的发现阶段，两者不是同一批仓库的进出。把它们相除得到的 34.8% 没有统计意义，本文列出它是为了示范一种常见误读——当一份报告同时给出多个池子的数字时，读者很容易把看起来配套的两端直接相除。第 2 条之所以可信，正因为它的四项数字都来自同一个池子。
未披露项与四家的共同缺口
本次核对中有若干细节在公开材料中找不到答案，统一说明如下：四家均未公布各自流水线的假阳性率与漏报率，Google 给出的真阳性率不足 7% 是针对「草率扫描」的通用判断，不等于四家产品的实测值；Cloudflare 的遥测是累计值，未给出时间窗口与仓库规模分布，因此无法折算单仓库均值；各家的运行成本、单次扫描耗时与 token 消耗均未披露；Mantis 的 85% token 降幅未说明基线是什么，是相对全量读取还是相对某种朴素摘要。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
共同缺口有三处。其一是跨工具可比性：没有任何一方公布过在同一批仓库上的横向对比，MarkTechPost 这次核对比较的是文档与仓库，不是独立实测，这一点原文也已声明。其二是漏报无法被测：所有公布的数字都是「扫出来之后有多少是真的」，而不是「有多少真的没被扫出来」，后者需要人工注入已知漏洞的对照集。其三是修补环节的正确性缺乏验证口径：Mantis 有对抗式补丁循环，但其余三家对自动补丁是否被验证过，公开材料语焉不详。
选型顺序与四条落地建议
如果把四家与十余款工具当作一个货架，按团队现状选择的顺序大致是：已经在 Claude Code 上的团队从 Claude Security 插件起步，一行安装、沿用既有额度；需要 CI 门禁与 SARIF 进 GitHub 的团队看 Codex Security，前提是组织在批准客户名单内；不希望被厂商锁定的团队选 Cloudflare 的技能包，代价是它不产补丁；有安全团队与沙箱的团队上 Mantis，拿到最深的证明链。
四条落地建议：
| 建议 | 做法 | 依据 |
|---|---|---|
| 用不同模型跑发现与验证 | 发现用一个模型，分诊换另一个，让模型互相检查 | Cloudflare 的既定做法；不同模型暴露的缺陷集合不同 |
| 先投资侦察上下文 | 把架构、信任边界、输入面整理成可消费的文档再开始扫描 | 首轮拒绝率由 40% 降至 11% 的改善来自这一环 |
| 把沙箱要求写成能力开关 | 无隔离环境时让线索停在需人工确认，而不是继续执行 | Cloudflare 与 Google 的一致做法 |
| 为项目写一份策略文件 | 明确什么算漏洞、什么不算，让每次扫描继承同一口径 | Codex Security 的 SECURITY.md 起草机制把这一环产品化 |
冷静判断：它改变了什么，没改变什么
这套循环真正改变的是信任的生产方式。过去一份安全扫描报告的可信度来自工具品牌与规则库版本；现在它来自一条可检查的链条——谁发现的、谁否定的、否定时用了什么证据、报告里的每条声明有没有被重新核对。Cloudflare 的阶段五「独立记录验证」是这条思路的极点：连报告本身都要过一遍验证。
它没有改变的是结论的覆盖率。所有公布的数字都在回答「扫出来的对不对」，没有一个在回答「该扫的扫到了没」。在一个真阳性率不足 7% 的起点上，把精确率提上去是必要的；但一个只报 5 条且 5 条全对的系统，与一个漏掉 200 条的系统并不矛盾。这两件事在公开材料里被混为一谈的情况相当常见。
还有一个更结构性的判断：四家收敛到同一条循环，本身说明这个子领域的架构探索已经进入稳定期。当不同组织在互不知情的情况下导出相同结构，通常意味着约束条件已经足够强，剩下的差异会集中在许可证、运行位置与商业模式上，而不是在架构上。对使用方来说，这是好消息——选型风险下降了；对做基础设施的人来说，这意味着单点创新的空间正在变小，接下来的机会更可能在跨工具的分诊合并与证据标准统一上。Cloudflare 那条跨 145 个仓库、含另一 harness 输出的共享分诊池，可能比四家里的任何一个产品都更值得关注。