我打开 Weco 那篇宣布递归自我改进的文章时，先看到的是两个数字：系统连续跑了八天，找到的版本超过了团队花两年手工打磨的 Agent。再翻到技术报告的“点火测试”，结论却收住了：升级后的 Agent 放到负责改进的那个位置，尚未表现出可以明确区分的优势。
这两段说的是同一个实验。它确实找到了更好的 Agent，也确实没有证明“更好的 Agent 会越来越快地制造更好的自己”。技术报告把这条界限写得很清楚。
现在看到 Agent 自动修改提示词、增加工具、重写搜索策略，很容易顺着往下推：既然它能改自己，下一代就能改得更好，再下一代还能继续加速。几次代码更新，被讲成了一条会自动延伸的能力曲线，终点就是常说的“智能爆炸”。
中间缺了一次验证。做任务的能力提高了，负责改进这套系统的能力是否也提高了？下次再看到“自进化”的演示，我会先找这个问题的答案。
Weco 的实验里有两层工作。内层 Agent 做研究任务，外层 Agent 修改内层的代码，再根据评测决定保留哪一版。内外两层各自使用固定的基础模型，变化发生在围绕模型的搜索、上下文管理和验证逻辑上。
这类修改完全可能提高系统能力。模型知道什么，与系统最终能完成什么，中间隔着不少工程决策。把相关信息取出来、让失败结果进入下一轮、把预算花在更有希望的尝试上，都能改变同一个模型的实际表现。
所以，拿“权重没有变”否认全部进步，也解释不了实验结果。一个研究系统能在相同预算下完成更多有效实验，已经是值得承认的能力提升。
但模型固定这件事，也不能被省略。这里展示的是一套 Agent 系统的改进，并没有展示基础模型自行完成新一轮训练。把两者写成同一件事，会让读者误判到底哪部分发生了变化。
更关键的是，负责产生改进的过程有没有一起升级。
一个自动优化程序，能连续找到更快的实现，并不奇怪。它可能一直由同一个搜索过程驱动，只是在不断改进被搜索的对象。对象越来越好，并不自动意味着搜索过程越来越强。
递归自我改进令人关注，是因为它还提出了后一个可能：改进的结果能够反过来增强下一轮研究，让后续改进更有效。要验证这件事，得把升级后的系统放回研究者的位置，比较它和原来的研究者。
Weco 把中途得到的 AIDE₄₇ 放到外层，与团队开发的研究 Agent 比较。两组各跑三个随机种子，每次运行 50 步，最终达到相近水平。升级版本的平均曲线较早接近最终得分，但样本太少，波动也大，尚不能确认它作为改进者更高效。
这句话限制的是本次实验能证明到哪里。它没有证明未来一定做不到，也没有证明现有系统已经进入了自动加速。
系统变得更好，与系统变得更善于让自己继续变好，需要两份不同的证据。
“循环跑起来了”只能说明尝试在连续发生。有效改进能否被识别、保留下来，又能否在下一轮继续发挥作用，才决定这个循环积累了什么。
如果评价标准始终是几道熟悉的题，持续上涨的分数可能来自对这几道题的适配。换成没见过的任务，收益还在，才更有理由认为系统找到了可以迁移的办法。
如果每次升级都使用更多调用和更长运行时间，曲线也可能上涨。那说明投入增加后产出增加，暂时还不能说明每单位研究成本带来的改进更大。
预算和迁移性因此需要与分数一起看。它们让“比上一版强”变成一个有条件、可以核对的判断，而不是只展示最好的一次运行。
“自进化”这个词还容易藏起另一件工作：由谁来决定系统该优化什么。
系统需要一个能比较候选版本的标准。人要选择任务、划定预算、决定什么算成功，还要检查评测是否遗漏了实际需要的能力。这些决定直接影响哪些版本被留下。
只要评测指标留了缝隙，搜索就会学会投机，比如为了跑高特定测试的分数而写出只针对该题的补丁。人需要不断审查和修补标准，才能防止系统绕过真正的问题。
代码由 Agent 修改，不会让这些取舍消失。评测遗漏了什么，自动优化也可能跟着忽略什么。
对使用者来说，这个区别也很实际。一个 Agent 自动改好了自己的工作流，可以先采用这次有效改动。没有必要同时相信，它从此可以无人管理地升级下去。
下一次看到递归自我改进的宣传，我会把结论拆开核对：新版本能否在没参与优化的任务上保持收益；比较时是否计入了完整预算；让它负责下一轮改进时，是否仍有优势。
如果只展示了代码修改和任务分数上涨，就先把结论停在这次能力提升上。