2026 年 7 月 30 日，Google 官方公布了一组令人瞩目的安全数据：Chrome 149 与 150 两个版本连续修复了 1,072 个安全漏洞，这一数量一举超过了过去两年（23 个版本里程碑）的修复总和。这一爆发式增长的背后，是 Chrome 安全团队全面接入内部 AI Agent 管线的结果。
从 2023 年利用 LLM 拓展模糊测试覆盖率，到 2025 年 Project Zero 推出 Big Sleep，再到 2026 年初建立覆盖全量代码库的 Agent Harness，Google 成功将漏洞挖掘演变为自动运转的基础设施。在 2026 年初的检测中，AI Harness 甚至找出一个存在于代码库中长达 13 年之久的沙箱逃逸漏洞（sandbox escape）。这一发现证明了 AI 在深层逻辑漏洞挖掘上的工程潜力，也标志着浏览器安全基础设施正从人力抽查转向全量自动审计。
自动化工程拆解：多 Agent 协作的技术架构
AI 自动化能力的跃升建立在严密设计的工程架构之上。Google 为 Gemini 构建了包含历史 CVE 与完整 Git 变更历史的专用知识库，并推动开发者编写 SECURITY.md 规范信任边界。批评者 Agent（critic agent）随后在独立上下文环境中消费这些安全规范，配合模型的多轮并行运行来消除大模型输出的非确定性。
在代码接入与安全隔离方面，AI Agent 被部署在隔离外网的锁定环境，所有网络请求经由严格的许可清单过滤。子 Agent 被禁止修改本地系统或跨越指定目录，避免研发管线自身成为潜在的攻击面。严格的访问控制与模块化隔离，确保了自动化分析工具在具备高权限代码理解力的同时避免引入额外安全隐患。
图：最近 Chrome Stable 各里程碑修复的安全 bug 数量。来源：blog.google 官方博客
在具体的分工协作上，原本耗时 5 至 30 分钟的人工分拣流程被重构成四阶段自动化流水线，涵盖噪音过滤、PoC 重现、元数据补充与责任人自动分配。每月流水线为开发团队节省了数百小时。在修复环节，修复 Agent 生成多个候选补丁后，交由 critic agent 模拟代码审查，最后由测试撰写 Agent 生成跨平台单体测试。
这套自动化机制已经深度集成至代码集成（CI）阶段，BigSleep 与 CodeMender 每 24 小时对所有提交（CL）扫描一次。仅在 2026 年 5 月，该系统就在代码合入生产环境前拦截了 20 多个严重漏洞，其中包括一个 critical 级别的 S1+ 严重问题。自动化安全检验跨越了传统的后置修补环节，直接演变为代码合入主干前不可或缺的防御闸门。
攻防双向加速：补丁空窗期引发的技术争议
漏洞修复数量的剧增在技术社区引发了激烈的讨论。在 Hacker News 上获得超过 500 点赞的讨论中，不少安全研究员提出质问：自动化工具找出的上千个 bug 究竟是真实的高危威胁，还是某种程度上造成了报告数量的膨胀？与此同时，Google 漏洞赏金计划（VRP）在 2026 年 3 月收到的报告量就已经超过 2025 年全年，导致团队重新调整奖励机制，仅对内部工具无法覆盖的增量贡献发放奖金。
更深层次的忧虑来自攻防不对等带来的风险。内部团队拥有 AI 工具提升修复效率，攻击者同样可以使用类似的语义分析大模型对主干代码提交进行逆向分析。代码修复公开与用户完成升级之间的时间差（patch gap）被急剧拉大，攻击者定位 N-day 漏洞的速度正在逼近代码合并的速度。
图：Chrome 自动化漏洞生命周期流程图。来源：blog.google 官方博客
当公开仓库的修复提交成为攻击者的漏洞指南时，传统的修复分发机制面临失效。如果安全补丁在合并后仍需数周才能到达 Stable 通道终端，防线就会在空窗期内被攻破。单向追求漏洞查找效率如果脱离了交付管道的协同升级，会加剧终端用户的暴露风险。
交付即防线：每周双发与零窗口自动重启
面对补丁空窗期的挑战，Google 改变了更新交付策略。安全团队将补丁从 main tree 快速挑选（cherry-pick）直接合并入 stable 发布分支，并将大版本更新缩短为每两星期一次，同时试点每周两次安全更新。将软件发布周期压缩至以天计算，是抵御攻击者利用自动化技术逆向分析 N-day 漏洞的最有效手段。
为了让终端用户无感接收频繁的更新，Chrome 在 150 版本中推行了动态补丁技术（dynamic patching）。利用浏览器的多进程架构，后台进程（如 Renderer 和 GPU 进程）可以在无感知状态下按顺序替换二进制文件。在 macOS 系统上，Chrome 150 进一步实现了零窗口下的自动重启更新，消除了因用户长期保持浏览器运行而导致的补丁滞后。
在架构层面的根源性防护上，Chrome 持续拓展内存安全改造。MiraclePtr 和 MiracleObject 的覆盖范围被进一步扩大，目标中和 GPU 主线程上最高 90% 的释放后使用（UAF）漏洞。同时，97% 的一方代码库已通过严格的 unsafe-buffer 编译警告检查，结合 Rust 在编解码器、数据解析器与字体栈中的定点替换，大幅降低了高权限进程的安全风险。
代码审查管线（CQ）中还部署了 AI 防御模型，实时扫描代码变更中的悬垂指针与数值溢出风险。AI 模型通过语义分析能够拦截跨模块的潜伏安全隐患，防止看似无害的代码改动被恶意组合成复合漏洞。这种将类型安全语言、静态架构防护与 AI 实时审核相结合的综合策略，为高频发布的更新交付搭建了第二条防线。
自动化时代的安全竞争重塑
Chrome 149 与 150 修复 1,072 个漏洞的工程实践，展示了 AI 时代安全模式的剧烈转折。然而，这一变革的核心价值不仅在于修补了多少历史债务，更在于它逼迫整个软件工程体系重构交付流程。当漏洞发现的门槛被大幅降低，攻防演变的战场必然向更新分发能力转移。
正如 Chrome 安全团队在公开报告中所言，漏洞修复数量的激增并非安全恶化的标志，每一个被封堵的漏洞都意味着攻击者失去了一个立足点。在自动化防线全面普及的时代，安全的胜负手在于能够最快将补丁推送至终端用户的自动化管线。
参考链接：
- Google 官方博客：Stronger with every update
- Hacker News 社区讨论：Chrome 149/150 Security Updates
