AgentSZZ: Teaching the LLM Agent to Play Detective with Bug-Inducing Commits

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

背景：
SZZ 算法是软件工程中识别“缺陷引入提交”（Bug-Inducing Commits, BIC）的主导技术，广泛应用于缺陷预测、漏洞分析和安全代码生成等任务。其核心逻辑是通过 git blame 追踪修复提交（Bug-Fixing Commit, BFC）中被修改或删除的代码行，回溯到最后一次修改这些行的提交。

现有挑战与局限性：
尽管已有多种变体（如 AG-SZZ, LLM4SZZ 等），但在开发者标注的数据集上性能仍有瓶颈（例如在 Linux 内核数据集上召回率仅为 0.552）。主要局限性包括：

1. 过度依赖 git blame： 传统方法局限于同一文件内的行级变更追踪，无法处理以下两种常见场景：
   • 幽灵提交 (Ghost Commits)： 修复提交中没有删除或修改任何代码行（如仅修改配置或注释），导致 blame 无法追踪。
   • 跨文件提交 (Cross-file Cases)： 缺陷引入的提交位于与修复提交完全不同的文件中。
   • 研究表明，Linux 内核中近四分之一的 BIC 因上述原因在基于 blame 的方法中本质上是“不可追踪”的。
2. 固定流水线限制： 现有的 SOTA 方法（如 LLM4SZZ）通常遵循固定的静态流水线，缺乏迭代推理和探索能力。相比之下，人类开发者在调试时会使用多种工具（如 git log, git grep）进行交互式、多步骤的信息搜集和回溯。
3. Agent 应用的挑战： 虽然基于 Agent 的方法适合模拟人类探索，但通用 Agent（如 mini-SWE-Agent）在特定任务中表现不佳，面临工具选择困难、缺乏领域指导以及工具输出导致 Token 消耗过大等问题。

2. 方法论 (Methodology: AgentSZZ)

作者提出了 AgentSZZ，一个基于大语言模型（LLM）Agent 的框架，旨在模拟侦探式的交互式调查过程，以识别 BIC。

核心架构

AgentSZZ 的工作流分为三个阶段（如图 1 所示）：

1. 预处理 (Preprocessing)： 提取修复提交的元数据、Diff 信息，去除泄露 BIC 的信息（如 Fixes 标签），并设定搜索的时间边界（修复日期之前）。
2. ReAct 调查循环 (ReAct Investigation Loop)：
   • 采用 ReAct 范式（Reasoning + Acting），Agent 在最多 15 个交互回合内进行迭代。
   • 观察 (Observe)： 调用工具获取仓库信息。
   • 推理 (Reason)： 结合领域知识分析证据，判断候选提交是否为 BIC。
   • 行动 (Act)： 决定下一步使用哪个工具及参数。
3. 输出 (Output)： 生成结构化的 BIC 哈希值、置信度及推理依据。

关键组件设计

A. 任务特定工具 (Task-Specific Tools)
为了限制 Agent 的搜索空间并提高效率，设计了 5 个封装好的 Git 工具，而非直接暴露原始 Git 命令：

1. git_blame：追踪特定文件行的归属（默认入口）。
2. git_show：获取提交消息和 Diff，用于语义分类（区分重构与缺陷引入）。
3. git_log_s (Pickaxe)：搜索添加/删除特定字符串的提交，支持跨文件追踪。
4. git_log_func：追踪特定函数的历史变更。
5. git_grep：在特定提交快照中搜索代码定义和调用点。
   这些工具支持作用域参数（如行范围、文件过滤、时间边界），使查询更精准。

B. 领域知识 (Domain Knowledge)
将领域知识编码到 Prompt 中，指导 Agent 的调查策略：

• 调查流程： 默认从 git blame 开始；若遇到幽灵提交，则尝试追踪上下文行；若遇到跨文件问题，则切换至 git_log_s 或 git_grep。
• 候选分析： 区分“非语义变更”（如重构、合并）和“语义引入”。对于重构，指导 Agent 穿透（penetrate）到父提交继续追踪。
• 因果确认： 使用反事实启发式（“如果该提交不存在，Bug 是否还会存在？”）来验证因果关系。

C. 结构化上下文压缩 (Structured Context Compression)
为解决多轮交互中 Token 消耗过大的问题，设计了三层压缩机制：

1. 搜索边界强制： 自动将时间搜索工具的上限设为修复日期。
2. 缓存去重与格式化： 缓存重复查询结果；将冗长的 Git 输出（如 porcelain 格式）转换为简洁的 LLM 友好格式，并截断元数据（如 Signed-off-by）。
3. 结构化提取： 当输出超过阈值时，根据工具类型进行确定性提取（如 git_show 仅保留 +/-/@@ 标记和文件头，git_blame 去重提交哈希等）。
   效果：在不显著影响效果的前提下，减少了超过 30% 的 Token 消耗。

3. 主要贡献 (Key Contributions)

1. 提出 AgentSZZ 框架： 首个利用 LLM Agent 进行交互式仓库探索以识别 BIC 的框架，突破了传统 SZZ 算法仅依赖 git blame 的局限。
2. 设计专用工具链与领域知识： 设计了 5 个针对 BIC 识别优化的工具，并编码了领域启发式规则，使 Agent 具备处理跨文件和幽灵提交的能力。
3. 引入上下文压缩模块： 显著提高了多轮推理的效率，降低了 Token 成本。
4. 广泛的实验验证： 在三个主流数据集（Linux, GitHub, Apache）上进行了全面评估，证明了其优越性。

4. 实验结果 (Results)

实验在三个数据集（DS_LINUX, DS_GITHUB, DS_APACHE）上进行，对比了 11 种基线方法（包括传统 SZZ 变体和 LLM4SZZ）。

• 整体性能 (RQ1)：

  • AgentSZZ 在所有数据集上均取得了最高的 F1 分数 和 召回率 (Recall)。
  • 相比 SOTA 方法 LLM4SZZ，F1 分数提升了 15.4% - 27.2%。
  • 即使使用相同的骨干模型（GPT-5-mini），AgentSZZ 仍比 LLM4SZZ 提升显著，证明性能提升源于 Agent 架构而非模型本身。
  • 相比通用 Agent (mini-SWE-Agent)，AgentSZZ 表现优异，后者因缺乏聚焦探索导致 F1 极低。

• 效率分析 (RQ2)：

  • AgentSZZ 平均仅需 5.7 个交互回合，而 LLM4SZZ 需 11.2 回合。
  • 虽然总 Token 数略高于 LLM4SZZ，但每回合的信息密度更高。
  • 相比 mini-SWE-Agent，AgentSZZ 将运行时间减少了 4.7 倍，Token 消耗减少了 9.5 倍，成本降低了 3.9 倍。

• 消融实验 (RQ3)：

  • 移除工具： 性能崩溃（F1 降至接近 0），证明任务特定工具是核心。
  • 移除领域知识： 召回率显著下降，证明领域指导对探索方向至关重要。
  • 移除压缩： Token 消耗增加 33.6%，成本增加 35.7%，但对 F1 影响微乎其微。

• 挑战性场景 (RQ4)：

  • 跨文件 (Cross-file)： 召回率提升高达 300%（GitHub 数据集）。
  • 幽灵提交 (Ghost)： 召回率提升高达 60%。
  • 这证明了 AgentSZZ 能有效解决传统方法无法处理的“不可追踪”场景。

5. 意义与结论 (Significance)

• 范式转变： 将 BIC 识别从“静态流水线”转变为“动态交互式探索”，更贴近人类开发者的调试逻辑。
• 解决核心痛点： 有效突破了 git blame 在跨文件和幽灵提交场景下的根本性局限。
• 实用价值： 通过工具抽象和上下文压缩，在保持高准确率的同时实现了可接受的推理成本和延迟，具备实际部署潜力。
• 未来方向： 论文指出目前的失败模式主要是“归因错误”（在多个合理提交中选错），未来可结合执行验证（Execution-based validation）或更细粒度的因果推理来进一步提升精度，并探索支持多 BIC 识别。

总结： AgentSZZ 通过结合 LLM 的推理能力、精心设计的领域工具以及高效的上下文管理，成功地将软件缺陷溯源任务提升到了一个新的水平，特别是在处理复杂、非线性的代码变更历史方面展现了巨大的潜力。