Cloudflare 披露了 Project Glasswing 的核心工程细节：如何把一款 AI 安全审计「技能」扩展成分布式漏洞扫描平台。他们的答案不是依赖更强的模型，而是一套模型无关的架构。
为什么通用编程助手不够用
安全分析需要同时维持数百个独立调查任务、跨越运行周期保持状态、事后重新定位和交叉引用。这意味着需要持久化、去重、可恢复、以及最终覆盖整个代码库的依赖追踪能力——这是一道编排问题，单纯靠提示词解决不了。
他们的方案从一段约 450 行的安全审计「技能」起步，在单个代码库上反复调整提示词，直到能挖出真实漏洞。随后他们为这个技能叠加编排层，逐渐演变成整个系统的骨架。
七阶段审计流程
原始技能在单次会话中运行七个阶段：三个并行研究智能体做侦察并输出 architecture.md；每个攻击类别对应一个 Hunter 智能体，用对抗思维尝试「打穿」代码而非审阅代码；对抗验证器尝试推翻每个发现；存活下来的漏洞生成人类可读的漏洞报告；同一批漏洞同时输出为 findings.json 并接受机械校验；最后由一个全新智能体独立重新验证每条发现。
三个瓶颈与解法
上下文耗尽：运行约一小时后上下文窗口填满，模型开始吞噬自身记忆，刚追踪到的漏洞瞬间丢失。解决方案：将状态完全外部化，把 LLM 当成无状态计算引擎。
持久化问题：中途崩溃意味着前功尽弃。一次 API 限速错误或连接抖动就可能损失数小时工作。解决方案：引入数据库持久化状态，支持中断恢复。
跨仓库推理盲区：单仓库会话完全看不到消费该库的应用之间的关联，而接口处暴露的漏洞数量往往超出预期。
最小可行架构
Cloudflare 给出的建议是：仅保留 Recon、Hunt、Validate 三个阶段存于数据库，配备一个不能自行提交发现的独立验证器。跨仓库追踪可以留到后续再添加。
核心原则是：把不同模型当作可互换的零件——用一个模型做初筛，另一个完全不同的模型做验证，让漏洞经过多套逻辑交叉检验。这套架构的价值不在于当下哪款模型最强，而在于「挽具」本身能持续运转。
编注：信源为 Cloudflare 官方工程博客，内容为技术实践详解，未涉及具体漏洞案例或行业竞品对比。