今天我们发布patching-bugs和regression-hunt，这两个插件让工程师可以把补丁开发和回归检查交给智能体。我们的 patching-bugs 插件会复现所报告的缺陷、开发修复并对其进行测试。regression-hunt 插件则检查是否有任何改动破坏了此前正常工作且受支持的行为。工程师可以指导工作并审查结果；维护者可以提供自己的安全假设和补丁要求，使智能体在项目规则范围内工作。
我们通过Patch the Planet构建了 patching-bugs 和 regression-hunt，这是我们与 OpenAI 的联合计划，我们已在该计划中为广泛使用的开源项目共同编写了数百个安全补丁。受我们在Scapy等项目上取得重大成功的激励，我们的插件借鉴了我们对已合并补丁的分析以及数千次我们工程师的 Codex 会话。
这些插件为维护者提供了结构化的工作流程、证据、独立检查和最佳实践，以改善他们的补丁卫生。在我们的初步评估中，regression-hunt 产生的误报发现比被提示“审查 PR 是否有回归”的基线 Codex 智能体少 25%。
标准化补丁流程
我们的9 月文章报告了我们部分 Patch the Planet 补丁引入的回归。自那以后，我们审查了由 Trail of Bits 工程师编写并由维护者合并到上游的每一个补丁。审查确认了已合并的 130 多个 PR 中的 21 个回归：16 个功能性问题、1 个性能问题和 4 个构建/测试问题。没有一个破坏了安全防护。
（“回归”指的是由某项改动引入的新缺陷，它破坏了真实用户或攻击者可达路径上此前正确且受支持的行为。）
对于每个补丁，一个智能体会查找潜在的回归，在改动前后用概念验证（PoC）运行确认每一个回归，然后将结果交给工程师审查。
审查过程噪声很大：如今漏洞披露的速度和规模前所未有，要让修补跟上节奏，业界需要提高信噪比。单次运行中，58 个候选中确认了 21 个回归（约 36% 精确率）。但由于智能体采取多种不同方法并得出不同结果，每次运行都会产生更多需要人工筛选的候选。
这让我们得出两个结论：
- 要减少引入的回归，我们需要一种标准化的补丁编写方式，每次都应用相同的检查。
- 要捕获我们仍然引入的回归，我们需要一种标准化的检查方式，并明文规定什么算作回归。
将两个步骤标准化还能让每次运行可重复、可比较。没有固定的检查清单能捕获所有回归，因此我们收集工程师修补会话中的智能体轨迹，并用早期版本未能通过的任务来为下一个版本做基准测试（图 1）。
我们如何设计插件
我们用两个主要来源来指导插件设计：对我们在上游合并的每个补丁的审查，以及工程师用来编写这些补丁的数千次 Codex 会话。
这引出了塑造我们 patching-bugs 和 regression-hunt 插件的四项原则：
- 用尽可能少的文字给出有主见的指导。我们给智能体很大的自由度，只记录 Trail of Bits 对什么是好补丁、什么是真正回归的判断。目标是用尽可能少的指导将智能体引向期望的结果。
- 模块化步骤。你不必端到端运行任一插件，因为两者都提供多项技能，可以串联使用，也可以单独使用。
- 严格的输入和输出模式。每一步都接收并返回一个定义好的模式，其中包含声明、代码修订、所需检查、原始证据和未决问题。固定模式减少了运行间的差异，并让每一步都能验证上一步的工作，而不是信任其摘要。
- 每个声明都有实时概念验证。每个结论都依赖于针对实时部署运行的 PoC：一个已构建、正在运行的项目实例，通过真实用户会使用的接口访问。在复现 bug、证明修复以及确认回归时，如果某个步骤无法产出实时 PoC，其结果就是不确定的。
regression-hunt 降低了误报率
regression-hunt 插件（图 2）：
- 枚举 候选回归通过追踪变更代码（diff）经由其调用方到达其真实接口。
- 复现每个候选回归在系统的实时部署上。
- 重放在实时部署上，将 PoC 重放于全新上下文的智能体。
- 判定前面所有步骤的结果，以验证该证明是否满足回归的要求。
除了上述四项原则外，还有两个对插件至关重要的核心方面：
- 定义回归：该插件对什么是回归、更重要的是什么不是回归有强烈的观点。举证责任落在智能体身上（特别是在“裁决智能体”步骤中），以证明有足够的证据表明疑似回归不是误报、不完整的修复、潜在 bug、既有 bug 等等。只有当所有这些关卡都通过时，插件才会报告回归。
- 纳入威胁模型：如果存在威胁模型，编排器会刻意将该文档作为全局上下文的一部分传递给每个独立的智能体步骤。这是为了要求每个步骤/智能体在得出结论之前回顾威胁模型。
我们对已合并 PR 的审查产出了一组 21 个已确认的回归，可用于评估 regression-hunt。我们使用完整集合将插件与一个被提示“审查 PR 中的回归”的基线 Codex 智能体进行比较。
在所有这些运行中，regression-hunt 产生的误报比基线少 25%，置信区间为 95%，范围为 14% 到 38%。其严格的证据要求也导致一些已知回归被归类为边缘情况：该插件识别出可能的回归，但未能收集到足够证据予以确认。因此，误报更少的同时，也带来了权衡：它能够有把握地报告的已知回归数量受到影响。
接下来，我们将调查这些案例为何仍处于边缘状态，并改进插件收集证据的策略。我们的目标是确认更多真实回归，同时在证据仍不充分时向维护者提供更清晰的信息。
patching-bugs 汇集了来自数千次智能体会话的最佳实践
patching-bugs 插件是对我们通过分析 Trail of Bits 工程师数千次 Codex 会话所总结出的全部最佳实践的提炼（图 3）。除了更传统的能力（例如在实时部署上复现和独立的对抗性审查）之外，该插件还强调：
- 三臂证明：该证明针对三份规格运行相同的复现：原始代码必须失败，打补丁后的代码必须通过，而完整回退后必须再次失败。通过移除补丁让缺陷重新出现，这提供了更强的证据，证明是补丁——而非无关的环境或测试变更——真正修复了该缺陷。
- 不变量引导的修复：补丁尝试修复被违反的底层安全不变量，而不是修复具体的缺陷。这有助于让补丁泛化到同一类缺陷的可能变体。
- 纳入回归分析：该插件强制要求运行 regression-hunt，以确保任何补丁都经过相同的标准流水线来检查错误。
插件的下一步
patching-bugs 和 regression-hunt 都将继续演进。我们的工程师目前正在他们的 Patch the Planet 工作中使用它们，我们也在收集关于它们如何被使用、哪些有效、哪些无效的数据。这些数据，连同更好的评估，将塑造下一个版本的能力：
- 评估 patching-bugs。我们正在构建一项评估，用来衡量插件的补丁是否修复了所报告的 bug 及其变体，且没有引入回归。
- 从智能体轨迹中学习。我们正在分析来自工程师会话的第一批轨迹级数据。它将显示 Codex 是否遵循每一步所需的规则和定义、跳过了哪些步骤，以及它的证据在哪里最薄弱。
- 让插件更具可配置性。patching-bugs 已经会读取项目自身的补丁指南（稍后会详细说明）。接下来，我们希望维护者能够选择是否最小化补丁集——或者，当更广泛的覆盖范围比误报更有价值时，放宽 regression-hunt 的规则以呈现更多候选。
这些插件编码了我们发现的、让智能体正确修补 bug 的最佳实践，而且当你告诉它们你的项目如何运作时，它们会表现得更好。
当你输入两类项目知识时，这些插件效果最佳：
- 一份
THREAT_MODEL.md，它告诉智能体什么算作漏洞或回归。regression-hunt 插件会把它传递给每一步，因此每个智能体都必须对照该文件检查自己的结论。它应定义以下内容：其受损会造成影响的资产、信任边界、访问控制、受支持的配置、关于什么算或不算漏洞的规范，以及一份有效 bug 报告所需的证据（示例）。 - 一份
PATCHING_GUIDELINES.md（或AGENTS.md），它告诉智能体和 patching-bugs 你的项目希望如何编写修复。它应概述如何构建和测试项目、修复应该多大、修复应该放在哪里、如何呈现提议的更改，以及回归测试必须证明什么（示例）。
在我们与 GPAC 合作的 Patch the Planet 工作中，我们的工程师编写了一份威胁模型和一份项目特定的补丁技能，其中记录了 GPAC 的维护者希望如何复现 bug、修复需要什么证据，以及补丁必须保留什么。Liboqs和validator.js也已按照我们的指南发布了威胁模型。
这些文件对你的项目、代码约定和运作方式越全面、越具体，你得到的输出就越好。
业界需要关注修补
随着 AI 加速发现 bug，我们需要同样迅速地把这些发现转化为可靠的修复。解决方案需要在速度和质量之间取得平衡：智能体需要理解一份报告，判断需要改动什么，并检查补丁是否修复了问题且没有引入回归。我们的 patching-bugs 和 regression-hunt 插件把我们从 Patch the Planet 中学到的东西带入这一工作流，帮助维护者从一份 bug 报告推进到一个他们可以自信审查并发布的补丁。
安装patching-bugs和regression-hunt，添加一个THREAT_MODEL.md和一个PATCHING_GUIDELINES.md到你的仓库，并让它们在你下一份 bug 报告上发挥作用。把项目的上下文提供给这些工具，这样它们就能帮你聚焦正确的修复并更快地验证它。然后分享你的反馈，包括关于我们的默认设置哪些地方不适合你项目的意见。这些真实案例将帮助我们构建下一个版本。