HAFixAgent: History-Aware Program Repair Agent

1. 研究背景与问题 (Problem)

背景：
自动程序修复（APR）领域正从传统的启发式、约束和基于模板的方法，迅速转向基于大语言模型（LLM）和智能体（Agent）的系统。然而，现有的大多数基于 LLM 的修复系统（如 RepairAgent, SWE-agent）主要依赖当前的代码快照（Snapshot）作为上下文，往往忽略了软件仓库的历史演化信息。

核心问题：

1. 复杂漏洞修复困难： 现有的 LLM 代理在处理跨多行、多位置（Multi-hunk）的复杂漏洞时表现不佳，因为它们缺乏对代码演化历史、开发者意图和共演化模式的理解。
2. 历史信息的可用性未知： 虽然先前的研究（如 HAFix）表明利用 git blame 提取的历史信息有助于修复单行漏洞，但在大规模、复杂的代理修复系统中，这种历史信息是否依然有效？是否会因为过多的噪声（多个提交记录）而淹没代理的注意力？
3. 鲁棒性挑战： 在实际应用中，漏洞定位（Fault Localization, FL）往往不完美。当定位出现偏差时，基于历史信息的修复系统是否依然稳健？

2. 方法论 (Methodology)

作者提出了 HAFixAgent，这是一个**历史感知（History-Aware）**的程序修复智能体。其核心设计理念是将基于仓库的启发式信息注入到智能体的自主执行循环中。

2.1 核心架构

HAFixAgent 采用轻量级的智能体架构，包含三个主要模块：

1. 上下文构建器 (Context Builder)：
   • 元数据上下文： 包含人工编写的漏洞报告、失败的测试用例和漏洞定位信息。
   • 历史提取器 (History Extractor)： 利用 git blame 工具定位修改或删除的漏洞行对应的提交记录（Blame Commit）。
     • 可 blame 漏洞： 直接获取修改行的提交。
     • 不可 blame 漏洞（Fallback）： 对于纯新增代码（无删除/修改），提取插入点前 5 行内最近的可执行代码行的提交记录。
     • 多提交处理： 如果一个漏洞涉及多个提交，使用 LLM 作为裁判（LLM-as-a-judge）选择最相关的一个。
   • 历史上下文注入： 从选定的提交中提取三种启发式信息并注入到 Prompt 中：
     • fn_all: 提交中所有共变函数的名称（捕捉结构共演化）。
     • fn_pair: 包含漏洞行的函数在提交前后的代码快照（捕捉语义演化）。
     • fl_diff: 提交中的文件级差异补丁（捕捉细粒度编辑模式）。
2. 智能体执行循环 (Agent Execution Loop)：
   • 基于 ReAct 范式（Reason-Act-Feedback）。
   • 智能体接收当前状态（包含历史上下文），生成 Bash 命令作为行动（如搜索、编辑、编译、测试）。
   • 在隔离的沙箱环境中执行命令，收集输出反馈，判断是否终止或继续迭代。
3. 工具集 (Tools)：
   • 使用标准的 Bash 工具（grep, sed, find, head/tail）和项目特定命令（compile, test）。
   • 设计原则是最小化且模块化，避免复杂的工具交互，确保性能提升主要归因于历史上下文的质量。

2.2 实验设置

• 数据集： 854 个 Defects4J (Java) 漏洞和 501 个 BugsInPy (Python) 漏洞。
• 基线对比： 在相同的大模型（DeepSeek-V3.2-Exp）下复现了最先进的基线：
  • RepairAgent: 基于 API 工具的自主代理。
  • BIRCH-feedback: 专注于多块（Multi-hunk）修复的反馈机制。
• 评估指标： Plausible@1（生成的补丁是否通过所有测试）、修复数量、成本（Token 消耗）、步骤数、以及在噪声漏洞定位下的鲁棒性。

3. 主要贡献 (Key Contributions)

1. HAFixAgent 的设计与实现： 提出了一种新颖的历史感知代理修复方法，将仓库历史（Blame-derived heuristics）深度集成到智能体的决策循环中，而非仅作为静态上下文。
2. 大规模实证研究： 在 Java (Defects4J) 和 Python (BugsInPy) 两个主流基准上进行了全面评估，证明了历史信息的广泛可用性（71.1% - 87.4% 的漏洞可获取历史）及其在不同语言中的分布差异。
3. 三种互补的历史启发式： 定义了三种从提交中提取信息的策略（函数名共演化、函数前后快照、文件级差异），并证明它们解决了不同子集的漏洞，具有互补性。
4. 鲁棒性验证： 证明了在漏洞定位不完美（存在行偏移噪声）的情况下，历史感知系统比非历史系统具有更强的韧性。

4. 关键结果 (Results)

4.1 有效性 (Effectiveness)

• 超越基线： 在 Defects4J 上，HAFixAgent 比 RepairAgent 高出 56.6%，比 BIRCH-feedback 高出 47.1%。
• 历史信息的增益：
  • Defects4J: 引入历史上下文后，修复率提升了 4.4% (从 522 到 545)。
  • BugsInPy: 提升更为显著，达到 38.6% (从 272 到 377)。
  • 复杂漏洞： 在单文件多块（SFMH）漏洞上，BugsInPy 的修复率提升了 190.7% (从 54 到 157)。
• 互补性： 三种历史启发式方法（fn_all, fn_pair, fl_diff）各自修复了独特的漏洞子集。联合使用所有历史配置比仅使用非历史配置多修复了 31.0% (Defects4J) 和 70.2% (BugsInPy) 的漏洞。

4.2 效率与成本 (Efficiency)

• 成本未显著增加： 引入历史上下文并没有显著增加智能体的步骤数或 Token 成本。在某些复杂场景下（如 BugsInPy 的 SFMH），历史上下文甚至帮助智能体更快收敛，降低了成本。
• 步骤控制： 大多数修复在 50 步限制内完成，复杂漏洞平均需要 26-34 步。

4.3 鲁棒性 (Robustness)

• 抗噪声能力： 在模拟漏洞定位噪声（行偏移 +1/+3/+5）的实验中，历史感知系统表现出显著的韧性。
  • 在 SFMH 漏洞上，当定位偏移 +5 行时，非历史系统的修复率崩溃至 0%，而历史感知系统仍保持了 40% - 56% 的成功率。
  • 这表明历史信息充当了“安全网”，在定位不准时提供了额外的上下文线索。

5. 意义与结论 (Significance & Conclusion)

• 范式转变： 该研究证明了在基于代理的 APR 系统中，仓库历史（Repository History） 是一个被低估但极具价值的上下文来源。它不仅能提升修复成功率，还能增强系统在现实世界不完美条件下的鲁棒性。
• 可扩展性： 研究结果表明，即使面对复杂的多块（Multi-hunk）漏洞，精心设计的启发式历史提取（如 git blame）依然有效，并未因信息过载而失效。
• 未来方向： 论文建议未来可以探索结合多个提交记录（针对多提交场景）以及构建多智能体架构（History Agent, Fixer Agent, Reviewer Agent）来进一步处理更复杂的跨文件漏洞。

总结： HAFixAgent 通过巧妙地将软件仓库的演化历史融入 LLM 智能体的工作流，显著提升了自动程序修复在复杂场景下的能力，同时保持了成本效益和鲁棒性，为下一代 AI 辅助软件开发工具提供了重要的设计思路。