Dream-RSI：把探索歷史變成可回放的自我改進迴路

長程 discovery（發現）任務通常有兩個角色。第一個是 discovery agent：提出候選演算法、數學構造或 GPU kernel，並實際執行與評估；第二個是 exploration policy：決定下一步要從哪個分支繼續、同時開幾個嘗試、何時停止。Dream-RSI 改的是後者，因此它比較像「探索控制器的離線評估與選擇器」，不是把 coding agent 重新訓練一遍。[3]

這個區分很重要：若把任何「下一輪做得更好」都叫作模型自我學習，就會把 prompt、工具、控制流程、策略程式與模型權重混成同一件事。本文後面所說的 RSI（recursive self-improvement，遞迴式自我改進），專指 exploration policy 在多輪中被回放評估、改寫、選出，再部署的閉環。

固定策略不一定差；它的問題是，探索空間變大之後，策略仍用同一套「往哪裡分支、怎麼平行、何時收手」的規則。作者把瓶頸拆成兩層：一是固定策略無法從累積的 discovery experience 改善，可能重複把計算花在已經反覆失敗的方向；二是若直接在線上優化策略，每個候選策略都要等一個長程 rollout 完成後才知道好不好。[1][3]

因此這篇工作的核心不是「再造一個更聰明的 discovery agent」，而是把原本藏在 harness 裡的探索決策抽出來，成為能被觀察、評估、版本化的 meta-layer。這也是為何它對 Agent 工程有啟發：長程任務的瓶頸有時不在模型回答內容，而在控制器把昂貴的執行機會分配給誰。

想像 Agent 第一次穿越一片陌生山區。它走錯路、遇到死路、回頭，並在過程中畫下一張地圖。下一個探索策略不需要把所有路再走一次；它可以在地圖上比較不同路線、避開已知死路，或重新考慮之前太早放棄的分岔。

Dream-RSI 把這張地圖對應到 discovery tree：每個節點是一個嘗試，帶著從父節點繼承的 workspace、產物、分數與診斷。完成的探索樹不是只供模型閱讀的文字摘要，而是能按父子關係被另一個 policy 重新走訪的記錄。[3]

精確性的正確邊界：作者稱 replay simulator 在「已實現的 search space」上是 exact，因為它揭露的是已發生的 outcome，而不是模型猜測的 outcome。這不代表它對未探索分支、換了 evaluator 的環境或下一次隨機生成結果都精確。[1][3]

論文的 loop 可以濃縮成三個階段。online（線上）是產生新候選與新結果；offline（離線）是固定 history 後，用相同的決策介面揭露既有節點；redeploy（重新部署）則把被選中的 policy 帶回下一輪。這裡的 offline 不是對模型做權重訓練，而是對探索控制器做歷史回放。

Off-policy（離策略）在此指「資料由一個已部署的行為策略留下，但現在拿另一個候選策略去評估」。它不是任意地把舊 log 丟給模型：候選只能使用回放時已揭露的 prefix（目前前綴），並且下一步只能走記錄中存在的 child。這個限制是低成本的來源，也是泛化能力的邊界。[3]

先固定同一個決策介面

每棵樹從 root r 開始。已揭露樹中的 root 與 leaf 是可繼續探索的 eligible nodes；平行 worker 數為 W 時，一輪動作是從這些節點挑一個 batch。用白話寫，policy 每次都在回答：「現在有哪些入口或分支尖端可以接著走？這一輪最多同時開幾個？」

論文把 online 與 replay 的介面刻意做成相同，差異放在「選完 batch 之後怎麼得到下一個觀測」。這使得 policy 的程式可以被拿到另一個 transition backend 執行，而不是為 offline 另造一套評估規則。[3]

Online 會生成，replay 只會揭露

對非 root 節點，replay 依照原樹的 parent–child 順序揭露下一個已記錄 child；對 root，則依既有記錄逐步開啟尚未揭露的分支。因而回放軌跡是原樹的 subtree，不是把所有節點一次塞進 prompt。每個 policy–tree pair 都重置，避免早先候選的觀測狀態污染後來候選。[3]

Dream-RSI 不只問「最後分數最高嗎」，也把代表性執行成本與平行度放進 replay objective（回放目標）。對第 i 棵歷史樹與第 m 個 policy version，論文給出的形式是：

其中：

• max sᵥ 是這次回放揭露 subtree 中最好的 discovery quality，論文設定分數越高代表品質越好。
• Nᵢᵐ 是回放軌跡揭露的非 root 節點數，代表「這條策略等價於要求多少次 generation–evaluation」，不是 replay 當下真的發生了多少次 API／程式執行。
• β₁ 是代表性執行成本懲罰；β₂ 是平行性獎勵，讓一次批次完成多個有價值的 continuation，而不是把相同工作序列化。
• kᵢᵐ,★ 是完成的回放決策輪數；若回放是非空的，最後一項近似「每一決策輪平均揭露多少嘗試」。

這個目標函數帶來一個工程上的提醒：若只最大化最高分，policy 可能把所有資源押在單一路線；若只最小化節點數，policy 可能太早停；若忽略平行性，理論上相同的節點數也可能有完全不同的 wall-clock。實作時應把品質、代表性成本、平行輪數分開記錄，不能只留下單一總分。[3]

外層 iteration t 的 offline phase 會從目前 policy πt 開始產生多個 revision。關鍵做法是：目前已部署的版本本身也放在候選集合中，所有候選都在相同的固定 history Ht 上回放，再選平均 replay score 最高者：

這就是「固定歷史上不變差」的正確讀法：相對於同一批已收集的 trees、同一個 replay transition、同一組 β，選出的版本在平均回放分數不低於目前版本。論文與官方頁面都把這個候選保留機制視為 selection 的理由。[1][3]

我的工程判讀：這是一個「對固定資料與固定 surrogate objective 的單調選擇性質」，不是部署安全性 theorem。若要把它帶進生產環境，仍需 holdout rollout、canary、版本鎖定與 rollback；否則只是把 history overfitting 包裝成穩定。

作者在三個 scientific discovery domain 評估八個任務：algorithm engineering、mathematical optimization 與 GPU kernel engineering。下面先列論文摘要和官方頁面特別突出的數字，再說這些數字不該被怎麼解讀。

Lasso 的表格：成本與下游結果要一起看

arXiv HTML 的 Lasso 表格列出兩個 discovery-agent 設定。Gemini-3.1-Pro 下，Dream-RSI 的 cumulative discovery-agent calls 為 317，六個 held-out downstream dataset 的平均 wall-clock runtime 為 2,931.0 ms；Recursive Fixed Exploration 為 550 calls 與 3,587.1 ms。Gemini-3.7-Flash 下，Dream-RSI 為 1,879 calls 與 2,350.6 ms；固定探索為 3,200 calls 與 2,516.7 ms。表格的 runtime 是越低越好，compute 是 cumulative calls。[3]

數學任務：不是每一欄都由 Dream-RSI 贏

在作者列出的代表性數字中，Sum Diff 的 Dream-RSI 為 1.145427，Recursive Fixed Exploration 為 1.144047，SimpleTES 為 1.143975；Circle Packing 三者都列為 2.635983；Auto Correlation 則是 Dream-RSI 1.456375、固定探索 1.456001、SimpleTES 1.453675，而且該欄越低越好。這表示「整體 competitive」不等於每個任務都刷新最佳值；作者也特別註明 SimpleTES 在 Auto Correlation 的數值較佳，但使用 51,200 generations。[3]

行為分析：先省計算，停滯後再擴張

在 ConvDiv 的分析中，作者報告 learned exploration policy 會先把 evaluated attempts 從 110 降到 50，性能停滯後再增加探索力度，並與之後的 round-best score 上升對齊。這比較像自適應資源配置，而不是單調地「越廣越好」或「越貪心越好」。官方頁面也報告，把歷史抽成語義方向直接塞進 prompt，在相同 budget 下反而劣於 replay；長程、多分支任務中，過強的語義先驗可能壓縮探索多樣性。[1][3]

論文把 replay simulator 與 world model 放在類比關係中：兩者都讓 policy 有機會在不重複真實互動的情況下「想像」路徑。然而，經典 world model 的核心是學習環境如何因動作而演化的可泛化 dynamics；Dream-RSI 的 replay simulator 則是把已發生的探索樹當成 empirical、grounded 的可回放資料結構。[3]

所以「evolving worlds」不是宣稱 Dream-RSI 擁有一個會預測未來的完整環境模型。每一輪 online deployment 只是新增一棵實際探索樹，讓 replay pool 擴大；它仍然不能把未被探索的 branch 變成已知事實。這個縮小後的定義反而是工程優勢：不必先訓練一個昂貴的 generative world model，就能利用已經為長程任務支付過的執行記錄。

Dream-RSI 的力量與限制是同一件事：它很忠實地重播歷史，因此不會憑空補上歷史沒有覆蓋的世界。下表把方法限制翻成工程風險。

公開性也是可重現性限制

本次查證的官方 GitHub README 明確寫著 code is being prepared for release；其 release plan 將「Discovered programs」「Full codebase」與「Reproduction scripts」列為 Being prepared。這代表論文、專案頁與部分 PDF 資產可讀，不代表完整程式碼與重現腳本已可供外部獨立重跑。[4]

證據界線：本文不把 preprint 寫成同儕審查定論，不宣稱作者結果已在本機重現，也不把「固定歷史上不變差」擴張成線上安全或品質保證。對任何引用的倍數與分數，請回到論文表格、官方頁面與 release plan 查核。

如果要把這個想法放進 Hermes、NOOA 或一般 Agent 平台，最小可行單位不是「讓 Agent 自己改所有東西」，而是增加一個可審核的 exploration-controller layer。以下是設計映射，不是聲稱論文已與這些平台整合；尤其 NOOA 的特定 API、隔離模型與資料格式，本文不做未查證假設。

不依賴新資料庫的最小記錄格式

先把資料契約定清楚，再選儲存後端。下面只是欄位示意，不是作者公開的程式碼或固定 schema：

{
  "tree_id": "run-2026-09-16-001",
  "task_version": "task-v3",
  "policy_version": "policy-v7",
  "evaluator_version": "eval-v2",
  "nodes": [
    {
      "node_id": "n-0042",
      "parent_id": "n-0017",
      "observed": true,
      "artifact_ref": "artifact://internal/…",
      "score": 0.0,
      "diagnostics": ["…"],
      "sensitive_fields": "redacted-or-separated"
    }
  ]
}

對 Hermes，這個 controller 可以由獨立 worker 管理，policy revision 以檔案變更和測試結果交付，外層任務再決定是否部署；對 NOOA 或其他平台，重點同樣是把「觀測 prefix、合法 batch、回放 transition、選擇閘門」做成平台無關的合約。不要把平台已有的長期記憶直接當 discovery tree：記憶是可檢索上下文，tree 還需要 parent–child、可揭露順序與 outcome 完整性。

1. 定義固定的 policy API：觀測內容、合法節點、批次上限 W、停止語意都要明確。
2. 為每次 online rollout 建立不可變 tree ID，保存 parent、workspace／artifact reference、score 與 diagnostics。
3. 將 online executor 與 replay executor 分開；offline 不得偷偷呼叫 discovery agent 或 evaluator。
4. 讓每個 policy–tree pair 從 root reset，並強制 policy 只能看到已揭露 prefix。
5. 把 history、task、evaluator、policy、objective、schema 全部版本化。
6. 將 represented probes、quality、parallelism 與 replay score 分開記錄，避免只最佳化一個混合數字。
7. 把目前 deployed policy 放進候選集合；若 revision 低於 baseline，selector 不得自動替換。
8. 對 policy code 執行 syntax、contract、resource、權限與敏感資料檢查，再進 staging。
9. 用新的 online rollout 或 holdout tree 驗證，不把 replay 上升當成部署成功證據。
10. 保留 approval、canary、版本鎖定與 rollback；任何自動學習都不能繞過線上安全邊界。
11. 在研究筆記中標示「作者報告／本文未重跑／尚未公開的 reproduction 資產」，讓讀者知道證據在哪一層。

1. 先看官方專案頁：快速建立三階段 loop、山徑地圖比喻與官方 highlight；不要先從倍數 headline 推導機制。dream-rsi.com[1]
2. 再看 arXiv HTML 的方法段：優先讀 discovery tree、online rollout、offline evaluation、replay objective 與 policy selection，尤其注意「只揭露已記錄 child」和「每個 pair 從 root reset」。arXiv HTML v1[3]
3. 接著看實驗段：確認每個數字的方向、budget、比較基準和是否是 held-out downstream data；不要把 2.43× fewer generations 和 2.09× higher performance 當成同一類指標。arXiv abstract[2]
4. 最後查 GitHub release plan：確認哪些資產已公開、哪些仍在準備；在完整 code 與 reproduction scripts 未列為可取得前，不要把本篇或其他文章的轉述當成獨立重現。GitHub repository[4]

若只記得一個判斷：Dream-RSI 的新意在於把已付費的長程探索歷史，轉成可供 meta-policy 反覆試走的有限世界。它不是把未探索的未來預測出來，也不是保證線上策略永遠變好；它提供的是一個可以被版本化、評分、審核和回滾的 exploration-controller 改進迴路。