NVIDIA SoL-Pi：少近半 Token，能力守得住嗎？（2026）

2026 年 9 月 17 日，由 NVIDIA、南洋理工大學與 MIT 研究者組成的團隊，在 arXiv 發表了〈SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness〉。SoL-Pi 不是新模型，而是一組裝在 coding agent 外層的 harness 改造：讓 AI 自己搜尋更省 token 的工具執行、上下文壓縮、觀察結果保存與 log 閱讀方式。

這篇文章會先還原 152 個研究方向如何收斂成四個機制，再把最醒目的省 token 數字放回正確比較基準，最後用 Terminal-Bench、公開程式與 agent 評測的隨機性研究，判斷它究竟證明了什麼。

先講結論：省近半 token，不等於免費升級

在 EdgeBench 公開的 51 題上，研究團隊報告：兩個 backend 都採 xhigh reasoning effort；SoL-Pi 的完整四機制「Efficiency」配置，相對同一個 Pi baseline，讓 GPT-5.6 Sol 的 token traffic 減少 49.0%、API-equivalent 成本減少 33.2%；Claude Opus 5 則分別減少 44.7% 與 33.5%。但兩邊的平均分數也都下降，分別只保留 Pi 的 93.7% 與 94.3%。

所以更準確的說法是：作者這次的 point estimates 呈現一個成本更低、分數也較低的折衷點，而不是「能力不變，帳單直接砍半」。這個差異很重要，因為論文另有一個名為「Performance」的結果，是每個 backend 各自挑出最高分的單一機制；它不是上述固定的四機制組合。

SoL-Pi 改的不是模型，而是模型的工作台

模型負責推理，harness 則決定模型看見哪些歷史、何時呼叫工具、執行結果如何回傳，以及長任務何時整理 context。同一個模型放進不同 harness，就像同一位工程師換了不同的工作台：工具擺放與紀錄方式，會直接改變完成速度、成本與犯錯機率。

搜尋從 152 個候選方向開始，再讓 auto-research loops 在 535 個搜尋環境中測試；其中 495 個來自 GitHub issue 與已合併 PR 的配對，40 個是帶 verifier 的合成任務。論文報告超過 3,000 次 runs、60,000 次 agent–environment interactions，最後只有四個機制通過篩選。

These counts describe the scope of our search; they do not establish a scaling law.

中文：這些數量只描述搜尋範圍，並沒有建立「搜尋愈大就一定愈好」的 scaling law。

SoL-Pi 論文，第 2.2 節

這也說明了「recursive self-improvement」在這裡的邊界：研究環境、接受門檻與最終評測由作者預先設計；候選假說、軌跡分析與實驗則由 research AI 驅動。論文本身只稱 RSI-inspired，並把複利式 recursive efficient improvement 列為長期願景，而不是本研究已證明的效果。

四個機制，分別刪掉四種重複工作

1. Action Fusion：修改與驗證合成一次工具呼叫

一般 agent 先修改檔案，下一輪再決定跑測試或 build。Action Fusion 允許 edit/write 同時攜帶後續命令，適合用在可預先指定後續命令的流程；是否融合由模型在呼叫前決定。它省的是中間一次模型 round trip，不是跳過驗證。

2. Online Context Compact：先算壓縮會不會回本

系統在 plan step 完成後，估計未來還有多少請求、context 成長多快，以及縮短 prompt 能否抵銷 cache rewrite 的成本；只有預期節省足夠，或已接近 context window 上限，才啟動 Pi 原生 compaction。這是成本模型，不是「context 一長就摘要」。

3. ObservationPack：原文留在本地，不必每輪重傳

超過 10 KiB、非 error 的純文字工具結果先完整傳給模型兩次，之後改成穩定 handle 加短 excerpt；需要細節時，agent 再用 obs_recall 讀回本地原文。這不是無損壓縮：完整資料仍存在儲存層，但不再全部留在模型當下可見的 context。

4. Evidence-Preserving Reducer：讓另一個模型先讀 log

對指定 build／test 命令產生、至少 4 KiB 的 diagnostic log，SoL-Pi 先保存原文，再交給設定的 reducer 模型（預設 GPT-5.6 Luna）挑出證據。主程式檢查 source hash、schema、status 是否與工具的 isError 相符，以及引文是否逐字存在；驗證失敗便回退到原始 log。但「引文真的出現在原文」只證明引用忠實，不保證 reducer 沒漏掉另一個關鍵錯誤。

51 題不是全都「從未碰過」：先看清楚評測切法

EdgeBench 完整資料集有 134 題，SoL-Pi 使用公開的 51 題，而且這些題目沒有進入前述 535 個搜尋環境。不過團隊又把公開題分成 11 題 one-way acceptance 與 40 題 final generalization：前 11 題曾用來決定候選是否接受，headline 表格則彙總全部 51 題。因此，可以說它避開了主要搜尋集，但不能把 51 題全稱為完全未參與選擇的最終 holdout；公開子集也不是按六個領域等比例抽樣，結果不能外推到完整 134 題的分布。

Backend／Harness	Total tokens	API-equivalent cost	EdgeBench 平均分
GPT-5.6 Sol／Pi	2.1538B	US$1,339	44.833
GPT-5.6 Sol／SoL-Pi Efficiency	1.0990B	US$894	42.003
Opus 5／Pi	2.3697B	US$1,741	44.756
Opus 5／SoL-Pi Efficiency	1.3101B	US$1,158	42.224

完整四機制版本在 GPT-5.6 Sol 上少用 49.0% token、少 33.2% 成本，但平均分由 44.833 降到 42.003；Opus 5 少用 44.7% token、少 33.5% 成本，平均分由 44.756 降到 42.224。兩個差距分別是 2.830 與 2.532 分，論文沒有提供重複 trial、confidence interval 或 equivalence test，所以「comparable」是作者的判讀，不是統計上已證明等效。

論文另列的 Performance point 確實比 Pi 高：Sol 為 47.208，Opus 5 為 50.482。但 Sol 選的是只有 ObservationPack 的版本，Opus 5 選的則是只有 Action Fusion 的版本。這是依 backend 事後選出的兩個不同 operating point，不能與完整四機制的低成本數字合成「同一套設定又更省、又更強」。

美元是價格模型，不是實付帳單

論文的 token traffic 包含 uncached input、cache read、cache write 與 output；論文表註稱，美元成本依 2026 年 8 月 17 日的 API 定價換算，是 list-price 的 API-equivalent estimate。它不等於每位使用者的真實發票，也不能直接套到訂閱制方案或不同 cache 價格。

摘要寫的每小時節省 US$8.75–13.50，是相對原生 Codex 與 Claude Code harness；相對 Pi 則是 US$4.36–5.71。這組時薪與把總成本差攤在 51×2、共 102 agent-hours 的換算一致，但論文沒有在方法段明載這個分母；它也不是工程師工時價值或未來模型價格的保證。

Terminal-Bench 4 把代價攤開了：更便宜，但少解三題

最值得盯住的反例，不在 EdgeBench，而在作者另外跑的 63 個 Terminal-Bench 4 CPU-only 任務。Codex 與 Pi 都解出 18 題，SoL-Pi 只解出 15 題；SoL-Pi 總模型成本為 US$211.12，低於 Pi 的 US$286.45。

相對 Pi，SoL-Pi 總成本少 26.3%，每解一題成本由 US$15.91 降到 US$14.07，改善 11.6%；但這次點估計的解題數也少 16.7%。作者將較低總成本解讀為跨 benchmark 的初步效率證據；15 比 18 不支持「成果完全不受影響」的強版本，但差距是否穩定仍需要重跑確認。

論文也沒有列出這組 TB4 實驗的精確模型 snapshot、reasoning effort、Codex／Pi／SoL-Pi commit、timeout 與重跑次數。因此它只能被視為作者報告的 transfer point estimate，還不是可獨立重建的穩定排名。

三個尚未跨過的證據門檻

1. 單次 point estimate，還不是穩定效果

SoL-Pi 主表沒有報告每題重跑次數、變異區間或統計檢定。另一篇蒐集 60,000 條 SWE-Bench-Verified trajectories 的研究〈On Randomness in Agentic Evals〉發現，單次 pass@1 估計可因抽到哪一次 run 而相差 2.2–6.0 個百分點。這項 SWE-Bench-Verified 結果不能量化 EdgeBench 分數的變異，只證明長程 agent 的單次評測可能有顯著 run-to-run variance；SoL-Pi 的小差距需要自己的重跑與 uncertainty 才能定性。

2. 外部 benchmark，不等於獨立復現

EdgeBench 與 Terminal-Bench 是外部建立的 benchmark，但執行並報告 SoL-Pi 結果的仍是論文作者。截至 2026 年 9 月 20 日，在查核 arXiv、官方 repo／issues 與公開網頁搜尋後，我們未找到完整 benchmark 的獨立重跑。我們檢視的公開 GitHub tree（commit bd00588）有四個 extension 與離線測試，但未包含 3,000 多次搜尋 runs、60,000 多次 interactions、逐 request cost ledger、完整 benchmark traces 與所有 launch manifests；因此無法只靠該 repo 重建整條證據鏈。

3. Harness evolution 本來就容易對選擇流程過擬合

2026 年另一項〈Rethinking the Evaluation of Harness Evolution for Agents〉研究，在可比的 feedback 與 inference budget 下發現，自動 harness evolution 不一定勝過更簡單的 test-time scaling，且在 disjoint held-out split 的泛化有限。它研究的不是 SoL-Pi，不能當作直接反駁；但它指出正確的驗證標準：搜尋預算要對等，真正未參與選擇的任務要分開報告。

開源版本的風險，不只在效能

NVlabs／SoL-Pi 採 MIT License，但四個機制預設全部關閉；安裝 extension 並不會自動重現論文的 Efficiency 配置。ObservationPack 與 reducer 會把內容保存在 Pi session directory，session 結束後不自動刪除；若啟用遠端 reducer，符合條件的 log 可能再送到另一個模型。官方也明說 secret detector 不是完整掃描器。

SoL-Pi is not a sandbox or permission boundary.

中文：SoL-Pi 不是沙箱，也不是權限邊界。

SoL-Pi Security 文件

換句話說，它繼承 Pi 原本能碰到的檔案、程序、網路與憑證範圍。若專案含私密 log、客戶資料或 token，先做權限隔離與資料分類，比先追求節省多少 token 更重要。

AlphaLab 的判讀：真正的突破，是把 harness 當成可量化產品

我認同 SoL-Pi 最核心的工程判斷：長時間 agent 的成本，不只由模型單價決定，也由「同一份資訊被重傳幾次、同一個決策被拆成幾輪、哪個模型負責讀哪種資料」決定。Action Fusion 與 ObservationPack 尤其值得注意，因為它們把局部、可驗證的重複工作移出 hot path；ObservationPack 仍保留原文召回。

我不認同把這批結果包裝成能力不變的自我改進。在作者這次點估計中，完整 stack 在兩個 EdgeBench backend 都以約 6% 較低平均分換取約三分之一 modeled cost，到了 Terminal-Bench 又少解三題；主表沒有重跑與不確定性，我們檢視的該版公開 repo 也不足以重建整套 benchmark。就已報告的 operating points 而言，它是一個成本較低、分數也較低的折衷點，不是普遍、無代價的 scaling law。

這仍然很重要。模型能力逐漸商品化之後，差異會愈來愈常出現在 harness：context 的資料生命週期、工具協議、cache 經濟性、驗證路徑與權限邊界。SoL-Pi 的貢獻，是把這些看似零碎的工程選擇拉進同一個可測量框架。

如果你正在做長任務 Agent，先採用這三個判準

1. 量資料生命週期，而不只量總 token。分開記錄 uncached input、cache read、cache write、output，以及大型 tool result 被重播幾次。
2. 先試可逆、局部、fail-open 的改造。從適合預先指定的 edit→test 融合，或 handle＋精確 recall 開始；把「轉換失敗時保留原始證據」列為自己的驗收條件，而不要假設所有 compaction 都會自動回退。
3. 把品質與成本放在同一張表。同時報成功率、平均分、每解一題成本、未觸發任務與真正未參與選擇的 held-out 結果，並為關鍵差距安排重複 runs。