Dream-RSI: Recursive Self-Improvement through Evolving Worlds

论文阅读：Dream-RSI——通过演化世界实现递归式自我改进

论文标题：Dream-RSI: Recursive Self-Improvement through Evolving Worlds
作者：Tong Zheng, Xidong Wu, Zheng Zhang, Zhankui He, Chaoyi Zhang, Benjamin Coleman, Ruoqiao Wei, Di Bai, Haolin Liu, Rui Liu, Xue Wang, Yue Zhuan, Wang-Cheng Kang, Renkai Xiang, Heng Huang, Xinwu Cheng, Yunsong Guo
作者单位：Google、Google DeepMind、University of Maryland, College Park、University of Virginia
发表位置：arXiv preprint，cs.CL，v1，2026-09-14
arXiv 编号：2609.14858
原文链接：https://arxiv.org/abs/2609.14858
项目主页：https://dream-rsi.com
官方仓库：https://github.com/zhengkid/Dream-RSI
主题：Recursive Self-Improvement、LLM Agent、探索策略、Scientific Discovery、Replay Simulator
核心问题：如何利用已经产生的搜索历史，以低成本反复评估和改进“如何探索”的策略，而不需要每修改一次探索策略就重新执行一次昂贵的真实搜索？

1. 引言：真正需要改进的，不一定是解题 Agent

很多使用 LLM Agent 进行科学发现、算法优化或代码优化的系统，都可以抽象成一个不断重复的过程：

提出候选方案
    ↓
实际运行 / 评测
    ↓
得到结果和反馈
    ↓
继续修改
    ↓
再次运行
    ↓
……

当任务足够困难时，这个过程可能持续成百上千次。

论文将这种过程称为 long-horizon discovery，即长时间跨度的发现过程。

随着 discovery 规模变大，一个越来越重要的问题出现了：

Agent 下一步究竟应该探索哪里？

例如，现在已经存在十几个候选方向：

  • 应该继续优化目前最好的方案吗？
  • 应该回到之前某个失败的方向重新尝试吗？
  • 应该新开一个完全不同的分支吗？
  • 应该同时运行多少个方向？
  • 某个分支连续若干次没有提升后，应该停止吗？
  • 整个搜索什么时候应该结束？

这些都不是“具体怎么解决科学问题”的决策，而是：

如何组织搜索过程本身。

论文把负责这部分行为的机制称为 exploration policy（探索策略）。

因此，这篇论文研究的对象并不是普通意义上的：

如何让 LLM 生成更好的代码

而是：

如何让系统学会更好地组织 LLM 的搜索过程

也就是一种更高层次的 meta-exploration。

2. 为什么优化探索策略很困难？

一种简单做法是人工提前写好一个固定策略，例如：

开 10 个并行分支
每个分支最多继续优化 10 次
始终优先继续当前最好方案
达到预算后结束

很多现有 discovery 系统实际上都采用类似的固定探索规则。

问题在于，随着搜索不断进行，什么样的策略最合适可能会发生变化。

比如搜索早期可能应该大量开新分支：

广泛探索

而在发现几个有希望的方向后，策略可能应该变成：

减少新分支
集中深入已有方向

如果某个方向长时间没有进展，又可能需要重新增加探索。

固定策略无法根据已经积累的 discovery experience 自动发生这种变化。

2.1 那为什么不直接在线优化 exploration policy？

另一个自然想法是：

policy_1
    ↓
实际跑完整个 discovery
    ↓
看结果

policy_2
    ↓
再跑一次 discovery
    ↓
看结果

policy_3
    ↓
再跑一次

但这会遇到两个核心问题。

第一，exploration policy 的反馈非常延迟。

一个具体候选程序好不好，运行一下 benchmark 很快就知道。

但一个“探索策略”好不好，往往必须让它控制几十甚至几百次 proposal-evaluation cycle，才能看到最终效果。

也就是说：

candidate solution
    → 快速得到 feedback

exploration policy
    → 必须控制很长一段搜索
    → 才能得到 feedback

第二，exploration policy 本身的搜索空间也非常大。

策略可以修改：

branch selection
branch depth
branch width
parallelism
pruning
stopping
recovery

因此，如果每尝试一种 exploration policy 都要重新运行完整 discovery，优化成本会非常高。

Dream-RSI 的核心就是试图解决这个问题。

3. 核心想法：Discovery History 本身就是一个 Simulator

论文提出的关键观察非常简单：

一次 discovery 跑完之后，其实已经产生了一棵包含大量搜索结果的树。

例如：

root
├── A
│   └── A1
│       └── A2
├── B
│   └── B1
│       └── B2
└── C
    └── C1

每一个节点都对应一次真实的 generation + evaluation。

节点中不仅保存候选方案，还保存：

代码或生成工件
workspace 状态
evaluation diagnostics
score
历史上下文

假设第一次真实运行时，系统探索顺序是：

A → A1 → B → A2 → B1 → C

那么搜索结束之后，这些结果已经全部存在磁盘上。

此时如果想测试另一个 exploration policy：

先 B
再 B1
然后 A
最后停止

实际上并不需要重新调用 coding agent，也不需要重新运行 evaluator。

因为：

B 的结果已经存在
B1 的结果已经存在
A 的结果已经存在

新的 policy 只需要在历史树上重新选择节点即可。

因此作者提出：

把已经完成的 discovery history 当成一个 replay simulator。

image

【Figure 2（Discovery history as a replay simulator）。重点观察：真实在线搜索只运行一次，但不同的 exploration policy 可以在已经记录好的 discovery tree 上选择不同分支、不同顺序、不同并行度和不同停止位置。】

这里所谓 simulator 并不是重新训练了一个神经网络 World Model。

它实际上是：

已经发生过的真实搜索空间
+
这些节点对应的真实执行结果

因此更准确地说，它是一个 经验型 replay simulator。

它只能模拟已经被真实探索过的区域，不能凭空预测历史树之外会发生什么。

但它有一个非常重要的优势：

回放过程中不需要重新执行昂贵的 coding agent 和 evaluator。

于是，一次昂贵的 online discovery 可以支持大量廉价的 off-policy evaluation。

4. Dream-RSI 整体框架

Dream-RSI 将整个系统组织成一个不断循环的过程：

Online Explore
    ↓
生成新的 Discovery Tree
    ↓
加入历史
    ↓
Construct Replay Simulator
    ↓
Dreaming-based Policy Improvement
    ↓
得到新的 Exploration Policy
    ↓
重新 Online Explore
    ↓
……

也就是：

真实探索
→ 历史积累
→ 离线回放
→ 改进探索策略
→ 再次真实探索

image

【Figure 1（Dream-RSI 整体框架）。重点观察三个阶段：Online Explore、Construct Replay Simulator、Dreaming-based Policy Improvement，以及改进后的 policy 如何重新进入下一轮真实探索。】

论文特别强调：

系统只修改 exploration-policy code。

以下组件始终保持固定：

discovery agent
evaluator
underlying model
execution interface

因此 Dream-RSI 并没有对 Gemini 进行梯度训练，也没有修改 coding model 权重。

发生递归自我改进的是：

如何调度和组织搜索的策略

而不是：

解决具体任务的基础模型

5. Discovery Tree 是如何构造的？

Dream-RSI 首先将 discovery 过程显式表示成一棵树。

根节点 root 表示初始 workspace。

每个非根节点对应一次新的 generation-evaluation attempt。

假设：

A
└── A1
    └── A2

那么：

  • A 从初始 workspace 开始；
  • A1 从 A 保存的 workspace 继续；
  • A2 从 A1 的 workspace 继续。

每个节点保存：

内容 含义
inherited history 从父节点继承的历史
filesystem snapshot 当前 workspace 状态
generated artifact Agent 生成的代码或方案
evaluation diagnostics evaluator 给出的诊断
score 当前方案得分

因此，一个 branch 本质上就是一个不断迭代优化的轨迹。

6. Exploration Policy 到底控制什么？

在任意时刻，policy 可以选择：

root
+
当前所有 leaf nodes

其中：

  • 选择 root：创建一个新的探索方向；
  • 选择某个 leaf：继续深入这个已有方向。

假设当前有：

root
├── A → A1
├── B → B1 → B2
└── C

那么当前可选择节点可能是：

root
A1
B2
C

如果 policy 选择：

[root, A1, B2]

则意味着同时执行：

新开一个 branch
继续 A
继续 B

论文允许最多 W 个 worker，因此一次 action 实际上不是一个节点，而是一个 batch：

C = {node_1, node_2, ..., node_k}
k <= W

这样 exploration policy 同时决定了两个东西：

探索哪里
+
同时探索多少个地方

因此 parallelism 本身也是 policy 的一部分。

7. Online Exploration

第 t 轮真实搜索使用当前 exploration policy：

pi_t

同时可以访问此前所有已经完成的历史：

H_(t-1)

但新的 discovery tree：

T_t

仍然从一个新的 root 开始构造。

每一个 decision round 中：

exploration policy
    ↓
选择若干 leaf / root
    ↓
分配给 W 个 worker
    ↓
discovery agent 生成新方案
    ↓
evaluator 实际运行并打分
    ↓
得到新的 child node

因为 coding agent 的生成具有随机性，所以 online transition 是随机的：

即使从完全相同的 workspace 开始，再次调用 discovery agent，也可能产生不同结果。

Online rollout 在两种情况下结束：

policy 主动选择 empty batch

或者：

达到最大 decision round K1

最终得到新的树：

T_t

随后加入历史集合：

H_t = H_(t-1) + T_t

接下来进入 offline dreaming。

8. Offline Replay：让新的 Policy 在历史里“做梦”

假设目前已经完成三轮在线搜索：

T1
T2
T3

那么 replay simulator pool 就包含：

H3 = {T1, T2, T3}

现在可以提出一个新的 exploration policy：

pi_new

然后分别让它在：

T1
T2
T3

上重新进行一次搜索。

但这一次没有真的执行 coding agent。

8.1 Replay 并不会一次性把整棵树给 Policy 看

这是方法中一个重要细节。

虽然 simulator 内部保存着完整历史树，但 policy 只能看到：

当前按照自己的决策已经 reveal 出来的 prefix。

也就是说，它不能直接偷窥：

某个还没有访问过的节点未来得分是多少

否则 replay 会发生严重的信息泄漏。

假设历史树实际上是：

root
├── A(score=1)
│   └── A1(score=10)
└── B(score=5)
    └── B1(score=6)

最开始 policy 只能看到：

root

如果它选择打开 A：

root
└── A(score=1)

此时它仍然不能看到 A1 的 score=10。

只有再次决定继续 A，simulator 才 reveal：

A1(score=10)

因此 replay 尽量模拟真实在线搜索中：

决策
→ 得到结果
→ 再决策

的因果顺序。

8.2 Replay 中的 transition 是确定性的

与 Online Exploration 不同：

Online:
选择节点
→ 真正调用 Agent
→ 生成新的结果

Replay 中：

Replay:
选择节点
→ 返回历史中已经保存的 child

所以 replay 不生成新的 discovery outcome。

如果一个 branch 历史上是：

A → A1 → A2

那么 replay policy 在 A 上继续探索时，只可能 reveal A1。

再继续则 reveal A2。

它无法生成：

A → A_new

因此 replay simulator 只覆盖：

已经实际探索过的 realized search space。

9. Replay 中到底评价 Exploration Policy 的什么？

论文希望一个好的 exploration policy 同时做到三件事：

找到更好的 solution
+
少做无效尝试
+
尽量利用并行计算

因此 replay objective 可以写成：

Replay Score
=
Best Discovery Quality
- beta1 * Number of Attempts
+ beta2 * Parallelism

第一项：

Best Discovery Quality

表示最终找到的最好节点有多好。

第二项：

Number of Attempts

惩罚探索成本。

如果一个 policy 为了找到同样的方案，需要：

100 次 generation

另一个只需要：

20 次 generation

显然后者更好。

第三项奖励并行性。

论文使用：

Number of Attempts / Number of Decision Rounds

衡量平均每一轮同时处理多少个 attempt。

例如：

Policy A:
100 个 attempt
100 个 sequential rounds

Policy B:
100 个 attempt
10 个 parallel rounds

如果最终效果相同，那么系统更偏好 Policy B。

因此 Dream-RSI 学到的不只是：

探索哪个 branch

还包括：

什么时候 batch 多个任务并行执行

10. Policy 是如何被真正修改的？

Dream-RSI 中存在一个固定的 LLM-based policy-development agent。

它负责修改 exploration policy 的可执行代码。

论文附录给出的 prompt 明确要求它只修改：

OptimalPolicy.solve(...)

而不能直接解决科学任务本身。

也就是说它面对的问题不是：

怎样写一个更快的 Lasso solver？

而是：

根据当前已经观察到的搜索历史，
接下来应该：

- 新开哪些 branch？
- 哪些 branch 应继续？
- 哪些 branch 应停止？
- 一轮应该并行多少任务？
- 整体什么时候结束？

Policy 本身因此是一段真正可执行的 orchestration code，而不仅仅是一段自然语言提示。

10.1 Prefix-only 约束

Policy-development prompt 中反复强调：

Prefix-only

也就是 policy 只能依据已经 reveal 的 information 决策。

允许使用：

observed nodes
baseline score
legal actions
branch structure
当前已经发生的失败 / 成功

不允许使用：

unrevealed scores
future result
true optimum
预先写死 winning cell id

这样 replay evaluation 才能近似：

如果这个 policy 当时真的在线运行，它会做出什么选择。

10.2 Policy Revision

假设当前 policy 是：

pi_t

离线阶段首先让它在所有历史 world 上运行：

T1
T2
...
Tt

得到 replay trajectories 与 scores。

policy-development agent 阅读这些结果，分析：

哪些决策有效
哪些分支过早停止
哪些探索浪费预算
什么时候应该增加 width
什么时候应该 deeper
什么时候应该 batch

然后产生：

pi_t^1

再在完全相同的历史 worlds 上 evaluate。

得到结果后继续修改：

pi_t^2
pi_t^3
...

整个流程可以理解为：

Policy
 ↓
Replay
 ↓
Feedback
 ↓
LLM 修改 Policy Code
 ↓
Replay
 ↓
Feedback
 ↓
继续修改

论文把这个过程称为 dreaming-based policy improvement。

11. 为什么称为 Recursive Self-Improvement？

假设最初策略是：

pi_1

第一轮真实搜索：

pi_1
→ T1

然后 T1 被转换成 replay world：

T1
→ simulator

离线 dreaming 后得到：

pi_2

再真实运行：

pi_2
→ T2

此时 simulator pool 变成：

{T1, T2}

然后：

{T1, T2}
→ improve policy
→ pi_3

随后：

pi_3
→ T3

整个循环就是：

pi_1
 ↓
T1
 ↓
pi_2
 ↓
T2
 ↓
pi_3
 ↓
T3
 ↓
...

这里存在一个正反馈循环：

更好的 policy
→ 产生新的 discovery experience
→ simulator pool 变丰富
→ 提供更多 policy improvement feedback
→ 得到新的 policy

因此作者将它称为：

Recursive Self-Improvement at the meta-exploration layer。

这里被递归改进的是 exploration controller，而不是基础 LLM 权重。

12. Appendix 中的实际 Policy 设计

论文附录进一步给出了 replay-based policy improvement 使用的完整 prompt。

其中一个重要设计是单一的：

beta

参数。

beta 控制 policy 的探索激进程度。

高 beta 倾向于：

更大的 width
更深的探索
更有耐心
更弱的 pruning

低 beta 倾向于：

更少的 probe
更早停止 stagnation branch
更强 pruning

但 beta 在一次真实 episode 中保持固定。

也就是说：

episode 内
beta 不根据 observation 动态变化

离线 replay 时则会 sweep 多个 beta，观察：

quality
work
parallelism

之间的 trade-off。

然后在下一轮 online rollout 前，根据历史结果选择新的默认 beta。

因此系统的适应发生在：

不同 recursive cycles 之间

而不是在同一次 episode 中不断临时修改 beta。

13. Online Discovery Agent 的 Prompt

论文附录还给出了在线 discovery agent 的 prompt。

它要求 Agent 在提出新方案之前：

  1. 阅读完整历史；
  2. 同时分析成功和失败；
  3. 区分：
    • idea 本身有问题；
    • idea 是好的，但实现存在 bug；
  4. 避免反复围绕已经饱和的局部方向做微小修改；
  5. 当历史搜索过度集中时，主动寻找结构不同的新机制。

因此 discovery agent 本身也会读取历史。

但是这和 Dream-RSI 的 replay simulator 是两个不同层次的历史利用方式。

普通 history conditioning 是：

history
→ 放入 Agent context
→ 帮助 Agent 下一次生成

Dream-RSI 是：

history
→ 构造成可交互的 replay environment
→ 用来评价 exploration policy

也就是说，Dream-RSI 的核心并不是简单地：

“把历史喂给 Agent。”

而是：

“把历史变成一个可以反复运行不同 controller 的环境。”

这也是论文在 Related Work 中强调的区别。

14. 实验设置

作者在三个领域共测试了 8 个 discovery tasks：

领域 任务
Algorithm Engineering Lasso Regularization Path
Mathematical Optimization Sum-Difference
Mathematical Optimization Autocorrelation Inequalities
Mathematical Optimization Circle Packing
GPU Kernel Engineering VGG16
GPU Kernel Engineering LayerNorm
GPU Kernel Engineering ConvDiv
GPU Kernel Engineering ConvMax

核心 controlled baseline 是：

Recursive Fixed Exploration

它和 Dream-RSI：

使用相同 discovery agent
使用相同 evaluator
使用相同 initialization
拥有相同 resource constraints
从完全相同的 exploration policy 开始

唯一关键区别是：

Recursive Fixed Exploration:
policy 永远不变

Dream-RSI:
每轮结束后利用 replay simulator 改进 policy

因此这个 baseline 主要用来隔离：

exploration-policy self-improvement 本身带来的影响。

15. 初始 Exploration Policy

两个方法第一轮使用完全相同的人工设计策略：

启动多个独立 workspace
+
每个 workspace 反复优化自己的候选方案

也就是一种简单的 parallel refining。

对于 Gemini-3.1 Pro：

10 个 parallel workspaces
最多 11 个 refinement steps

因此单轮上限：

10 * 11 = 110 calls

对于 Gemini-3.7-Flash：

32 个 workspaces
最多 20 个 refinement steps

对应：

32 * 20 = 640 calls

Dream-RSI 在第一轮和 baseline 完全一样。

真正的差异从第二轮开始出现。

16. 实验一：Lasso Regularization Path

第一个任务是算法工程中的 Lasso Regularization Path。

目标不是简单求一次 Lasso，而是实现一个：

正确
+
尽可能快速

的完整 regularization-path solver。

Discovery 阶段采用 SimpleTES 相同的 17 个 synthetic instances。

最终泛化能力则在 6 个 held-out dataset 上测试：

Gisette
RCV1
DNA
Leukemia
Colon
Duke Breast

论文首先检查数值正确性。

如果 solver 无法满足 correctness requirement：

score = 0

只有正确的程序才比较运行效率。

16.1 主要结果

平均运行时间越低越好。

方法 Model Discovery Calls 六个 Held-out 数据集平均 Runtime
sklearn - - 44180.3 ms
glmnet - - 13767.5 ms
SimpleTES GPT-OSS-120B 51,200 3804.8 ms
Recursive Fixed Exploration Gemini-3.1-Pro 550 3587.1 ms
Dream-RSI Gemini-3.1-Pro 317 2931.0 ms
Recursive Fixed Exploration Gemini-3.7-Flash 3200 2516.7 ms
Dream-RSI Gemini-3.7-Flash 1879 2350.6 ms

对于 Gemini-3.1-Pro：

Fixed:
550 calls
3587.1 ms

Dream-RSI:
317 calls
2931.0 ms

也就是说，Dream-RSI 同时：

减少 discovery compute
+
得到运行更快的最终 solver

对于 Gemini-3.7-Flash 也观察到类似趋势：

3200 → 1879 calls

2516.7 → 2350.6 ms

与 SimpleTES 相比，SimpleTES 使用：

51,200 generations

而 Gemini-3.1-Pro Dream-RSI 只使用：

317 calls

二者相差约 162 倍。

16.2 Recursive Discovery Dynamics

论文进一步比较每一轮 recursive discovery 后的性能。

由于 Round 1 使用完全相同的 exploration policy：

Dream-RSI
=
Recursive Fixed Exploration

两者起点相同。

之后 Fixed Exploration 继续重复旧策略。

Dream-RSI 则执行：

online discovery
→ replay
→ policy improvement
→ online discovery

因此从第二轮开始，两条搜索轨迹逐渐分离。

论文报告，在两个 backbone 上，Dream-RSI 都使用更少累计 discovery compute 得到更好的 downstream runtime。

16.3 最终发现的 Lasso Solver

作者还分析了 Dream-RSI 最终发现的程序。

与 SimpleTES 根据问题尺寸在：

LARS
和
Coordinate Descent

之间切换不同，Dream-RSI 找到的 solver 将 adaptivity 放在 active-set optimization 内部。

其中组合了：

strong-rule screening
+
Cauchy-Schwarz-based KKT pruning
+
selective exact-gradient recomputation
+
full refresh fallback

其核心逻辑是：

如果一个 feature 可以通过便宜的 bound 判断没有必要重新计算 exact gradient，就直接跳过。

只有 bound 无法确定时才进行精确计算。

而当 pruning 效率下降时，再回退到完整 refresh。

此外还结合：

active-set bookkeeping
lazy Gram-matrix construction
hardware-aware implementation

完整代码被作者放在论文 Appendix C 中。

17. 实验二：Mathematical Optimization

作者随后测试三个数学发现任务。

17.1 Sum-Difference

目标是构造一个有限整数集合：

A subset of Z

使某个关于：

sumset A+A
difference set A-A

的比例指标尽可能大。

17.2 Circle Packing

目标是在 unit square 中放置：

26 或 32 个 circle

满足：

圆全部位于正方形内部
圆之间不重叠

并最大化圆半径总和。

17.3 Autocorrelation Inequalities

该任务需要寻找满足一定 support 和 integral constraints 的函数，使 autocorrelation 相关目标达到最优。

论文把三个任务分别作为：

离散组合优化
几何优化
函数优化

的代表。

Discovery agent 使用：

Gemini-3.1 Pro

Dream-RSI 和 Fixed Exploration 均运行 10 个 recursive rounds。

18. 数学任务结果

论文报告结果如下：

方法 Sum Diff ↑ Auto Correlation ↓ Circle Packing ↑
AlphaEvolve - 1.455700 2.635862
AlphaEvolveV2 1.121936 - 2.635983
OpenEvolve - 1.460000 -
CodeEvolve - - 2.635980
ShinkaEvolve - 1.457800 2.635982
TTS-Discovery - - 2.635983
ThetaEvolve - 1.493000 2.635983
EvoX - 1.458900 2.635900
SimpleTES 1.143975 1.453675 2.635983
Recursive Fixed Exploration 1.144047 1.456001 2.635983
Dream-RSI 1.145427 1.456375 2.635983

在 Sum-Difference 上：

Dream-RSI = 1.145427

高于：

SimpleTES = 1.143975
Fixed = 1.144047

Circle Packing 上：

2.635983

与表中最好的已有结果持平。

Autocorrelation 上：

Dream-RSI = 1.456375

没有超过 SimpleTES 的：

1.453675

但论文指出，SimpleTES 在这一任务使用：

51,200 generations

而 Dream-RSI 使用不到：

1,000 generations

因此作者主要强调的是 discovery quality 与 compute efficiency 的综合表现，而不是所有任务上的绝对最好分数。

19. 实验三：GPU Kernel Engineering

第三类实验来自 KernelBench。

目标是让 Agent 自动生成：

数值正确
+
执行尽可能快

的 GPU kernel。

作者选择四个任务：

VGG16
LayerNorm
ConvDiv
ConvMax

性能使用：

1 / runtime

衡量，因此数值越高越好。

使用的 coding agent 是：

Gemini-3.1 Pro

仍然与 Recursive Fixed Exploration 进行 controlled comparison。

19.1 KernelBench 结果

Task Dream-RSI 相对于 Fixed Exploration 的结果
VGG16 相近性能下使用 2.43× 更少 generations
LayerNorm 相近性能下使用 1.79× 更少 generations
ConvDiv 相近 budget 下性能 2.09× 更高
ConvMax 相近 budget 下性能 1.44× 更高

可以看到两种不同情况。

对于 VGG16 与 LayerNorm：

最终性能差不多

主要收益体现在：

更快找到这个水平的方案

对于 ConvDiv 与 ConvMax：

给定相似 discovery budget

Dream-RSI 最终找到的 kernel 性能更高。

20. Further Analysis：历史应该怎么利用？

论文随后专门研究：

历史到底应该作为“提示信息”，还是应该作为 replay simulator？

这也是 Dream-RSI 很关键的一组分析。

一种自然的 history reuse 方法是：

过去 trajectory
 ↓
LLM 总结
 ↓
得到 high-level guidance
 ↓
放进下一轮 prompt

例如从历史中总结：

某类优化似乎比较有效
某类方向经常失败
以后应该重点搜索 X

然后把这些指导直接提供给 discovery agent。

作者分别测试：

Fixed Exploration
Fixed + Guidance

Dream-RSI
Dream-RSI + Guidance

在 ConvDiv 实验中，加入 explicit directional guidance 后，两个方法的效果反而都下降。

论文对此的解释是：

在 long-horizon discovery 中存在大量并行探索线程，如果把历史压缩成强方向性的 semantic guidance，可能会过早限制未来搜索空间。

因此论文强调的 history reuse 与：

history → summary → prompt

不同。

Dream-RSI 采用：

history
→ interactive replay environment
→ 让 controller 自己在其中尝试不同策略

也就是说，历史主要用来提供：

经验反馈

而不是强制告诉未来搜索：

应该往哪个科学方向走

21. Exploration Policy 的行为真的发生变化了吗？

论文还在 ConvDiv 上观察了每一轮 policy 的搜索行为。

Round-best performance 为：

Recursive Round Best Performance
E0 0.427
E1 0.625
E2 0.855
E3 1.403
E4 1.488
E5 1.499
E6 1.770
E7 1.880
E8 1.898

与此同时，每轮实际 evaluation attempt 数量为：

Recursive Round Evaluated Attempts
E0 110
E1 110
E2 87
E3 80
E4 50
E5 92
E6 80
E7 91
E8 86

可以看到，policy 并没有简单地：

越来越省计算

而是先从：

110

逐渐下降到：

50

当性能增长开始趋于平台期后，又重新增加到：

92

随后伴随新的性能提升。

论文将其解释为一种 adaptive exploration pattern：

已有搜索效果不错
→ 减少 exploration effort

进展开始停滞
→ 再增加 exploration effort

这说明 policy improvement 最终改变的不只是某一个固定参数，而是整个搜索预算分配行为。

22. 与已有 Self-Evolving Agent 方法的区别

论文将相关工作分为几个方向。

22.1 Scientific / Algorithmic Discovery

包括：

AlphaEvolve
OpenEvolve
CodeEvolve
ShinkaEvolve
PACEvolve
DeltaEvolve
MLEvolve
SimpleTES

这些系统主要研究：

如何不断生成、评估、修改 candidate solution

近期一些工作开始进一步研究：

如何控制整个搜索过程

例如：

SkyDiscover
SwarmResearch
EvoX

Dream-RSI 也属于这个更高层次的问题。

区别在于：

Dream-RSI 重点解决 exploration policy 的评价反馈昂贵且延迟的问题。

22.2 Self-Evolving Agent

已有工作会改进：

model weights
agent harness
context
skills
test-time behavior
rubrics
environment

Dream-RSI 的更新对象则是：

exploration policy

也就是：

“Agent 应该怎么搜索”

这一 meta-level mechanism。

22.3 Memory / History / Experience Reuse

很多 Agent 工作会把过去 experience 变成：

Memory
Context
Skill
Training Data
Library
Search History

然后帮助下一次 task execution。

Dream-RSI 的区别在于：

History
不是只给 Agent 阅读
而是变成一个 Environment

更具体地说：

普通 Memory:
history
→ retrieval
→ context
→ action

Dream-RSI:
history
→ replay simulator
→ policy evaluation
→ exploration-policy update

它利用历史的对象发生了变化：

普通方法主要帮助：

object-level task solving

Dream-RSI 则主要帮助：

meta-level exploration optimization

23. Dream-RSI 中的“World Model”应该如何理解？

论文受到 model-based RL 与 Dreamer 系列工作的启发。

在 model-based RL 中：

真实环境 interaction
 ↓
学习 dynamics model
 ↓
Agent 在 model 里 imagination
 ↓
改进 policy

Dream-RSI 对应的是：

真实 discovery
 ↓
记录 discovery tree
 ↓
把 tree 当 replay world
 ↓
exploration policy 在其中 dreaming
 ↓
改进 exploration policy

但两者仍有明显区别。

Dream-RSI 并没有训练一个能够预测：

如果执行一个从未尝试过的 action
未来会发生什么

的神经 world model。

它只重放：

已经真实发生过的 trajectory

因此这里的 world 更接近：

empirical replay world

而不是 learned generative dynamics model。

其优势是：

不存在模型预测误差

因为每一个 replay outcome 都来自真实执行记录。

相应地，它只能覆盖：

历史已经探索到的 search space

论文的方法设计始终围绕这一 replay setting 展开。

24. 方法的信息流总结

整个 Dream-RSI 可以整理成如下信息流。

                     ┌─────────────────────┐
                     │ Exploration Policy  │
                     └──────────┬──────────┘
                                │
                                ▼
                     ┌─────────────────────┐
                     │   Online Discovery  │
                     │   Coding Agent      │
                     │   + Evaluator       │
                     └──────────┬──────────┘
                                │
                                ▼
                     ┌─────────────────────┐
                     │   Discovery Tree    │
                     │ code / score /      │
                     │ diagnostics / state │
                     └──────────┬──────────┘
                                │
                                ▼
                     ┌─────────────────────┐
                     │ Replay Simulator    │
                     │ Pool                │
                     └──────────┬──────────┘
                                │
                                ▼
                     ┌─────────────────────┐
                     │ Alternative Policy  │
                     │ Replay Evaluation   │
                     └──────────┬──────────┘
                                │
                                ▼
                     ┌─────────────────────┐
                     │ Policy-development  │
                     │ Agent edits code    │
                     └──────────┬──────────┘
                                │
                                ▼
                     Improved Exploration Policy
                                │
                                └────→ 下一轮 Online Discovery

其中真正更新的是：

Exploration Policy

不会更新：

Coding Agent weights
Evaluator
Task environment

25. 论文的核心贡献

按照作者的总结，Dream-RSI 的贡献主要有三点。

第一，提出：

History as Replay Simulator

以往 discovery history 更多被当成：

文本上下文
Memory
Training Data

Dream-RSI 将已经完成的 structured discovery tree 当成：

可交互的 replay environment

从而重新利用已经支付过成本的 evaluation outcomes。

第二，提出：

Meta-Layer Recursive Self-Improvement

整个循环为：

online exploration
→ history
→ replay
→ exploration-policy improvement
→ online exploration

使 exploration controller 本身可以持续改进。

第三，通过算法工程、数学优化和 GPU kernel engineering 共 8 个任务展示：

更好的 discovery quality
和 / 或
更低的 discovery cost

并且这些结果不需要对底层 coding agent 进行梯度更新。

26. 论文没有单独给出 Limitations / Future Work 章节

当前 arXiv v1 没有单独设置 Limitations 或 Future Work 章节。

论文的 Conclusion 主要再次总结：

Discovery History
        ↓
Replay Simulator
        ↓
Low-cost Off-policy Feedback
        ↓
Exploration Policy Improvement
        ↓
Online Redeployment

因此这里不额外添加论文没有明确提出的局限性或未来研究方向。

需要注意的是，论文方法本身明确规定 replay 只能 reveal 已经记录在 historical discovery tree 中的 outcome；它不会在 replay 阶段生成历史之外的新 discovery result。这属于方法定义的一部分，而不是作者额外给出的 limitation 分析。

27. 总结

Dream-RSI 研究的不是：

如何让 LLM 自己变得更聪明

也不是：

如何训练一个更好的 coding model

而是 long-horizon agentic discovery 中更高一层的问题：

如何让 Agent 学会“怎样搜索”

传统 discovery pipeline 通常将 exploration strategy 作为一个固定的 harness：

固定 branch 数
固定 refinement depth
固定 parallelism
固定 stopping rule

Dream-RSI 则把这一层显式表示为：

Executable Exploration Policy

并让它本身进入 self-improvement loop。

论文最核心的机制可以浓缩成：

第一次真实探索很贵，
但它留下了一棵包含真实结果的 Discovery Tree。

既然这些结果已经付过一次计算成本，
那么以后就不必为了测试另一套搜索策略，
重新执行所有 Coding Agent 和 Evaluator。

让新的 Exploration Policy
在已经发生过的历史里重新走一遍即可。

因此：

Discovery History

从过去通常意义上的：

Memory / Context

进一步变成了：

Replay Simulator

随后系统利用这个 simulator 对大量 alternative exploration policies 进行低成本 off-policy evaluation，由固定的 LLM-based policy-development agent 根据 replay feedback 修改 exploration-policy code，再将改进后的 policy 部署到下一轮真实 discovery 中。

最终形成：

Explore
  ↓
Record
  ↓
Replay
  ↓
Improve Policy
  ↓
Explore Again
  ↓
...

这就是论文所谓的：

Recursive Self-Improvement through Evolving Worlds。

这里不断“演化”的 world，是随着真实 discovery 不断扩充的 historical replay simulator；不断自我改进的对象，则是控制长时间搜索过程的 exploration policy。

参考

  1. Tong Zheng et al. Dream-RSI: Recursive Self-Improvement through Evolving Worlds. arXiv:2609.14858, 2026.
    https://arxiv.org/abs/2609.14858

  2. Dream-RSI Official Repository.
    https://github.com/zhengkid/Dream-RSI

  3. Dream-RSI Project Page.
    https://dream-rsi.com

  4. Alexey Novikov et al. AlphaEvolve: A Coding Agent for Scientific and Algorithmic Discovery. arXiv:2506.13131, 2025.

  5. Shunyu Ouyang et al. KernelBench: Can LLMs Write Efficient GPU Kernels? arXiv:2502.10517, 2025.

  6. H. Ye et al. Evaluation-Driven Scaling for Scientific Discovery. arXiv:2604.19341, 2026.

posted @ 2026-09-22 17:34  YourF4u1t  阅读(3)  评论(0)    收藏  举报