技术摘要：TrajSpec —— 基于轨迹引导的缺陷报告规范细化

问题陈述

仓库级自动化程序修复（APR）智能体依赖缺陷报告作为其主要任务规范。然而，标准的缺陷报告通常仅描述观察到的失效症状，而忽略了关键的修复相关信息，例如潜在的失效机制、具体的行为要求以及完整的实现范围。因此，APR 智能体可能会检查无关的代码、推断出错误的逻辑需求，或者生成的补丁仅解决了报告的症状，却未能恢复预期的仓库行为。尽管之前的研究重点在于改进智能体的搜索策略、定位能力或提示词工程，但这些方法通常假设输入的报告提供了一个充分的规范。目前在通过在程序修复过程开始前，从仓库中收集缺失的规范细节来精炼报告的方法方面，仍存在空白。

方法论：TrajSpec

作者提出了 TrajSpec，一种用于仓库支持的规范细化的轨迹引导方法。该系统通过以下流水线处理原始缺陷报告 ($b$) 和修复前仓库快照 ($R_c$)：

1. 未验证轨迹收集：
   TrajSpec 仅使用 $b$ 和 $R_c$ 执行一个轨迹收集智能体。该智能体探索仓库、检查代码并对问题进行推理。至关重要的一点是，此运行过程是未验证的：TrajSpec 不会对此阶段产生的任何候选补丁进行验证。任何候选补丁都会被丢弃，仅保留执行轨迹 ($\tau$) —— 即一个由“思考-行动-观察”元组组成的序列。即使智能体最终生成的补件是错误的，该轨迹仍可作为仓库支持证据的来源。

2. 分层证据抽象：
   原始轨迹通常具有噪声且篇幅冗长。TrajSpec 从 $b$ 和 $\tau$ 中提取候选发现，重点关注三个维度：

   • 失效机制（Failure Mechanism）： 解释症状的源代码行为。
   • 行为要求（Behavioral Requirement）： 应当保持的行为。
   • 实现范围（Implementation Scope）： 涉及的代码位置。

   这些发现被组织成一个具有三个详细层级的层次化表示 ($M$)，每个维度均包含：

   • 高层级（High-level）： 一个候选规范结论。
   • 中层级（Mid-level）： 诊断性推理与关系（例如，代码路径、依赖关系）。
   • 低层级（Low-level）： 具体的仓库观测结果（例如，特定的文件、函数、变量）。

3. 草案生成与基于仓库的评审：
   利用 $b$ 和 $M$，大语言模型（LLM）按照固定的模式（标题、描述、根因、复现步骤、预期行为、观察到的行为）生成一份草拟的精炼报告 ($\hat{b}$)。

   随后，通过一个基于仓库的评审步骤，根据 $R_c$ 对 $\hat{b}$ 进行验证。评审智能体会评估草案中的主张是否得到了 $M$ 及实际源代码的支持。它会移除未经支持的主张，修改不确定的陈述，添加缺失的仓库支持细节，并确保实现范围得到适当的界定。输出结果为最终的精炼报告 ($\hat{b}_f$)，它将作为下游修复智能体的任务规范。

核心贡献

• 形式化定义： 本文将针对仓库级 APR 的缺陷报告增强定义为“仓库支持的规范细化”，旨在明确失效机制、行为要求和实现范围。
• TrajSpec 框架： 引入了一种方法，通过从未验证的轨迹收集运行中提取并层次化组织规范证据，并根据源代码对这些证据进行评审，从而在不假设轨迹中的候选补丁正确的前提下生成精炼报告。
• 全面评估： 在所有 300 个 SWE-Bench Lite 实例上使用 Mini-SWE-Agent V2 进行评估，证明了显著的性能提升。
• 泛化性： 证明了 TrajSpec 的收益可以推广到不同的下游修复智能体（Agentless 和 AutoCodeRover）。
• 组件分析： 消融实验证实，层次化证据表示和基于仓库的评审对于性能提升都至关重要。

评估结果

作者在 300 个 SWE-Bench Lite 实例上对 TrajSpec 进行了评估：

• 主要修复智能体 (Mini-SWE-Agent V2)：

  • 使用 GPT-5-mini 时，Pass@1 从 41.00%（原始报告）提升至 59.67%。
  • 使用 MiniMax M2.5 时，Pass@1 从 54.67% 提升至 64.33%。
  • TrajSpec 在两种设置下均优于基准线 “Agentic-Base”（该基准线虽然使用了轨迹数据，但缺乏层次化抽象和仓库评审）。
  • 改进效果广泛分布在 12 个不同的仓库中，TrajSpec 在扩大修复覆盖范围的同时，几乎保留了之前由原始报告修复的所有实例。

• 跨智能体泛化性 (100 个实例的分层样本)：

  • Agentless： Pass@1 从 41.00% 提升至 71.00%。
  • AutoCodeRover： Pass@1 从 47.00% 提升至 72.00%。

• 消融研究：

  • 移除基于仓库的评审后，Pass@1 从 59.67% 下降至 48.00%。
  • 移除层次化证据表示后，Pass@1 下降至 47.67%。
  • 这证实了结构化证据并针对仓库验证主张对于性能提升是必不可少的。

• 成本分析：

  • 虽然 TrajSpec 会产生额外的报告生成成本（使用 GPT-5-mini 时约为每个实例 $0.083），但它减少了下游修复输入 Token 的使用量约 24%，并降低了修复运行本身的货币成本。相对于显著的收益提升，总体的端到端成本仍然处于较低水平。

重要性与主张

本文声称，TrajSpec 通过解决由于缺陷报告描述不足而导致的“规范问题”，为提升仓库级修复提供了一个极具前景的方向。作者强调：

1. 轨迹的价值超越了补丁生成： 即使是未验证的轨迹，也包含了关于失效机制和代码范围的有价值证据，这些证据可以被抽象和结构化，以优化任务规范。
2. 验证至关重要： 仅仅使用轨迹数据是不够的；层次化结构和基于仓库的评审步骤对于过滤噪声并确保主张植根于修复前代码是必要的。
3. 任务规范非常重要： 改进输入规范（即缺陷报告）与改进修复智能体本身同样重要。TrajSpec 证明，通过为智能体提供可操作的、有仓库支持的上下文，能够一致地提高不同模型和智能体架构的修复性能。

作者保持了谦逊的态度，指出其评估仅限于 SWE-Bench Lite 中的 Python 仓库，且对于其他语言或基准测试的有效性仍有待未来研究。他们同时也承认，虽然精炼后的报告提高了自动化修复指标，但本研究侧重于对 APR 的效用，而非人类感知的报告质量。