夜雨聆风一句话：用 AI 做漏洞发现，真正可复用的不是某个神奇提示词，而是一套可持久化、可验证、可替换模型的安全分析流水线。
AI 安全工具现在很容易做出一个好看的 demo。
给模型一段代码，让它扮演安全研究员，再要求它找漏洞。它可能真的会找到一些问题，也可能输出一份很像样的报告。
但 Cloudflare 的漏洞发现 harness 文章提醒我们：企业级安全工作不能建立在一次性的 Agent 会话上。
因为安全分析面对的不是一个问题，而是一组持续存在的工程约束：上下文会耗尽，发现会重复，模型会误报，任务会中断，漏洞会跨仓库出现，验证需要独立完成。
所以，关键问题不是“模型能不能发现漏洞”，而是：
你有没有一套系统，把模型的不稳定输出变成可验证、可追踪、可复用的安全结果？
子 Agent 有用，但不是系统本身
很多团队会自然想到：既然一个 Agent 不够，就开更多子 Agent。
Cloudflare 的判断更冷静：子 Agent 有用，但它们不能替代 harness。
原因很简单。真正的漏洞发现通常需要：
多轮侦察不同代码路径； 按攻击面拆分任务； 把中间状态保存到模型上下文之外； 对发现做反向验证； 去重同类问题； 追踪跨仓库依赖； 在失败或限流后恢复进度。
这些不是提示词问题，而是编排问题。
如果所有状态都放在一次对话里，模型上下文一满，系统就开始遗忘；如果每次运行都从头开始，安全团队很难把发现沉淀下来；如果验证者和发现者是同一个角色，误报就会被包装得更像真问题。
最小可行 harness：Recon、Hunt、Validate
Cloudflare 给出的最小建议很实用：先不要追求复杂平台，先做三个阶段。
第一，Recon。让系统理解代码结构、关键组件、输入输出、危险边界，并把架构认知写下来。
第二，Hunt。按攻击类型拆开搜索，而不是让一个 Agent 泛泛地“找所有漏洞”。每个 Hunter 只盯一个窄问题，比如权限绕过、注入、状态竞争、数据泄露路径。
第三，Validate。验证者不能提交自己的新发现，只负责反驳、复现、定位和过滤误报。
这个角色分离非常关键。安全工作里最贵的不是“有线索”，而是“线索是否可信”。
状态必须离开模型上下文
Cloudflare 在实践中遇到的一个核心限制，是上下文耗尽。
单次模型会话跑久了，前面的发现、假设、路径和排除项都会变得不可靠。解决办法不是继续压缩提示词，而是把状态外部化：数据库、文件、结构化 findings、阶段记录、验证结果，都应该存在模型之外。
这带来一个重要变化：模型从“记住一切的专家”，变成“读取状态、执行窄任务、写回结果的计算单元”。
这也是为什么 harness 要模型无关。
今天某个模型适合发现，另一个模型适合验证，明天排序可能变化。系统应该允许替换模型，而不是把流程绑死在某个供应商或某个提示词上。
误报治理是安全 Agent 的分水岭
安全场景最怕两件事：漏报和误报。
漏报让你以为安全，误报则消耗工程团队信任。一旦开发者发现 AI 安全工具总是制造噪音，后续真正重要的告警也会被忽略。
所以 harness 里必须有对抗式验证：验证者要主动尝试推翻发现，检查代码行号、调用链、可达路径、输入条件和利用前提。
更进一步，还要把幸存的发现转成测试、补丁或可复现步骤。只有这样，AI 输出才不是“安全作文”，而是工程团队可以处理的工作项。
对企业 AI 安全的启发
这篇文章最值得借鉴的，不是某个具体工具，而是工程姿态。
不要从“买一个安全 Agent”开始，而要从安全流程里最重复、最可验证的环节开始：代码侦察、已知漏洞模式扫描、PR 级别验证、依赖边界检查、历史漏洞回归测试。
也不要一开始就做跨所有仓库的大平台。
更稳的路线是：
选一个重要仓库； 建立 Recon / Hunt / Validate 三阶段； 用数据库保存状态； 把 findings 做成结构化格式； 让独立验证者过滤误报； 再逐步扩到更多仓库和攻击面。
结尾
AI 会让安全分析更自动化，但不会让安全工程变简单。
真正可靠的 AI 安全能力，不是把模型包装成“黑客”，而是把模型放进一套严肃的工程流水线里：有边界、有状态、有验证、有审计，也能随时替换。
提示词可以启动一次发现，harness 才能支撑一套能力。
参考资料：Cloudflare Blog, “Build your own vulnerability harness”。
