自动化漏洞修复：从基于模板的方法到AI代理的演变

译者 | 晶颜

审校 | 重楼

自动化漏洞修复已经从简单的基于模板的方法发展到由LLM、代理、无代理和RAG范例驱动的复杂AI系统。

如果你有软件开发经验，就会知道调试通常是工作中最耗时且最令人沮丧的部分。试想一下，如果人工智能可以帮你处理这些烦人的漏洞呢？

自动化程序修复（Automated Program Repair，APR）的最新进展使这一目标日益成为现实。接下来，就让我们来探索一下这项技术是如何发展的，以及它的发展方向吧。

基础：传统的漏洞修复方法

早期的自动化漏洞修复方法依赖于相对简单的原则。像GenProg这样的系统就是应用预定义的转换规则来修复常见的模式，比如空指针检查或数组边界验证。虽然这种方法在当时是创新之举，但在处理复杂的代码库时，它很快就达到了极限。

1 # Example of a simple template-based fix
2 def fix_array_bounds(code):
3 # Look for array access patterns
4 pattern = r'(\w+)\[(\w+)\]'
5 
6 # Add bounds check
7 replacement = r'(\2 < len(\1) ? \1[\2] : null)'
8 
9 return re.sub(pattern, replacement, code)
1.
2.
3.
4.
5.
6.
7.
8.
9.

总体来说，这些早期基于模板的系统面临着下述重大挑战：

• 有限的灵活性。它们只能解决与预定义模式匹配的错误。
• 计算成本过高。基于约束的方法通常要运行数小时才能生成补丁。
• 薄弱的适应性。它们努力在大型动态代码库中处理新颖或复杂的问题。

当Facebook试图为它们的React代码库实现基于模板的修复时，系统在框架的组件生命周期模式和状态管理复杂性方面遇到了困难。类似地，当在Apache Commons库上使用时，基于约束的方法通常要运行数小时才能为中等大小的函数生成补丁。

LLM驱动的修复兴起

大型语言模型（LLM）的引入改变了自动化漏洞修复的可能性。像GPT-4、Code Llama、DeepSeek Coder和Qwen2.5 Coder这样的模型不只是修补语法错误，它们还能理解代码的语义意图，并在复杂的代码库中生成上下文合适的修复。

概括来看，这些模型带来了下述多种功能：

• 上下文感知推理。它们理解代码不同部分之间的关系。
• 自然语言理解。它们弥合了技术问题陈述和可操作修复之间的缺口。
• 从模式中不断学习。它们从大量的代码中识别常见的漏洞模式。

具体而言，每种模型都有其独特的优势：

现代APR系统的三个范式

基于代理的系统

基于代理的系统通过多代理协作利用LLM，每个代理专注于一个特定的角色，如故障定位、语义分析或验证。这些系统擅长通过任务专门化和增强协作来解决复杂的调试挑战。

在此类系统中，最具创新性的实现包括以下几种：

• SWE-Agent——为大规模存储库调试而设计，它可以处理跨存储库依赖关系；
• CODEAGENT——集成LLM与外部静态分析工具，优化协同调试任务；
• AgentCoder——软件工程任务的端到端模块化解决方案；
• SWE-Search——采用蒙特卡罗树搜索（MCTS）进行自适应路径探索。

其中，SWE-Search具有自适应路径探索能力，是一项重大进步。它由一个用于探索的SWE代理、一个用于迭代反馈的Value代理和一个用于协作决策的Discriminator代理组成。与缺乏MCTS的标准代理相比，该方法的相对改善率为23%。

无代理系统

无代理系统通过消除多代理协调开销来优化APR。它们通过一个简单的“三阶段”模式来运作：

• 层次定位。首先，确定有问题的文件，然后放大类或函数，最后确定特定的代码行；
• 上下文修复。生成具有适当代码更改的潜在补丁；
• 验证。使用重现测试、回归测试和重新排序方法测试补丁。

DeepSeek Coder凭借其存储库级别的预训练方法在这一类别中脱颖而出。与之前在文件级别操作的方法不同，DeepSeek使用存储库级别的预训练，通过创新的依赖解析算法更好地理解跨文件关系和项目结构。

该模型利用了一种平衡的方法，在中间填充训练中使用50%的前缀-后缀-中间比例，提高了代码完成和生成性能。结果不言自明——DeepSeek-Coder-Base-33B在首次发布时，在HumanEval上的平均准确率达到50.3%，在MBPP基准上的平均准确率达到66.0%。

RAG系统

像CodeRAG这样的检索增强生成（RAG）系统将检索机制与基于LLM的代码生成混合在一起。这些系统结合了来自GitHub存储库、文档和编程论坛的上下文信息，以支持修复过程。

这种系统的主要特点包括以下几点：

• 上下文检索：从外部知识来源中提取相关信息；
• 自适应调试：支持涉及领域专家或外部API集成的修复；
• 基于执行的验证：通过受控的测试环境提供功能正确性保证。

当在SWE基准上进行评估时，无代理系统的成功率达到50.8%，优于基于代理的方法（33.6%）和检索增强方法（30.7%）。然而，每个范例都有特定的优势，这取决于用例和存储库的复杂性。

新一代APR系统性能评估

评估APR系统需要跨多个维度测量性能：漏洞修复的准确性、效率、可扩展性、代码质量和适应性。以下是三个关键基准：

SWE -bench：全方位的基准

SWE -bench在12个流行的Python存储库中测试真实GitHub缺陷的APR功能。它创建了具有解决问题任务的真实世界场景，这些任务需要深入的分析和代码编辑中的高精度。解决方案是使用个别存储库中的特定测试用例进行评估，以获得客观评级。

CodeAgentBench：专注于多代理框架

作为SWE -bench的扩展，CodeAgentBench的目标主要是多代理框架和存储库级调试功能。它主要从以下方面评估系统：

• 动态工具集成——能够与静态分析工具和运行时集成；
• 代理协作——任务专门化和代理间通信；
• 覆盖范围——复杂的测试用例和多文件挑战。

CodeRAG-Bench：测试检索增强方法

CodeRAG-Bench专门评估集成了上下文检索和生成管道的系统。它通过测量系统如何整合来自不同来源（如GitHub discussion和文档）的信息来测试修复复杂漏洞的适应性。

当前的限制和挑战

尽管取得了令人瞩目的进步，但APR系统仍然面临以下重大障碍：

• 有限的上下文窗口——处理大型代码库（数千个文件）仍然具有挑战性；
• 准确性问题——由于缺乏准确的上下文敏感代码生成，多行或多文件编辑有更高的错误率；
• 计算费用——使大规模、实时调试变得困难；
• 验证差距——当前的基准测试不能完全反映现实世界的复杂性。

现实世界的应用程序

将APR集成到行业工作流程中已经显示出显著的好处，具体如下所示：

• 自动化版本管理——在升级期间检测和修复兼容性问题；
• 安全漏洞修复——模式识别和上下文感知分析，以加快修补速度；
• 测试生成——为未覆盖的代码路径创建单元测试，并为复杂工作流创建集成测试。

正在实施APR工具的公司汇报了下述结果：

• 与手动调试相比，修复常见问题的时间减少了60%；
• 测试覆盖率增加40%；
• 减少30%的回归漏洞。

诸多大型企业都正在采取行动：

• 谷歌的Gemini Code Assist报告称，常规开发人员的任务时间减少了40%；
• 微软的IntelliCode提供了上下文感知的代码建议；
• Facebook的SapFix自动修复生产环境中的漏洞。

原文标题：Automated Bug Fixing: From Templates to AI Agents，作者：Meghana Puvvadi、Santhosh Vijayabaskar