今天我们发布了patching-bugs和regression-hunt这两个插件，让工程师可以将补丁开发和回归检查委派给代理。我们的patching-bugs插件重新生成已报告的bug，开发修复并进行测试。regression-hunt插件检查任何更改是否破坏以前正常工作和被支持的行为。工程师可以指导工作并审查其结果；维护者可以提供自己的安全假设和补丁要求，以便代理在项目规则内工作。我们通过Patch the Planet项目构建了patching-bugs和regression-hunt，这是我们与OpenAI的联合倡议，我们共同为广泛使用的开源项目编写了数百个安全补丁。受到在Scapy等项目上取得的重大成功的激励，我们的插件基于我们分析的合并补丁和数千次工程师Codex会话。插件为维护者提供了一个结构化的工作流程、证据、独立检查和最佳实践，以改善他们的补丁卫生。在我们的初步评估中，regression-hunt产生的虚假积极结果比基线Codex代理在“审查PR的回归”提示下产生的少25%。标准化补丁过程 我们九月的帖子报告了一些我们Patch the Planet补丁引入的回归。从那时起，我们审查了所有Trail of Bits工程师编写并维护者合并的补丁。审查确认了超过130个合并的PR中有21个回归：16个功能性，1个性能，和4个构建/测试。没有一个破坏安全保护。（“回归”是指变更引入的新的缺陷，破坏了沿着真实用户或攻击者可以达到的路径以前正确和被支持的行为。）对于每个补丁，代理会查找潜在的回归，在变更前后通过概念证明（PoC）运行确认每一个，然后将结果传递给工程师进行审查。审查是嘈杂的：今天的bug披露以空前的速度和规模到达，为了跟上补丁的步伐，行业需要提高其信噪比。21个确认的回归是在一次运行中的58个候选者中识别出来的（~36% 精度）。但由于代理采用多种不同的方法并得出不同的结果，每次运行都会生成更多候选者以供手动分类。这使我们得出了两个结论：为了引入更少的回归，我们需要标准化补丁的编写方式，每次应用相同的检查。为了捕捉我们仍然引入的回归，我们需要标准化检查的方法，并为什么算作回归制定书面规则。标准化这两个步骤也使每次运行都是可重复和可比较的。没有固定的清单能够捕获每个回归，因此我们从工程师的补丁会话中收集代理轨迹，并利用早期版本未能基准的任务为下一个版本基准（见图1）。 图1：生成和评估补丁的反馈循环。 我们是如何设计插件的 我们使用两个主要来源来指导插件的设计：我们合并到上游的每个补丁的审查和我们的工程师为编写这些补丁而使用的数千次Codex会话。这使我们形成了四项原则，塑造了我们的patching-bugs和regression-hunt插件： 尽可能少的字数提供意见指导。我们给予代理广泛的自由，并仅记录Trail of Bits对什么构成良好补丁和真实回归的判断。目标是以最少的指导将代理引导至期望结果。 模块化步骤。您不必端到端运行任一插件，因为它们都提供可以结合使用或独立使用的多种技能。 严格的输入和输出模式。每一步都采用并返回定义的模式，包括声明、代码修订、所需检查、原始证据和开放问题。固定模式减少了运行间的可变性，允许每一步验证之前步骤的工作，而不是信任其摘要。 为每个声明提供实时概念证明。每个结论都依赖于针对实时部署的PoC运行：通过真实用户将使用的接口访问的构建、运行的项目实例。在重现bug、证明修复和确认回归时，如果某一步无法提供实时的PoC，其结果是不确定的。 regression-hunt减少错误积极率 regression-hunt插件（见图2）：通过追踪更改的代码（diff）及其调用者到其真实接口，列举候选回归。在系统的实时部署上重现每个候选回归。在新上下文代理上重播实时部署中的PoC。判断所有先前步骤的结果，以验证证明是否满足回归的要求。 图2：regression-hunt工作流程。除了上述四项原则之外，还有两个对插件至关重要的核心方面： 定义回归：该插件对什么是回归有强烈看法。