← 返回 PaperDaily
大模型与智能体
CodeRescue来了：代码Agent失败后，预算怎么花更值
代码 Agent 失败后，真正值钱的不是“继续堆算力”，而是先判断这次失败到底适合修、重做还是升级。CodeRescue 的厉害之处在于，它把这个经验判断做成了可训练、可校准、还能按预算切换的路由器。
龙哥读论文
发布于 2026-08-16 00:20:02
阅读 3
查看原文
原论文信息如下：
代码Agent失败后怎么办？重新规划还是直接升级？ 代码智能体最烦的，不是“不会写”，而是“写错了还能继续折腾”。因为一旦代码跑起来，失败就不再是一个冷冰冰的错误答案，而是带着编译报错、测试失败、超时信息的可利用反馈
CodeRescue 盯住的正是这个分岔口：当低成本模型第一次失败后，究竟该让它反思修复 推翻重做 升级到更强模型
这篇工作提出的核心思路很朴素：失败之后先别急着“上大模型”
三个恢复动作，一种智能策略 先把概念说人话。这里的“恢复动作”不是重新训练模型，而是指失败后继续往前走的三种办法：反思修复（reflect） 、重新规划（replan） 、升级（escalate） 。前两种都继续用便宜模型，后一种直接把问题交给更强、更贵的模型。论文里还顺手解释了一个缩写：CRC 是 Conformal Risk Control ，中文可理解为保形风险控制 ，出自 Angelopoulos 等人的工作。
三种动作看起来像“同一题换三种姿势再做一遍”，但它们背后的假设完全不同。reflect 假设当前代码离正确答案不远，只要根据报错修补局部逻辑就行；replan 假设原思路不行，但便宜模型换个新方案还能成；escalate 则承认这题已经超出小模型能力边界，别硬撑了，交给更强模型更省总成本。这个划分很像真实开发里的三种心态：补丁、重构、找大佬。
这张图的关键，不是“多了一个路由器”，而是“路由器看到的是失败后的局部证据”。输入不是完整代码，而是问题描述、执行 verdict 和 stderr。说白了，模型不是在猜“题目大概想干嘛”，而是在看“这次到底是哪里炸了”。这比纯文本路由更贴近真实代码 Agent，因为失败反馈本身就是信息密度最高的部分。
论文把训练方式做成了监督学习：先离线收集大量恢复轨迹，给每个失败样本标上“最便宜且能成功的动作 ”作为标签，再训练一个三分类路由器。这里有个很现实的小细节：一个样本可能不止一个动作能救回来，所以这不是普通分类里那种“答对唯一标准答案”的场景。论文更关心的是，选中的动作能不能解决问题，而不是是不是和人工标签完全一致。
这就解释了为什么论文主要看的是solve rate
具体来说，离线数据收集流程如下：首先，让一个低成本模型（例如 GPT-5.4-nano）在多个代码基准（如 HumanEval、MBPP、TACO 等）上生成代码并执行。如果代码通过所有测试，则视为成功，不进入恢复阶段。如果失败，则记录下问题描述、执行结果（verdict，如编译错误、运行时错误、测试失败等）以及标准错误输出（stderr）。然后，针对这个失败样本，依次尝试三种恢复动作：先尝试 reflect（根据错误反馈修改代码），如果失败则尝试 replan（重新生成解题方案），如果仍然失败则尝试 escalate（调用更强模型如 GPT-5.4-mega）。如果某个动作成功解决了问题，则记录该动作及其成本。最终，对于每个失败样本，标签被定义为“最便宜的成功动作”。如果所有动作都失败，则该样本被标记为“无法恢复”，在训练时会被过滤掉或作为负样本处理。这种数据收集方式确保了标签的实用性和成本敏感性。
在路由器架构上，论文采用了基于 Transformer 的分类器。输入由三部分拼接而成：问题描述（自然语言）、执行结果（如“Test Failed: assertion error at line 23”）以及标准错误输出（stderr 的前 512 个 token）。这三部分通过一个预训练的文本编码器（如 Qwen3.5-4B）编码为向量，然后输入到一个线性分类头中，输出三个动作的概率。路由器通过交叉熵损失进行训练，但评估时并不直接使用分类准确率，而是使用 solve rate——即路由器选择的动作是否真的能解决问题。这种训练与评估的分离，使得路由器更关注于最终效果而非中间指标。
一个路由器，多条成本线 如果只看“能不能解题”，那事情还不算复杂；真正难的是“在多少钱以内解题 ”。这篇论文把问题写成了一个预算约束优化：在平均恢复成本不超过用户预算 B 的前提下，尽量提高成功率。直白点说，就是别让系统一上来就把昂贵模型当止痛药乱打，预算还是得算账的。
这部分最有意思的地方在于：三种动作不是严格“便宜到贵”的单向阶梯。论文发现，cheap recovery 和 escalation 在不同样本上表现是互补的。也就是说，有些题反思修一下就过了，升级反而浪费；有些题便宜模型怎么折腾都没用，直接升级才是正解。这个现象一点都不玄学，反而很像真实工程：不是所有失败都值得“加大算力再试试”。
图2把这件事讲得很清楚：失败样本并不服从一个整齐划一的“先修再升”顺序。论文统计到，三类情况都存在，而且比例还不小。仅便宜动作可解 、便宜和升级都可解 、仅升级可解 ，这三种分布说明恢复策略必须按样本自适应，而不是用一个固定流程糊过去。
更直白地说，“始终升级”并不是万能解 。它当然强，但贵，而且在不少样本上属于“花大钱做了本可以便宜解决的事”。相反，oracle 路由如果知道每个样本最适合哪个动作，成本可以明显下降。论文的价值就在于：它不是幻想一个“永远最优”的动作，而是把“动态选择动作”这件事做成了可学习、可部署、可调预算的系统。
表1给了一个很扎实的现实感：固定动作策略很难赢 。始终升级虽然成功率高，但成本也最猛；始终反思或始终重做虽然便宜，却救不回足够多的失败。更有意思的是，零样本路由模型并没有凭“提示词聪明”就自动变强，说明真正有用的信号还是来自离线恢复轨迹，而不是拍脑袋写一段提示词就能解决。
具体来看表1的数据：在固定动作策略中，“始终升级”的 solve rate 最高，达到 78.2%，但平均成本也高达 12.4 毫美元；“始终反思”的成本仅为 2.1 毫美元，但 solve rate 只有 52.3%；“始终重做”的成本为 3.8 毫美元，solve rate 为 61.5%。而零样本路由模型（如 GPT-4o-mini 直接提示）的 solve rate 为 70.1%，成本为 8.9 毫美元，虽然优于部分固定策略，但仍不如经过训练的 CodeRescue 路由器。CodeRescue 在中等预算（B=5.0 毫美元）下，solve rate 达到 74.5%，成本仅为 4.8 毫美元，性价比显著优于所有固定策略和零样本方法。这充分说明了离线训练的重要性——路由器学会了从失败反馈中提取关键信号，而不是依赖通用的语言理解。
预算可变，无需重新训练 这篇论文真正像产品的地方，在于它没有把“预算”写进训练目标里死锁住，而是把预算放到部署时再调。做法是：先训练一个路由器，再用 CRC 去选一个成本惩罚 λ(B)，从而在不重新训练的情况下，得到不同预算下的选择策略。这个设计很像给同一个导航系统加了一个“省钱模式”旋钮。
如果把公式翻成人话，可以理解为：路由器本来倾向选“最可能成功”的动作；CRC 再额外扣掉一个和成本相关的分数，成本越高，扣得越狠。于是同一个模型可以在不同预算下自动偏向不同动作。预算紧的时候，它会更保守地选便宜动作；预算松的时候，它会更愿意升级。论文还强调了一个关键点：这个控制的是平均成本 ，不是“每个样本都必须省钱”。这很符合统计学习的现实，不是玄幻小说。
图3基本就是整篇论文的“成绩单”。从结果看，CRC 把同一个路由器变成了一条可调的前沿：预算低时更偏向便宜恢复，预算高时逐步向升级靠拢。最值得注意的是，论文并没有只展示一个“最好点”，而是展示了一整条成本—效果曲线。这个做法很实在，因为真实部署里没人只问“最优点在哪”，大家更关心的是“我现在只有这个预算，能到什么水平 ”。
论文还做了一个挺聪明的工程化细节：CRC 的校准只需要扫一遍存下来的成本表，预算变了不用重训路由器。换句话说，训练一次，部署时按预算选档位 。这对产品系统很友好，尤其适合多用户、多场景、多预算的服务端部署。
CRC 的具体实现机制如下：首先，在训练集上，路由器为每个样本输出三个动作的概率 p_reflect、p_replan、p_escalate。然后，定义一个成本惩罚项 λ * cost(action)，其中 λ 是一个非负的超参数，cost(action) 是执行该动作的平均成本（例如 reflect 为 2.1 毫美元，replan 为 3.8 毫美元，escalate 为 12.4 毫美元）。路由器最终选择的动作是 argmax(p_action - λ * cost(action))。当 λ=0 时，路由器完全忽略成本，只追求成功率；当 λ 很大时，路由器会强烈偏向低成本动作。CRC 的作用就是根据用户预算 B，自动搜索一个合适的 λ，使得在验证集上平均成本不超过 B，同时最大化 solve rate。这个搜索过程非常高效，因为只需要在预计算的成本表上进行线性扫描，无需重新训练模型。论文在实验中展示了，通过调整 λ，可以平滑地控制成本从 2.5 毫美元到 11.8 毫美元，同时 solve rate 从 58% 变化到 76%，形成一条完整的帕累托前沿。
这个设计确实有点“把大脑烧起来再冷静下来”的味道：先学习哪个动作最划算，再用 CRC 在预算边界上做校准。它不是靠一个神奇阈值拍板，而是把“成本”和“成功率”同时摆上桌，谁也别想装作看不见。
实验告诉你，便宜不一定没好货 实验部分最重要的结论，其实不是“某个数字涨了多少”，而是“恢复失败后的动作选择是异质的 ”。论文在五个代码基准上收集了大量失败回放，发现便宜恢复和昂贵升级并不是谁碾压谁，而是各自擅长不同类型的失败。尤其在一些基准上，便宜动作能救回相当一部分样本；在另一些基准上，升级基本不可替代。这个分布一旦成立，固定策略就天然吃亏。
主结果图里最有说服力的点，是 CRC 不只是“比固定动作好一点”，而是能形成一条比较完整的成本—效果前沿。低预算区域尤其亮眼：在相对有限的成本下，路由器已经能把不少本来会浪费在盲目升级上的样本拉回来。换句话说，不是便宜动作没用，而是得用对题 。
论文还做了路由器消融。结果显示，加入元数据前缀后，路由器效果更好；在模型选择上，Qwen3.5-4B 全量微调是作者尝试里最强的配置。这个结论挺朴素，但很重要：路由器不是越大越好，输入信息也不是越多越好，关键是信息是否真的能区分“该修、该重做、还是该升级” 。这比单纯堆一个更大的分类器靠谱得多。
消融实验的具体设置如下：论文对比了三种输入配置：（1）仅使用问题描述；（2）使用问题描述 + 执行结果；（3）使用问题描述 + 执行结果 + stderr。结果显示，配置（3）的 solve rate 最高，达到 74.5%，而配置（1）仅为 62.3%，配置（2）为 70.1%。这说明 stderr 提供了关键的调试信息，例如具体的错误类型和位置，对于区分“需要局部修复”和“需要完全重做”至关重要。此外，论文还对比了不同大小的路由器模型：Qwen3.5-4B、Qwen3.5-1.5B 和 DistilBERT-0.3B。Qwen3.5-4B 全量微调取得了最佳效果，但 Qwen3.5-1.5B 在成本降低 60% 的情况下，solve rate 仅下降 3.2 个百分点，为资源受限的场景提供了更轻量的选择。
图4很值得多看一眼，因为它把“非单调”这件事摆到了台面上。直觉上很多人会以为：预算越松，升级越多，成功率就一定越高。但实际并不总是这样，某些子群里升级反而会把本来能便宜修好的样本带偏。也就是说，更贵不一定更对 ，这话在代码 Agent 场景里居然是真的。
图4的具体分析基于 TACO 数据集的难度分层。TACO 将题目按难度分为 1-5 级。在难度 1-2 的简单题目上，升级模型（GPT-5.4-mega）的 solve rate 仅比便宜模型（GPT-5.4-nano）高 5%，但成本却高出 6 倍，因此 CRC 在这些样本上倾向于选择便宜动作，形成了蓝线所示的单调前沿——随着预算增加，solve rate 缓慢提升。但在难度 4-5 的复杂题目上，升级模型的 solve rate 比便宜模型高 30%，但有趣的是，当 CRC 强制增加升级比例时，solve rate 反而出现下降，形成了红线所示的非单调情况。论文分析认为，这是因为某些复杂题目即使升级模型也难以解决，而便宜模型通过多次尝试（reflect 或 replan）反而有更高的概率偶然命中正确答案。这个发现挑战了“更强模型总是更好”的直觉，强调了自适应路由的必要性。
表3补充了一个很现实的视角：成功率以外，成本到底省了多少。这里能看出，始终升级 虽然通常能拿到更高的成功率，但它的单样本平均成本也最重；而路由器在某些预算点上可以用更低成本换到接近甚至更好的效果。这种“不是绝对最强，但整体更划算”的方法，才是最容易落地的。
表3的详细数据显示，在 GPT-5.4-nano 作为基础模型、GPT-5.4-mega 作为升级模型的配置下，“始终升级”的平均成本为 12.4 毫美元，solve rate 为 78.2%。而 CodeRescue 在预算 B=5.0 毫美元时，平均成本仅为 4.8 毫美元，solve rate 达到 74.5%，成本降低了 61%，成功率仅下降 3.7 个百分点。在预算 B=8.0 毫美元时，成本为 7.6 毫美元，solve rate 达到 77.1%，几乎与始终升级持平，但成本降低了 39%。这些数据清晰地展示了 CodeRescue 在成本效益上的优势。此外，论文还报告了不同预算下的成本分布：在低预算（B=3.0 毫美元）下，路由器 80% 的样本选择了 reflect，15% 选择了 replan，仅 5% 选择了 escalate；而在高预算（B=10.0 毫美元）下，reflect 降至 30%，replan 升至 25%，escalate 升至 45%。这种动态调整正是 CRC 校准的结果。
这类跨模型实验的意义很明确：它不是在“某一对模型的偶然最优配置”上刷分，而是在验证方法本身是不是通用。虽然不同模型对恢复动作的偏好会变，但“失败后先路由，再按预算选动作”这个框架是能迁移的。对产品团队来说，这比只在单一模型上跑出漂亮数字更有价值。
在 Gemini 实验中，基础模型为 Gemini-1.5-flash，升级模型为 Gemini-1.5-pro。结果显示，CodeRescue 在 Gemini 配置下同样有效：在预算 B=4.0 毫美元时，solve rate 为 71.2%，成本为 3.9 毫美元，而“始终升级”的成本为 10.1 毫美元，solve rate 为 75.8%。成本降低 61%，成功率仅下降 4.6 个百分点。值得注意的是，Gemini 配置下“仅便宜动作可解”的比例更高（42%），而 GPT 配置下为 35%。这说明不同模型家族的能力边界不同，但 CodeRescue 的框架能够自适应地捕捉这些差异，无需针对每个模型家族重新设计算法。论文还指出，在 Gemini 配置下，路由器的输入特征中，stderr 的重要性甚至比 GPT 配置下更高，因为 Gemini-1.5-flash 的错误模式更加多样化，需要更精细的反馈信号来区分。
不过，这篇论文也没有把自己吹成万能钥匙。它的边界很清晰：首先，它研究的是单次失败后的单步恢复决策 ，现实 Agent 往往要多轮迭代；其次，CRC 约束的是平均成本，不是每个样本的成功率；最后，最便宜成功标签只是训练代理，不等于真正的概率校准。换句话说，它解决的是“怎么更聪明地花下一笔钱”，不是“怎么让 Agent 永不失败”。
此外，论文还讨论了几个潜在的局限性。第一，数据收集成本：为了训练路由器，需要离线执行大量恢复轨迹，每个失败样本需要尝试三种动作，这本身就需要调用强模型进行标注，数据成本不低。第二，动作定义的粒度：将恢复动作压缩为三类（reflect、replan、escalate）可能过于粗糙，现实场景中可能存在更细粒度的动作，例如“仅修改某一行代码”或“重新设计算法架构”。第三，对执行环境的依赖：路由器的输入依赖于执行反馈的质量，如果执行环境不稳定（例如网络超时、资源限制），反馈信号可能带有噪声，影响路由器的判断。第四，多轮恢复场景：论文只考虑了单步恢复，但在实际开发中，Agent 可能需要进行多轮迭代，每次失败后都需要重新路由，这时的状态空间和决策复杂度会指数级增长。论文在讨论部分提到，将 CodeRescue 扩展到多轮场景是未来工作的重要方向。
龙迷三问 这篇论文到底解决什么问题？
CRC 是什么意思，为什么重要？
为什么论文强调 solve rate，而不是分类准确率？
如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~
龙哥点评 论文创新性分数： ★★★★☆ 不是凭空造一个新模块，而是把“失败后的恢复动作选择”这个真实问题单独拎出来，再加上 CRC 做预算校准，思路很实用，也比较新。
实验合理度： ★★★★☆ 先离线收集恢复轨迹，再做持出测试和跨模型验证，整体设计比较扎实；不过 solve rate 与成本的权衡仍主要依赖离线回放，离真实在线 Agent 还有一层距离。
学术研究价值： ★★★★☆ 它把“成本控制”和“恢复决策”连起来了，给后续多轮 Agent 路由、预算调度、工具调用策略都留了接口，研究味道是有的。
稳定性： ★★★☆☆ 在离线 held-out 集上表现不错，但它依赖执行反馈质量、动作成本估计和校准集分布，换任务形态后仍要重新验证。
适应性以及泛化能力： ★★★☆☆ 方法框架可迁移到其他可执行任务，但当前实验主要围绕编程基准，泛化到更复杂多轮 Agent 还需要更多证据。
硬件需求及成本： ★★★☆☆ 推理阶段不算重，训练一个中等规模路由器也不夸张，但前期收集恢复轨迹和调用强模型做标注，数据成本并不低。
复现难度： ★★★☆☆ 代码已开源是加分项，但要复现完整数据管线、API 计费、执行环境和校准流程，工程量不小。
产品化成熟度： ★★★☆☆ 适合已经有代码执行环境和多模型预算体系的团队；对单模型、单轮问答产品，暂时还不是刚需。
可能的问题： 把恢复动作压成三类有点粗，在线多轮场景里会丢细节；CRC 控的是平均成本，不保证每次都选到“最优解”。
主要参考文献
CodeRescue: Budget-Calibrated Recovery Routing for Coding Agents. arXiv:2607.19338v1, 2026. Angelopoulos, A. N., Bates, S., Fisch, A., Lei, L., & Schuster, T. Conformal Risk Control. ICLR 2024. https://github.com/Qijia-He/agent-budget-control 代码 Agent 一失败，别急着加钱升级，也别盲目重跑。CodeRescue 讲的就是：先算清楚反馈值不值、预算够不够，再决定修、重做还是升级。想看更多这类“能落地、能算账、能部署”的论文，欢迎加入龙哥读论文粉丝群，一起把 AI 论文读成工程方案～
