RSI火了，但自进化也会过拟合：Google等提出RRSI，给自进化施加正则化

最近，Recursive Self-Improvement（RSI，递归式自我改进）正在迅速成为 Agent 领域最受关注的方向之一。

过去谈 RSI，我们很容易想到一个颇具未来感的场景：AI 修改自己的模型，再用更强的自己继续改进下一代系统。但真正落到今天的 Agent 上，RSI 已经有了一条更现实的路径 —— 不需要先修改模型权重，Agent 可以先修改 “模型外面的自己”。

Prompt 怎么写、什么时候调用工具、如何管理 Context 和 Memory、失败后怎么恢复、什么时候反思、什么时候停止…… 这些围绕模型构成的 Agent Harness，本身就决定了同一个基础模型最终能做成多少事情。

于是，一个很自然的闭环出现了：Agent 执行任务，观察失败，自动修改 Harness；修改后的 Agent 再执行任务，再根据新的反馈继续修改。这已经是一种真实发生在 Agent system level 的 Recursive Self-Improvement。

但问题也随之而来：如果一个 Agent 一轮又一轮地根据同一批任务修改自己，它到底是在 “进化”，还是只是在越来越会做这套题？

• 论文链接：https://arxiv.org/abs/2609.24972
• GitHub 链接：https://github.com/google-research/rrsi
• 项目主页：https://regularized-rsi.com/

RSI 最大的隐患：越改越强，还是越刷越熟？

现有 Harness Evolution 通常遵循一个很直观的流程：先让当前 Agent 在一组任务上执行，根据成功和失败轨迹产生 feedback；然后让 LLM 修改 Harness，再把新的 Harness 放回同一批任务上评测。分数更高的版本留下来，进入下一轮。

问题是，这批 evolve tasks 会被一遍又一遍地使用。第 1 轮 Harness 的修改来自这些任务，第 2 轮又根据修改后的表现继续优化，第 10 轮、第 30 轮依然如此。整个过程逐渐变成了一个对有限数据持续进行的 adaptive search。

论文指出，这会带来三类耦合问题：benchmark-specific fitting、evaluation noise chasing，以及 complexity accumulation。Agent 可能记住当前 Benchmark 独有的 pattern，也可能把随机涨分误认为真实 improvement，甚至不断增加 Prompt、Context 和控制逻辑，用越来越多的 test-time compute 换取 evolve set 上的一点点提升。

最终就会出现一个非常反直觉的现象：evolve score 持续上涨，但真正离开 Evolution Set 后，收益却迅速缩水，甚至消失。

图 1｜Evolve Set 上的提升，并不等价于 OOD 上的提升。

真正的问题不是 “Harness 能不能持续变高分”，而是这些改动离开反复见过的任务后，还剩下多少。

RRSI：不是限制 Agent 能改什么，而是 Regularize “它怎么改自己”

RRSI（Regularized Recursive Self-Improvement of Agent Harnesses）的关键设计，是没有把 Agent 的自我修改能力锁死。

Prompt 可以改，Control Flow 可以改，Tool 可以改，Memory、Skill、Context Management 可以改，甚至 Subagent 也可以增加或删除。换句话说，Agent 依然拥有一个开放的 self-modification space。

RRSI 真正 regularize 的，是 Agent 在这个空间中 “如何搜索”。它把 Harness RSI 拆成两个问题：Proposal 负责决定 “下一轮应该尝试改什么”，Selection 负责决定 “哪些修改真的有资格成为永久状态”。

图 2｜RRSI 同时 Regularize Proposal 与 Selection，而不是限制 Harness 的可编辑空间。

在 Proposal 端，RRSI 首先限制一次 Self-Improvement 可以同时塞进多少相互纠缠的修改。前期允许更广泛的探索，但随着 Evolution 推进，每一轮允许同时修改的机制越来越少，让后期的每一次变化更容易归因。

同时，它会保留完整的 Evolution History：过去哪个 hypothesis 成功过、哪个机制已经失败过、某次修改增加了多少 score、付出了多少 cost，都会继续成为下一轮 Search 的 evidence。搜索长期停滞时，还会把部分 capacity 转向此前较少被探索的 Harness component。

Selection 端则更加严格：一个 Candidate 并不会因为 “分数涨了” 就自动成为下一代 Harness。Benchmark-specific 的改动会被提前筛掉；落在 evaluation noise 范围里的涨分不会轻易写入永久状态；额外增加的 Context 和 Token 必须用足够的 Performance Gain 证明价值；长期没有贡献的机制还会被直接 Prune。

换句话说，RRSI 不是阻止 Agent 变化，而是要求每一个想永久留下来的变化都 “证明自己”。

一个很反直觉的结果：Evolve Score 更高，反而进化得更差

这篇论文里最值得看的，并不是某个 Benchmark 又涨了几个点，而是下面这组 Ablation。

在 Agentic Workspace 上，如果去掉 Regularization，普通 Unregularized Evolution 可以把 evolve score 推到 92.8，高于 RRSI 的 90.5。如果仍然用传统的 “训练分数越高越好” 来判断，前者看起来显然更成功。

但到了三个完全不参与 Evolution 的 OOD Benchmark，结果反了过来：Unregularized Evolution 的 OOD Average 只有 40.3，而 RRSI 达到 43.6。与此同时，前者每个 Trial 需要 3.80M Policy Tokens，RRSI 只有 2.42M。

也就是说，更高的 Evolve Score 并没有带来更好的 Self-Improvement，反而对应更差的 Transfer 和更高的 Inference Cost。

图 3｜去掉 Regularization 后，Evolve Score 更高，但 OOD 更差、Token 更多。图源：RRSI 论文 Table 2。

对于 RSI 来说，最大化 “眼前的 improvement”，本身就可能是一种 overfitting。

真正重要的是：离开 Evolution Set 之后，还剩下多少？

RRSI 最终在 Coding、Agentic Workspace 和 Engineering Design 三类环境、共 8 个 Benchmark 上进行了验证。

这里最重要的实验设置是：Harness 只在一个 Benchmark 上 Evolution，然后冻结，不再进行任何修改，直接放到整个 Self-Improvement 过程中从未见过的 Benchmark 上测试。

结果显示，Coding 中，从 Terminal-Bench 2.1 Evolution 出来的 Harness，在 SWE-bench Verified 上从 82.0 提升到 83.8；Agentic Workspace 中，JobBench 从 36.0 提升到 40.7，GDPval 从 48.8 提升到 52.3，APEX-Agents 从 34.2 提升到 37.9；Engineering Design 中，Frontier-Eng 从 17.7 提升到 22.0。

最高 OOD improvement 达到 + 4.7 points，并且 held-out splits 全部得到提升。

图 4｜RRSI 在三个 Domain 上都把 Evolution 得到的改进迁移到了未见 Benchmark。

更好的泛化，不需要一个更 “重” 的 Harness

Harness Evolution 还有一个很现实的问题：Agent 完全可以通过不断加入更多 instructions、更多 context 和更多 recovery mechanism，让系统越来越复杂。分数可能因此上涨，但每一次 Inference 也会越来越昂贵。

因此，作者进一步比较了不同 Evolution 方法最终得到的 Harness Cost。结果很直观：RRSI 在 Agentic Workspace 上每个 Trial 大约消耗 2.42M Policy Tokens，而 Unregularized Evolution 达到 3.80M。与其他 Evolved Harness 相比，RRSI 也处在更好的 “更少 Token、更高 OOD” 区域。

这说明 RRSI 并不是靠给 Agent 塞进越来越多东西来获得 Transfer。相反，Regularization 会阻止没有足够收益支撑的复杂度增长，并删除已经不再贡献的机制。

图 5｜横轴为 Policy Tokens / Trial，纵轴为 OOD Average。RRSI 同时获得更高 Transfer 和更低 Inference Cost。

30 轮进化曲线：真正留下来的改动只有 10 次

那么，一次 “被 Regularize 的自我进化” 到底长什么样？

下面这张图展示了 Gemini 3.5 Flash 在 Coding 任务 Terminal-Bench 2.1 上的 30 轮 Harness Evolution。最终，Incumbent Harness 从 64.6 提升到 78.7，一共增加 14.1 points。

但它并不是一路 “见到涨分就收”。30 轮 Evolution 里，真正被接受并成为新 Incumbent 的 Candidate 只有 10 个；还有 9 个 Candidate 没有产生足够的 measured gain，6 个在 Screening 阶段就被拒绝，2 个没有通过 Smoke Test，另外 3 轮没有产生 Proposal。

图中的浅蓝色区域是 noise-adjusted floor。也就是说，Candidate 的分数有一点点变化，并不能说明 Agent 真的进步了。一个修改只有提供了足够可信的 evidence，才有资格进入下一代 Harness。

图 6｜Gemini 3.5 Flash 在 Terminal-Bench 2.1 上的 30 轮 RRSI Evolution Curve。蓝线为 Incumbent，浅蓝区域为 Noise-adjusted Floor。

Recursive Self-Improvement 的重点，不是让更多修改存活，而是让真正有用的修改存活。

RSI 走到下一步，问题已经不只是 “AI 能不能修改自己”

过去，人们讨论 Recursive Self-Improvement 时，最自然的问题是：AI 能不能修改自己？

但当 Harness RSI 真正开始跑起来之后，一个可能更困难的问题正在出现：AI 怎么知道，自己刚刚做出的修改究竟是真正的 Progress，还是一次 Benchmark-specific Optimization？一次分数上涨，是学到了更好的执行机制，还是碰巧利用了 Evaluation Noise？多加一段 Context，到底是在增强 Agent，还是单纯用更多 Test-time Compute 掩盖原来的问题？

如果 Self-Improvement 本身也是一个反复利用有限 Feedback 的 Adaptive Search Process，那么它自然也会遇到机器学习里非常熟悉的问题 ——Overfitting。

RRSI 想传递的核心观点其实非常简单：Self-Improvement 本身，也需要 Regularization。

下一阶段的 RSI，可能不只是追求 Self-Modification。更重要的是 Generalizable Self-Improvement：让 Agent 不只是越来越擅长 “改变自己”，而是逐渐学会判断，哪些改变是真正的进步，哪些改变只是在越来越会做自己见过的题。