Google 提出 RRSI：如何防止 AI 在递归自我改进中“越学越会刷题”？

让 AI 自己改进自己，一直是人工智能领域一个颇具想象力的话题。

经典的递归自我改进（Recursive Self-Improvement，RSI）设想是：一个足够强的 AI 能够改进自身，改进后的 AI 又拥有更强的能力继续改进自己，如此循环下去，能力提升的速度可能越来越快。这也是之前“智能爆炸”讨论背后的基本逻辑。

不过，真正进入 Agent 时代以后，一种更现实的自我改进已经开始出现。

AI 未必需要重新训练自己的模型参数。它可以先修改模型外面的东西，比如提示词、工具、记忆系统、上下文管理方式和任务执行流程。如果新的系统表现更好，就继续以这个版本为基础进行下一轮修改。

最近，Google Cloud AI Research 联合多家高校研究人员发表论文 《RRSI: Regularized Recursive Self-Improvement of Agent Harnesses》，研究的正是这种“系统层面的递归自我改进”。

论文原文（PDF）

但论文关注的重点并不是如何让这种自我改进变得更快，而是一个更基础的问题：

当一个 Agent 的测试成绩一轮比一轮高时，我们如何确定它真的变强了？

因为还有另一种可能：它只是越来越熟悉那套测试题。

今天的 Agent，模型只是其中一部分

理解 RRSI 之前，首先要理解论文里的一个核心概念：Harness。

论文把 Agent 简化成两部分：

Agent = 底座模型 + Harness

底座模型可以是 Claude、Gemini 这样的通用大模型。Harness 则是围绕模型搭建起来的整套运行环境，包括提示词、工具、记忆、Skill、上下文管理、子 Agent，以及各种控制流程。

可以把底座模型理解成一个人的基础智力，把 Harness 理解成这个人的工作环境。

同一个程序员，给他一台只能编辑文本的电脑，和给他完整的 IDE、搜索工具、代码执行环境、知识库以及一套成熟开发流程，最终能完成的任务显然不同。

Agent 也是如此。

今天很多 Agent 产品的能力差异，并不完全来自底层模型，而来自模型外部的工程系统。同一个模型，换一套工具和工作流，最终表现可能差很多。

这也意味着，自我改进不一定非要修改神经网络。

如果一个 Agent 能够分析自己的失败记录，然后修改 Harness，再重新运行任务，它就已经形成了一个最基本的自我改进闭环：

当前系统
↓
运行任务
↓
找到问题
↓
修改系统
↓
再次运行。

如果新的版本更好，就以它为起点继续下一轮。

RRSI 研究的就是这种形式。

它可能只是在反复做同一套题

乍看之下，这套流程没有什么问题。

假设一个 Agent 在 100 个任务上的成功率是 70%。系统分析失败案例后修改提示词，成功率提高到 76%；随后增加一个更合适的工具，成绩提高到 81%；再优化上下文管理，成绩提高到 85%。

如果继续运行几十轮，我们可能得到一条非常漂亮的曲线。

问题在于，这几十轮优化很可能一直在看同一批任务。

第一轮以后，系统已经知道哪些类型的题容易失败；第二轮以后，它又知道哪些特殊情况比较难处理。随着反馈越来越多，测试集中的信息实际上不断进入 Harness 的设计过程。

最终，系统可能会发现某些非常具体的规律。

比如某类任务总会出现一种固定格式，于是在 Prompt 里增加专门处理这种格式的说明；某些任务需要特定的文件搜索路径，于是执行流程逐渐向这些案例倾斜。

每一次修改单独看都很合理，测试成绩也确实在提高。

但如果换一批全新的任务，提升可能突然消失。

这其实就是我们非常熟悉的过拟合，只不过发生的位置从“模型训练”转移到了“Agent 自我改进”。

普通模型训练时，我们知道不能只看训练集成绩，因为模型可能把训练数据学得很好，却无法泛化到新数据。

Agent 自我改进也面临同一个问题，而且可能更加严重。

因为它不是只看一次测试结果，而是反复查看结果，并根据这些结果继续设计下一代系统。每一轮都会把更多测试集的信息带入后续搜索过程。

论文将这种过程称为一种 adaptive empirical optimization，也就是基于经验结果不断调整搜索方向的自适应优化。

这也解释了为什么 RSI 很容易产生一个错觉：

测试成绩在持续上涨，于是我们自然地把它理解成“能力在持续上涨”。

两者实际上并不等价。

RRSI 本质上是给“自我进化”增加实验纪律

RRSI 中第一个 R 代表 Regularized，也就是正则化。

这里不必把正则化理解成复杂的数学方法。它想解决的问题很朴素：

如果允许 Agent 不断修改自己，那么这个修改过程也需要受到一定约束，否则搜索很容易被测试集牵着走。

值得注意的是，作者并没有限制 Agent 能改哪些东西。

Prompt 可以改，Memory 可以改，工具和工作流同样可以改。真正受到约束的是修改的方式以及版本的选择方式。

论文将其分成两部分。

一部分发生在候选方案产生阶段，用来约束“下一步准备怎么改”；另一部分发生在候选版本筛选阶段，用来判断“这个改动是不是真的值得留下”。

这样做的目的，是尽量让每一次改动都有比较清楚的证据，而不是只根据一次分数变化做决定。

前期可以大胆尝试，后期要越来越克制

RRSI 使用的第一个方法叫 Annealed Update Sparsity。

它规定了一件很简单的事情：随着自我改进逐渐进行，每一轮允许修改的组件数量应该减少。

例如在早期，一次可以同时调整 Prompt、Memory 和工具；到了后期，一轮可能只允许修改一个组件。

这种设计主要是为了解决“效果到底来自哪里”的问题。

假如一次更新同时做了五项修改，最终成绩提高了 4%，我们很难知道这 4% 到底来自哪一项。其中甚至可能有两项修改其实造成了负面效果，只是被另外几项提升掩盖了。

到了自我改进后期，这种问题会越来越严重。因为系统已经比较成熟，新的改动通常很细小，如果同时改变太多地方，很容易把偶然波动误认为真正的优化。

因此 RRSI 选择让搜索逐步收敛。

前期仍然保留较大的探索空间，因为这时候我们还不知道问题主要在哪里；到了后期，则要求系统更谨慎地验证单个假设。

这和软件性能优化很相似。

刚开始可以重构整个架构，但当系统已经接近稳定时，如果想确认究竟是什么让延迟降低了，就最好一次只动一个变量。

自我改进还需要“记住哪些路走不通”

另一个有意思的设计是，RRSI 会把过去的修改记录下来。

Agent 不只是知道“当前版本是什么样”，还能够看到此前尝试过什么、修改的理由是什么、最终性能如何，以及这次修改有没有被接受。

这看起来是一个很普通的工程设计，却解决了自动优化系统里一个常见的问题：重复犯同一种错误。

例如系统曾经尝试增加一层额外的反思过程，结果发现既增加了成本，也没有改善任务成绩。

如果没有历史记录，过几轮之后另一个 proposer 很可能再次提出一个本质相同的方案，只不过换了一种表述。

长期运行以后，大量计算都会消耗在重复探索已经失败过的方向上。

RRSI 希望把这个过程变得更像真实的研发工作。实验失败并不是白费，它会成为下一轮搜索的证据。

换句话说，自我改进不仅要有记忆模块服务于任务本身，还需要有一套关于“自己如何改过自己”的记忆。

如果一直改 Prompt 没效果，就应该去别的地方看看

递归优化还有一个问题：很容易产生路径依赖。

比如最开始改 Prompt 带来了明显收益，后面的系统就可能持续围绕 Prompt 优化。几轮以后，真正的瓶颈也许已经变成了工具能力或上下文管理，但搜索仍然停留在原来的方向。

RRSI 会判断最近若干轮是否仍有明显提升。

如果改动带来的收益已经落入正常噪声范围，系统就认为当前搜索方向可能已经进入平台期，并主动将部分候选方案放到过去较少探索的组件上。

这里其实没有特别复杂的理论。

它只是承认了一件现实中的事情：

一个曾经有效的优化方向，并不会永远有效。

自我改进如果只是不断加深同一个方向，本质上仍然可能是局部搜索。真正想获得新的能力，有时候需要跳出已经熟悉的修改空间。

更关键的问题，是哪些改动有资格进入“下一代”

前面的机制主要负责产生候选方案。

但对于递归自我改进来说，更关键的一步其实发生在后面：选哪个版本继续往下走。

普通的软件实验里，一次失败更新可以简单回滚。

但在 RSI 中，被选中的版本会成为下一轮的起点。如果某个错误改动被误认为进步，它不仅影响当前版本，还会改变之后整个搜索轨迹。

因此 RRSI 对候选版本设置了几道额外门槛。

其中第一道是检查候选方案是否出现了针对 benchmark 的特殊适配。

例如修改后的代码中出现具体任务名称、特殊数值，或者明显针对某几个测试案例写死的逻辑，系统会直接拒绝这个版本。

更有意思的是，论文要求这种检查发生在正式评分之前。

原因在于，即使最后不采用一个“投机取巧”的版本，如果系统已经知道这个版本获得了很高的分数，这个信息仍然可能影响后续搜索。

下一轮 proposer 会看到：“刚才那个方向好像特别有效。”

于是测试信息还是通过反馈渗透进了之后的自我改进过程。

所以作者索性不让这类候选版本看到正式结果。

有时候涨了 0.5 分，其实什么都没有发生

第二道门槛来自大模型评测本身的随机性。

同一个 Agent 多跑几次，成绩可能自然上下波动。比如一次得到 83.1，一次得到 84.0，下一次又变成 82.8。

这时候，新版本如果得到 83.6，很难说它真的比原来的系统更强。

RRSI 因此会先估计评测本身大致存在多大的噪声。

只有当变化超过这个范围以后，系统才会更有把握地认为某个修改产生了真实影响。

这对长期自我改进尤其重要。

因为一次 0.2 分的误判看起来微不足道，但如果几十轮都允许这种误差进入下一代，整个系统可能在不知不觉中偏离原来的能力水平。

问题并不一定表现为某一轮突然大幅退化，而可能是大量几乎无法察觉的小错误逐渐累积起来。

Agent 变强了，还是只是变贵了？

RRSI 还把计算成本放进了版本筛选过程。

这点对于今天的 Agent 特别重要。

一种非常直接的“增强 Agent”方法，是让它做更多事情：增加反思次数，增加重试，引入更多子 Agent，最后再用一个 Judge 做选择。

这样确实可能提高成功率。

但如果任务成绩只提高了很少，Token 消耗却增长几倍，就很难说这是一次高质量的能力改进。

从系统角度看，它更像是用额外算力换取了更高的成功率。

因此 RRSI 要求性能收益和复杂度增长之间保持一定比例。

大的性能提升可以容忍更多额外计算，小的性能提升则不能带来过高成本。

论文实际上是在试图区分两个经常被混在一起的概念：

系统本身变得更有效，和系统只是投入了更多推理资源。

这也是 Agent 评测越来越需要关注的问题。如果只看最终成功率，很容易把计算扩张误认为智能提升。

自我进化不能只会“加东西”

RRSI 还有一个很有工程味道的机制：结构裁剪。

Agent 优化天然容易出现一个趋势：系统越来越复杂。

遇到一种失败，加一段提示词；又遇到一种失败，增加一个 Skill；再出现问题，引入新的 Memory 或 Subagent。

长期迭代之后，Harness 很容易积累大量历史遗留结构。

问题是，有些组件可能只在某一阶段有用，后来已经没有实际贡献，却因为没有人主动删除而一直留在系统里。

RRSI 会跟踪组件最近是否持续产生正面收益。如果没有足够证据表明某个结构仍然有用，就尝试删除它，再观察性能变化。

这和软件工程中的代码清理很像。

真正成熟的系统优化，并不是功能越堆越多越好。有时删除一个已经失去价值的模块，反而能降低复杂度，让后续优化更容易判断。

最高的测试分数，并没有带来最好的泛化

RRSI 最值得关注的一组结果来自 Harvey LAB。

作者比较了未经约束的自我改进和 RRSI。

在用于自我进化的 benchmark 上，无约束方案最终达到了 92.8 分，高于 RRSI 的 90.5 分。

如果实验到这里结束，我们很容易得出一个结论：

RRSI 的各种限制拖慢了进步。

但当作者把两个系统放到此前没有参与优化的新任务上时，情况发生了变化。

原始 Agent 的 OOD 平均成绩是 39.7 分。

经过无约束自我改进后，成绩只提高到 40.3 分。

RRSI 则达到 43.6 分。

更值得注意的是，无约束方案每次实验消耗的 Token 从大约 156 万增加到了 380 万；RRSI 最终约为 242 万。

也就是说，那个在原测试集上进步最多的 Agent，同时也积累了更多系统复杂度和计算成本，但这些改动并没有很好地转化成面对新任务时的能力。

这组结果把整篇论文的问题说得很清楚：

benchmark 上的自我改进幅度，并不能直接代表可迁移能力的增长。

一个比“能不能自我改进”更难的问题

过去谈 RSI 时，人们经常把问题概括为：

AI 能不能改进 AI？

如果答案是肯定的，那么下一步自然会讨论这种改进是否会持续加速，最终走向所谓的“智能爆炸”。

RRSI 提醒我们，在这两个问题之间其实还缺少了一层：

我们如何确认每一轮所谓的“自我改进”都是真实的？

只要系统存在明确的评价指标，就会存在针对指标本身进行优化的可能。

学校如果只看考试成绩，教学就可能变成押题；公司只看某项 KPI，员工自然会围绕 KPI 调整行为。

Agent 也一样。

如果它能够反复查看 benchmark 反馈，又被要求持续提高 benchmark 分数，那么随着迭代次数增加，它越来越适应 benchmark 几乎是必然结果。

所以未来研究 RSI，不能只观察一条不断上涨的能力曲线。

我们还必须知道，这些提升能不能迁移到新任务，背后增加了多少计算成本，每一项改动的贡献是否能够解释，以及系统是不是在积累越来越多只对当前评测有效的结构。

从这个角度看，RSI 不只是一个“如何优化”的问题。

它同时也是一个如何测量进步的问题。

距离真正的“智能爆炸”，RRSI 还有很远

需要强调的是，这篇论文研究的 RSI 和科幻意义上的“AI 不断重写自己”还有明显区别。

实验中的底座模型保持不变。

Agent 修改的是模型之外的运行系统，而不是自己的神经网络参数。它没有重新训练下一代模型，也没有自主发明新的训练算法。

因此更准确的说法是：

RRSI 研究的是 Harness 级或者系统级的递归自我改进。

不过这种形式反而可能更接近短期现实。

修改 Prompt、工具、Memory 和工作流，要比训练一个新的前沿模型容易得多。今天的 Agent 已经能够编写代码、修改配置、创建工具并分析自己的失败记录，把这些能力组合起来，就具备了初步修改自身运行系统的条件。

所以真正值得关注的问题可能不是：

“什么时候 AI 才能完全重写自己？”

而是一个已经开始出现的问题：

当 Agent 可以长期修改自己的运行方式以后，我们应该怎样控制这条进化轨迹？

自我改进首先要解决“什么才算进步”

RRSI 并没有证明 AI 已经进入了真正意义上的递归智能爆炸。

它做的事情其实更基础。

论文告诉我们，当 AI 开始参与自身系统设计以后，最大的困难之一并不是让测试成绩继续上涨。只要不断观察失败案例、增加工具和调整流程，让 benchmark 分数变高往往并不困难。

困难的是判断这些变化究竟有没有形成真正可以迁移的能力。

一个长期运行的自我改进系统，如果没有这种判断能力，完全可能在每一次迭代中都有看似合理的进步，最后却只是越来越适应自己的评价体系。

所以，递归自我改进真正需要解决的第一个问题，也许不是：

AI 能不能让自己变得更强？

而是：

当 AI 说自己已经变强时，我们凭什么相信它？