周五晚上十一点多，我照例翻 cs.CL 的新列表催眠。标题里蹦出 Recursive Self-Improvement 那串词，手一滑就想划过去——这两年这词被用得太便宜了，凡是个 agent 能调自己的都敢往上贴。副标题里 "Evolving Worlds" 让我手指停了一下。
点开。
arXiv:2609.14858v1 [cs.CL] 14 Sep 2026
Dream-RSI: Recursive Self-Improvement through Evolving Worlds
12 pages · 17 authors · 777 KB
提交时间戳 UTC 00:10:47，我这边已经是第二天上午了。作者列表我数到尾，Tong Zheng 打头，Yunsong Guo 收尾，17 个人，12 页，人均 0.7 页。这不是吐槽灌水——这种规模内行都懂意味着什么，实验室集体产出，第一作者大概是把东西亲手码出来的那个。DOI 那栏还挂着 pending，v1 嘛。
丑话说前头：我只读了摘要和框架，正文里三个场景的具体实验设置一行没看。下面所有判断都建立在这前提下，谁发现我漏了正文关键一段，直接骂。
它把问题定在哪
摘要里我先抓的是问题定义。它说探索是递归自我改进的驱动力，但"如何管理和提升探索策略"是瓶颈，然后把现状归成一个两难：写死的策略跟不上搜索空间膨胀，在线策略优化又得在长时程 rollout 里干等延迟且昂贵的反馈，还得在巨大的元搜索空间上搜。
这两个我都熟。一个是"规则写死了跑不动"，一个是"想学，但学不起"。真正的成本不在策略本身——在于你每评估一次策略，都得把 agent 真放出去跑一遍。
它的解法核心一句话：把累积的发现历史当成回放模拟器，在里面做梦，拿即时、便宜的离策略反馈去改探索策略。
history_tree = run_agent(env) # 在线，贵
replay_simulator = build(history_tree) # 离线，便宜
dreaming = sample(replay_simulator)
new_policy = improve(policy, dreaming)
run_agent(env, new_policy) # 又回在线，还是贵
看到这结构我脑子里第一个跳出来的是 offline RL 那套。不绕弯子：发现历史树就是你手头那批样本，已实现的搜索空间就是你采样的分布，dreaming 就是在样本上做 off-policy 评估。类比我觉得挺准，但它不是贬义——把 offline RL 的老思路显式地搬进 agent 编排层，做成一个轻量、可编程的东西，这事本身有工程价值。
更让我点头的是它的克制。底层编码 agent 不动，只动上面那层编排。画外音：17 个作者里要是没人拦着，这东西很容易写成"我们提出了一个端到端的全新架构"。没有，就加了一层。这个分寸我服。
我盯上的是 repeated 这个词
摘要里"避免重复且昂贵的在线评估"那句，我看了挺久。
省的是重复那部分。第一次在线评估你还是得跑。回放模拟器不是替代品，是张折扣券——你付过一次全价样本，第二次评估策略时不用再去真实环境付一遍。这节省是真的，尤其那种一次 rollout 要几分钟几十分钟的场景。但把它说成"避免在线评估"，我觉得话说满了。
采样分布 : 历史发现树覆盖的已实现区域
部署分布 : 策略改进后真正要去的地方
上面这两行的错位，是 off-policy 的老毛病，换个名字叫 dreaming 不会让它消失。回放模拟器的边界就是"已实现"三个字——它只能帮你在去过的地方挑得更好，没法告诉你去没去过的地方有什么。这不是它设计得差，是这类方法的先天短板。
论文自己也知道，所以后面要把改进后的策略重新部署回在线环境，模拟器池跟着扩。这步是对的，但它同时说明白一件事：在线那一下绕不过去，这套东西省的是频率，不是环节。
这里我得推翻自己一下
写到这里我回头看了眼自己刚抛的判断，发现有个问题：我拿自己的场景去套人家了。
论文举的三个场景——算法工程、数学优化、GPU 内核工程——共同点刺眼：验证信号便宜、明确、可自动跑。内核快不快，跑 benchmark；优化解好不好，看目标值。这种地形上"已实现搜索空间"的限制没那么致命，因为好解附近往往还有好解，分布错位撑死是个坡度问题。我前面那套"模块之间差着一整座山"的说法，是我把自家的活硬塞进来了。
扯远了，回正题。
但这个观察反过来给了我一个更硬的判断：这东西吃的是"可自动验证"的红利。回放模拟器要能算奖励，前提是你得在历史里定位到一个可比较的信号。落到我手上那些活——"这个重构是不是更可维护""这段日志打得对不对"——信号在哪？找不出来。这时候回放模拟器就是个空转的循环，转得飞快，跑出来的分没人信。
第二层更麻烦。假设你退一步，拿测试通过率当奖励。那奖励质量完全取决于测试本身。而如果测试是同一个模型顺手写的，就是让 AI 给自己的 bug 当裁判。这条我踩过，不改口。
成本这笔账我不敢替它算
摘要里"显著降低发现成本"没给数字。v1，可以理解，但也意味着现在任何"降了多少"的说法都是猜。
我猜省下来的钱主要来自"评估策略"这一环，不是"发现"本身。这俩词在摘要里被并列，成本结构完全不同——发现要真把 agent 放出去改代码、编译、测试；评估是拿一个候选策略去打分。回放模拟器能替的是后者。前者不但替不掉，还可能因为你多跑了一些不靠谱的策略而变贵。所以别把"降低发现成本"直接读成"发现变便宜了"。
还有一处我没在摘要里看到：那个 discover → 建模拟器 → dreaming → 改策略 → 回到 discover 的循环，结构上闭合，闭合不等于收敛。每一步都把历史树喂进池子，池子越来越大，可回放的分布就会越来越偏向"已经好用的那部分策略生成的路径"。这跟推荐系统里的反馈回路是同一类东西——你越按过去的数据优化，就越少看到过去没被选中的东西。也许正文里讨论了，十二页我读了两页，凭这两页下的判断都该打折 😅。
那这次留下什么
一条能马上用的：以后凡是标题带 self-improvement、recursive 这类词的论文，我先翻到实验部分找两样东西——它的验证信号从哪来，贵不贵，能不能自动跑。两样都答得上来，这篇值得细读；答不上来，上面的框架再漂亮也跟我没关系。
Dream-RSI 两样都答得上来，所以它进了我的待读列表。至于那个回放模拟器能不能带它跳出局部，我还是那句，信一半。等它把成本数字放出来再说。