当编码代理失败时，廉价重试优于升级，成本仅为其35%

为什么失败路由对编码代理很重要

在可执行环境中运行代码的编码代理拥有大多数LLM应用所没有的东西：可操作的错误信息。编译失败、运行时崩溃或错误的测试输出不仅告诉代理它失败了，而且通常还说明了原因。对于任何大规模部署这些代理的人来说，问题在于接下来该怎么做。

现有系统将此视为二元级联。先尝试一个廉价模型；如果失败，则将问题交给一个昂贵的模型。这有效，但浪费了失败产生的信息。廉价模型已经看到了提示，已经编写了代码，已经看到了错误。告诉人类“试试别的”的同一个错误，也可以告诉同一个廉价模型一些东西。

恢复路由公式

CodeRescue，在2026年7月21日发布于arXiv的一篇论文中描述，将失败后的决策形式化为一个路由问题。在初始尝试失败后，系统在不同恢复操作中选择：使用执行反馈重试同一个廉价模型，尝试不同的廉价策略（论文实验中使用了一种“提示重写”操作，用错误上下文重新表述原始任务），或者升级到更强的模型。每个操作都有成本，且成功率因失败类型而异。

作者在来自五个编码基准的执行回放序列（包括尝试、反馈和结果）上训练了一个监督路由器。路由器学习为每个失败特征选择哪个恢复操作。结果是形成了一种可以在中途混合廉价重试和升级的策略，而不是固定在一个链上。

无需重新训练的预算控制

操作员的预算可能会变。今天你能承受每个任务十美分，明天也许只有五美分。为每个预算重新训练路由器是不切实际的。CodeRescue增加了一个共形风险控制（CRC）层，该层在无需重新训练的情况下选择部署时的成本惩罚。CRC在可交换性假设下工作，并提供边际预期成本控制，这意味着操作员设定一个成本目标，系统保证平均成本在所有任务上低于该目标，无需逐个任务调整。

正是这种机制让同一个系统既能服务于利润微薄的初创公司，也能服务于资金雄厚的研究实验室，在相同的硬件上使用不同的成本目标。

数据：廉价恢复作为可行替代方案

实验将GPT-5.4-nano（廉价模型）与GPT-5.4（昂贵模型）进行了对比。在留出的失败案例中，CodeRescue产生的校准前沿优于所有固定操作基线：始终升级、始终用反馈重试、始终提示重写。它还击败了纯提示路由器（一个简单的提示告诉模型选择恢复策略）和二元级联基线（无路由，任何失败直接升级）。

校准前沿点在平均恢复成本仅为35%的情况下匹配了始终升级的解决率。这不是一个边际改进。这是针对大规模运行代理的成本-性能权衡的结构性转变。

互补的失败模式

论文报告称，廉价恢复和升级表现出互补的成功模式。某些失败类型，特别是语法错误和缺少导入，在廉价模型看到错误信息后通过重试始终得到修复。其他类型，如多步管道中的微妙逻辑错误，则需要更强模型更广泛的上下文理解。路由器学会了区分它们。

这与许多开发者已有的直觉一致。一个在难题上失败的廉价模型通常以同样的方式失败两次。一个在简单打字错误上失败的廉价模型通常在重试时修复它。区别在于失败本身，而非模型。

这对生产部署意味着什么

CodeRescue正好针对那些级联系统处理不佳的成本敏感型部署场景。二元级联将廉价计算浪费在本可廉价修复的失败上，因为它升级任何失败，或者将昂贵计算浪费在实际上可通过上下文恢复的失败上。这种路由方法与预算校准相结合，为操作员提供了一个带有性能保证的成本控制旋钮。

代码已在GitHub上提供，这意味着这不是一个封闭的研究成果。大规模运行编码代理的团队可以针对自己的失败分布测试路由方法。一个大的未解问题是，基于五个基准训练的路由器是否能迁移到生产工作负载。论文的CRC层假设可交换性，这在分布内的留出任务上是合理的，但对于领域转移则很脆弱。生产部署可能希望随时间监控路由器的成本-性能前沿，并在失败特征分布漂移时重新训练。

这些都不改变核心发现：当编码代理失败时，最便宜的路径并不总是升级。有时，你只需让它再试一次。