四家实验室的AI安全代理殊途同归：发现者不能确认自己的发现

AI代码安全扫描面临一个可量化的可靠性危机。Google安全团队公开写道，粗糙的AI代码扫描会产生幻觉漏洞，真正率低于7%——也就是说，一个93%时间都在犯错的扫描器给审查者带来的成本超过它节省的成本。Snyk自己的VulnBench测试进一步证实了问题的普遍性：49.7%的纯LLM审查发现在下一次运行时消失，说明单次模型输出远不够稳定。

面对同一问题，Anthropic、OpenAI、Cloudflare和Google在2026年各自发布了AI安全扫描代理，却收敛到了几乎相同的设计：一个代理负责发现漏洞，另一个独立代理负责证伪它，只有经受过反驳的存活发现才进入修补阶段。Cloudflare在其README中把这条规则写得最直白：验证者永远不是发现漏洞的那个代理。Anthropic、OpenAI和Google各自描述了类似的验证步骤，在发现进入报告之前必须经过独立质疑。

这种趋同不是巧合，而是对噪声问题的工程响应。核心原则是职责分离：报告发现的代理永远不拥有确认权。这与人类安全审计中的同行评审逻辑一致——作者不能自己审稿。在AI代理语境下，这意味着两个独立的模型调用（甚至两个不同的模型）必须对同一发现得出一致结论，才能进入下一步。Cloudflare还采用了一个更具体的做法：用不同模型分别做发现和分诊，让模型之间互相检查。

四家工具的区别在于验证的深度和运行环境。Anthropic的Claude Security插件运行在Claude Code会话内，不需要额外API密钥，扫描计入用户现有套餐额度，输出Markdown报告和SARIF文件，补丁以.patch文件形式生成但不自动提交。OpenAI的Codex Security提供CLI和SDK，支持深度模式并行发现，可导入GitHub扫描警报，但客户端虽开源（Apache-2.0），背后的扫描器仍需OpenAI访问权限。Cloudflare的审计技能是MIT许可、模型无关的，要求支持并行子代理的编码代理，理想情况下需要操作系统级沙箱且无外部网络——没有沙箱时，发现停留在needs_validation状态而非被执行。Google的Mantis最激进：它尝试在沙箱中复现每个漏洞，从静态利用草图到单元测试或模拟服务器，修补环节还有一个对抗循环专门攻击自己的修复。

Cloudflare公开的内部数据揭示了一个值得注意的杠杆：改进侦察上下文（即让代理先充分理解架构、信任边界和输入面）将第一轮拒绝率从40%降到了11%。这意味着发现质量的上游瓶颈不是验证不够严格，而是初始理解不够充分。在20,799个原始候选发现中，约12,057个通过了验证，最终7,245个可操作发现被发送给工程团队。

这一收敛模式的可迁移教训是：任何依赖AI代理输出的工作流，如果噪声是核心约束，那么最可靠的架构改进不是让同一个代理更谨慎，而是引入结构性的对抗验证。发现与确认的分离是最低成本的质量提升手段，而侦察阶段的上下文投入对最终信噪比的影响可能比验证环节的严格程度更大。

需要保留的边界是：以上所有性能数字均为各公司自报，缺乏独立第三方复现。Cloudflare的40%→11%改善基于其内部128个代码库，未必适用于外部项目。Google的7%真正率是其安全团队对其自身扫描经验的描述，不是标准化基准测试结果。这一架构趋同本身是公开可验证的事实——四家工具的仓库和文档都展示了相同的多代理验证模式——但各工具的实际有效性仍需独立评估。