原文链接：https://www.chatprd.ai/how-i-ai/how-mozilla-fixed-500-security-bugs-with-mythos

从让模型找 Bug 到让系统持续变安全：Mozilla 的 AI Agent 安全工程闭环

很多人看到 Mozilla 的案例时，第一反应是：一个叫 Claude Mythos 的模型，帮助 Firefox 在短时间内修复了数百个安全问题。

但这并不是一个“更强模型横空出世，自动把 Bug 都修完”的故事。

真正值得关注的是：Mozilla 没有把大模型当成一个会聊天、会写代码的工具，而是把它放进了一套可以提出假设、调用工具、运行测试、验证结果、生成补丁，并由工程师复核的安全工程闭环中。

这篇文章尝试把这个案例拆成一套普通研发团队也能借鉴的教程：

• 为什么“让模型报告漏洞”很容易变成噪音；
• Mozilla 的 Agentic Harness 是怎么工作的；
• 为什么第一步不是全库扫描，而是先做优先级判断；
• 发现、验证、修复为什么要拆成不同角色；
• 普通团队如何从一个小模块开始搭自己的 AI 审计闭环。

1. 先理解问题：AI 报告很多，但真正有用的很少

在开源项目中，维护者一直面对一个成本不对称问题：

让模型对一段 C++ 代码提出“这里可能有漏洞”非常便宜；但工程师要验证它是不是漏洞、能不能被利用、影响范围有多大，却非常昂贵。

这类“看起来合理、实际上不可复现”的报告，会给安全团队带来严重负担。模型可以批量提出猜测，维护者却必须逐条排查。

Mozilla 的思路不是继续优化“报告写得多漂亮”，而是把验收标准改成一个更硬的目标：

不只告诉我可能存在问题；请给出一个可执行、可复现的测试用例，证明问题真实存在。

这个变化非常关键。安全工作不再停留在“语言上的判断”，而进入“能否被工具验证”的阶段。

2. 核心架构：把模型装进 Agentic Harness

Mozilla 为漏洞挖掘构建了一套自定义 Agentic Harness（智能体执行框架）。可以把它理解为：给模型一个明确任务，并提供完成任务所需的实际工具。

模型不再只是阅读代码后给出建议，它还能：

• 访问目标代码与构建环境；
• 分析特定文件或函数；
• 生成 HTML、脚本等测试样例；
• 启动特制的 Firefox 构建版本；
• 读取 AddressSanitizer 等工具的执行反馈；
• 根据失败原因继续修改假设与测试。

在这个框架中，一个漏洞发现任务更像是循环实验：

阅读目标代码
  -> 提出可被攻击的假设
  -> 生成最小复现用例
  -> 在测试浏览器中运行
  -> 读取崩溃 / 日志 / 检查器反馈
  -> 调整假设并再次尝试
  -> 产出可复现 PoC

Mozilla 甚至会给模型一个具有引导性的前提：“这个文件里存在安全问题，请把它找出来。”

这并不是要模型凭空编造漏洞，而是为了让它把搜索资源集中在明确目标上，持续构造、测试和淘汰假设。模型如果第一次没有触发异常，不会直接停在“我没有发现问题”，而是会根据测试结果继续尝试。

这也是 Agent 工作流与普通代码问答最本质的区别：

答案不是最终交付物，经过执行验证的结果才是。

3. 第一步不是扫描全部代码，而是先决定“该查哪里”

Firefox 拥有海量代码。即使模型可以持续运行，也不可能让它以同样成本扫描每一个文件。

因此，Mozilla 在漏洞挖掘前先设置了一个“LLM 裁判”角色，为候选文件打分。这个裁判并不直接找漏洞，而是回答两个问题：

1. 风险可能性：这个文件出现内存安全问题的概率有多高？
2. 可达性：恶意网页是否容易触发到这段代码？

例如，体量大、位于网页内容可直接触达路径上的核心文件，通常会排在更前面。经过排序后，真正消耗算力的漏洞挖掘 Agent 才进入这些高价值目标。

这套做法的价值不局限于安全领域。对于大型工程团队，它同样可以用来判断：

• 哪些模块最值得做性能优化；
• 哪些遗留代码风险最高；
• 哪些 UI 页面最可能存在体验或可访问性问题；
• 哪些依赖升级最需要人工优先审查。

在大代码库里，AI 的第一份工作未必是“解决问题”，也可以是把人和算力带到最值得解决的问题上。

4. 漏洞发现之后，还必须有独立验证与修复闭环

发现崩溃并不等于确认真实漏洞，更不等于完成修复。

Mozilla 在主 Agent 之后增加了独立验证环节。验证 Agent 会检查：

• 测试是否依赖开发环境中的特殊开关；
• 模型是否为了制造成功而改动了不该改的代码；
• 漏洞路径是否符合真实攻击条件；
• 复现步骤是否稳定；
• 结果是否能被安全工程师理解和复核。

只有通过验证的结果，才会进入补丁阶段。

随后，修复 Agent 会尝试生成代码补丁，并由系统自动执行一轮关键回归：

应用补丁
  -> 重新构建 Firefox
  -> 运行原始 PoC
  -> 确认崩溃是否消失
  -> 交由人工安全工程师审查

这层机制尤其重要，因为一个目标极强的 Agent 可能会为了“找到漏洞”而采取不符合实际安全条件的路径。独立验证器就是对抗这种偏差的护栏。

而在最后一步，人类工程师仍不可替代。模型或许能给出一个局部修复，但资深工程师可以进一步判断：

• 同类缺陷是否存在于另外几个模块？
• 是否应当修改抽象层，而不是只修补一个触发点？
• 这个补丁会不会引入新的兼容性风险？
• 修复是否符合项目长期架构方向？

于是，AI 负责完成大量重复、耐心且可验证的搜索工作；人类负责系统性设计与架构判断。

5. 为什么这套方法能真正提高安全产出？

Mozilla 的案例说明，提升不来自单一模型能力，而来自四个能力叠加。

5.1 目标足够清晰

每个 Agent 都知道自己是做优先级判断、找漏洞、验漏洞还是修漏洞。角色越清楚，输出越容易被验证。

5.2 工具能够闭环

模型可以构建、运行、检测、读取日志，而不是只停留在文本层。没有工具反馈，模型只能产生猜测；有了反馈，模型才能进行实验。

5.3 结果必须可复现

没有 PoC、没有运行证据，就不算完成发现。可复现性把“看起来像”变成了“确实发生”。

5.4 人类把控系统性修复

自动化处理局部发现，人类负责安全边界、修复范围和最终合入。AI 没有绕开研发流程，而是增强了 DevSecOps 流程。

从这个角度看，AI 并没有直接替代安全研究员，而是压缩了安全研究中最耗时的部分：浏览代码、形成假设、编写测试、反复运行、整理证据。

安全团队的工作重心，也会从“有没有时间把每一份线索查完”，逐渐转向“如何设计更可靠的验证环境、如何提升修复的系统性、如何管理持续涌入的高质量发现”。

6. 普通团队如何借鉴：从一个小闭环开始

不需要拥有 Firefox 这样规模的代码库，团队也可以从一个小范围开始建立自己的 AI 审计闭环。

步骤 1：选一个高风险、边界清楚的目标

优先选择这些模块：

• 支付；
• 权限校验；
• 文件上传；
• 账号登录；
• 数据导出；
• 长期没人愿意碰的遗留模块。

不要一开始就要求 AI “审计整个系统”。目标越大，验证成本越容易失控。

步骤 2：让模型获得真实反馈

至少连接一类反馈源：

• 静态扫描；
• 单元测试；
• 集成测试；
• 运行日志；
• 沙箱环境；
• 构建失败信息；
• 安全扫描工具输出。

没有工具反馈，模型只能写分析；有了反馈，模型才能迭代。

步骤 3：把“可复现”设为最低验收标准

每一个发现至少应包含：

• 触发条件；
• 测试用例；
• 执行结果；
• 影响说明；
• 最小化复现步骤；
• 修复前后的对比证据。

步骤 4：让验证角色与发现角色分离

不要让同一个 Agent 既负责发现又负责宣布成功。独立验证可以明显降低误报、投机式路径和环境依赖问题。

步骤 5：让补丁进入既有研发流程

补丁可以由 AI 提议，但必须经过：

• 自动测试；
• 代码评审；
• 发布检查；
• 负责人确认；
• 线上监控或回滚预案。

Agent 应增强现有 DevSecOps 流程，而不是绕开它。

7. 可以跟踪哪些指标？

如果你要在团队里试点这类流程，可以先跟踪几项简单指标：

指标	目的
每小时计算资源产出的有效发现数	判断算力是否用在高价值目标上
发现结果的可复现率	判断 Agent 输出是否从猜测进入证据
误报率与人工复核耗时	判断验证环节是否有效
补丁通过回归测试的比例	判断修复 Agent 是否可靠
从发现到修复发布的周期	判断端到端闭环是否真的提速

这些指标不需要一开始就很复杂。关键是先把“模型输出很多内容”转成“系统持续产生可验证结果”。

结语：模型不是答案，验证系统才是护城河

Mozilla 的案例最重要的启示，是把对 AI 的关注点从“哪个模型更聪明”转向“我们是否为模型设计了正确的任务、工具、反馈和护栏”。

模型能力会持续升级，但真正可积累的组织能力，是将模型接入工程系统之后形成的流程资产：

• 优先级机制；
• 执行环境；
• 测试工具；
• 验证规则；
• 漏洞分流；
• 补丁审核；
• 发布机制。

当 AI 能够提出假设、动手验证、接受失败、继续迭代，并把结果交给工程师做更高层判断时，它才不再只是一个聊天助手，而开始成为软件研发与安全体系中的生产力。

---

参考资料

1. ChatPRD，How Mozilla Fixed 500 Security Bugs with Claude Mythos，2026-06-21。
2. Mozilla Hacks，Brian Grinstead、Christian Holler、Frederik Braun，Behind the Scenes Hardening Firefox with Claude Mythos Preview，2026-05-07。
3. Mozilla Blog，Bobby Holley，The zero-days are numbered，2026-04-21。