Dan Jones、Alexandra Godoi、Grant Bourzikas · Cloudflare Blog · 阅读原文
原始来源：Dan Jones、Alexandra Godoi、Grant Bourzikas · Cloudflare Blog
发现渠道：Cloudflare 仓库 README
Cloudflare 公布了一套从单仓库审计技能扩展而来的漏洞发现流程。这里的 harness 是围绕模型的执行框架：它保存任务、调用工具、安排验证，并在中断后接着运行。最初的技能让不同 Agent 负责了解架构、寻找攻击路径和尝试推翻发现；扩展到多个仓库后，真正增加的是状态保存、覆盖记录、去重与依赖追踪。
团队把每阶段写入 SQLite，以运行、仓库和阶段识别任务，发现一项便保存一项。覆盖账本记录代码区域与攻击类别，薄弱处产生新任务；如果一个可疑路径超出当前范围，就另建明确任务继续调查。缺少构建环境或虚拟机时，系统记录所需条件，等条件齐备再重跑，而不是让不完整的结果混进已验证队列。
验证分两层：固定程序检查文件、路径及报告结构，新的 Agent 再尝试推翻漏洞假设。团队要求已确认发现的复现测试针对未改动的原代码，随后由另一套系统去重、判断生产环境能否到达该路径，再准备修补。开源 security-audit-skill 是单仓库起点，并不等于公开了这套完整内部系统。
原文累计流程图显示，20799 条初始候选中约12057条通过第一轮验证；它们与另一套工具的输入汇合后，再经去重与适用性判断，留下7245条交给团队处理。不同节点的分母不同，不能据此计算真实漏洞召回率。作者明确没有全部真实漏洞的标签集，也说明这些数字来自隔离研究环境；图中数量不能解释为线上仍有同样多未修复漏洞。
可信度 65 · 重要性 84 · 新颖度 78
技术与主题
Agent 系统 · AI 编程 · 评测与基准 · Multi-Agent · Coverage Tracking · Adversarial Validation · SQLite
Cloudflare 作者团队
从单仓技能发展为内部跨仓扫描系统的工程复盘。
忠实转述（非原句）：团队认为，应先让提示词在一个仓库里产生真实结果，再按瓶颈添加编排层。持久化应早于大规模并发：一次连接错误不应该抹掉数小时工作。作者没有声称知道漏掉了多少真实漏洞，而是观察重复扫描是否仍有新增发现。
编辑评读
这套实践值得借鉴的是把“未完成”保留成可继续的对象。缺一个环境、只检查了某个入口、找到了可能同源的缺陷，都有不同后续动作。若只保存最终报告，下一次运行很容易从头猜测，或把上次没有查完当成已经覆盖。持久化因此不仅是防崩溃，也决定哪些证据能跨轮次积累。
“独立验证”仍要按具体含义理解。更换 Agent 可以隔开上下文，更换模型可以增加不同搜索路径，但并不保证错误在统计上独立。更强的约束来自原代码上的可重放结果，以及生产配置能否让攻击者走到该路径。开源技能的三种状态也有意义：已确认、待验证、已否定各自保留，不用一个严重性分数掩盖未解的问题。
对小团队，可迁移的起点是任务表、原始证据与一个不能自行提交新发现的验证角色；跨仓依赖追踪则要等实际需求出现。本文没有运行整套框架，不能给出本地漏报率或费用收益。应当把“报告格式可校验”和“安全判断成立”作为两项不同的验收。