StopLoss：让代码智能体学会识别失败并及时止损

导语

代码智能体并不是“运行得越久越可能成功”。在许多任务中，智能体其实已经走上了无法通过验证的路径，却仍会继续调用工具、修改文件和执行测试。若由前沿大模型持续充当监督者，监控本身的推理费用可能抵消提前停止所节省的成本。

论文提出的 StopLoss，试图把“何时应该放弃”变成一个低成本、可部署的预测问题。它像金融市场中的止损订单一样，不负责修复任务，也不改变原有代码智能体，只在判断运行大概率失败时提前结束流程。

核心方法

• 从最终结果反推早期信号：研究者使用已经完成的代码智能体轨迹，并以最终验证通过或失败作为监督信号，为轨迹中更早的局部窗口打标签。这样，模型学习的不是泛泛的“代码质量”，而是哪些工具调用模式往往预示着最终失败。
• 小型外部监控器：StopLoss 使用约 7B 至 8B 规模的语言模型，对最近一段工具步骤进行一次前向计算，输出失败风险分数。它不需要读取整个历史，也不需要让另一个大模型重新进行完整判断。
• 通过阈值控制中止：阈值根据成功运行进行校准，目标是在尽量不误杀成功任务的前提下拦截失败运行。监控器可以作为执行器外部的一层，不要求重新训练或改造原有智能体。
• 与通用裁判比较：实验将 StopLoss 与六种读取相同窗口的通用模型裁判对比，测试覆盖 SWE-bench Verified，以及一个 SWE-bench Pro 子集，并使用 GPT 和 Claude 执行器。

结果与意义

结果表明，单纯依靠最终结果进行监督，也能让失败预测在首次检查时从接近随机的水平提升为有用信号。StopLoss 每次检查的成本比测试中的通用裁判低约一到两个数量级。在 SWE-bench Verified 上，相比完成所有任务，它在保留 99% 成功运行的条件下，将每个保留解的成本降低 4.5%。在成本更高的 Pro 子集上，降幅最高达到 31%；使用 Qwen3-8B 骨干时，报告的降幅达到 48%。四种测试设置中，StopLoss 的每个保留解成本都低于所有对照裁判策略。

这项工作的价值不只是“用更小的模型替代更大的模型”。它展示了一种清晰的系统分工：执行器负责尝试解决问题，监控器负责判断继续投入是否值得。对于长轨迹、工具调用昂贵的代码智能体，这种分离可以把失败识别从高价的开放式推理，转化为一次快速的风险评分。

当然，提前停止也伴随误判风险。阈值需要根据执行器、任务分布和验证器重新校准，训练轨迹的覆盖范围也会影响跨模型泛化。因此，StopLoss 更适合作为带有保守保护策略的成本优化组件，而不是绝对可靠的失败证明器。研究同时开放了代码、模型和数据，为进一步检验不同任务及执行器上的效果提供了基础。

来源：Hugging Face Daily Papers