← 返回 PaperDaily 大模型与智能体

CodeRescue来了：编码代理失败后也能控预算

代码代理终于不只是“会不会改对”，而是开始认真算“改一次要花多少钱”。这篇 CodeRescue 把失败后的恢复动作拆成可路由、可校准、可控预算的流程，思路很实用，工程味也很足。

龙哥读论文 阅读 3 查看原文
#Agent #大语言模型 #人工智能
CodeRescue来了：编码代理失败后也能控预算
原论文信息如下：
论文标题:
CodeRescue: Budget-Calibrated Recovery Routing for Coding Agents 发表日期:
2026年07月 发表单位:
University of Washington, New York University, ByteDance, Amazon 原文链接:
https://arxiv.org/pdf/2607.18877v1.pdf 开源代码链接:
https://github.com/Qijia-He/agent-budget-control

编码代理失败后，花钱的“艺术” | 新研究提出CodeRescue，让预算可控的恢复路由成为可能

代码代理真正难的地方，往往不是“第一次能不能写对”，而是失败之后怎么花钱最值。这篇 CodeRescue 盯住的就是这个工程里很现实、但经常被忽略的问题：当廉价模型已经把代码跑崩了，下一步到底该继续让它修一修，重新规划一版，还是直接把任务交给更贵的强模型？
这件事听起来像“多花点算力而已”，但放到真实编码代理里就完全不是一回事。一次失败会带来编译错误、断言失败、输出不对、超时，甚至 stderr 里一长串看不懂的报错。对人类程序员来说，这些信息叫“线索”；对代理来说，这些线索如果用对了，廉价模型还能抢救一下；用错了，就只能继续烧钱。CodeRescue 的核心思路很朴素：失败不是终点，而是一个新的路由决策点。
封面
图3：GPT-5.4-nano 持出测试集上的成本—解题率前沿。蓝色圆点是不同预算下的 CRC 运行点，星号是未加约束的最优路由，灰色虚线是二元级联基线，橙色菱形是零样本提示路由，叉号是固定动作基线。
这篇工作最有意思的地方，不是再造一个“更聪明的模型”，而是把恢复动作拆开来管：修复、重规划、升级。然后再叠一层 Conformal Risk Control，简称 CRC（Conformal Risk Control，保形风险控制），让同一个路由器能按预算切换不同的部署点。说人话就是：不是每次都得“全力出手”，系统可以先判断这次失败值不值得继续用便宜算力抢救。

从“二元升级”到“三选一”：如何精准分配恢复成本？

传统的成本控制路由，常常是“便宜模型先上，实在不行再升级”。这套逻辑在很多场景里都成立，但在编码代理里会显得有点粗糙。因为代码失败后，系统已经拿到了执行反馈，这就相当于侦探案卷里多了一页口供，完全可以再判断一次：是继续让便宜模型根据报错修一下，还是干脆换个思路重写，还是直接交给强模型。
CodeRescue 把失败后的恢复动作定义成三个选项。reflect 是让便宜模型利用错误反馈做局部修补；replan 是让便宜模型基于反馈重新规划一版；escalate 则是把问题连同反馈一起交给更强的模型。这里的 escalate 不是“认输”，而是承认某些任务已经超出廉价模型的修复半径，继续硬拧只会浪费预算。
这三个动作并不是简单排队。论文观察到一个很关键的事实：cheap recovery 和 escalation 不是谁天然碾压谁。有些样本只靠便宜修复就能过，有些必须升级，有些两边都行。于是，路由器不能只学“哪种模型更强”，而要学“哪种恢复动作在当前失败样本上最划算”。这也是这篇论文比普通 cascade 更细的一点：路由的对象不是模型，而是恢复策略。
图1：预算控制的恢复路由
图1：预算控制的恢复路由。廉价编码尝试失败后，路由器会读取问题、判定结果和 stderr 来给恢复动作打分；CRC 再把用户预算 B 映射成成本惩罚 λ(B)，从同一个训练好的路由器上切出不同预算点。
训练时，论文用离线恢复轨迹做监督。每个失败样本会记录哪些动作能通过评测，然后把“最便宜的成功动作”当作标签。这里没有把问题简化成普通分类，因为多个动作可能都能解决同一个样本，真正重要的是最终解题率，而不是标签是否猜中了某个唯一答案。换句话说，路由器不是在背标准答案，而是在学怎么少花钱把事情办成。
论文还给这个路由器加了一个很工程化的限制：部署时预算会变，不能每次都重新训练。于是引入 CRC 层，把预算 B 变成一个成本惩罚 λ。这个 λ 会在同一个路由器上推动不同动作的选择：λ 小时更愿意冒险用强动作，λ 大时更偏向便宜动作。这样一来，同一个模型，一次训练，多档预算，这才像能上线的系统。
如果把核心流程压缩成一句话，大概就是：先用便宜模型做初次生成，失败后读取执行反馈，再由监督路由器在 reflect、replan、escalate 之间选一个最值的动作，最后用 CRC 把“想花多少钱”变成“系统实际怎么选”。

CRC校准：同一路由器，不同预算，如何一键切换？

这里最值得单独拎出来说的是 CRC。它的作用不是再训练一个更强的路由器，而是给现成路由器加一个预算旋钮。预算紧，就把 λ 调大，系统更偏向便宜动作；预算松，就把 λ 调小，系统更愿意为更高解题率付出更高成本。
CRC 的好处在于，它不要求动作成功率一定单调。这个限制很重要，因为在编码恢复里，动作之间的关系并不规整：有时 replan 比 reflect 更有效，有时 escalate 才是正解，有时某个动作在某类样本上反而会“帮倒忙”。如果硬把这个问题当成单调级联，会把很多真实的非线性结构抹平。CRC 只管成本的可控性，不强行假设解题率一定随预算平滑上升，这就比很多“看起来优雅、其实很脆”的方法靠谱一点。🙂
图2：成功动作结构
图2：GPT-5.4-NANO 校准集与测试集合并持出集上的成功动作结构。左图按基准展示 S(x) 的分布，分成仅便宜动作、便宜/升级重叠、仅升级三类；右图比较了平均 oracle 恢复成本和 always-escalate 的成本。
从理论上看，CRC 用的是 Conformal Risk Control 的思路。这里的“保形”不是装饰词，而是说它借助校准集，把预算约束转成一个可部署的统计控制问题。论文里给出的保证是平均成本控制，不是“每个样本都不超预算”，这一点必须说清楚。它保证的是未来样本的边际期望成本不超过 B，而不是高概率地让每条样本都完美守规矩。
这类设计的工程价值很直接：预算变化时，不需要重训路由器，也不需要重新搜一大堆阈值。只要扫描一张预先算好的 λ 表，就能切换到新的预算点。对于实际系统来说，这种“可调档”比单点最优更重要，因为真实业务从来不是只有一个预算。

实验验证：效果与成本的完美“双赢”

实验部分最先回答的是：这套路由到底有没有必要。论文在五个代码基准上收集了失败后的恢复轨迹，包括 APPS、TACO、BigCodeBench、LiveCodeBench 和 CodeContests，覆盖从面试题到竞赛题的不同难度。廉价模型先生成初稿，失败后再跑三种恢复动作，记录哪些动作能把题做对，再用这些轨迹训练路由器。
这里的数据设计挺像真实业务：一部分问题在初次尝试就解决了，不需要恢复；一部分失败后根本救不回来；还有一部分问题，便宜修复和强模型升级都能搞定。正是这种“有时能救、有时救不活、有时两边都行”的混合结构，才让路由问题变得有意义。要是所有样本都只能升级，那就没啥路由可言了，直接交钱就行。
表1：路由基线对比
表1：GPT-5.4-nano 持出测试集上的路由基线对比。左侧是固定动作策略，右侧是用零样本提示直接充当路由器的模型。成本单位为毫美元，右表中括号内拆分了恢复动作本身和路由器调用的成本。
表1先把最朴素的疑问打掉：固定一个动作不够用。always-escalate 虽然解题率最高的固定策略之一，但成本很高；always-replan 和 always-reflect 虽然便宜，却明显不够强。更关键的是，训练出来的路由器在不加预算约束时，能在更低成本下拿到更高解题率，说明“按样本选动作”这件事不是锦上添花，而是刚需。
图2进一步解释了为什么会这样。成功动作并不是单一层级，而是分成三种结构：仅便宜动作可解、便宜动作和升级都可解、只有升级可解。论文统计到 pooled 持出集里，三类样本都存在，而且不同基准之间差异很大。比如有的基准更偏“便宜修复”，有的则更依赖升级，这就解释了为什么一个统一阈值很难吃遍所有场景。
图3是整篇论文最像“产品图”的地方。随着预算放宽，CRC 会把同一个路由器从更便宜的恢复方式逐步推向更激进的升级方式，形成一条离散的成本—解题率前沿。论文给出的一个很扎眼的点是：在中等预算附近，三动作路由器能以大约35% 的 always-escalate 成本，拿到超过 always-escalate 的解题率。这个结果不只是“省钱”，而是说明廉价恢复并非边角料，而是真能替强模型分担一部分工作。
图3：成本—解题率前沿
再看表2，论文开始回答“路由器为什么会更强”。结果显示，加入元数据前缀后，路由器效果明显更好。这个元数据包括来源、难度和算法标签，听起来像小信息，实际上很有用，因为执行反馈本身并不总能告诉模型题目属于哪种分布。对分类标签的选择上，hard label 也比软标签更稳。模型骨干方面，Qwen3.5-4B 的全参数微调表现最好，LoRA 虽然省资源，但在这个任务上略逊一筹。
表2：路由器消融实验
表2：GPT 持出测试集上的路由器消融实验。左侧是数据配方消融，右侧是 backbone 与训练方法消融。
表3则把成本单独拎出来看，结果很符合直觉：always-escalate 最贵，always-reflect 最便宜，但便宜不等于划算，关键还得看解题率。CodeRescue 的价值不在于把成本压到极限，而是在不同预算下找到一个更合理的平衡点。这个平衡点的意义很实际，因为真实部署里，很多系统不是“能不能用”，而是“在给定预算下怎么尽量多办成事”。
表3：平均恢复成本
表3：GPT 测试集上的平均单样本恢复成本。“Always-a” 表示不管路由器怎么判断，都强制对每个样本使用动作 a。
论文还做了跨模型验证，在 Gemini 2.5 Flash / Pro 的组合上也复现了类似的路由收益。这个动作很重要，因为它说明方法不是只对 GPT 这组模型管用，而是更像一种通用的“失败后恢复调度器”。如果一个方法换个模型就塌，那通常只能算 demo；如果跨模型还能站住，才更像可迁移的系统设计。
表4：Gemini 恢复路由结果
表4：Gemini 恢复路由在持出测试集上的结果（n=229）。
不过，这里也别把结果吹成“万能按钮”。CRC 控制的是平均成本，不是每个样本都省钱；路由器学的是“最便宜成功动作”的代理标签，不等于精确建模每个动作的成功概率；而且论文的主设定还是单次失败后的单步恢复，真实编码代理往往要反复试错、多轮编辑、多轮执行。也就是说，这个工作已经把第一步做得很漂亮，但离完整的长链路代理系统，还有一段路要走。

总结与思考：未来编码代理的“性价比”之道

CodeRescue 的价值，不在于它又发明了一个更复杂的路由器，而在于它把编码代理里最现实的那笔账算清楚了：失败之后，不是只看“能不能升级”，而是要看“哪种恢复方式最值”。这个视角很像真实工程里的资源调度，少一点概念包装，多一点成本意识。
对普通从业者来说，这篇论文最大的启发是：编码代理的性能，不只是模型本体决定的，还取决于失败后的恢复策略。未来更成熟的代理系统，可能不会只有“一个大模型从头到尾包办一切”，而是会像调度中心一样，在不同失败类型上分配不同的恢复预算。对研究者来说，这也提示了一条很实用的路线：别只盯着初次生成的准确率，失败样本的再利用本身就是一块很大的增益空间。
当然，后续还有几个明显方向。第一，多轮恢复比单步恢复更接近真实产品，路由器需要学会在一串行动里动态决策。第二，预算约束可能不止是平均成本，还可能包括时延、上下文长度、失败风险等多维指标。第三，动作集合也许不该只停留在 reflect、replan、escalate，未来还可以加入检索、单元测试生成、局部补丁搜索等更细粒度工具。这个方向一旦做细，编码代理就不再只是“会写代码”，而是会“会算账”。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是编码代理失败后的恢复决策：不是简单问“要不要升级更强模型”，而是问“在 reflect、replan、escalate 这三种动作里，哪一种在当前预算下最划算”。

CRC 是什么意思，为什么它重要？CRC 是 Conformal Risk Control，中文可理解为保形风险控制。它的作用是把用户预算 B 转成一个成本惩罚 λ，让同一个训练好的路由器在不同预算下切出不同的部署点，而且给出平均成本控制的统计保证。

为什么这篇工作不是普通的“模型级联”论文？因为它路由的不是单纯的模型强弱，而是恢复动作。失败后的执行反馈让问题从“重新答题”变成“带着诊断信息修题”，这使得便宜模型的二次利用变得合理，也让路由空间比二元升级更丰富。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆ 不是“发明了新模型”，而是把编码代理失败后的恢复动作做成了可路由、可校准、可控预算的系统，这个切口新，而且很实用。

实验合理度：★★★★☆ 基线、消融、跨模型验证都比较完整，尤其把固定动作、零样本路由、二元级联都拉来对比，比较像一篇认真做系统的论文。

学术研究价值：★★★★☆ 对编码代理、成本控制、执行反馈利用都有启发，尤其适合后续扩展到多轮代理和更复杂的工具链。

稳定性：★★★☆☆ 单步恢复和平均成本控制是扎实的，但多轮真实代理里会不会继续稳定，论文还没完全回答。

适应性以及泛化能力：★★★☆☆ 在五个基准和 Gemini 组合上有一定泛化迹象，但动作集合和失败分布变化很大时，仍需要重新校准。

硬件需求及成本：★★★☆☆ 训练一个 4B 路由器不算离谱，但系统里仍要跑廉价模型、强模型和校准流程，整体不是“轻到随便上手机”的级别。

复现难度：★★★☆☆ 代码已开源是加分项，但数据需要收集失败轨迹和执行回放，复现成本仍不低。

产品化成熟度：★★★☆☆ 在有明确预算和可执行反馈的编码场景里可用，但更适合先做内部调度模块，不适合直接当通用代理核心。

可能的问题：平均成本控制不等于单样本稳控，多轮恢复和更复杂工具链下的收益边界还不清楚，离真正大规模上线还差最后一段硬仗。


主要参考文献

CodeRescue: Budget-Calibrated Recovery Routing for Coding Agents. arXiv:2607.18877v1, 2026. https://arxiv.org/pdf/2607.18877v1.pdf
开源代码：https://github.com/Qijia-He/agent-budget-control

代码代理最怕的不是失败，而是失败之后乱花钱。想看更多这种“性能、成本、部署门槛”一起算账的论文，欢迎加入龙哥读论文粉丝群，和一群同样爱抠细节的朋友一起拆方法、看实验、聊落地。  

end
欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如 图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。代码代理、智能体、自动驾驶、图像、医疗、金融都能找到同路人。
wechat_helperdianzan
转发文章 微博 X LinkedIn Facebook
龙哥读论文 · PaperDaily

本文基于龙哥读论文 PaperDaily 数据库整理，结合论文原文与工程视角进行解读。