先看证据
把机制串起来
LLM智能体的能力不只来自模型权重，还来自包围模型的“harness”：提示词、工具、控制流、记忆和上下文管理。RRSI不训练模型，而是让外循环修改这些组件，并在任务上反复评估。问题在于，若始终用同一批任务选优，系统可能记住题目而不是学会可迁移的工作方法。
RRSI仍允许修改提示词、工具、记忆、控制流和子智能体，但限制搜索过程：早期用余弦退火允许多项编辑，后期收紧为更容易归因的单项编辑。每个候选都记录修改组件、假设、差异、得分变化和成本变化，提议器据此避免重试已被证伪的思路；停滞时再把预算转向尚未探索的组件。泄漏批评器在评测前拦截任务名、实体、答案及基准专用逻辑，噪声地板则用未修改基础harness的方差估计随机波动，只有超过该波动的收益才算进步。额外推理token必须由实测收益抵偿，不再产生收益或收益过小、过贵的组件会成为剪枝
['适合冻结模型、可反复执行任务的智能体工程优化', '先保留未修改基线，估计方差后再设收益门槛', '编码场景需Docker与harbor，候选以独立worktree评测', '不适合缺少稳定评测集或收益噪声极大的任务']
变化不在模型权重，而在模型外壳
Google Cloud AI Research 联合北卡罗来纳大学教堂山分校、斯坦福大学和圣路易斯华盛顿大学，开源了 RRSI，也就是 Regularized Recursive Self-Improvement。它面向的是一个具体问题：让大语言模型智能体修改自己的提示词、工具、记忆、控制流和子智能体配置，但不更新模型权重。换句话说，RRSI改造的不是模型本身，而是模型工作的“外壳”，也就是通常被称为 harness 的那套运行结构。
这一区别值得读者先记住，因为它改变了自我改进的工程边界。传统意义上的训练需要数据、梯度和权重更新，RRSI则把改进变成对可执行系统的递归搜索。智能体可以提出新的配置和工作流，再由框架运行、比较并保留候选方案。问题随之从“模型能不能学会”转成“搜索过程会不会只学会当前评测集”。
固定评测集会把自我改进变成记忆竞赛
没有额外约束的 harness evolution 循环通常很直接：系统在一组固定的 evolve tasks 上提出修改，运行候选方案，留下得分最高的那个，然后重复这个过程。隐患也正来自这里。每一轮都反复接触同一批任务，智能体可能逐渐适配题目名称、实体、答案模式或基准特有的逻辑，而不是形成能迁移到新任务的能力。
RRSI把这类失败拆成三种来源。第一是 benchmark-specific fitting，也就是针对基准特征拟合。第二是 noise chasing，即把随机波动误判为真实进步。第三是 complexity accumulation，即工具、提示和工作流不断叠加，系统变得更重，却没有可靠的收益。这三种问题都会扩大 evolve-set 分数与真实迁移效果之间的差距，因此框架的核心不只是“提出更多编辑”，而是限制哪些编辑值得继续搜索。
RRSI把搜索过程本身加上了“正则化”
RRSI的做法不是冻结 harness，而是约束它如何变化。早期轮次使用退火式编辑预算，允许一次组合多个修改，帮助系统探索较大的设计空间。随着搜索推进，预算收紧到一次只允许一个可归因的变化，这让后续分数变化更容易对应到具体组件。每个候选方案还会记录修改组件、原始假设、代码或配置差异、分数变化和成本变化，提议器可以读取这份证据账本，避免重复尝试已经被证伪的想法。
框架还设置了几道相互配合的门槛。泄漏 critic 会在评分前拒绝包含任务名称、实体、答案或基准专用逻辑的编辑。噪声调整后的 floor 要求收益超过未修改基础 harness 的方差，而成本规则要求额外推理 token 必须由可测量的收益支付。停滞发生在噪声范围内时，预算会转向此前没有被触碰的组件。长期不再带来收益的组件则会成为 pruning 的对象。研究团队把编辑预算、剪枝和成本规则分别类比为 L0、L1 和 L2 正则化，但这里的“参数”不是模型权重，而是智能体系统的结构复杂度、保留组件和推理开销。
分数提升的关键，不是单一基准上的冠军
在 Claude Opus 4.8 作为策略模型时，Terminal-Bench 2.1 的 evolve split 从 74.2% 提升到 80.2%。更重要的是，SWE-bench Verified 没有参与选择，却从 82.0% 上升到 83.8%。在分布外任务上，JobBench、GDPval 和 APEX-Agents 分别提升 4.7、3.5 和 3.7 个百分点。EngDesign 的 evolve split 提升 4.9 个百分点，Frontier-Eng 提升 4.3 个 Medal points，Harvey LAB 则在 evolve split 上提升 1.1，在 held-out split 上提升 2.3。材料给出的结论是，6 个 held-out split 全部改善。
结果并不只依赖这一种模型。以 Gemini 3.5 Flash 作为 policy 时，Terminal-Bench 2.1 从 64.6% 提升到 78.7%，SWE-bench Verified 从 76.8% 提升到 79.0%。同时，agentic workspace 实例中，RRSI 每次 trial 使用约 242 万 policy tokens，未正则化的 evolution 使用约 380 万。研究摘要将其表述为少 30%，项目页面则写作少 36%，这两个数字存在口径差异，不能在没有原始计算细节的情况下当作同一个精确结论。更稳妥的判断是，RRSI在报告的实验中同时取得了迁移收益和更低的策略 token 消耗。
对工程团队来说，它更像评测基础设施而非自动升级按钮
RRSI的部署形态也说明了它的定位。代码以 Apache 2.0 开源，要求 Python 3.10 以上，接受 LiteLLM model string，默认配置假设使用 Vertex AI 上的 Claude Opus 4.8。典型代码路径是先执行 `python3 rrsi.py --domain coding baseline` 建立基线，再执行 `python3 rrsi.py --domain coding run` 启动搜索。每轮会在独立的 git worktree 中生成两个候选方案，完成筛选和评估后，把分支快进到胜者。coding 实例还需要 Docker 和 harbor，其他领域则通过一个 adapter module 接入。
这对技术负责人的实际含义很具体。团队可以把提示词、工具编排、记忆策略和控制流当成可版本化的系统组件，要求每次改动都留下假设、差异、得分、成本和迁移证据，而不是凭一次演示决定升级。RRSI适合用来研究“怎样改 harness 才能泛化”，不适合直接替代生产环境的发布门禁。它仍然依赖评测集设计、候选预算、模型策略和执行环境，开源项目也被明确定位为 research-grade，而不是官方 Google 产品。