SWE-Trail：让历史轨迹指导代码智能体训练数据采集

导语

代码智能体解决仓库问题时，通常要经历定位文件、阅读代码、修改实现、运行测试和反复调试等一连串步骤。这些完整的操作轨迹，已经成为训练和后训练代码模型的重要数据来源。问题在于，轨迹采集方式本身会影响模型最终学到什么。

从“多采样”到“有方向地采集”

常见做法是针对同一个 issue 独立运行智能体多次，再从结果中筛选或整理数据。随着采样次数增加，后续轨迹容易重复早期路径，新增信息不断减少。直觉上，早期轨迹可以帮助后续采集找到更有价值的探索方向，但如果把这些历史轨迹直接作为提示提供给智能体，模型训练时就可能依赖测试阶段不存在的额外建议，形成训练—测试不匹配。

SWE-Trail的核心取舍是：让历史指导“去哪里采集”，而不是指导智能体“具体怎么做”。在一次新的 rollout 中，采集器会分析已有轨迹，寻找一个可能仍值得探索的状态或检查点。随后，智能体只使用自己在正常运行时能够看到的上下文，提出若干候选下一步动作。SWE-Trail再从同一检查点短暂执行这些候选路线，评估哪条路径更值得继续，最终保留并延展相应轨迹。

核心要点

• 历史轨迹被放在采集器外部，不进入智能体上下文。
• 采集器负责分配探索预算，智能体负责生成代码操作和推理过程。
• 候选动作从同一状态出发进行比较，减少盲目重复采样。
• 方法评估的不是单次轨迹数量，而是用这些轨迹训练学生模型后的实际解决能力。

实验结果与意义

论文使用由采集轨迹训练的124B学生模型进行评估。相较独立采样，SWE-Trail在SWE-bench Multilingual上的平均解决率提升2.33个百分点，在SWE-bench Pro上提升1.60个百分点。一个重要的对照是：不使用历史信息、但保留相同采集流程时，虽然得到的已解决轨迹更多，在Multilingual上的提升只有0.11个百分点。这表明收益主要来自历史引导本身，而不是采集流程的机械变化。

这项工作把代码智能体数据构建中的关注点，从“再生成更多轨迹”转向“把有限预算投入到更有信息量的状态”。同时，历史只影响数据收集策略，不改变智能体在训练样本中的可见条件，有助于缓解额外提示造成的分布偏移。它并不意味着所有重复探索都没有价值，也没有证明该策略适用于所有任务；但对于步骤长、分支多、采样成本高的仓库修复任务，SWE-Trail提供了一种兼顾探索效率与部署一致性的思路。

来源：Hugging Face Daily Papers