过去几个月，我们一直在自己的基础设施上测试各种专注于安全的大语言模型。这些模型帮助我们发现自身系统中潜在的漏洞，以便修复；同时也让我们看到，攻击者借助最新模型将能做到什么。
在这些模型中，没有哪一个比 Anthropic 的 Mythos Preview 更受关注。几周前，我们受邀作为 Project Glasswing 的一部分使用 Mythos Preview。很快，我们就把它对准了自家五十多个代码仓库，看看它能发现什么，也看看它是如何工作的。
这篇文章分享我们的观察：这些模型哪些方面做得好、哪些不行，以及围绕它们的架构和流程需要如何改变，才能大规模使用它们。
Mythos Preview 带来了什么变化
Mythos Preview 是真正的一次飞跃，在讨论其他内容之前，值得先坦率地说明这一点。我们对自己的代码运行模型已有一段时间，而从此前通用前沿模型所能做到的，到 Mythos Preview 如今的表现，这不只是对既有能力的小幅改进。
它是另一类工具，在做另一类工作，因此很难与早期模型做干净的同类对比。所以，与其试图拿 Mythos Preview 和通用前沿模型做基准测试，不如描述它实际能做什么，以及我们在使用 Mythos Preview 的整个工作中最突出的两个特点：
- 构造利用链：真实的攻击很少只用一个漏洞，而是把若干小的攻击原语串联起来，形成可用的利用程序。例如，它可能把一个 use-after-free 漏洞变成任意读写原语，劫持控制流，再借助返回导向编程（ROP）链完全控制系统。Mythos Preview 能够拿到其中好几个原语，并推理如何把它们组合成一个可运行的证明。它在过程中展现出的推理，看上去像是资深研究员的工作，而不是自动扫描器的输出。
- 生成证明：发现一个漏洞与证明它可被利用是两回事，而 Mythos Preview 两者都能做。它会编写能触发疑似漏洞的代码，在临时环境中编译并运行。如果程序的行为符合模型的预期，这就是证明；如果不符，模型会读取失败信息，调整假设，再试一次。这个循环与它发现的漏洞同样重要，因为没有可运行证明的疑似缺陷只是猜测，而 Mythos Preview 能自己补上这道缺口。
上面所述的部分能力并非 Mythos Preview 所独有。当我们让其他前沿模型使用同一套测试框架（harness）时，它们也发现了相当数量的相同底层漏洞，在某些情况下，推理层面走得比我们预期的更远。它们的不足出现在把各个环节拼接起来的时候：模型会指出一个有意思的漏洞，写出一段深思熟虑的说明解释其重要性，然后就停下了，真正的利用链没有完成，可利用性问题悬而未决。Mythos Preview 带来的变化在于，模型现在可以把这些低严重度的漏洞（它们在传统上会不被注意地躺在待办列表里）串联成一个更严重的单一利用。
合法漏洞研究中的模型拒绝行为
Anthropic 作为 Project Glasswing 的一部分提供的 Mythos Preview 模型，并不具备那些面向公众的通用模型（如 Opus 4.7 或 GPT-5.5）中额外的安全防护。
尽管如此，该模型仍会自发地对某些请求表示抗拒。就像让它适合做漏洞挖掘的那些网络安全能力一样，这个模型有自己涌现出来的防护机制，有时会让它对合法的安全研究请求加以抗拒。但我们发现，这些自发的拒绝并不一致：同一个任务，换一种表述或放在不同的上下文中，就可能产生完全不同的结果，下面的例子说明了这一点。
Mythos Preview 拒绝构建可运行概念验证的示例
例如，该模型最初拒绝对某个项目做漏洞研究，随后在项目环境发生一项无关的改动后，同意对同样的代码执行同样的研究。而被分析的代码本身没有任何变化。
在另一个案例中，模型在一个代码库里发现并确认了几处严重的内存漏洞，随后却拒绝编写演示用的利用程序。同样的请求换一种表述，得到了不同的回答；由于模型的概率性本质，即便是同一个请求，不同次运行的结果也可能不同。语义上等价的任务，取决于以何种方式、在什么时候呈现给模型，可能产生截然相反的结果。
这一点很重要：虽然模型自发的拒绝与防护确实存在，但其一致性不足以单独充当完整的安全边界。这正是为什么未来任何公开提供的、具备强大网络安全能力的前沿模型，都必须在这一基线行为之上加入额外的安全防护，使其适合在 Project Glasswing 这类受控研究环境之外更广泛地使用。
信噪比问题
安全漏洞分诊中最困难的部分之一，是判断哪些漏洞是真的、哪些可被利用、哪些需要立即修复。即使在 AI 出现之前，这也是个难题。AI 漏洞扫描器和 AI 生成的代码让情况变得更糟，在 Cloudflare，我们为此搭建了多个后置验证阶段。
噪声率主要由两个因素决定：
- 编程语言：C 和 C++ 让你直接控制内存，也随之带来了缓冲区溢出、越界读写等漏洞类别，而 Rust 这类内存安全语言在编译期就消除了它们。我们一直观察到，用内存不安全语言编写的项目会产生更多误报。
- 模型偏差：优秀的人类研究员会告诉你他们发现了什么，以及有多大把握。模型不会。让模型去找漏洞，它就会找出来，不管代码里有没有。返回的结果充满“可能”“潜在”“理论上可能”等含糊措辞，含糊的结论远远多于确凿的结论。对探索性工具来说，这种倾向是合理的；但对分诊队列来说却是灾难性的，每个推测性的结论都要花费人力的注意力和 token 才能排除，而这一成本在成千上万条结论上会不断累积。
Mythos Preview 在这方面有明显改进，尤其是它串联原语的能力：把多个漏洞组合成一个可运行的概念验证（PoC），而不是孤立地报告它们。附带 PoC 的结论是可以直接行动的结论，这意味着花在追问“这到底是不是真的？”上的时间要少得多。
我们的测试框架被刻意调成多报，这样我们能看到更多（漏掉更少），代价是噪声也多得多。但到了分诊环节，Mythos Preview 的输出质量明显更高：含糊的结论更少，复现步骤更清晰，得出“修复还是排除”的决定所需的工作也更少。
为什么把通用编码智能体直接指向一个代码仓库行不通
去年我们刚开始做 AI 辅助漏洞研究时，本能的做法很直接：把一个通用编码智能体指向任意一个代码仓库，让它去发现漏洞。这种做法确实“有效”，因为模型会产出结论；但它无法对真实代码库形成有意义的覆盖，也无法找出有价值的结论。主要有两个原因：
- 上下文：编码智能体针对单一的聚焦工作流做了调优：构建功能、修复缺陷、编写重构。它们读入大量源代码，一次只持有一个假设，并围绕它迭代。这恰恰不符合漏洞研究的形态，漏洞研究天然是窄而并行的。人类研究员会选定某个具体对象，并彻底地研究它。这个对象可能是一个复杂的功能、跨越安全边界的转换，或某一类具体的漏洞，比如命令注入，即攻击者的输入最终被当作 shell 命令执行。然后他们再换一个功能、安全边界或漏洞类别重来一遍，在整个代码库上重复数千次。针对一个十万行的仓库，单个智能体会话（即使带有子智能体）在模型上下文窗口被填满、触发压缩之前，大概只能有效覆盖攻击面的千分之一，而压缩还可能丢弃本来很重要的早期发现。
- 吞吐量：单流智能体一次只做一件事，而真实的代码库需要同时针对众多组件提出众多假设，并在发现有趣线索时能进一步展开。你可以更用力地驱动单个智能体，但到某个时刻，限制你的不再是模型，而是交互形态本身。事实证明，在研究员已有线索、希望多一双眼睛时，直接在编码智能体里使用该模型进行人工调查是没问题的；但要实现高覆盖率，它是错误的工具。认识到这一点之后，我们不再试图让 Mythos Preview 去做不对口的工作，而是转而围绕它搭建测试框架。
测试框架（harness）究竟解决了什么
大规模运行这项工作后，我们得出了四条经验，每一条都指向需要一个管理整体执行的测试框架：
- 范围收窄，结论更好：对模型说“在这个仓库里找漏洞”，它就会漫无目的地游荡。而告诉它“在这个特定函数里找命令注入，它上方的信任边界是这样，这是架构文档，这是该区域此前的覆盖情况”，它做的事就更接近研究员实际会做的。
- 对抗式评审降低噪声：在初始发现与队列之间加入第二个智能体，使用不同的提示词、不同的模型，且不能自己产生新的发现，就能拦下很多噪声，而第一个智能体如果只是检查自己的工作，是会漏掉这些噪声的。事实证明，让两个智能体刻意“唱反调”，远比只告诉一个智能体要谨慎有效得多。
- 把链条拆分给不同智能体，推理更好：“这段代码有漏洞吗？”和“攻击者真的能从系统外部触达这个漏洞吗？”是两个不同的问题，分开问时模型回答每一个都更好，因为每个问题都比合并后的问法更窄。
- 并行的窄任务胜过一个穷尽式智能体：让许多智能体处理范围严格限定的问题，事后再对结果去重，覆盖率会比让一个智能体做到穷尽更高。
这些观察每一条都关乎模型行为，合在一起，描述的已经不再是聊天界面，而是一个帮助你实现最终成果的测试框架。搭建测试框架的第一步很简单，你可以请模型帮忙，我们就是这么做的：我们用 Mythos Preview 在原有测试框架的基础上扩展、定制和改进，以适应它的长处。
下面描述一个测试框架在实践中的样子。
我们的漏洞发现测试框架
下面按阶段介绍我们的漏洞发现测试框架。它被用来扫描我们运行时、边缘数据路径、协议栈、控制平面，以及我们所依赖的开源项目中的线上代码。
| 阶段 | 做什么 | 为什么重要 |
|---|---|---|
| 侦察（Recon） | 一个智能体自上而下阅读仓库，把任务分派给负责各子系统的子智能体，产出一份架构文档，涵盖构建命令、信任边界、入口点和可能的攻击面。它还会为下一阶段生成初始任务队列。 | 让所有下游智能体共享上下文，避免漫无目的地游荡。 |
| 狩猎（Hunt） | 每个任务是一个攻击类别加上一条范围提示。狩猎者（真正去找漏洞的智能体）并发运行，通常同时约五十个，每个再展开出少量探索子智能体。每个狩猎者都可使用工具，在每个任务独立的临时目录中编译并运行概念验证代码。 | 大部分工作在这里完成：并行的许多窄任务，而不是一个穷尽式智能体。 |
| 验证（Validate） | 一个独立的智能体重新阅读代码，并试图推翻最初的发现。它使用不同的提示词，且无法自行提出新的发现。 | 拦下相当比例的噪声，这些噪声是狩猎者审查自己的工作时发现不了的。 |
| 补缺（Gapfill） | 狩猎者标记出它们接触过但没有彻底覆盖的区域，这些区域会重新入队，再来一轮。 | 抵消模型倾向于偏向它已经取得过成功的攻击类别的趋势。 |
| 去重（Dedupe） | 根因相同的发现会合并为一条记录。 | 变体分析是一项功能，而不是用重复项来撑大队列的手段。 |
| 追踪（Trace） | 对共享库中每个已确认的发现，追踪智能体会展开（每个下游依赖的代码仓库一个实例），利用跨仓库符号索引，判断攻击者可控的输入是否真的能从系统外部到达该漏洞。 | 把“存在缺陷”变成“存在可达的漏洞”。这是最关键的阶段。 |
| 反馈（Feedback） | 可达的追踪结果会成为新的狩猎任务，派发到漏洞实际暴露的下游仓库中。 | 形成闭环，流水线在运行中越来越好。 |
| 报告（Report） | 一个智能体依据预定义的 schema 编写结构化报告，自行修正不符合该 schema 的校验错误，并将报告提交到摄取 API。 | 输出是可查询的数据，而不是自由格式的文字。 |
这对安全团队意味着什么
其他安全负责人对 Mythos Preview 最强烈的反应都集中在速度上：扫描更快、修补更快、压缩响应周期。我们接触过的不止一个团队，现在的 SLA 是从 CVE 发布到补丁上线生产只有两小时。这种本能可以理解：攻击者的时间线缩短了，防守方的时间线也必须随之缩短。但仅仅更快是不够的，我们认为不少团队即将花费大量时间、精力和金钱，才会以惨痛的方式认清这一点。
修补得更快，并不会改变产出补丁的流水线的形态。如果回归测试要花一天，要达到两小时的 SLA 就只能跳过它，而跳过回归测试所带来的漏洞，往往比你试图修补的漏洞更糟。我们在让模型自己写补丁时就吃过类似的亏：有几个补丁修好了原来的漏洞，却悄悄破坏了代码所依赖的其他东西，而且已经上线了。
更难的问题是，围绕漏洞的架构应该是什么样子。原则是：即便漏洞存在，也要让攻击者更难利用，使漏洞披露与打上补丁之间的时间差不再那么要紧。这意味着在应用前面设置防御，阻止漏洞被触达；意味着设计应用时，让代码某一部分的缺陷无法让攻击者进入其他部分；也意味着能够在同一时刻把修复推送到代码运行的每一个地方，而不是等各个团队自行部署。
我们也认识到，这个话题是双刃剑。帮助我们在自家代码中找到漏洞的这些能力，落到不法之手，也会加速针对互联网上每个应用的攻击。Cloudflare 位于数百万个这样的应用前面，而上述架构原则恰恰是我们的产品为客户落实的那些原则。在接下来的几周里，我们会分享更多这对客户意味着什么。
如果你的团队也在做类似的工作，并希望交流心得，欢迎通过 security-ai-research@cloudflare.com 联系我们。
我们对 Mythos Preview 的研究是在受控环境中针对我们自己的代码进行的；通过这项工作发现的每个漏洞，都已按照 Cloudflare 正式的漏洞管理流程进行了分诊、验证，并在需要采取行动的地方完成了修复。
这项工作是团队协作的成果。感谢 Albert Pedersen、Craig Strubhart、Dan Jones、Irtefa Fairuz、Martin Schwarzl 和 Rohit Chenna Reddy 对本文背后研究、工程与分析工作的贡献。