AI 辅助漏洞发现正从概念验证走向工程化落地。Anthropic 近期开源的 defending-code-reference-harness 框架，将 Claude Opus 4.6 的代码理解能力与多 Agent 协作架构相结合，在无需定制化脚手架的前提下，已在开源代码库中发现超过 500 个高危漏洞。本文从工程实现角度，拆解该框架的流水线设计、Agent 分工机制与验证策略，为安全团队构建自主漏洞检测系统提供可落地的参考架构。
流水线架构：七阶段闭环设计
该框架采用 recon → find → verify → dedupe → report → patch 的七阶段流水线，每个阶段由专门的 Agent 负责，通过标准化接口传递上下文信息。这种设计将传统安全测试中的模糊测试、静态分析、人工验证环节拆解为可并行执行的模块化任务。
Recon 阶段的轻量级 Agent 负责代码结构分析，将目标代码库划分为若干独立的攻击面（focus areas）。与盲目全量扫描不同，该 Agent 通过读取源码识别输入解析子系统的边界，确保后续并行 Find Agent 探索不同区域而非重复收敛于同一漏洞。在 C/C++ 场景下，这一阶段通常识别出文件解析器、网络协议处理器、配置加载模块等独立组件。
Find 阶段启动多个隔离的 Agent 实例并行执行。每个 Agent 在独立的 gVisor 容器中运行，读取分配给它的攻击面子集，构造畸形输入并监控 ASAN（Address Sanitizer）崩溃信号。关键约束条件是：只有当某个输入能够连续 3 次触发相同崩溃时，才被视为有效漏洞候选。这一设计大幅降低了误报率，避免了传统模糊测试中常见的偶发性崩溃干扰。
Verify 阶段引入独立的 Grader Agent 进行交叉验证。Grader 在全新的容器中复现 Find Agent 提交的 PoC（Proof of Concept），确保崩溃可重现且非环境依赖。这种 "双盲验证" 机制类似于学术界的同行评审，有效过滤了 Agent 幻觉产生的虚假漏洞。
多 Agent 协作与沙箱隔离
框架的核心创新在于将单一大模型任务分解为多个专业化 Agent 的协作网络：
- Recon Agent：负责攻击面识别与任务分区
- Find Agent：执行定向模糊测试与崩溃触发
- Grader Agent：验证崩溃可重现性
- Judge Agent：比对已知漏洞库进行去重判断
- Report Agent：生成结构化可利用性分析报告
- Patch Agent：基于漏洞根因生成修复代码
每个 Agent 运行在独立的 gVisor 沙箱中，网络出口被严格限制为仅允许访问 Claude API。这种隔离机制确保即使某个 Agent 被恶意输入诱导执行危险操作，其影响范围也被限制在容器内部。对于生产环境部署，建议将沙箱节点部署在独立的 Kubernetes Pod 或 Firecracker MicroVM 中，进一步降低横向移动风险。
Agent 间的通信采用文件系统作为中间介质而非直接 RPC 调用。Find Agent 将 PoC 写入共享存储，Grader Agent 读取后在新容器中执行验证。这种设计虽然增加了 I/O 开销，但避免了复杂的分布式状态同步问题，符合安全工具 "简单即安全" 的设计哲学。
漏洞验证与去重策略
漏洞去重是自动化漏洞发现系统的关键瓶颈。该框架采用三级去重机制：
第一级：崩溃签名哈希。基于 ASAN 输出的堆栈跟踪生成指纹，快速过滤完全相同的崩溃模式。
第二级：Judge Agent 语义比对。对于哈希碰撞或相似崩溃，Judge Agent 分析漏洞根因（如缓冲区溢出 vs Use-After-Free），判断是否属于同一根本问题的不同触发路径。
第三级：跨运行去重。/triage 技能可聚合多次扫描结果，结合威胁模型重新校准严重等级，并将漏洞路由至对应组件负责人。这一机制支持安全团队建立 "扫描 - 修复 - 回归测试" 的外循环，持续收敛攻击面。
在 Anthropic 的实践中，Claude 展现出超越传统模糊测试工具的漏洞发现能力。以 GhostScript 字体处理模块为例，Agent 通过分析 Git 提交历史识别出修复补丁的边界检查逻辑，进而发现同一函数在其他调用路径上仍存在未修复的类似漏洞。这种 "基于代码演化的漏洞挖掘" 思路，是传统覆盖率导向模糊测试难以实现的。
补丁生成与验证流程
Patch Agent 的修复验证包含四个硬性检查点：
- 构建通过：修复后的代码能够成功编译
- PoC 失效：原始崩溃输入不再触发 ASAN 报错
- 回归测试通过：目标项目的现有测试套件全部通过
- 绕过测试：启动新的 Find Agent 尝试寻找绕过补丁的新攻击向量
这一验证流程确保了补丁的语义正确性，而非仅仅是表面上的崩溃消除。然而框架文档明确提示：自动生成的补丁仍需人工审核才能提交上游。建议安全团队建立 "机器生成 - 人工审查 - 自动化测试 - 社区反馈" 的闭环流程，将 AI 的效率优势与人工的上下文判断相结合。
工程化落地建议
对于希望采用该框架的安全团队，建议遵循渐进式部署策略：
Day 1：使用交互式技能（/threat-model、/vuln-scan、/triage）在目标代码库上完成端到端验证，这些技能仅读写文件无需沙箱。产出威胁模型文档与静态扫描结果。
Day 2：在已知漏洞的开源库（如 drlibs）上运行完整流水线，熟悉 recon → find → verify → report 的自动化流程。
Days 3-5：使用 /customize 技能将流水线适配至目标技术栈。需要回答三个核心问题：检测信号是什么（ASAN 崩溃 / 异常 / 回调）、PoC 形态如何（文件 / HTTP 请求序列 / 交易列表）、目标如何构建运行（Dockerfile / 构建脚本）。
Week 2+：建立周期性扫描机制，将漏洞发现集成至 CI/CD 流水线。建议从关键开源依赖项开始，按业务暴露面和 CVE 历史排序扫描优先级。
局限性与风险考量
该开源框架明确声明不接受外部贡献且不做长期维护，生产环境使用需自行承担维护成本。此外，自动化漏洞发现的双刃剑效应不容忽视：框架文档强调必须遵循负责任的漏洞披露流程，在修复方案就绪前不公开漏洞细节。
对于资源受限的团队，可考虑 Anthropic 提供的托管服务 Claude Security，其包含多阶段验证管道和漏洞生命周期管理功能。无论采用开源自建还是托管服务，核心原则是一致的：AI Agent 负责规模化扫描与初筛，人类专家负责最终验证与修复决策，形成人机协同的安全防御体系。
资料来源
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。