原始来源：Waterloo · StopLoss
发现渠道：Hugging Face Daily Papers
原始来源：相关原始说明 / 公开讨论
编程 Agent 有时会长时间重复失败尝试，继续花钱却没有解决任务。StopLoss 把“这次运行还值得继续吗”做成独立监控器：执行 Agent 不变，外部70亿至80亿参数的小模型只读取最近的行动和工具反馈，预测继续、停止或交付。它既不需要读取执行模型的隐藏状态，也不靠一段昂贵的长篇推理来判断。
研究者用已有运行的最终验证结果构造训练窗口：失败轨迹的窗口标为停止，成功轨迹接近结尾的窗口标为交付，其余标为继续。实际监控从第5步开始，每隔3步看一次最近3组行动—观察，输入上限1600 token，直接读取类别分数。这里容易出现一个统计陷阱：一条本来成功的运行只要有一次分数越界，就会被误杀。因此阈值校准针对成功轨迹中的最高停止分数，而不是把各个窗口当成互相独立的样本。
论文评估的是离线回放中的中止策略，扣掉被截断的后续执行费用，再加上监控费用，并计算每个保留成功任务的成本。对一个 Verified/Luna 设置，作者报告保留99%的成功，单位成功成本降低4.5%；更难的 Pro 条件下出现更大收益，说明余下失败成本越高，停止策略越可能划算。另一方面，能力强的通用裁判也可能因检查费用过高，反而抬高总成本。
这些数字有明确边界。策略评估使用每个执行器共享的425道 Verified 与213道 Pro 任务，Pro仅覆盖三个Python仓库；小模型开销由 A6000 单卡推理时间折算，并未完整计入训练、空闲服务和线上调度。校准集上的误杀目标也不是换模型、换任务后的保证。论文没有验证停止后交给另一条路线重试的效果。
可信度 65 · 重要性 84 · 新颖度 83
技术与主题
Agent 系统 · AI 编程 · 系统与效率 · 评测与基准 · 多模态 · 训练与对齐 · Early Stopping · LoRA · Trajectory Monitoring · Cost per Solve
编辑评读
这个工作的关键贡献，是把“识别失败”改写成带处置代价的决策。分类分数更准，并不一定让系统更省钱：监控有账单，误停还会减少可交付结果。把成本除以保留下来的成功数，能揭示只看总支出时看不到的退化。使用成功轨迹最大分数校准，也正确对应了反复检查中“任何一次误报都会终止”的规则。
但失败标签依赖当时的执行器和继续策略。一个在原轨迹中失败的任务，可能通过换检索、修复环境或换模型完成；监控器学到的不是任务不可解的证明。因此可以迁移的是决策框架：先估计继续的预期收益与代价，再明确停止后是放弃、排队还是升级。要验证升级策略，必须重新测量完整路径的成功与总费用，不能把离线截断的节省直接加到重试方案上。本期检索未找到有实质数据的独立复现，结论保留为作者实验。