FC-SWE：让软件工程智能体从失败补丁中学习

导语

软件工程智能体面对的并不是一次性问答，而是持续阅读代码、调用工具、修改仓库并运行测试的长流程任务。一次补丁没有通过验证，并不意味着任务只能失败；测试输出往往已经暴露了错误位置和修复方向。NVIDIA 团队提出的 FC-SWE，尝试把这种“失败后的再尝试”正式纳入强化学习训练，让智能体不仅学习如何写出补丁，也学习如何根据反馈修正补丁。

核心方法

传统的 GRPO 做法通常是针对同一个 issue 独立生成多条轨迹，执行补丁并比较最终奖励。这种方式可以利用成功与失败的差异，但失败轨迹中的验证信息通常不会作为下一次生成的输入。FC-SWE 将过程改造成由初始尝试和恢复尝试组成的链条：

• 失败条件上下文：补丁验证失败后，系统将仓库恢复到任务初始状态，并把原始 issue、失败补丁以及验证器反馈交给下一次尝试。
• 轨迹局部奖励：每次尝试只保留自己的验证结果。恢复尝试成功时，不会反向把奖励错误地归给此前失败的补丁。
• 主动集合优势估计：同一任务的比较组只包含实际执行过的初始轨迹和恢复轨迹，同时保留失败尝试；没有被触发的轨迹不会被虚构加入比较。

这种设计解决了恢复训练中的两个难点：下一次尝试是否生成取决于前一次结果，而它的输入又取决于前一次执行产生的具体反馈。通过重置仓库，实验还能够区分“利用反馈修复”与“在被污染的代码状态上继续修改”。

实验结果与边界

论文在全部 500 个 SWE-bench Verified 任务上，使用 Qwen3.5-4B 与 SWE-agent 进行实验，并采用验证器辅助的多次尝试协议。FC-SWE 的 Resolved@1 为 41.7%，Resolved@2 为 52.8%；对应的 GRPO 基线分别为 38.9% 和 48.5%。虽然训练阶段每条链最多包含两次尝试，但在测试时给予 11 次尝试预算，FC-SWE 达到 70.7% 的 Resolved@11。

这些指标需要谨慎解读。Resolved@K 表示在最多 K 次、且由验证反馈衔接的尝试中累计解决任务的比例，不等同于独立采样意义上的 Pass@K，也不是标准单次尝试排行榜成绩。因此，结果主要说明该方法提升了“带反馈恢复”的能力，而不能直接推导为所有软件工程场景下的普遍性能提升。

意义与影响

FC-SWE 的价值在于把失败从单纯的负奖励，转化为后续决策可用的训练信号。这一思路适合测试成本高、状态复杂且任务需要多轮工具交互的智能体系统。未来，恢复链条如何扩展到更多轮次、如何降低验证器调用成本，以及反馈质量变化时训练是否仍然稳定，仍是值得评估的问题。论文代码计划发布到 NVIDIA NeMo RL 的专门分支，目前尚未公开。

来源：Hugging Face Daily Papers