Google DeepMind 最近放出了一篇关于 RSI（递归自我改进）的新研究，在开发者圈子里引发了不少关注。
论文标题是 Dream-RSI: Recursive Self-Improvement through Evolving Worlds，由 Google DeepMind、弗吉尼亚大学和马里兰大学联合发表，代码已开源在 github.com/zhengkid/Dream-RSI。
过去做递归自我改进（RSI），大家默认卡在底座模型的解题能力上。但 DeepMind 这次把重点转向了长程任务里的探索策略，并把它做成了一段可以自我改进的程序对象。实测表明，在算法工程、数学优化和 GPU 算子工程中，这套方法把搜索算力开销降低了一到两个数量级。
01 现有 RSI 方法的缺陷
在介绍自己的方案之前，论文先梳理了现有探索方法的各自短板。
1. 静态探索策略，面对大搜索空间必然空转
以 AlphaEvolve、CodeEvolve、SimpleTES 为代表的第一代方案，探索策略全程由人工预设。论文在对照实验中给出了具体的策略基线：系统固定启动 10 个独立工作区并行探索，每个工作区固定走 11 步连续精炼，分支之间互不相通。每轮迭代不管前期跑出了什么结果，都机械地重复这套固定配额。
浅层任务上，这种预设还能跑通。但到了数千次提议和评估的长程任务里，策略就完全不具备自适应性了。当某条分支的改进在第 3 步已经走平，系统依然会把预设的 11 步全部跑满。同时，由于无法吸收全局经验，后一轮的新分支往往会把上一轮已经被证明无效的方向从头再踩一遍，算力就这样白白浪费掉。
2. 在线元策略优化：边探索边调规则，长程试错成本过高
第二类思路不只是让模型找解，还试图让模型在任务执行过程中在线学习并动态调整搜索规则（比如 EvoX）。由系统实时决定何时发散探索、何时收敛深挖、给各分支分配多少算力。
这套机制真落地时，会撞上两重成本限制。
一是反馈极度延迟且昂贵。评估一段生成的代码，跑一次测试几秒就能拿到结果。但评估一套搜索规则是否有效，必须让模型在真实环境里跑完整条长任务调用链，直到整棵探索树展开才能看到最终收益。
二是真实环境试错代价太大。在线优化意味着每次调整规则都在消耗真实的线上算力与调用配额。一旦新策略尝试失败，整场任务的投入直接沉没。
02 Dream-RSI 核心逻辑：把历史数据做成物理模拟器
排除了上面两条失效路径之后，DeepMind 给出了破局点：历史探索数据不该只当参考文本看，它本身就是一座可以零成本重放的物理模拟器。
1. 三阶段递归自改进闭环
Dream-RSI 的整体系统由三个紧密咬合的阶段循环驱动。
第一阶段是在线探索。系统部署当前版本的探索策略，指挥底层的 Coding Agent 与评测沙箱真实交互，把所有的探索尝试沉淀为一棵结构化的“发现树”。
第二阶段是世界演化。系统把最新探索出的节点、代码快照、报错信息、运行时长和客观得分，无损并入历史模拟器资产池，环境世界随之演化扩张。
第三阶段是离线做梦。在完全脱离真实 API 和沙箱环境的前提下，系统让成千上万个候选探索策略在历史模拟器里高速重跑，综合评估策略的解质量与计算效率，筛选出最优策略代码，部署到下一轮真实探索中。
整个闭环有一条硬约束：底层大模型、评价函数、测试环境完全锁死不变，只更新探索策略代码本身。这是确保性能提升可归因的技术底线。
2. 核心机制：发现树直接充当回放模拟器
过去跑过的每一次尝试——代码快照、报错日志、运行时长和客观得分——都记录在硬盘上。
当需要评估成千上万种不同的探索策略时，不需要向大模型发起新的推理请求，也不需要重新跑评测沙箱。候选策略只需要在这棵已有的历史树上遍历一遍，策略想看哪个分支，系统就调出当年记录的真实结果。一次真实的探索，换来上万次零 Token 消耗的离线模拟。
3. 探索策略代码的四个决策维度
理解了上面的闭环和模拟器之后，这个被反复优化的“探索策略代码”在技术层面到底控制什么？
为了让探索策略变成一段可以被量化优化的程序，系统将搜索过程统一形式化为一棵树上的遍历调度。探索策略在每个决策轮次只做四件事：选节点，决定从当前发现树的哪些节点作为父节点派生新尝试；定并发，根据系统设置的最大 Worker 限制，决定当前并行调度几个生成任务；设深度，在同一条分支上允许连续深入尝试几步，决定深挖还是广搜；下止损，什么时候选择空批次主动结题，避免无休止的边际消耗。探索过程不再是没形式化的经验逻辑，而是一段输入输出明确的 Python 控制器代码。
03 Agent 自我改进中的避坑指南
论文附录给出的 Prompt 约束，是作者团队在实际工程里踩坑后的沉淀。如果不加控制，模型在自主探索时会出现几类典型的判断变形。
1. 别把实现级报错误判为算法方向失败
一个常见的坑：Agent 在某条分支上遇到一个 Bug，比如维度不匹配、显存超限或者编译参数遗漏，模型就会得出这条思路不行的结论，立刻把整条方向放弃。论文的应对规则很明确——必须对报错做严格分类。不可恢复的算法错误才能放弃分支，维度错、参数错、显存溢出都属于可修复失误，单次出现不允许关停分支。
2. 引入分支的赦免与重开机制
早期几次失败会让模型产生偏见，导致后面有潜力的分支被雪藏。论文给的规则是：分支判定不能只看最新一次输出，必须看整条分支的历史轨迹。只要后续尝试出现了进展，系统必须具备撤销关闭的能力，抹掉早期的失败标记，重新激活分支。
3. 避免在收益走平的局部反复打转
Agent 容易在局部的细枝末节上反复修补，提升曲线已经走平了，还死守在原有思路上。论文的解决办法是在调度批次里加入结构性异构候选，把探索多样性作为和单步收益同等重要的指标，打断死循环。
4. 探索强度需要动态调整
探索不能按固定步长匀速推进。实测数据显示，最优策略在初期取得突破时，会自动把单轮尝试从 110 次压低到 50 次，主动节省算力；等到进入平台期时，再重新调动高密度探索算力去冲瓶颈。
5. 警惕把历史直接塞进 Prompt，先验引导反而压制多样性
很多开发者的直觉习惯是：把上一轮尝试的经验、教训或方向性建议总结出来，直接写进下一次调用的 Prompt 里做语义引导。论文在 5.1 节专门为这种操作做了一组对照消融实验。
实验结果显示，在完全同等的发现算力预算下，无论基于固定探索基线还是 Dream-RSI，加入 Prompt 显式方向引导的 Agent，最终性能表现都落后于没有任何引导的对照组。原因在于长程自主探索依赖多线程并发的多样性，在 Prompt 里强加高维的方向性先验会过早框死模型的解空间，反而切断了潜在的最优探索分支。经验应当沉淀为环境历史供策略回放，而不是变成提示词里的思维定势。
04 三大任务开销对比：算法工程、数学优化与算子生成
消除了盲目试错之后，Dream-RSI 的收益直接体现在算力开销上。
1. 算法工程：Lasso 正则化路径求解
以 SimpleTES 为对照基线，原方案消耗了 51,200 次生成。同样使用 Gemini-3.1 Pro，固定探索策略耗费 550 次 Agent 调用，下游运行耗时 3,587.1 毫秒；Dream-RSI 仅用了 317 次调用，下游耗时压低到 2,931.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 在不到 1,000 代之内追平了此前消耗 51,200 代的 SOTA 模型，预算开销压缩了 50 倍以上。
3. GPU 算子工程：更少代数达到工业级性能
在 KernelBench 测试中，达到同等性能目标，VGG16 上减少了 2.43 倍的代数开销，LayerNorm 上减少了 1.79 倍。在恒定算力上限下，ConvDiv 和 ConvMax 的算子性能分别提升了 2.09 倍与 1.44 倍。
05 Dream-RSI 的适用边界
任何技术都有适用条件，这套方案目前有三个明确的前提边界。
第一，必须依赖客观、可自动评分的评测沙箱。系统之所以能闭环，前提是代码能不能跑、耗时多少、数学目标是否达成，全都有确定性的评测器兜底。迁移到开放域创意生成或模糊业务分析等缺乏客观真值评分的场景，整套回放评估将无法成立。
第二，回放模拟器无法凭空产生未探索的真值。离线做梦只能对已经记录下来的历史分支做重排、重访与剪枝，无法预测从未尝试过的未知路径。新知识的拓展依然依赖周期性的在线探索。
第三，策略代码本身存在复杂度上限。当前演化的探索策略受限于模型编写控制流代码的能力，当探索图谱变得庞大时，策略代码本身的维护将构成新的工程挑战。
06 写在最后：从调优模型走向治理探索
面对 Agent 任务失败时，很多人的第一反应是底座大模型能力不够，于是陷入微调 Prompt 或者等下一代模型的等待中。
Google DeepMind 这篇工作展现了一种不同的工程思路：底座模型完全可以不动，把模糊的探索行为规范成确定性的代码接口，把跑过的试错历史盘活成离线模拟器，再用清晰的工程规则卡住 Agent 的假性失败，同样能在真实任务里拿到一个数量级以上的效率跃迁。
对于正在搭代码生成、科学计算或者长流程 Agent 的开发者来说，怎么管好探索本身，往往比换一个模型更管用。这类围绕 Agent 与探索策略的话题，之后也可以在云栈社区继续深入讨论。
发表于 1 小时前
|
查看: 3|
回复: 0
