文章摘要
多家科研机构联合发布Dream-RSI预印本，针对长期运行编码智能体代码生成的搜索规划问题，在保留原代码生成模型、评测器参数不变的前提下，通过历史搜索树离线回放迭代优化探索策略。多任务验证显示，该方法大多可减少智能体调用次数，提升最终程序性能。

近期，由多家科研机构联合推出的Dream-RSI预印本，针对长期运行的编码智能体的搜索规划问题展开了深入研究。这类智能体在完成代码生成任务时，需要反复做出决策：是继续深耕当前的优化方向，还是切换到新的探索路径；是并行推进多个任务，还是在合适的时机终止当前流程。研究团队保留了代码生成模型与评测器的参数不变，将这类决策逻辑封装为可执行的探索策略，并让该策略从过往的搜索记录中持续迭代优化。

该方法的核心在于利用真实探索过程中生成的历史搜索树进行离线回放。一棵完整的历史树会记录每一次探索的起始工作区、生成的代码内容，以及评测器给出的反馈结果。与此同时，策略开发代理会基于这些已有的记录，测试不同版本的探索策略，通过对比各版本的表现来选出更优的策略，再将其应用到下一轮的真实搜索中。每一轮真实搜索都会生成新的历史树，为后续的策略迭代提供更多数据支持。

研究团队在8个任务上验证了这套方法的有效性，包括Lasso路径求解、三类数学优化任务，以及四项GPU kernel优化任务。其中Lasso任务的对比结果最为直观：与固定探索策略相比，使用Gemini-3.1 Pro模型的实验组，累计智能体调用次数从550次降至317次；使用Gemini-3.7 Flash模型的实验组，调用次数从3200次降至1879次，且最终得到的求解器在6个下游数据集上的平均运行时间也更短。在GPU kernel任务中，该方法要么减少了代码生成次数，要么提升了最终程序的运行性能；而在数学优化任务中，效果则表现为领先、持平或略微落后于固定策略。

为何需要持续迭代搜索策略

以寻找更快的Lasso求解器为例，代码生成模型会输出候选程序，评测器会验证程序的数值正确性与运行速度，智能体再根据反馈调整生成的代码。但仅仅是决定“接下来从哪里开始新的尝试”，就会极大影响整个搜索过程的成本与最终结果：如果持续在同一个工作区中精修代码，可能会陷入局部最优；如果同时开启多个探索方向，虽然有可能更早找到优质方案，但也可能分散搜索预算，降低整体效率。

本次研究的主要对照实验组为Recursive Fixed Exploration。以Gemini-3.1 Pro的配置为例，该实验组每轮会启动10个独立工作区，每个工作区最多连续进行11次改进；而Flash模型的配置则是32个工作区，每个工作区最多进行20次改进。每个工作区可以利用自身的历史记录，智能体也可以读取之前的提案与得分，但跨轮次的搜索控制规则不会发生变化。Dream-RSI方法在第一轮使用相同的探索策略，从第二轮开始，它会先基于已积累的历史记录修改控制代码，再继续后续的搜索。两组实验使用了完全相同的代码生成模型、评测器、初始化设置与每轮资源限制。

直接在线测试新的搜索策略成本极高。评测一段候选程序只需要生成并运行它，但要验证一套新的搜索规则是否有效，则需要让该规则组织多次生成与评测流程，直到完成一段足够长的探索轨迹。如果每修改一次策略都重新运行完整的流程，策略开发的成本会迅速超过原本用于代码发现的预算。Dream-RSI的解决思路是，利用已经获得的探索记录来完成策略的对比与选择。

基于历史树的离线回放逻辑

真实的搜索流程从一个初始工作区开始。当智能体选择某个节点继续探索时，会继承该节点保存的文件状态与之前的观察结果，生成新的候选代码；评测器会返回错误信息、诊断结果与得分，这次新的尝试会作为父节点的子节点被记录下来。每个节点保存的不仅仅是一个排名分数，还包括生成的代码、评测结果与可以继续修改的工作区状态，因此这棵历史树完整保留了所有走过的探索方向，以及每一步之后的实际反馈。

探索策略每次只能看到当前已经显露的树结构，它可以选择在某个叶节点上继续探索，也可以回到根节点开启新的分支；一次最多可以选出与工作区数量相符的一批节点，如果没有可选的节点则终止搜索。策略需要决定从哪里开始新的尝试、并行处理多少个任务，而具体的新代码生成工作仍然由代码智能体完成。在线运行时，同一个工作区的后续生成结果带有随机性，新的结果必须经过真实执行才能得知。

离线回放流程沿用了同样的决策接口，但将代码生成与评测环节替换为读取历史记录。每测试一个候选策略，会先将完整的历史树隐藏，只露出根节点。如果策略选择根节点，系统会按照历史创建顺序依次揭示下一条已有分支；如果策略选择某个已显露的叶节点，则会揭示该节点在历史中实际产生的下一个子节点。代码、诊断信息与得分只会在被揭示时才进入策略的视野。策略随后会重新决定是继续当前分支、开启新分支、并行处理任务或是终止搜索，另一份候选策略也会从根节点重新开始，可能看到同一历史树的不同部分。

由于回放只需要读取现成的记录，候选策略不需要每次都重新调用代码生成模型与评测器；但由于历史树中仍有未知的部分，策略必须定期回到真实搜索流程中，才能扩充下一轮可以用于回放的历史数据。回放过程会同时统计已揭示节点中的最优得分、所需的尝试次数，以及这些尝试是否可以有效并行。负责开发策略的语言模型会查看各版本策略在历史树上的轨迹与反馈，修改探索策略代码，再将新版本放到同一批历史树上进行对比。当前使用的策略也会参与对比，因此入选的新版本在这批历史的平均回放得分上至少不会差于旧版本，而在真实的下一轮搜索中，仍可能产生不同的结果。

迭代策略在真实场景中的表现

本次研究的策略开发并非简单地为代码智能体添加“过往优秀方案”的提示词。研究团队在ConvDiv任务上进行了对比实验：将过往的探索轨迹总结为方向性文字，添加到下一轮的提示词中。结果显示，无论是固定探索策略还是Dream-RSI方法，添加这种提示词后的效果都不如不添加的版本。这一实验仅覆盖了该任务与对应的配置，但也说明两种使用历史数据的方式存在本质区别：文字提示会直接影响智能体生成的代码内容，而离线回放机制则是用于优化搜索过程的资源分配规则。

ConvDiv任务的另一组结果展示了策略随轮次变化的过程。每轮需要评测的尝试次数从110次一度降至50次；当性能进入平台期后，尝试次数又会上升，同时伴随进一步的性能提升。这一观测结果让“策略会随着搜索进度自适应调整”的结论有了可观察的过程，而不需要仅仅通过最终得分来倒推。

多任务场景下的效果验证

Lasso任务的目标是找到计算完整正则化路径更快且保持数值正确的程序。研究团队先用17个合成实例来搜索程序，再在6个未参与搜索的下游数据集上测试运行时间。搜索过程中累计的智能体调用次数代表了程序发现阶段的投入，而最终程序在数据集上的运行时间则代表了交付后的性能，这两个指标在论文中被分别统计。

在Gemini-3.1 Pro实验组中，Dream-RSI方法仅用317次智能体调用，就得到了六项数据集平均运行时间为2931.0毫秒的求解器；而固定探索策略使用了550次调用，得到的平均运行时间为3587.1毫秒。在Flash模型实验组中，两组的调用次数分别为1879 对 3200次，平均运行时间分别为2350.6 对 2516.7毫秒。两组实验都在相同的模型与评测条件下，用更少的尝试次数找到了平均性能更优的程序。

在平均数据的背后，两个实验组找到的程序并不完全相同。Pro实验组在最大的RCV1数据集上的性能提升尤为明显，运行时间从固定策略的19550.1毫秒降至14616.0毫秒，但其余五个数据集的运行时间反而更长；Flash实验组则有五个数据集的运行时间更快，仅一个数据集稍慢。这也解释了为何论文既要报告六项数据集的平均结果，也要给出逐数据集的表格：搜索策略的改变不仅影响了尝试次数，还改变了最终找到的程序更适配的输入类型。

研究团队还与SimpleTES进行了横向对比：后者报告的代码生成次数为51,200次，而Dream-RSI的Pro实验组仅用317次智能体调用，两者的调用次数差距约为162倍。SimpleTES使用的是gpt-oss-120b模型，而Dream-RSI使用的是Gemini模型，且两者的搜索实现方式也存在差异，这个数字仅用于展示两套系统的相对位置。如果要单独衡量历史回放步骤带来的改进，与同模型的固定探索策略进行对比会更为直接。

数学优化任务为策略设置了不同的目标：Sum–Difference任务需要找到一个整数集合，使得和集相对于原集合的增长大于差集的增长，得分越高越好；Circle Packing任务需要在单位正方形内排列圆形，使半径之和尽可能大；Autocorrelation任务则需要压低函数自卷积的峰值，得分越低越好。在使用Gemini-3.1 Pro模型的十轮对照实验中，Dream-RSI在Sum–Difference任务上的得分为1.145427 对 1.144047，Circle Packing任务的得分均为2.635983，Autocorrelation任务的得分为1.456375 对 1.456001，略落后于固定策略。这说明探索控制器可以跨任务使用，但并非在所有任务上都能取得更好的结果。

GPU kernel任务的候选程序需要先通过正确性检查，再按照运行时间的倒数1/毫秒来计算性能得分。在VGG16与LayerNorm两项任务中，当两组实验组达到相近性能时，Dream-RSI所需的生成次数分别约为固定策略的1/2.43与1/1.79；在ConvDiv与ConvMax任务中，当搜索预算相近时，Dream-RSI找到的kernel性能分数分别为固定策略的2.09倍和1.44倍。前两项任务对比的是达到相同性能所需的尝试次数，后两项任务对比的是相同尝试次数下能找到的程序性能。

总的来说，Dream-RSI方法的价值在于，将原本隐藏在智能体工作流之外的搜索控制器，变成了可以被修改与对比的对象。真实的探索过程生成带有代码与反馈的历史树，离线回放让策略开发代理可以在已知的历史数据中反复试错，更新后的策略代码再用于扩张新的历史记录。

参考资料

以上内容不代表本平台立场，仅供读者参考