大模型自动调试FixAgent修复代码八成九成功案例

“A Unified Debugging Approach via LLM-Based Multi-Agent Synergy”

调试bug，大概是程序员日常中最让人头秃的环节了——没有之一。如今大模型都能自己写代码了，那能不能让它们来帮忙自动debug呢？今天介绍的这篇论文，给出了一个相当亮眼的答案：FixAgent在QuixBugs数据集上正确修复了80个错误中的79个，准确率接近99%。这成绩，确实让人眼前一亮。

论文地址：https://arxiv.org/pdf/2404.17153

摘要

FixAgent是一个利用大语言模型实现自动化调试的框架，专门解决软件中bug的定位、修复和分析问题。目前基于LLM的调试工具普遍面临三大瓶颈：一是错误定位不准会直接拉低修复效果；二是碰上复杂逻辑错误容易翻车；三是常常忽略程序运行的上下文信息。针对这些痛点，FixAgent从经典的“橡皮鸭调试法”中汲取灵感，设计了三个核心策略——LLM Agent专门化与协同、关键变量跟踪、程序上下文理解。实验结果相当亮眼：在QuixBugs数据集上，FixAgent正确修复了80个bug中的79个；在Codeflaws上，它的修复数量也超过了所有对比工具，正确率高达97.26%。

简介

修bug这事儿，时间和金钱的成本都不低，自动化调试工具能大大缓解手动调试的负担。传统的故障定位和自动程序修复方法各有各的问题：要么需要大量人工测试用例，要么在不同的编程语言之间要做大量定制改造，实在不够灵活。

大语言模型可以直接用于自动程序修复，不用预先定义修复模式，这无疑是个好方向。然而，当前基于LLM的调试工具仍然卡在三个老大难问题上：故障定位不够准、复杂逻辑处理不好、忽视程序上下文。

FixAgent就是冲着这几个问题来的。它基于LLM多智能体协同，把橡皮鸭调试法的原则搬到了LLM调试中。

具体来说，FixAgent的设计围绕三个挑战展开：1）缺少有效的协同工作；2）缺少对关键变量的跟踪；3）缺少对程序上下文的理解。对应的，FixAgent也设计了三个核心组件：专业Agent协同、中间变量跟踪、程序上下文构建。

实验数据很能说明问题。FixAgent在两个广泛使用的数据集上全面碾压所有基线方法——它修复了3982个缺陷中的2780个，平均正确率96.5%。在QuixBugs上，它正确修复了80个真实世界错误中的79个，其中还包括10个之前从未被修复过的bug。在Codeflaws上，它比最好的APR基线（AlphaRepair）多修复了24个错误，比最好的LLM对手（GPT4）多修复了586个缺陷。论文还在Codeflaws和新收集的ConDefects数据集（Python和Ja va）上做了大量消融实验，以验证模型在数据泄漏风险下的表现。

背景

故障定位错误

故障定位的问题分两种：定位偏了和定位漏了。不管哪一种，都会严重影响下游的修复效果。目前最先进的故障定位方法准确率仍然很低——在Defects4J V1.2.0上，最厉害的技术也只能达到不到22.3%。

复杂逻辑故障修复

GPT4在LeetCode这类在线编程平台上已经能达到和人类相当的水平。但修复逻辑错误这件事，对LLM来说依然很棘手，很多时候连运行时信息对修复都没什么帮助。

忽略程序上下文

现在的APR工具大多只盯着源代码和测试结果，完全不管重要的程序上下文。举个例子，一个高级APR工具生成的补丁忽略了变量作用域，这种修复根本通不过编译。这个案例充分说明了程序上下文的重要性。编程本质上是解决问题，对实际软件进行上下文感知的调试才是正路。

橡皮鸭调试

橡皮鸭调试法是很经典的方法：开发者把自己的期望和实际实现都讲出来（哪怕是对着一只橡皮鸭），逐行解释代码，从而找到预期与实际之间的差距。基本思路就是把代码拆成片段，然后用自然语言描述它们。

方法

FixAgent是一个基于LLM的统一调试框架，包含三个专门的Agent：分别负责定位错误、生成补丁、以及错误后审查。每个Agent都使用中间变量跟踪设计，并且接受构建好的程序上下文。此外还有一个额外的LLM Agent，专门生成测试输入来缓解过拟合问题。如果生成的补丁不可行，系统会用包含失败信息的反馈来重新采样修复Agent。

专业Agent协同

调试流程由三个LLM Agent按顺序工作：故障定位器负责识别有问题的代码语句，修复生成器负责生成可执行且正确的补丁，后错误分析器负责分析原始代码为什么出错、补丁背后的原理是什么。每个Agent都有自己的角色描述和任务目标，并且依赖上游结果来修正自己的输出。最终的答案包括：故障定位器确定的有问题语句、修复生成器生成的补丁、以及后错误分析器提供的分析。

中间变量跟踪

每个Agent都被要求针对失败的测试用例，跟踪关键的中间变量值，并把它们和预期结果进行比较。Agent必须在回复中明确展示这种跟踪，同时全面解释它如何帮助推导出答案。优先关注那些对程序行为有重大影响的信息——比如核心逻辑执行和状态——这能帮LLM把注意力集中在最可能出问题的部分。这种跟踪设计让LLM能把复杂程序拆解成多个中间状态，并在调试时进行额外计算。更关键的是，它还提高了LLM决策的透明度——我们能清楚地看到Agent是怎么得出答案的，为将来的人机交互埋下了伏笔。

上下文构建

FixAgent从两个维度挖掘程序上下文：需求和依赖关系。首先，对于有详细文档的程序，直接采用程序功能、输入输出格式、精度要求等描述来阐明预期行为。如果程序没有文档但实现了常见算法，则用一个通用LLM（不一定是FixAgent的基础模型）根据算法名称（通常是程序中的函数名）来生成介绍，作为需求描述。

其次，解析有bug程序的依赖关系，提取依赖文件的代码，放在程序顶部。这个操作虽然简单，但效果很好——大多数LLM是左到右处理token的，并且是在文件级代码上训练的，所以先处理相关代码、再处理问题程序，正好对路。这两种策略共同构建了程序的信息上下文。

其他

测试输入生成：除了人工编写的测试用例，FixAgent专门设计了一个额外的Agent Crafter来生成测试用例。提示格式遵循（profile-specification-instruction）。Crafter还会解释测试用例背后的原理，引导自己挖掘多样化的异常输入，鼓励生成较长的测试输入。

反馈支持的重采样：调试过程难免出错。为了减少错误修复，FixAgent采用反馈支持设计：如果生成了不可信的补丁，就重新采样FixAgent获取另一个补丁，并用会话方式把失败的测试信息反馈给模型。这个设计让FixAgent和以前的APR工具保持了一致——它们通常对数千个候选补丁进行采样。最终，使用bug修复分析选出的最佳修复返回给用户。用户也可以请求任何Agent的具体响应，包括相应的回答和解释。

实验

论文围绕三个核心问题展开：

• 问题一：FixAgent与最先进的APR工具和LLM相比，表现如何？
• 问题二：FixAgent在不同LLM上的能力怎样？它对基础模型的提升有多大？
• 问题三：FixAgent的每个设计组件贡献了多少？

实验设置

数据集。FixAgent与其他通用LLM在公共数据库上进行了对比。对比指标包括可行补丁数、正确补丁数和正确率。使用了三个数据集：Codeflaws、QuixBugs和ConDefects。为了节省成本，每个数据集只选择了300个有错误的程序用于对比。

基线：一共对比了16个基线模型，包括10个APR工具和6个基础LLM模型。

问题一

在Codeflaws和QuixBugs上，FixAgent的修复效果全面超过了所有其他自动程序修复方法。在Codeflaws上，它比所有APR方法和LLM都要好。在QuixBugs上，FixAgent修复了7个之前从未被修复过的bug。

问题二

用不同的基础LLM来测试FixAgent的能力，结果显示FixAgent能有效地与不同基础LLM配合，但效果受限于基础模型本身的能力。理论上模型越大效果越好，但FixAgent-deepseek-coder反而优于FixAgent-ChatGPT和FixAgent-Gemini——尽管后两者的模型尺寸更大。原因应该在于DeepSeek-Coder的专业训练数据和目标。

进一步评估FixAgent在Codeflaws上对其基础模型的提升。在所有对比中，FixAgent对GPT4的提升最大——正确修补和合理修补的bug分别增加了33个和35个。总体来看，应用FixAgent平均能比原始LLM提升20%。这种增强非常关键：它以非侵入的方式显著提高了LLM的调试能力，不需要任何重新训练或微调，证明LLM确实能从软件工程原则（比如橡皮鸭调试法）中受益。

问题三

在FixAgent的各个设计中，上下文构建贡献最大。移除上下文后，正确修复的错误减少了122个，凸显了上下文在调试中的重要性——它提供了理解问题领域、推断预期功能、应用适当修复的潜力。这也解释了为什么即使故障定位不完美，语言模型仍然明显优于传统的APR工具。

变量跟踪是第二重要的设计。去掉跟踪会导致可行和正确修补分别减少37个和38个。这是因为LLM在错误诊断和减少推理负荷方面的改进——通过口头表达每个变量的作用和预期行为，LLM更容易指出预期和实际结果之间的差异，从而促进有针对性的修复。结构化解释也减轻了模型的推理负荷。如果用单个Agent替代多Agent协同，同样会减少28个可行和正确的修复。

最不有用的设计是反馈支持的重新采样。虽然额外反馈提供了更多信息，但它扩大了对话窗口，模型有限的注意力必须分配给这些新信息，可能牺牲其他关键细节。这种权衡解释了为什么与独立采样相比，额外反馈并没有显著增强LLM的调试能力。

限制

FixAgent通过优化现有技能，显著提高了多个LLM的调试性能。但它的有效性与基础模型的基本能力紧密相关——FixAgent无法从根本上改变LLM的内在能力，只能在一定范围内优化其现有技能。因此论文选择GPT4作为默认基础模型，因为它在广泛的认知任务中性能领先。

为了缓解过拟合问题，论文引入了一个额外Agent来生成测试输入，但这个Agent无法直接计算相应的预期输出或测试预期结果——这主要是因为LLM的内在概率机制，使得精确提供计算答案很困难。解决这类类似数学推理的问题，是LLM面临的重大挑战之一。FixAgent无法克服它们固有的限制，因此必须引入其他信息（如正确的代码或手动计算的答案）来获得生成输入的输出，形成完整的测试用例。

总结

FixAgent是第一个通过LLM Agent协同实现统一调试框架的方案，以端到端的方式完成故障定位、补丁生成和错误后分析。核心洞察在于：LLM可以从开发者认可的软件工程原则中受益。因此，FixAgent遵循橡皮鸭调试的原则——详细解释代码——来设计新的方法，释放LLM的调试潜力，缓解以往的挑战。在两个广泛使用的数据集上的评估证明，FixAgent优于APR工具和基于LLM的竞争对手；在最近收集的数据集中进行的额外实验（避免数据泄漏）也进一步展示了它在调试上的泛化能力和有效性。代码和生成的补丁已经开放，可供进一步研究和复制。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：大模型自动调试FixAgent修复代码八成九成功案例要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题