谷歌重磅发布Dream-RSI，最新RSI研究！

现有RSI方法的缺陷

在讲自己的方案之前，论文先梳理了现有探索方法各自的缺陷。

1. 静态探索策略，面对大搜索空间必然空转

以 AlphaEvolve、CodeEvolve、SimpleTES 为代表的第一代方案，探索策略全程人工预设。

论文在对照实验中给出了具体的策略基线。系统会固定启动 10 个独立工作区并行探索，每个工作区固定走 11 步连续精炼，分支之间互不相通。每轮迭代不管前期跑出了什么结果，都机械重复这套固定的配额。

在浅层任务上，这种预设能跑通。但在数千次提议和评估的长程任务里，策略不具备自适应性。

当某条分支的改进在第 3 步就已经走平，系统依然会把预设的 11 步全部跑满。同时，由于无法吸收全局经验，后一轮的新分支往往会把上一轮已经证明无效的方向从头再踩一遍，导致算力空转。

2. 在线元策略优化：边探索边调规则，长程试错成本过高

第二类思路不仅让模型找解，还试图让模型在任务执行过程中，在线学习并动态调整搜索规则（如 EvoX）。例如由系统实时决定何时发散探索、何时收敛深挖、各个分支分配多少算力。

这套机制在实际落地中会面临双重成本限制。

一是反馈极度延迟且昂贵。评估一段生成的代码只需跑一次测试，几秒就能拿到反馈。评估一套搜索规则是否有效，必须让模型在真实环境中跑完整条长任务调用链，直到整棵探索树展开才能看到最终收益。

二是真实环境试错代价大。在线优化意味着每次调整规则都在消耗真实的线上算力与调用配额。一旦新策略尝试失败，整场任务的投入直接沉没。

Dream-RSI 核心逻辑，把历史数据做成物理模拟器

排除了上面两条失效路径后，DeepMind 给出了破局点。历史探索数据不该当参考文本看，它本身就是一座可以零成本重放的物理模拟器。

1. 三阶段递归自改进闭环

Dream-RSI 的整体系统由三个紧密咬合的阶段循环驱动。

第一阶段是在线探索。系统部署当前版本的探索策略，指挥底层的 Coding Agent 与评测沙箱真实交互，把所有的探索尝试沉淀为一棵结构化的“发现树”。

第二阶段是世界演化。系统把最新探索出的节点、代码快照、报错信息、运行时长和客观得分，无损并入历史模拟器资产池，环境世界随之演化扩张。

第三阶段是离线做梦。在完全脱离真实 API 和沙箱环境的前提下，系统让成千上万个候选探索策略在历史模拟器里高速重跑，综合评估策略的解质量与计算效率，筛选出最优策略代码，部署到下一轮真实探索中。

在整个闭环中有一条硬约束。底层大模型、评价函数、测试环境完全锁死不变，只更新探索策略代码本身。这是确保性能提升可归因的技术底线。

2. 核心机制，发现树直接充当回放模拟器

过去跑过的每一次尝试，代码快照、报错日志、运行时长和客观得分都记录在硬盘上。

当我们需要评估成千上万种不同的探索策略时，不需要向大模型发起新的推理请求，也不需要重新跑评测沙箱。候选策略只需要在这棵已有的历史树上遍历一遍，策略想看哪个分支，系统就调出当年记录的真实结果。

一次真实的探索，换来了上万次零 Token 消耗的离线模拟。

3. 探索策略代码的四个决策维度

在理解了上面的闭环和模拟器之后，这个被反复优化的“探索策略代码”，在技术层面到底在控制什么？

为了让探索策略变成一段可以被量化优化的程序，系统将搜索过程统一形式化为一棵树上的遍历调度。探索策略在每个决策轮次只做四件事。

第一，选节点。决定从当前发现树的哪些节点作为父节点，派生新的尝试。

第二，定并发。根据系统设置的最大 Worker 限制，决定当前时刻并行调度几个生成任务。

第三，设深度。在同一条分支上允许连续深入尝试几步，决定深挖还是广搜。

第四，下止损。什么时候选择空批次主动结题，避免无休止的边际消耗。

探索过程不再是未形式化的经验逻辑，而是一段输入输出明确的 Python 控rollers代码。

Agent自我改进中避坑指南

论文附录给出的 Prompt 约束，是作者团队在实际工程里踩坑后的沉淀。如果不加控制，模型在自主探索时会出现几类典型的判断变形。

1. 别把实现级报错误判为算法方向失败

常见的一个坑是，Agent 在某条分支上遇到了一个 Bug，比如维度不匹配、显存超限或者编译参数遗漏，模型就会得出这条思路不行的结论，立刻把整条方向放弃。

论文的应对规则明确。必须对报错做严格分类。不可恢复的算法错误才能放弃分支，而维度错、参数错、显存溢出都属于可修复失误，单次出现不允许关停分支。

2. 引入分支的赦免与重开机制

早期的几次失败会让模型产生偏见，导致后面有潜力的分支被雪藏。

论文给出的规则是，分支判定不能只看最新一次输出，必须看整条分支的历史轨迹。只要后续尝试出现了进展，系统必须具备撤销关闭的能力，抹掉早期的失败标记，重新激活分支。

3. 避免在收益走平的局部反复打转

Agent 容易在局部的细枝末节上反复修补，提升曲线已经走平，还是死守在原有思路上。

论文的解决办法是在调度批次里加入结构性异构候选，把探索多样性作为和单步收益同等重要的指标，打断死循环。

4. 探索强度需要动态调整

探索不能按固定步长匀速推进。实测数据显示，最优策略在初期取得突破时，会自动把单轮尝试从 110 次压低到 50 次，主动节省算力；等到进入平台期时，再重新调动高密度探索算力去冲瓶颈。

5. 警惕把历史塞进 Prompt，先验引导反而压制多样性

很多开发者的直觉习惯是：把上一轮尝试的经验、教训或方向性建议总结出来，直接写进下一次调用的 Prompt 里做语义引导。

论文在 5.1 节专门对这种做法做了一组对照消融实验。

实验结果显示，在完全同等的发现算力预算下，无论是在固定探索基线上、还是在 Dream-RSI 上，加入了 Prompt 显式方向引导的 Agent，最终性能表现都落后于没有任何引导的对照组。

原因在于长程自主探索依赖多线程并发的多样性。在 Prompt 里强加高维的方向性先验，过早框死了模型的解空间，反倒切断了潜在的最优探索分支。经验应当沉淀为环境历史供策略回放，而不是变成提示词里的思维定势。

三大任务开销对比：算法工程、数学优化与算子生成

消除了盲目试错之后，Dream-RSI 带来的收益直接体现在算力开销上。

1. 算法工程，Lasso 正则化路径求解

以 SimpleTES 为对照基线，原方案消耗了 51200 次生成。

同样使用 Gemini-3.1 Pro，固定探索策略耗费 550 次 Agent 调用，下游运行耗时 3587.1 毫秒。Dream-RSI 仅用了 317 次调用，下游耗时压低到了 2931.0 毫秒，算力开销比 SimpleTES 低了约两个数量级。

产出的求解器自发结合了 Cauchy-Schwarz KKT 剪枝、强规则筛选与惰性 Gram 矩阵构造，性能超过了标准的 sklearn 和 glmnet。

2. 数学优化，千代以内追平或超越前人

在三个数学任务上，Dream-RSI 使用 Gemini-3.1 Pro 运行 10 轮。

在 Sum-Difference 任务上取得 1.145427 评分，刷新了包括 SimpleTES 在内的纪录；Circle Packing 追平了学界公认的最强解 2.635983；Autocorrelation 在不到 1000 代之内追平了此前消耗 51200 代的 SOTA 模型，预算开销压缩了 50 倍以上。

3. GPU 算子工程，更少代数达到工业级性能

在 KernelBench 测试中，达到同等性能目标，VGG16 上减少了 2.43 倍的代数开销，LayerNorm 上减少了 1.79 倍。在恒定算力上限下，ConvDiv 和 ConvMax 的算子性能分别提升了 2.09 倍与 1.44 倍。

Google Dream-RSI的适用边界

任何技术都有适用条件，这套方案目前有三个明确的前提边界。

第一，必须依赖客观、可自动评分的评测沙箱。系统之所以能闭环，前提是代码能不能跑、耗时多少、数学目标是否达成，全都有确定性的评测器兜底。迁移到开放域创意生成或模糊业务分析等缺乏客观真值评分的场景，整套回放评估将无法成立。

第二，回放模拟器无法凭空产生未探索的真值。离线做梦只能对已经记录下来的历史分支做重排、重访与剪枝，无法预测从未尝试过的未知路径。新知识的拓展依然依赖周期性的在线探索。

第三，策略代码本身存在复杂度上限。当前演化的探索策略受限于模型编写控制流代码的能力，当探索图谱变得庞大时，策略代码本身的维护将构成新的工程挑战。

写在最后：从调优模型走向治理探索

面对 Agent 任务失败时，很多人的第一反应是底座大模型能力不够，于是陷入微调 Prompt 或者等下一代模型的等待中。

Google DeepMind 这篇工作展现了一种工程思路：底座模型完全可以不动，通过把模糊的探索行为规范成确定性的代码接口，把跑过的试错历史盘活成离线模拟器，再用清晰的工程规则卡住 Agent 的假性失败，同样能在真实任务里拿到一个数量级以上的效率跃迁。

对于正在搭代码生成、科学计算或者长流程 Agent 的开发者来说，怎么管好探索本身，往往比换一个模型更管用。

JOTO 企业落地观察

• 对企业部署而言，Dream-RSI 提供了一种不依赖模型升级的效能提升路径：将探索行为代码化、历史数据资产化、评估过程离线化。这意味着企业在已有大模型基础设施上，可通过构建策略代码训练与回放模拟器，显著降低长程任务的算力消耗，规避频繁更换底座模型带来的迁移与适配成本。
• 这类系统的取舍在于对评测沙箱的刚性依赖。企业若希望复用该范式，必须首先建立可自动化、客观量化的任务评估体系，尤其在代码生成、数学优化等强确定性场景中才具备实施基础；而在主观性强、真值模糊的业务分析类任务中，该闭环无法成立，需另寻其他治理路径。
• 对智能体工程而言，Dream-RSI 将‘探索’从黑盒行为转变为可调试、可版本化、可单元测试的程序模块。企业团队需重构Agent架构，分离策略控制器与执行引擎，并配套建设发现树存储、模拟器调度与策略AB测试能力，这要求工程重心从Prompt调优转向控制流代码的生命周期管理。
• 在RAG知识工程视角下，该研究揭示了历史交互数据的深层价值——它不仅是检索源，更是可执行的环境模拟资产。企业知识库建设不应止步于文本向量化，而应同步沉淀结构化执行轨迹（代码快照、报错上下文、耗时、得分），为未来构建具备‘回放-推演’能力的知识操作系统提供数据基础。