Google DeepMind、马里兰大学帕克分校和弗吉尼亚大学的研究者近日在 arXiv 提交了 Dream-RSI 预印本。它研究的是长时间工作的 coding agent 怎样安排一次次尝试：何时另开方向，何时沿已有方案继续，几个任务可以并行，以及什么时候该停。团队保持生成代码的模型和评测器不变，把这套安排写成可执行的探索策略，再让策略从过去的搜索记录中改进。
该方法的关键是把真实探索留下的历史树用于回放。一棵树记录了每次从哪个工作区继续、生成了什么、评测给出什么反馈；另一位策略开发代理修改探索策略代码，让不同版本在这些已记录的树上试跑、比较，选中的版本再进入下一轮真实搜索。新一轮又会留下新的树，供之后继续改策略。
论文在 Lasso 路径求解、三类数学优化和四项 GPU kernel 任务上检验这条路线，共 8 个任务。最清楚的同条件结果来自 Lasso：与固定探索策略相比，Gemini-3.1 Pro 组累计 Agent 调用从 550 次降到 317 次，Gemini-3.7 Flash 组从 3200 次降到 1879 次，最后找到的求解器在六个下游数据集上的平均运行时间也更低。GPU kernel 的四项实验分别体现为更少生成次数或更高的程序性能；数学任务则有领先、持平和略微落后。
一段搜索策略，为什么值得反复改
让 Agent 找更快的 Lasso 求解器时，生成模型会写候选程序，评测器检查数值是否正确、运行是否更快，Agent 再依据反馈修改。仅仅决定“接下来从哪里试”，就会改变这场搜索的成本和结果：一个工作区里继续精修，可能越走越深；另开几个方向，可能更早遇见好方案，也可能把预算分散掉。
论文的主要对照是 Recursive Fixed Exploration。以 Gemini-3.1 Pro 的设置为例，它每轮启动 10 个独立工作区，每个最多连续改进 11 步；Flash 的设置是 32 个工作区、每个最多 20 步。每个工作区能利用本路线的历史，coding agent 也会读到之前的提案和分数，但跨轮控制搜索的规则不再变化。Dream-RSI 第一轮使用相同策略；从第二轮起，它会先利用已积累的历史修改这段控制代码，再继续搜索。两边使用同一 coding agent、评测器、初始化和每轮资源限制。
策略本身很难直接在线试错。评测一段候选程序，只需生成并运行它；要知道一套新搜索规则是否有效，却要让它组织许多次生成和评测，直到走出一段足够长的探索轨迹。若每改一次规则都重跑这条链，策略开发很快会吃掉本应用来发现程序的预算。Dream-RSI 的办法是让已经获得的探索记录承担这轮比较。
论文图 1：真实探索留下历史树，策略在回放中改进后进入下一轮搜索
历史树怎样让策略“先试一遍”
真实搜索从一个初始工作区开始。Agent 选择某个节点继续时，会继承该节点保存的文件状态与先前观察，生成新候选；评测器返回错误、诊断和分数，新尝试成为父节点的一个孩子。节点保存的不只是一个排行榜数字，还包括程序、评测结果和可继续修改的工作区。因此，这棵树同时保留了走过的方向和每一步之后实际看到了什么。
探索策略每次看到的是当前已经显露的树，它可以在可选的叶节点上继续，也可以回到根节点打开新分支；一次最多选出与 worker 数相符的一批节点，选空批次就停止。策略决定尝试从哪里出发、并行做多少个，具体的新代码仍由 coding agent 生成。在线运行时，同一个工作区下一次会生成什么带有随机性，新结果必须真实执行后才能知道。
离线回放沿用这个决策接口，却把生成和评测换成读取记录。每测一份策略，先把一棵已完成的历史树遮住，只露出根节点。策略选根节点，系统按当年的创建顺序揭示下一条已有分支；选一个已显露的叶节点，就揭示它在历史中实际走出的下一个孩子。代码、诊断和分数到被揭示时才进入策略的视野。策略随后重新决定延续、开新分支、并行或停止；另一份候选策略也从根节点重新开始，可能看到同一历史的不同部分。
论文图 2：不同探索策略可在同一棵历史树上揭示不同轨迹并取得回放反馈
正因为回放只读取现成结果，候选策略无需每次都重新调用 coding agent 和评测器；又因为未知部分仍然未知，策略必须定期回到真实搜索，才能扩充下一轮可回放的世界。
回放会同时计入已揭示节点中最好的分数、为此需要多少次尝试，以及这些尝试是否有效并行。固定的 LLM 策略开发代理查看各版本在历史树上的轨迹与反馈，修改探索策略代码，再把新版本放到同一批树上比较。当前策略也参与选择，所以入选版本在这批历史的平均回放分数上至少不差于它；真实下一轮仍可能走出不同结果。
改过的策略，回到真实搜索后发生了什么
策略开发不是给 coding agent 添一段“上次有哪些好点子”的提示词。论文在 ConvDiv 上做过相近的尝试：把先前轨迹总结成方向性文字，放进下一轮提示。固定探索和 Dream-RSI 加上这种指导后，都不如各自不加指导的版本。这个实验只覆盖该任务和设置，却说明两种使用历史的方式确实不同：文字会直接影响 Agent 想写什么；回放则检验控制器怎样分配下一批尝试。
ConvDiv 的另一组结果展示了策略怎样随轮次改变。论文图 6 中，每轮被评测的尝试数一度从 110 次降到 50 次；性能进入平台期后，尝试数又上升，并伴随进一步的性能改进。它让“策略会适应搜索进度”有了可观察的过程，不必只从终局分数倒推。
从 Lasso 到 GPU kernel：收益落在哪些地方
Lasso 的目标是找出计算完整正则化路径更快、同时保持数值正确的程序。研究者先用 17 个合成实例发现程序，再到 6 个没有参与搜索的下游数据集测运行时间。搜索时累计调用多少次 Agent，是寻找程序的投入；找到的程序在数据集上跑多久，是交付后的性能，两者在论文中分别计量。
Gemini-3.1 Pro 组里，Dream-RSI 用 317 次 Agent 调用得到六项平均 2931.0 毫秒的求解器；固定探索用了 550 次，结果为 3587.1 毫秒。Flash 组是 1879 对 3200 次调用，平均运行时间 2350.6 对 2516.7 毫秒。两组都在相同模型和评测条件下，用更少尝试找到平均表现更好的程序；论文图 3b 把五轮搜索中的累计调用与平均运行时间一起画了出来。
论文图 3b：五轮 Lasso 搜索中，平均运行时间与累计 Agent 调用的变化
平均值背后，两个模型找到的程序不太一样。Pro 组对最大的 RCV1 数据集改善明显，从固定策略的 19550.1 毫秒降到 14616.0 毫秒，但其余五项逐项更慢；Flash 组则有五项更快、一项更慢。这也解释了为什么论文既要报告六项平均，还要给出逐数据集表格：搜索策略改变的不只是尝试次数，也改变了最后找到的程序更适合哪类输入。
论文还与 SimpleTES 作横向比较：后者报告 51,200 次生成，Dream-RSI 的 Pro 组是 317 次 Agent 调用，因此论文给出约 162 倍的数量差距。SimpleTES 使用 gpt-oss-120b，Dream-RSI 使用 Gemini，搜索实现也不同；这个数字呈现两套系统的相对位置。要看历史回放这一步本身带来什么变化，前面的同模型固定策略对照更直接。
数学任务把策略放进不同的目标里。Sum–Difference 要找一个整数集合，使和集相对原集合的增长大于差集的增长，得分越高越好；Circle Packing 要在单位正方形内排圆，使半径之和尽可能大；Autocorrelation 则要压低函数自卷积的峰值，分数越低越好。使用 Gemini-3.1 Pro 的十轮对照中，Dream-RSI 在第一项得到 1.145427 对 1.144047，第二项两边同为 2.635983，第三项为 1.456375 对 1.456001，略落后于固定策略。探索控制器能跨任务使用，但并非每一种目标都得到更好的结果。
GPU kernel 的候选先过正确性检查，再按运行时间的倒数 1/毫秒计性能。VGG16 和 LayerNorm 两项达到相近性能时，Dream-RSI 所需生成次数分别是固定策略的约 1/2.43 和 1/1.79；ConvDiv 和 ConvMax 在相近搜索预算下，找到的 kernel 性能分数分别是固定策略的 2.09 倍和 1.44 倍。前两项比的是找到相近程序要试多少次，后两项比的是花相近尝试能找到多快的程序。
论文图 4：四项 GPU kernel 测试中，较少生成次数与较高程序性能对应不同任务
Dream-RSI 的价值，是让原本藏在 Agent 工作流外面的搜索控制器也成为可修改、可比较的对象。真实探索提供带程序和反馈的历史树，回放让策略开发代理在已知部分反复试错，更新后的代码再去扩张历史。
参考链接
Dream-RSI arXiv 页面：https://arxiv.org/abs/2609.14858 Dream-RSI 论文 PDF：https://arxiv.org/pdf/2609.14858 Dream-RSI 项目主页：https://www.dream-rsi.com/ Dream-RSI 官方仓库：https://github.com/zhengkid/Dream-RSI