Mozilla 在一篇技术文章中披露，团队使用 Anthropic 的 Claude Mythos 预览版，配合一套自动化 harness，对 Firefox 进行大规模安全加固。结果很直接：Firefox 在 2025 年每月大约修复 20 到 30 个安全问题，2026 年 4 月这一数字升至 423 个。
这不是“AI 独立挖出 423 个高危漏洞”的故事。更准确的判断是，LLM 在安全工程里开始显露一种新角色：不是替代维护者，而是在被约束、编排、筛选后，提供更高密度的漏洞信号。对开源项目来说，这比又一个模型跑分更有现实意义。
Firefox 的变化来自模型，也来自 harness
Mozilla 对变化原因的解释很克制：一是模型能力变强，二是团队改进了 harness 技术，包括如何引导模型、规模化运行模型、叠加多个模型输出，并从噪声中筛出信号。
这点很重要。过去一年，许多开源维护者对 AI 安全报告的印象并不好。LLM 生成一个看似合理的漏洞报告成本很低，维护者验证、复现、回复却很慢。这种不对称成本，让“AI 报洞”一度更像负担。
Mozilla 这次展示的是另一种路径：把模型放进工程流程，而不是让模型直接把报告扔给维护者。
| 项目 | 过去常见状态 | Mozilla 这次的变化 | 判断 |
|---|---|---|---|
| 报告质量 | 大量看似正确的误报 | harness 负责生成、筛选、验证线索 | 噪声被工程流程压低 |
| 修复规模 | 2025 年每月约 20-30 个 | 2026 年 4 月达到 423 个 | 数量异常上升，但不等于全是高危 |
| 典型案例 | 依赖人工审查发现旧问题 | 包括 20 年历史的 XSLT bug、15 年历史的 <legend> 元素 bug | 老代码成为重点受益区 |
| 防御结果 | 漏洞链常被多层机制阻断 | 不少攻击尝试被 Firefox 既有纵深防御拦住 | 说明防御体系仍是底座 |
重要的是有效信号，不是“AI 挖洞”的口号
这件事真正重要的地方，在于它给安全团队提供了一个可操作方向：LLM 不必一次性完成发现、验证、修复全流程，只要能稳定放大有效信号，就已经有价值。
Firefox 这样的老牌浏览器尤其适合观察这种变化。浏览器代码历史长、攻击面大，DOM、渲染、脚本、样式、XML/XSLT 等模块都积累了大量边角行为。一个 20 年历史的 XSLT bug 和一个 15 年历史的 <legend> 元素 bug 被翻出来，说明模型辅助工具可能擅长在旧代码、复杂状态机和冷门路径里制造压力测试。
但这里有一个原文读者容易忽略的条件：Firefox 有成熟的安全流程、自动化测试基础、沙箱和纵深防御，也有能消化这些发现的工程团队。换成维护人手不足、测试覆盖薄弱的小型开源项目，同样的模型输出未必是收益，可能仍是工单洪水。
横向看，GitHub CodeQL、OSS-Fuzz、传统静态分析和模糊测试早就承担过类似角色。LLM 的新意不在于“替代它们”，而是可能补上更灵活的路径探索和语义推理。它更像加入流水线的一层放大器，而不是一把万能钥匙。
开源维护者该看流程，不该只看模型名
对开源维护者和安全工程团队，最现实的启发不是马上采购某个模型，而是重新设计入口：AI 生成的漏洞线索不能直接进入维护者队列，必须先经过复现、去重、最小化样例和严重性初筛。
这会改变团队分工。安全工程师要更多维护 harness、评估模型输出质量、设计验证门槛；AI 工程团队则要为模型调用成本、提示策略、结果聚类和失败样本负责。预算讨论也会从“买不买 LLM”变成“能不能把它接入现有 CI、fuzzing、bug triage 和补丁审查流程”。
接下来最该观察三件事：Mozilla 后续月份的修复量是否回落；这些问题中有多少能对应到可复现、可利用的安全边界；Claude Mythos preview 以外的模型和其他大型开源项目，能否复制类似结果。目前只能说，Firefox 案例证明了上限，不证明行业平均水平。
对普通 Firefox 用户，短期收益更朴素：更多旧问题被提前修掉，攻击者可利用的边角路径减少。对维护者来说，真正的压力也更具体：谁来给 AI 输出把关，谁来承担误报成本，谁来决定一个自动化发现是否值得进入安全发布节奏。