四家代码安全智能体如何选型

AI 安全扫描正在从「让模型读代码、列风险」变成一套分工明确的流程：先找漏洞，再由独立角色尝试推翻，最后才讨论修复。这篇横向比较的核心结论是，Claude、Codex、Cloudflare 和 Google 的路线已经接近，差别主要在接入方式、验证深度和使用门槛。

对程序员来说，值得看的不是谁报出的漏洞更多，而是谁能解释漏洞如何触发、为什么成立，以及补丁是否真的堵住了问题。原文提供了不少产品细节和团队数据，但它并不是统一条件下的横向实测，选型时需要分清这两件事。

为什么找漏洞和确认漏洞要分开

原文引用 Google 安全团队的判断：粗糙的 AI 代码扫描，真阳性率可能低于 7%。也就是一百条告警里，真正成立的可能不到七条。剩下的内容仍然需要人读代码、核对调用链、判断运行条件，审查成本很容易超过收益。

四家共同采用的办法是职责分离。发现问题的 Agent 负责提出假设，另一个 Agent 负责找反例：输入真的可控吗？前面是否已经做过权限检查？危险函数在当前配置下能否执行？

安全扫描的价值，取决于告警经得住多少反驳。

但「独立验证」也有层次。换一个 Agent 检查推理，主要是在减少自说自话；把攻击请求打到运行中的应用，才是在核对实际行为。Google 的内部系统 PageBreak 就采用独立的非 AI 验证器，在运行中的应用上执行攻击，原文称它发现了 500 多个经过验证的 XSS 漏洞。这个结果属于 PageBreak，不能直接算作 Mantis 的成绩。

四套工具，差别在接入和证据要求

Claude Security 适合已经在 Claude Code 里工作的开发者。它会梳理架构、建立威胁模型，再扫描组件并独立验证，支持扫描代码库、扫描变更和建议补丁。它不单独发起模型调用，无需额外 API key，消耗现有 Claude 套餐额度。

报告包含 Markdown 和 SARIF 2.1.0，后者可用于 GitHub code scanning。每条发现附带严重程度、CWE 分类、影响和复现步骤；补丁在临时副本里生成，以 F<n>.patch 保存，不会自行提交、推送或创建 PR。

原文列出的产品沿革包括：2026 年 2 月有限预览，托管版以 Claude Opus 4.7 面向 Enterprise 进入公测，插件于 7 月 22 日进入 beta，托管版在 8 月转向 Claude Mythos 5。这些来自原文引用的不同报道，并不是本文独立核验的版本状态。

Codex Security 的特点是流水线接口比较齐全。它提供 CLI 和 TypeScript SDK，可以扫描整个仓库、指定路径或 Git diff；cs policy 会生成用于约束后续扫描的 SECURITY.md。它还能导入 GitHub 告警、根据 Git 历史建议负责人，导出 SARIF、JSON、CSV，并发布到 Linear。

这段命令完成 CLI 安装、登录和扫描：

npm install --global @openai/codex-security
cs login
cs scan

要留意 cs login：Apache-2.0 开源的是客户端，扫描服务仍有访问门槛。原文称 CLI 和 SDK 面向获批客户有限测试，要求 Node.js 22.13+、Python 3.10+；README 列出了 OpenAI、Amazon Bedrock、OpenRouter、Fireworks AI，但不能据此认定任何人都能绕过准入使用服务。

原文还列出 –mode deep，用于并行发现任务。这里的横线沿用原文排版，复制执行前需要核对 CLI 文档。GitHub Action 默认只报告结果，接入 CI 不等于已经配置好阻断合并的规则。

Cloudflare 则把流程做成 MIT 许可的 Security Audit Skill，不绑定模型，但要求宿主 Agent 支持工具调用和并行子 Agent，还需要 Node.js 运行验证器。其产物是审计记录与报告，原文对照表没有把补丁生成列为能力。

Mantis 提供 Apache-2.0 的审查技能和 ADK 参考框架，更强调复现与补丁验证。下面是原文的参考框架启动方式：

git clone https://github.com/google/mantis.git
cd mantis/reference && ./install.sh
./run.sh path/to/code

最后一行需要换成目标代码路径。它还支持 –focus 聚焦「look for IDOR」一类问题，用 –max-tokens 设置消耗上限；这两个参数同样需要核对原文横线的排版。

Cloudflare 和 Mantis 如何把验证做深

Cloudflare 的六阶段审计从侦察开始，把架构、信任边界和输入入口写入 architecture.md，并维护覆盖台账。台账记录哪些区域已经检查、哪些还存在空白，避免多个 Agent 都盯着同一处显眼代码。

随后，独立猎手按台账分工，覆盖检查角色寻找遗漏；新验证者尝试推翻候选问题。结果按 confirmed、needs_validation、rejected 写入 findings.json，经过 schema 校验后，再由新 Agent 复核最终记录中的源码断言，最后生成 REPORT.md 和详情文件。

它要求操作系统强制隔离、禁止外网的沙箱。缺少这种环境时，线索保留为 needs_validation，不直接执行。输出默认放在仓库外的 ~/security-audit-skill/<repo-name>/run-<N>。

Cloudflare 公布的内部数据能说明筛选规模：约 450 行的技能催生了覆盖 128 个仓库的内部框架；20,799 个原始候选中，约 12,057 个通过验证。另一个包含其他框架产出的共享分诊池覆盖 145 个仓库，共有 13,841 条发现，去掉 5,442 条重复项和 1,154 条仓库归属错误或低风险项后，向工程团队发送了 7,245 条可处理发现。

这里有两套统计范围，不能连成一条漏斗计算成功率。

更有参考价值的是，Cloudflare 称改善前期侦察上下文后，首轮拒绝率从 40% 降到 11%。他们也会用不同模型分别做发现和分诊。不过，原文没有给出控制其他变量后的对照实验。

Mantis 的路线则是先读仓库历史，从过去的安全修复中学习，再把文件逐层压缩成目录和根级摘要。Google 称这种分层摘要让 token 开销降低超过 85%，但原文没有交代具体基线和准确率代价。

在验证阶段，Mantis 会从静态攻击草图逐步尝试单元测试或模拟服务器复现；修补后，再用对抗循环攻击补丁，并依据分级准则校准严重程度。mantis-advise 还会把发现反馈给后续代码生成。

它追求的不只是「问题似乎成立」，还包括「攻击能否重现，修复能否扛住再次攻击」。

我的判断

这篇最有价值的判断，是把选型重点从模型能力移到验证流程。对 Node 服务或全栈仓库，一条越权告警如果没有说明身份、资源归属和触发路径，很难直接进入修复排期。

不过，原文主要比较仓库、文档和厂商披露，没有在相同代码库、预算和模型条件下测试四套工具。因此，「Codex 的流水线最成熟」「Mantis 的证明循环最深」可以作为阅读文档后的选型意见，不能当作性能排名。

独立 Agent 也不保证独立判断。同一个模型可能重复相似误解；不同模型互相检查值得尝试，但文章没有提供它相对单模型方案的收益数据。

和传统静态分析相比，Agent 更适合串联业务上下文、提出攻击假设；确定性分析器和测试更适合提供可重复的证据。原文提到 Snyk 自有 VulnBench 中，49.7% 的纯 LLM 审查发现会在下一次运行中消失。这个数字不能外推到所有工具，却足以提醒团队检查结果稳定性。

自动生成补丁可以提速，补丁正确性仍要单独验证。

能拿来做什么

• 已经使用 Claude Code 的团队，可以从一次变更扫描开始，检查报告能否提供明确的源码位置、触发条件和复现步骤，再决定是否扩大到全仓深度扫描。
• 需要接入 GitHub 的 Node 或全栈项目，可以优先评估 SARIF、PR 扫描和结果导出，同时确认服务准入、运行环境与 CI 阻断策略。
• 自建审计流程时，可以借鉴 Cloudflare 的覆盖台账和三种结果状态，把「尚未验证」与「确认漏洞」分开保存，避免直接把模型猜测塞进缺陷队列。
• 对越权、注入等候选问题，可以借鉴 Mantis 的办法，把触发条件落成可运行测试，再检查补丁是否阻断攻击，以及正常请求是否仍能通过。