Agent改自己的外壳，先要防止对着评测题投机

论文 / Agent系统 · 8.8/10 · 奇怪但可能重要

RRSI研究的是一个很现实的问题：同一个基础模型，换一套提示词、工具、控制流、记忆和上下文管理，表现可能相差很大。既然这些部件可以改，能否让Agent自动分析失败、提出修改、跑评测，再把更好的版本保留下来？

困难也很直接。如果系统始终对着同一批任务演化，它很容易记住评测细节，或塞进只对某套数据有效的规则。训练集上进步很大，换到新任务就消失。RRSI没有把可修改范围锁死，而是约束搜索过程：早期每次只准改少量部件；完整记录试过的假设，避免反复走同一条死路；由critic先检查是否出现基准专用逻辑；小于评测噪声的提升不算数；新增token成本必须换来足够收益；长期无效的部件会被裁掉。

结果显示，Terminal-Bench 2.1从74.2升到80.2，分布外的SWE-bench Verified从82.0升到83.8；工作类任务中JobBench从36.0升到40.7；工程设计的Frontier-Eng从17.7升到22.0。论文总结，搜索集最高提升14.1个百分点，五项分布外评测最高提升4.7个百分点，同时比未正则化的演化少用30%策略token。

分布外提升明显小于搜索集提升，这不是可以略过的小字，恰好是论文要解决的核心。它说明Agent外壳确实能被自动优化，也说明“在一个榜上变强”和“得到可迁移的新能力”仍有距离。

还要避免把它写成“模型独立完成自我进化”。基础模型是冻结的，搜索中的policy、proposer、analyst和critic主要使用Claude Opus 4.8，部分评审使用Gemini 3.5；完整运行还需要多套基准、容器和大量调用。它更像一套自动化Agent工程系统：每个修改都有假设、代码diff、成本和外部测试，过程能被审计，也能回滚。

这篇论文在北京时间9月22日01:54提交，比本期严格窗口早约5小时，因此列作近期补看。代码已经开放，下一步最值得看的是别的团队能否在新领域复现，以及搜索本身的费用是否低于它带来的长期收益。