论文综述：Dream-RSI——在「演化世界」里做梦式自我改进

一、论文是干什么的？

设想一个AI智能体正在做「自动化科学发现」的工作：帮你找出效果更好的算法、设计更精巧的数学构造，或者写出跑得更快的GPU代码。这类工作通常需要不断尝试——写一个方案、测一下效果、再根据反馈改进方案，如此循环成千上万次。真正决定效率的，往往不是「写代码的那个智能体」本身写得好不好，而是「探索策略」：先试哪个方向、要不要同时铺开多条路线并行尝试、什么时候该放弃一条没希望的分支、什么时候该收手。

问题在于，这个「探索策略」本身也需要被改进，但改进它非常昂贵：你得把一个新策略真的拿去跑一遍完整的发现流程，可能要等上成百上千轮「生成—评测」循环，才能知道这个策略到底好不好。这就好比每次想知道一张新地图画得好不好，都得重新去爬一次山。

Dream-RSI要解决的正是这个问题。它的核心比喻很直观：登山者第一次探索一片陌生山区时，会走弯路、碰死胡同、来回折返，但只要把这次探索的完整轨迹记录下来，画成一张地图，以后就不用真的再爬一次山了——可以直接在脑子里「回想地图」，试着想象走另一条路线会不会更快，这就是论文里说的「做梦」（dreaming）。Dream-RSI把智能体过去真实探索留下的完整历史，变成一个可以免费反复「回放」的模拟世界，让系统在这个模拟世界里做梦式地试验成千上万种不同的探索策略，挑出表现最好的一个，再把它派到真实世界里去继续探索，如此循环，逐步实现探索能力本身的「递归自我改进」（Recursive Self-Improvement，RSI）。

二、核心方法与创新

Dream-RSI把整个系统拆成一个不断循环的三段式流程：① 在线探索（Online Explore），② 构建回放模拟器（Construct Replay Simulator），③ 做梦式策略改进（Dreaming-based Policy Improvement）。

发现树（discovery tree）是一切的基础。 智能体每一次真实探索，都会在一棵树上不断长出新节点：每个节点代表一次「尝试」，保存了当时的工作空间快照、生成的代码或方案、评测诊断信息，以及一个打分 $s_v$ 。整个系统有一个统一的「决策接口」：探索策略每一轮观察当前这棵树，从「可继续扩展的节点集合」（根节点加上所有当前的叶子节点）里选出一批节点，分配给若干个并行的「工人」（worker，实际上就是并发的模型调用）。每个被选中的节点会让底层的编码智能体（discovery agent）读取该节点保存的历史，生成一个新的候选方案，再由评测器（evaluator）打分，从而长出新的子节点。这套接口在「真实在线探索」和「回放做梦」两种模式下是完全一样的，区别只在于新节点是真的被生成出来，还是从历史记录里直接读出来。

在线探索阶段：当前的探索策略指挥编码智能体，在真实世界里跑若干轮，得到一棵完整的发现树，同时把所有尝试的完整轨迹都记录下来。这一步是唯一「花真钱」的环节。

构建回放模拟器：把这棵记录完整的发现树，直接变成一个可重复使用的「世界」。因为树上每个节点的结果都已经保存好了，任何一个新策略想知道「如果我这样探索会怎样」，只需要读取历史记录，不需要重新调用编码智能体或评测器，因此评估一个新策略的代价几乎为零。

做梦式策略改进（核心机制）：给定一批历史发现树，做梦时策略会从空树（只有根节点）出发，一轮一轮地做决策——选一批要继续探索的节点；但这一次，「继续探索」不再是真的生成新方案，而是直接把历史树里对应位置早已存在的子节点「揭示」出来。这个做梦过程最多进行 $K_2$ 轮，一旦策略选择了空的批次，或者整棵历史树已经被完全揭示，就提前终止。

论文给出了具体的「回放目标函数」（原文公式1），用来给每一次做梦的表现打分：

V_i^m = \max_{v \in \mathcal{T}_i^{m,k_i^{m,\star}}} s_v \;-\; \beta_1 N_i^m \;+\; \beta_2 \frac{N_i^m}{\max\{1, k_i^{m,\star}\}}

这个公式由三部分组成：第一项是做梦过程中挖到的最好方案的分数（发现质量）；第二项用系数 $\beta_1$ 惩罚「揭示了多少个节点」（相当于惩罚计算成本，揭示的节点越多，代表如果这是真实探索会花掉越多次生成—评测调用）；第三项用系数 $\beta_2$ 奖励「平均每一轮决策揭示了多少个节点」（鼓励策略把多个尝试打包成一批并行执行，而不是一个一个慢慢来）。一个策略版本在多棵历史树上做梦的平均分记为 $V^m$ 。

策略是怎么被改进的：系统里有一个「策略开发智能体」（policy-development agent），它会去看当前策略版本做梦时留下的完整轨迹和得分，分析哪些决策是成功的、哪些反复失败，然后修改探索策略的可执行代码，产出下一个候选版本。这个过程重复 $M$ 次，得到 $M$ 个候选策略，每一个都会在同样的历史树集合上重新做梦评分一遍，最终选出平均得分最高的版本作为下一轮要真正部署到线上的策略。由于当前策略本身也是 $M$ 个候选之一，这保证了新策略的做梦得分不会比旧策略差，从理论上给出了「只会变好、不会变差」的保障。

这个设计最重要的一点是：整个自我改进只发生在「探索策略」这一层可读、可编辑的代码逻辑上，负责真正生成候选方案的底层编码智能体（Gemini模型本身）完全没有被重新训练或修改权重。也就是说，Dream-RSI改的不是模型「脑子」，而是「怎么安排模型去尝试」的调度逻辑——这让整个自我改进过程变成一份可以像代码diff一样审查的东西，而不是黑箱式的权重更新。

三、使用了哪些模型和计算资源？

驱动编码智能体（discovery agent）的基座模型：论文通过Gemini CLI（geminicli.com）调用Gemini-3.1 Pro和Gemini-3.7-Flash两个模型，分别在算法工程、数学优化、GPU核函数工程三个领域里担任实际「写代码、提方案」的智能体。论文没有单独说明「策略开发智能体」（负责改写探索策略代码的那个角色）具体用的是哪个模型版本，大概率也是通过同一套Gemini CLI体系调用，但原文没有逐一注明，这一点暂无更明确的信息。

对比基线用到的模型：SimpleTES基线使用GPT-OSS-120B；数学优化任务的其他对比系统里，TTS-Discovery用Qwen3-8B，ThetaEvolve用蒸馏版的Distilled-Qwen3-8B，EvoX用Gemini-3.0-Pro，AlphaEvolve和AlphaEvolveV2用Gemini-2.0 Pro与Gemini-2.0 Flash的组合。

计算资源：论文全文没有提到任何具体的GPU型号（没有出现H100、A100等字样），也没有说明背后跑Gemini模型用了多少张卡、什么机房。所有的「计算量」都是通过云端API调用（Gemini CLI）完成的，论文用「并行worker数量」来描述并发规模，例如Lasso任务里Gemini-3.1 Pro配置为10个并行工作区，Gemini-3.7-Flash配置为32个并行工作区，但这些worker对应的是并发API请求数，而不是本地硬件数量。因此，硬件层面的信息，论文中未明确说明。

每次探索的成本与节省数值：论文全程用「发现智能体调用次数」（discovery-agent calls，也就是生成—评测的轮次数）作为衡量探索代价的指标，没有报告绝对的墙钟时间（wall-clock time）或美元成本。具体数值如下：

在Lasso正则化路径求解任务中，固定探索策略下Gemini-3.1 Pro每轮用10个并行工作区、最多11步精炼，即每轮110次调用，5轮共550次调用；Dream-RSI把总调用数降到317次，减少约42%，同时下游六个数据集上的平均求解耗时也从3587.1毫秒降到2931.0毫秒。
同一任务下Gemini-3.7-Flash版本：固定策略每轮32个工作区、最多20步，即每轮640次调用，5轮共3200次；Dream-RSI降到1879次，减少约41%，平均耗时从2516.7毫秒降到2350.6毫秒。
作为参照，SimpleTES基线固定使用51200次生成，对应的平均耗时是3804.8毫秒；传统求解器sklearn和glmnet则分别需要44180.3毫秒和13767.5毫秒（这两个是直接调用现成库，不涉及「探索次数」）。
在三个数学优化任务（Sum-Difference、圆堆积Circle Packing、自相关不等式Autocorrelation）上，Dream-RSI用Gemini-3.1 Pro跑10轮递归发现，总生成次数控制在1000次以内，而SimpleTES基线固定消耗51200次生成，相当于节省超过50倍的计算预算。
在GPU核函数任务（KernelBench的VGG16、LayerNorm、ConvDiv、ConvMax）上，Dream-RSI要达到和基线相当的性能，VGG16只需约2.43倍更少的生成次数，LayerNorm约需1.79倍更少；在相同生成预算下，ConvDiv的性能能提升约2.09倍，ConvMax约提升1.44倍。

需要提醒的是，摘要里最醒目的「162倍」这个数字，对应的是Dream-RSI相对SimpleTES（用能力较弱的GPT-OSS-120B、固定跑满51200次生成）的节省幅度；而在使用完全相同底座模型、相同每轮预算的「固定探索策略」这个更公平的对照组面前，Dream-RSI节省的调用次数大约是1.7倍左右（即上文550降到317、3200降到1879这两组数据）。这个细节在后面网络讨论部分也有人专门指出。

四、实验结果

Dream-RSI在三个差异很大的领域里做了验证，一共覆盖8个具体的发现任务。

算法工程（Lasso正则化路径求解）：目标是自动写出一个又快又准的Lasso求解器代码。下表是几种方法在6个下游数据集上的平均运行耗时（毫秒，越低越好）：

方法	使用模型	探索计算量（调用次数）	平均运行耗时（毫秒）
sklearn	–	–	44180.3
glmnet	–	–	13767.5
SimpleTES	GPT-OSS-120B	51200	3804.8
固定探索策略	Gemini-3.1 Pro	550	3587.1
Dream-RSI	Gemini-3.1 Pro	317	2931.0
固定探索策略	Gemini-3.7-Flash	3200	2516.7
Dream-RSI	Gemini-3.7-Flash	1879	2350.6

可以看到，Dream-RSI不仅用更少的探索次数超过了传统求解器和SimpleTES基线，比起用同一个模型、同样预算的固定探索策略，也做到了「更省更好」。

数学优化：在Sum-Difference（离散组合优化）、圆堆积（几何优化）、自相关不等式（函数优化）三个任务上，Dream-RSI和一大批公开的自动发现系统（AlphaEvolve、AlphaEvolveV2、OpenEvolve、CodeEvolve、ShinkaEvolve、TTS-Discovery、ThetaEvolve、EvoX、SimpleTES）做了对比。结果是：Sum-Difference上Dream-RSI取得了所有方法里最好的成绩（1.145427，越高越好）；圆堆积上多家方法（包括Dream-RSI）都打平在同一个已知的最优值2.635983附近；自相关不等式上（越低越好）Dream-RSI是1.456375，比SimpleTES的1.453675略高一点，也就是这一项上Dream-RSI其实比SimpleTES略逊一筹，但要注意Dream-RSI全程只用了不到1000次生成，而SimpleTES固定消耗了51200次——用远小的计算量做到「总体持平甚至更好」，是论文强调的重点，但严谨地说并非在每一项指标上都全面胜出。

GPU核函数工程：在KernelBench的VGG16、LayerNorm、ConvDiv、ConvMax四个代表性任务上，Dream-RSI与「固定探索策略」对比：在VGG16和LayerNorm上，Dream-RSI能用更少的生成次数（分别约2.43倍和1.79倍更少）达到相近的核函数执行速度；在ConvDiv和ConvMax上，给定相同的生成预算，Dream-RSI能分别把性能进一步提升约2.09倍和1.44倍。

五、潜在应用与已落地应用

潜在应用方向：这套「把历史探索变成免费模拟器」的思路，理论上能用在任何「评测代价高、需要长时间试错」的智能体工作流上，例如自动化机器学习流水线搜索、芯片/电路设计的自动搜索、新材料或新分子的计算发现、更广义的科学假设生成与验证智能体，乃至强化学习环境本身的自动设计。因为它不需要改动底层编码智能体的参数，理论上可以作为一层「外挂调度层」，直接叠加在现有的编码智能体产品上，不需要重新训练模型。

已落地或已公开的部分：论文作者搭建了一个项目主页与交互式演示，见dream-rsi.com；代码仓库已在GitHub建立，但截至综述撰写时（2026年9月18日），仓库README显示代码仍在「准备发布中」，已发布的是论文PDF和交互演示页面，完整代码库、复现脚本和「发现出的具体程序代码」都还未公开。由于作者团队包括Google与Google DeepMind的研究人员，这项工作也被视为Google内部关于智能体自我改进方向的一次公开研究成果展示。

六、网络上的讨论与评价

这篇论文在HuggingFace论文页面获得了295个点赞，属于近期热度较高的论文之一。通过搜索能找到以下几类讨论：

一些聚合与索引类站点（如alphaXiv、HyperAI）收录了这篇论文的基本信息和摘要转载；日本的机器学习论文笔记社区仓库（GitHub上的AkihikoWatanabe/paper_notes第6577号issue）也做了阅读笔记式的记录。
加密与科技新闻站点cryptobriefing.com发了一篇报道，标题直接采用了论文摘要里最抓眼球的说法——「Google的Dream-RSI把发现智能体调用次数降低了162倍」。
相对更深入的评论来自AI安全研究博客CellCog（cellcog.ai），这篇博客的态度比较正面但也给出了几点值得注意的提醒：第一，它指出「162倍」这个headline数字只是相对于用较弱模型GPT-OSS-120B、且固定跑满51200次生成的SimpleTES基线而言，如果换成用完全相同的Gemini底座模型做对照（固定探索策略），Dream-RSI真实节省的调用次数其实只有大约1.7倍，这个差距值得读者注意；第二，博客提醒论文里所有实验都是「用Google自家的Gemini模型去改进Google自家的发现系统」，独立第三方复现会很重要；第三，代码截至该文发布时仍未公开。这篇博客还从AI安全角度做了引申，认为Dream-RSI把自我改进限制在「可读、可审查的探索调度代码」这一层，而不是直接修改模型权重，这种「看得见的自我改进」路线，恰好呼应了此前Anthropic首席执行官Dario Amodei公开把递归自我改进列为重点关注方向后业内的讨论，但博客也明确说明这并不等于从设计上就自动保证了安全性。

七、思维导图

mindmap
  root((Dream-RSI 递归自我改进))
    研究背景与问题
      固定探索策略成本高 需真实生成-评测才能验证好坏
      核心洞察 已完成的discovery tree可当replay simulator做零成本off-policy评估
    方法与技术贡献
      三阶段递归循环
        Online Explore 在线探索生成historical trace
        Construct Replay Simulator 构建可复用模拟器
        Dreaming-based Policy Improvement 做梦式改进
      发现树与Dreaming机制
        节点保存工作区快照、artifact、评测诊断与分数
        做梦从空树出发 最多K_2轮 直接揭示历史子节点
      Replay目标函数（公式1）
        发现质量项取已揭示节点的最高分
        执行成本项按揭示节点数加权惩罚
        并行奖励项鼓励每轮批量揭示更多节点
      策略改进与选择
        policy-development agent读取轨迹改写策略代码
        生成M个候选版本 重新做梦评分选出V^m最高者
        新策略不劣于旧策略的理论保证
    实验设计与结果
      算法工程 Lasso正则化路径
        Gemini-3.1 Pro 550到317次调用 减少约42%
        Gemini-3.7-Flash 3200到1879次调用 减少约41%
        耗时2931.0ms 对比固定策略3587.1ms
      数学优化 Sum-Difference/圆堆积/自相关不等式
        Gemini-3.1 Pro 10轮少于1000代 对比SimpleTES 51200代
        Autocorrelation指标上略逊于SimpleTES
      GPU核函数工程 KernelBench
        VGG16 2.43倍更少生成 LayerNorm 1.79倍更少生成
        同预算下ConvDiv提升2.09倍 ConvMax提升1.44倍
    理论分析与洞察
      探索策略与底层Gemini编码智能体解耦 可像代码diff一样审查
      162倍(对比弱基线SimpleTES)与1.7倍(对比同底座固定策略)的区别
    影响与展望
      潜在应用 AutoML流水线搜索/芯片电路设计/科学假设验证智能体
      局限 未披露GPU硬件与墙钟时间 代码尚未公开 实验全部基于Gemini自家模型