编程Agent失败预警可能看错对象

给编程 Agent 加一个失败预测器，发现苗头不对就停止、重试或切模型，听起来很合理。但一篇新论文提出：预测器可能只是认出了难题和弱模型，并没有看懂这一次执行哪里出了问题。

Igor Eduardo 的解读围绕这个错位展开：报警准确，不代表报警触发的动作有用。对正在搭建 AI 编程流程的团队，这篇最值得带走的，是如何判断监控到底在观察运行，还是在给任务难度打分。

同样是失败，为什么不能都按重试处理

论文《Hard Issue, Weak Model, or Bad Run? Rethinking Failure Prediction for Coding Agents》于 2026-11-05 发布，编号为 arXiv 2611.08285。它把编程 Agent 的失败拆成三类：

• 任务太难，多数模型都做不出来，此时停止执行或交给人处理可能更合适。
• 模型偏弱，它在许多任务上都表现不好，此时换更强的模型更有针对性。
• 这次跑偏，同一个模型在同一个任务的其他尝试中能够成功，此时重试才可能救回来。

失败预测器通常会读取尚未完成的执行轨迹，包括推理、命令和工具输出，再判断是否报警。产品希望它识别第三类问题，但它也可能只学会了前两类。

知道任务容易失败，和知道这次执行正在失败，是两种能力。

论文开头的例子很直观：假设模型处理简单任务的成功率为 90%，处理困难任务只有 10%。一个只知道任务难度的评分器，就能拿到 0.90 的汇总 AUROC；但让它比较同一个任务的两次执行，成绩只有 0.50，相当于随机猜测。

AUROC 可以理解为：随机挑一次失败和一次成功，评分器把失败排在更危险位置的能力。问题出在挑选方式上。把不同任务混起来比较，很容易测出识别难题的能力，却没有回答运行监控真正需要的问题。

0.92 的高分，为什么还不能证明它看懂了执行

研究使用了一个包含 500 个真实仓库问题的常用基准。主要数据中，每个模型对每道题尝试一次，共有七个模型的 3,492 次运行，其中 994 次失败；研究还使用了 23 个模型的结果，以及另一份包含重复运行的公开数据。

最醒目的结果是：一个完全不读取执行轨迹、只参考其他模型表现来估计任务难度的基线，汇总 AUROC 达到 0.92。读取轨迹的预测器只有 0.62–0.63。

这不只是分数高低的问题。测试折中的 494,109 对失败与成功样本，有 99.66% 来自不同任务。评估几乎一直在问「哪道题更难」，很少问「同一道题哪次跑得更差」。

限制在同一个任务内比较，仅使用模型身份的基线达到 0.72，轨迹预测器为 0.60–0.61。在整体较弱的模型反而成功的「爆冷」样本对上，预测器只有 0.42，低于随机水平。这支持研究者的判断：预测器很可能在复现模型强弱排序，而没有捕捉这次运行的特殊变化。

进一步把预测器分数加到任务难度和模型身份之上，研究测试的全部 18 种配置中，AUROC 增量在统计意义上均等同于零。这个结果限定在他们测试的配置内，不能扩展成所有轨迹信息都没有价值。

重复运行的数据也说明，坏运行确实存在。试验覆盖 522 个任务，每个模型至少运行四次，结果变异分解为：任务难度占 53%，运行间变化占 42%，模型与任务的专门适配占 4.6%。与此同时，预测器分数方差的 64–82% 来自任务之间的差异。

可供重试挽救的波动不少，报警却主要跟着任务难度走。两者没有对上。

换模型的收益，可能只是多试了一次

单次结果很容易制造一种路由空间：最强单模型解决了 76.8% 的任务，而只要任意模型成功就算成功，覆盖率达到 86.8%，相差 10.0 个百分点。

但后者相当于提前知道每道题该选哪个模型。研究发现，这个理想差距落在仅靠随机性也能产生的范围内，因此不能直接把它当成模型各有所长的证据。

失败也高度集中：994 次失败中，448 次发生在没有任何模型解出的 64 道题上，占失败总数的 45%。至少在已观察到的结果里，这些题没有可供切换的成功模型。

实际选择模型的增益很小。根据同一道题的历史运行挑选模型，在新运行上只增加 0.09 个百分点；面向新任务的路由器增加 0.41 个百分点。相比之下，把每次失败都交给一个固定的第二模型，增加了 6.91 个百分点。

这里有两个限制。其一，6.91 的结果假设存在完美失败检测器，不能直接视为中途报警系统的可得收益。其二，这个结果支持「额外尝试很重要」，却不能单独证明「换模型优于原模型重试」。要回答后一个问题，还得让两种策略用相同的尝试次数和预算比较。

路由策略需要证明自己的收益超过普通重试，而不只是超过只跑一次。

我的判断

我赞同这篇对评估口径的质疑。团队要的是「看到报警后采取动作，最终更划算」，汇总 AUROC 回答的却可能只是「失败样本通常长什么样」。指标计算没有错，产品据此作出的判断仍然可能错。

不过，证据边界必须保留。研究主要覆盖一个基准和一种 Agent 执行框架，只研究基于轨迹的预测器；重复运行试验使用较旧模型，新任务路由器采用的任务特征也比较浅。没有检出模型与任务的专门适配，不等于这种适配不存在。原文作者没有复现实验，也刻意没有列出模型、基准及既有系统的名称。

因此，我不会据此建议团队撤掉失败预测。更合理的选择，是先让简单基线进入评估：任务难度、模型身份，以及直接再试一次。复杂监控若能在相同预算下胜出，才有理由承担额外成本。

作者主张可靠性声明应有重复运行和等预算对照，这是他的评估取舍，并非另一项实验结论。对短、便宜、确定性强的任务，单次评估可能已经够用；运行越长、随机性越强，而且越需要中途干预，区分失败原因就越重要。

能拿来做什么

• 给现有 AI 编程任务留出一小批重复样本，让同一模型多次处理同一仓库问题，先确认失败有多少来自运行波动，再决定是否建设复杂监控。
• 评估失败预测器时，把任务难度和模型身份两个不看轨迹的基线放在同一批样本上，并报告同一任务内的排序能力，检查预测器是否提供了额外信息。
• 给仓库修复流程增加自动路由前，用相同尝试次数比较路由、固定第二模型和原模型重试，避免把多一次机会带来的收益记到路由头上。
• 把停止、重试和切模型分别记账，观察它们触发后的最终成功率与总成本；报警命中率不能代替动作效果，阈值还需要结合无效运行和漏报的实际代价确定。