最近在折腾自我改进编程智能体的时候我发现一个特别尴尬的事实真正吃预算的根本不是模型推理而是评测。跑一轮实验下来生成代码可能只花了几百美元的API费但等你去起环境、装依赖、跑测试套件、判读输出时间和钱一下子就翻了好几倍。MIT和Sakana AI放出的这个新框架核心就是冲着这个痛点去的——用LLM评判器来给自我改进编程智能体做低成本评估。这篇文章我想从“为什么评估成本会爆炸”讲起再把框架的设计逻辑拆开最后给一份能直接落地的复现思路和避坑经验适合正在做智能体开发、跑迭代实验、或者被CI评测账单吓到的同学参考。1. 先算一笔账自我改进编程智能体的钱都花在哪了1.1 自我改进循环里“测试”才是隐藏的大头一个典型的自我改进编程智能体跑一圈的逻辑是这样的模型先根据任务描述生成初始代码然后测试环境给它一个反馈再根据失败信息修改代码如此循环往复直到通过所有测试或者到达轮次上限。很多人直觉上觉得贵的是模型调用毕竟一次生成要消耗大量token。但真把实验跑起来你会立刻发现瓶颈在“评价”这一步。每生成一个候选解你都要做这些事开一个干净的容器、装依赖、编译、跑测试套件、解析输出、判断是超时还是崩溃还是输出格式不对。这一套流程快的十几秒慢的几分钟而一个正常的自我改进实验一轮就要生成几十上百个候选解后续还要迭代多轮。我自己的实测里评估环节占据的总时长经常超过70%费用占比更高因为环境构建和并行计算资源是最烧钱的。如果是SWE-bench这类真实仓库级别基准那就更夸张了。你得在真实项目环境里构造出代码变更、运行预置的隐藏测试、比对执行结果单次评测的复杂度比“跑一道算法题”高一个数量级。整个流程走完你根本分不清是在跑模型实验还是在维护一套测试基础设施。1.2 评估成本是指数级膨胀的不是线性增长把开销模型拆开看大概是这样总开销 候选样本数量 × 迭代轮数 × 单次评估成本 模型生成成本更现实一点还要加上失败重试某个候选解编译不过、某个测试环境炸了都需要额外重跑问题在于这三项不是独立变量。候选数量越多越有可能通过“广撒网”找到更好的代码迭代轮数越多每一步的改善空间越有可能被挖掘出来。于是人们倾向于加大这两个量但它们和单次评估成本是乘法关系。方向一多总开销就呈指数级往上蹿。那砍掉一些评测不行吗不行。编程任务最麻烦的地方在于“看起来能跑”和“真正正确”差距非常大。一个代码可能语法正确、模块能加载、示例测试也能过但换到隐藏测试就彻底崩了。如果你为了省成本减少评测坏样本就会顺着筛选漏洞混进来自我改进循环会被错误信号带着跑偏最后模型能力没提升反而学会了“制造假阳性”。2. MIT和Sakana AI这个框架核心是给评估加了一道“预筛”2.1 一句话概括把评测拆成快的和慢的两档我之前看到很多团队想省评估成本思路都是“减少样本、减少轮次”也就是从量上做减法。这套新框架的思路不一样它动的是评估结构本身。它的做法可以概括成先把每个候选解交给一个LLM评判器打分选出分数最靠前的一小撮再送去做完整的外部验证。完整验证的结果最后会回流到评判器那里做校准。用大白话说以前的模式是“每个候选都要过一遍正规考试”现在的模式是“先用AI阅卷老师快速筛一遍只有预选通过的少数人才进考场”。快的一档负责高频、低成本的粗筛慢的一档负责低频、高成本的终审。整个循环里贵的外部验证从“每轮多次”变成“每轮少数几次”预算自然就降下来了。2.2 为什么评判器选的是LLM而不是规则或静态检查有同学可能会问做一个基于规则的预筛不行吗比如检查代码是否有main函数、是否调用了指定库、是否有明显异常。这些能覆盖一部分问题但编程智能体评估的核心困难是语义正确性规则完全抓不住。静态检查工具也一样能查风格、能查未使用的变量但查不出“算法的思路是不是对题”。这也是为什么标题里强调的是LLM评判器。一个语言模型可以同时看任务描述、候选代码、测试运行输出综合考虑代码能不能满足约束、逻辑是否自洽。它不需要真正跑完所有测试却能给出一个和真实质量大体相关的排序信号。从成本维度看LLM做一次判定通常只要几秒钟、几分钱比起一个完整测试环境跑的几分钟、几块钱确实便宜太多了。这个框架由MIT和Sakana AI两家一起做我觉得也挺合理。Sakana AI本身就在演化算法和低成本AI训练上做了很多探索他们很习惯“资源受限”的场景MIT这边更关注推理智能体如何从反馈中学习两边一碰撞自然就会想到“评估别用蛮力用更聪明的方式”。3. 评判器给出的不是“真理”而是“带噪声的排序信号”3.1 别让评判器做最终裁决只让它做候选筛选我第一次看到这种方案时最担心的一个问题就是LLM评判器靠谱吗它能替代真实测试吗这个框架的聪明之处就在于此——它压根就没打算让评判器替代真实测试。评判器的输出是一个“带噪声的排序信号”它只在大量候选里筛出相对更好的那一小批。至于最终答案对不对还是要交给外部验证来做最终裁决。这个设计特别重要。大家可以做一个简单实验拿一个开源小模型去给一堆代码候选打分你会发现它的绝对分数经常不可信同一个候选换个提示词表述分数都可能波动。但如果你让它对几十个候选排序靠前的那几个平均质量大概率比靠后的好。也就是说你可以不信任它的绝对值但可以信任它的相对比较能力。筛选场景利用的恰恰是这种相对比较能力我不需要你知道“这个代码值多少分”只需要你能告诉我“这批候选里哪些值得送进去跑真实测试”。3.2 评判器的分数不可信时用不确定性信号来兜底一个负责任的评判器在拿不准的时候应该“表示不确定”而不是硬给一个平庸的分数。这里最常见的实现方式就是重复采样。同一个候选交给评判器打三次分如果三次结果差异特别大说明评判器自己都没把握这时候强行按照平均值排序就很危险。更稳妥的做法是把这类高方差样本直接标记为“不确定”然后跳过预筛直接送进外部验证。这个思路有点像我们平时做自动化测试的pytest-flaky处理一个测试用例不是每次都能稳定通过时你不会直接断言它是好消息或坏消息而是先重跑几遍再决定要不要上报失败。评判器的不确定性信号就是编程智能体评估里的“flaky检测”。3.3 一旦外部验证结果回流评判器就需要持续校准框架里还有一环容易被忽略外部验证的结果必须回灌给评判器去做校准。为什么因为评判器的排序能力不是恒定的。假设某个版本的候选代码特别爱写大量注释和防御性检查评判器可能觉得这代码很细致、很全面于是给了高分。但外部验证会发现这代码的实际运行效率一塌糊涂。如果外部验证结果不回流评判器就会一直保持这个坏习惯越筛越偏。校准的做法在工程上也很直接定期把外部验证的真实结果和评判器分数放到一起算相关性比如斯皮尔曼排序相关系数。数值一旦掉下去就说明评判器开始被某些表面特征欺骗了要么调整打分维度要么换一个更强的评判模型要么临时提高外部验证的比例。4. 落地复现笔记把框架思路转成工程的五个步骤4.1 第一步先搞清楚你的评估到底贵在哪别急着上评判器。我之前见过一个团队花了很大力气集成LLM评判器最后发现他们的任务本身跑一次测试只要几十毫秒瓶颈完全不在评估而在生成模型太慢。方向直接做反了。做之前先抽几轮全量评测算三组数字单样本外部验证的平均耗时和平均费用单轮实验平均生成的候选数量整个自我改进循环的预期迭代轮数把这三项乘起来你就知道评估的总预算量级。只有当“外部验证的单价 × 候选数量”高到明显影响实验迭代速度时引入评判器才划算。4.2 第二步选定评判器和打分维度评判器模型的选择有自己的门道。最佳实践是选一个比主模型便宜数倍的开源模型而不是用和主模型同一级别的大家伙。既然评判器只是做相对排序一个中等规模模型往往就够用了关键是它的打分要稳定。打分维度这个事我建议初始不要贪多。我自己的经验是先只评两个维度第一是“根据任务描述和已有输出这个代码在多大程度上能实现目标功能”第二是“代码的可维护性和对约束的遵守程度”。两个维度各打一个分再按固定权重合成排序分。等跑稳了再加第三个维度比如“异常处理是否合理”。维度越多评判器的注意力越分散排序稳定性反而下降。另外一个特别容易踩的坑是不要把参考实现或最终答案发给评判器。一旦评判器见过参考实现它就不是在判断候选质量而是在做模式匹配。这和小学生对着答案批卷子一样分数必然失真。4.3 第三步搭双通道管线并接入外部验证候选生成之后做两件事先走评判器快速打分按排序取Top-k进入外部验证外部验证结果写回校准队列用于后续评判器调优这里的k怎么定我的建议是不要拍脑袋设一个固定值而是先拿历史上50个候选同时跑人工评测和评判器打分观察“Top-5”也就是评判器打出来的前五名里真正通过外部验证的比例有多高。如果很高说明评判器比较可靠可以适当把k调小如果偏低就得把k调大甚至回到全量评测。这个比例就是你的“预筛命中率”它应该成为管线日常监控的核心指标。下面是思路级别的伪代码真实项目里建议把各个阶段拆成异步任务来跑方便定位问题for task, reference in task_queue: candidates agent.generate(task, N) # 生成N个候选解 scores judge.score(candidates, times3) # 评判器重复打分 uncertain flag_uncertain(scores, threshold) # 高方差样本标记 selected select_top_k(scores, k) uncertain # 高分样本不确定样本 for cand in selected: real_result full_validate(cand) # 外部真实验证 log_pair(scores[cand], real_result) # 记录分数-结果对4.4 第四步调校准频率别等到崩了再补救校准不是一次性工作而应该是循环里持续跑的“后台任务”。每跑一批实验就拿上一批sample的“评判器分数-真实结果对”更新一次相关性统计。我习惯用滑动窗口只统计最近200个验证样本这样既不会太敏感也不会让历史脏数据长期拖着评判器不放。如果发现相关性持续下降先别急着重训评判器。最容易先中招的问题不是模型变笨而是候选分布漂移了。比如生成模型换了参数代码风格大变评判器没见过这种风格打分自然失真。这时候最快的方法是微调评判器的打分提示词把新风格里的特征词写清楚再不行就切一个更强的开源评判模型。4.5 第五步设安全阀保留随时退回全量评测的能力框架省预算的前提是评判器还靠谱。一旦你发现预筛命中率突然崩了比如最近Top-k里真实通过率只剩原来的一半这时候整个循环继续跑只会越来越歪。所以管线里必须有一个熔断机制命中率跌破阈值时自动把后续所有候选都送去外部验证同时暂停评判器筛选等待人工介入调整。这个安全阀看着简单但绝大多数人不会提前做。等发现问题的时候一轮实验可能已经烧掉几千个错误评分样本自我改进信号已经被污染了。5. 实际操作中我踩过和见过别人踩的坑5.1 评判器会无意识偏爱“好看的”代码我第一次用评判器做预筛时发现Top候选里大量出现那种注释特别详细、变量命名特别冗长、但算法效率并不高的代码。原因不难理解语言模型的打分偏好里天然包含了“看起来完整、解释清楚”的权重它很容易把详尽的注释和防御性编程误判为高质量。从那以后我的打分提示词里会特别注明如果候选代码与任务描述不匹配或者存在明显冗余逻辑即便注释详尽也不应加分。此外还会做“字段盲评”把代码内部的注释先剥离掉一部分再让评判器打分减少表面特征的干扰。效果立竿见影Top-k的命中率明显回升。5.2 只验证Top-k会让累积偏差快速变大这个坑更隐蔽也更致命。你每轮只挑打分最高的几个送外部验证被淘汰的低分样本压根没有真实结果。一轮两轮还好几十轮之后候选池里那些“能骗过评判器但过不了真实验证”的样本会不断积累而真正的优质样本反而因为数量少被稀释掉。这本质上是用模型标注数据去训练模型的闭环退化问题。我后来的做法是每轮固定从排序靠后的候选里额外抽5%也送去外部验证并把结果一并写入校准集。这样等于给系统引入了抽样真值让评判器能及时发现自己的排序偏差不让偏科长期存在。5.3 这个框架解决的是评估成本不是模型能力上限最后说一个心态层面的坑。省下来的预算如果不投回“生成更多更好的候选”模型是不会有真实能力提升的。评判器帮你降低了评估成本但候选本身的质量上限还是由生成策略和搜索空间决定的。如果生成模型每次产出的都是同一水平的代码省再多评估费自我改进也到不了天花板。我在跑这类实验时最后养成的习惯是把省下来的预算全部投入去增加初始生成样本数量以及多轮迭代的轮次上限。只有让生成侧充分探索评估侧的降本才真正转化成能力提升。6. 这套评估策略的延展空间6.1 从编程智能体推广到别的智能体任务只要满足“生成成本低、验证成本高”的场景这个双层评估思路都值得一试。我后来在数据分析智能体任务里也套过类似的逻辑让一个轻量模型先对候选分析报告的合理性和数据覆盖度打分选Top几再去做真实的数据验证和指标计算。核心条件和编程场景一模一样——生成候选很快但真正验证一份报告是否可靠往往需要跑整个分析管线贵得多。判断能不能套用有一个很简单的试金石记录一下单次真实验证的成本再算一笔“如果验证次数下降到五分之一实验迭代速度能提升多少”。只要收益大于引入评判器带来的噪声这套思路就成立。6.2 什么场景别硬套这把锤子反过来如果外部验证本身已经非常便宜跑完一个测试用例只要零点几秒就别硬塞一个评判器进来。那一层额外的模型打分不仅贵还引入了新的噪声源。判别任务模糊的时候也一样比如让模型判断“这段代码风格好不好”本身就没有严格标准评判器的分数就更加不可靠直接用真实评分反而更稳。6.3 和现有CI系统结合的前景这套框架放在团队工程环境里天然适合改造成CI的预筛策略。普通提交先走轻量级评判器配合少量关键测试快速通不过就退回合并前的高成本门禁再做完整回归。等于是在CI前面加了一道“智能体检”让大部分不合格代码在最便宜的阶段就被拦下。这种落地方式不需要推翻现有测试体系只是往外层铺一个快速筛选层工程风险小得多我认为这也是这个研究最值得借鉴的现实价值。
