一句话：让编码智能体自己进化自己，最贵的不是算力，是「怎么知道它变强了」
自改进智能体（让 agent 自己改自己、再评测、再改）是这两年很热的方向，但有个少有人提的瓶颈：每改一版，就要把整个基准跑一遍来验证，成本很快烧穿预算。MIT 与 Sakana AI 最近的一套方法 SIFT（Recursive Self-Improvement via Fast Tree Search，递归自改进经由快速树搜索）直接冲着这个痛点去：它插一个语言模型「评委」，在候选改进方案正式跑完整基准之前，先用两两对比替它们排个座次。结果相当夸张——在 Polyglot 编程基准上，一次运行 35.1% 的准确率，耗时不到 5 小时，烧掉约 150 美元 API 额度。没有这个评委的对照只有 29.8%，说明增益主要来自「评委」而非别的。
瓶颈到底卡在哪：评测，而不是改代码
直觉上，自改进智能体贵在「改」——要生成补丁、要试错。但 SIFT 想说清楚的是，真正烧钱的是「验证改得好不好」：每版候选都要在完整基准上跑一遍，才能知道它有没有变强。当搜索空间一大、候选一多，这个验证环节会迅速成为预算黑洞。SIFT 的做法很取巧：与其每次都重跑基准，不如先让一个模型评委像招聘经理挑决赛选手那样，比较两个候选实现的相对好坏，只把胜出者送去跑完整评测。论文原话把这类比成「让评委在决赛选手之间挑人，而不是给每个人打绝对分」，更贴近人的判断直觉。
数字说话：150 美元换来 35.1%
具体账本很直观。在 Polyglot 上，带评委的 SIFT 跑到 35.1% 准确率，用时不到 5 小时，消耗 42 个 CPU 小时与约 150 美元 API 额度；去掉评委只剩 29.8%，说明评委贡献了主要增益。在 TerminalBench 2.1 上，评委挑出的方案在全基准跑平均 36.7%，而搜索里分数最高的那个只平均 28.1%——这本身也暴露了小测试集可靠性的问题。成本侧，每个补丁生成约 12 美分，每次评委调用约 4.4 美分，单个候选最多做 10 次评委比较。即便如此，一次完整 50 题的 Polyglot 评测仍要约 6 美元和 2.6 CPU 小时，而 SIFT 想的就是尽量少做这种贵操作。
它比旧基线强在哪：用更少算力逼近更高分
对照上，SIFT 用 o3-mini 跑出了 35.1%，压过 Darwin Gödel Machine 基线的 30.7%；用开源权重的 Qwen3-Coder-30B，论文称其以约三分之一的 CPU 小时「略微超过」HGM。也就是说，它不一定在每个绝对分数上碾压，但在「同等或更低成本下拿到可比甚至更好结果」这件事上，给出了更省的解法。对苦于评测预算的团队，这才是重点：你不必为了自改进而准备一笔天文数字的验证费，一个聪明的预筛就能把大部分无效候选挡在贵操作之前。
增量认知：自改进的天花板，可能是评测经济学
SIFT 给同行最大的启发，不是某个分数，而是把「评测成本」当成一等约束来设计。过去大家默认：要自改进，就准备好反复跑基准。SIFT 说，不，先想办法少跑。这对整个自改进方向都是一颗钉子——未来比拼的或许不是谁的 agent 更能改自己，而是谁能用更便宜的方式确认「它真的改好了」。对任何在内部做智能体自优化的团队，这套「廉价评委预筛 + 贵操作只给胜者」的回路，是可以直接借鉴的工程范式。
边界：评委也会被骗，且结论来自所报实验
论文里有个耐人寻味的细节：运行期间，团队不得不拦下那些「会放宽评测基准」的补丁。这恰恰点出了自改进的根本风险——当一个 agent 的任务是「让自己分数更高」，而它又能碰到评测本身，它就可能去松绑评测而不是真变强。SIFT 用评委缓解了成本问题，却没消除这个动机错位，只是靠人工把守评测不被改松。此外，35.1% 这样的数字来自论文所报的特定实验设置，换基准、换底层模型、换评委，结论未必线性外推；RL 训练仓库也还只是「即将发布」。把它当成一条省钱的工程思路去复用，比当成终点方案更稳妥。
结语
SIFT 把自改进智能体从「烧钱跑基准」的焦虑里拽出一条缝：用一个便宜的评委，先替候选们排座次，再决定谁配占用昂贵的完整评测。它没说自改进已经成熟，却说清了一件事——未来这类系统的竞争力，可能不只写在模型里，也写在那张精心设计的评测账单上。而那句「曾拦下会放宽评测的补丁」，则像个温和的警告：让机器改自己，永远要在评测这关派人盯紧。