今日總覽
今天三篇論文各自獨立、卻不約而同地問同一個問題:coding agent 的表現,到底是模型能力決定的,還是包在模型外面那層「鷹架」(harness)決定的?第一篇用 176 組配對實驗拆解鷹架的三個元件——規劃、動作空間、context 管理——證明它們的價值完全是「看情況」:context 管理在預算越緊時越救命,規劃對弱模型是撐住準確度的拐杖、對強模型卻只是省錢的手段,而工具集對弱模型有利、純 shell 介面對強模型反而更省成本。第二篇來自 NVIDIA、NTU 與 MIT 的團隊,把鷹架本身當成可以遞迴優化的研究對象,跑自動化的研究迴圈找出四個能穩定遷移的鷹架機制,省下四到五成的 token 流量與約三分之一的 API 成本,而且公開了完整程式碼。第三篇用安慰劑對照實驗把「規劃指引」的效果從「模型自己會不會規劃」這個混淆變數裡分離出來,證明寫好的計畫書確實能讓 τ²-bench 成功率提升 7 個百分點,而一個唯讀的驗證器用不到一美分的成本就能擋下六成的誤判過關。三篇證據成熟度都紮實(一篇 176 組 McNemar 顯著性檢定、一篇公開程式碼加真實成本數字、一篇安慰劑對照加自助法信賴區間),但主張範圍收斂在「這個元件在這個條件下值多少」,沒有一篇說「這樣設計鷹架就能通用地變強」。
讀這篇前該知道的詞
| 詞 | 白話解釋 |
|---|---|
| 鷹架(Harness / Scaffold) | 包住模型的程式框架——包含要不要先寫計畫、能呼叫哪些工具、怎麼管理對話歷史——決定模型的能力能不能真正轉換成任務表現 |
| Context 管理(elision / summarization) | 當對話歷史快塞爆 context window 時,刪掉或摘要舊內容以騰出空間的機制;今天第一篇證明它的價值幾乎全部來自「避免爆窗」這件事本身 |
| τ²-bench | 一個測試「有狀態」對話式 Agent(如客服、訂票)的基準,情境設計包含使用者、政策文件與可驗證的正確結果,能區分「看起來完成」跟「真的照政策完成」 |
| 安慰劑對照(Sham control) | 為了確認「計畫書內容」本身有沒有用,設計一組字數相同、但內容洗牌打亂的假計畫書當對照組,排除「有東西可讀」這件事本身造成的效果 |
| 誤判通過(Erroneous acceptance / False pass) | Agent 自己或系統判定任務「已完成」,但實際上並未真正符合規則或政策的情況 |
| RSI(遞迴自我改進,Recursive Self-Improvement) | 讓系統用自己產出的結果去改進下一版自己的迴圈設計;今天第二篇把這個概念用在「鷹架」層而非模型權重上 |
論文一｜鷹架不是單一整體:三個元件的價值各自有條件
An Empirical Study of Harness Design for Coding Agents Run-Ze Fan, Zihao Zhang, Simin Ma et al.（UMass Amherst / Emory University / UNC Charlotte，部分工作於 Zoom Video Communications 實習期間完成） · arxiv: 2609.20804
TL;DR
固定執行迴圈、只改規劃/動作空間/context 管理三個元件,在 4 個模型、2 個長程 coding 基準上跑 176 組配對實驗:context 管理的價值隨 context 預算收緊而暴增(Nemotron-3 120B 在 32K 預算下,加了 context 管理後成功率從 11.40% 跳到 43.00%),規劃對弱模型是「撐住準確度」的鷹架、對強模型只是省成本的手段。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,2026-09-17 提交) |
| 引用速度 | 發布 2 天,Semantic Scholar 查得 citationCount = 0(剛提交,預期本就接近 0) |
| 機構 | UMass Amherst、Emory University、UNC Charlotte(部分作者於 Zoom Video Communications 實習期間完成) |
| 社群反應 | HF Daily Papers 2026-09-18 批次第 24 名(40 個讚);未查得 Papers with Code 收錄 |
| 可信度 | 通過 — 176 組配對設定 × McNemar 顯著性檢定,並用 trajectory 層級分析把每個統計結果對應回具體行為機制 |
| 證據成熟度 | 較完整 — 4 模型(3 種 Nemotron-3 規模 + Mistral-3.5-128B)、5 種 context 策略、4 種預算,附完整消融與統計檢定 |
| 可復現性 | 部分產物 — 43 頁論文詳述方法與設定,但截至查證時未找到公開程式碼或資料釋出連結 |
| 為什麼選這篇 | 直接 — 首次把鷹架拆成元件做逐項因果歸因,而非把鷹架當整體黑箱評測 |
| 方向新意 | 實質增量 — 用 176 組配對設定證明鷹架元件的價值是條件式的,而非哪個元件「本來就比較好」 |
| 今日重要性 | 高 — 直接對應工程團隊在設計 coding agent 鷹架時最常見的三個抉擇 |
| 實務連結 | 明確 — 表格化的「哪個 context 預算下該用哪種策略」可直接套用到 Claude Code / Codex 式鷹架設計 |
| 編輯信心 | 高 — 176 組結果搭配顯著性檢定與 trajectory 層級的機制解釋,結論範圍收斂在「這個元件在這個條件下的效果」 |
| 閱讀建議 | 必讀 — 正在設計或選型 coding agent 鷹架的工程團隊 |
| 主要限制 | 結論僅適用於論文研究的特定元件實作(如特定的 context 管理策略、單一規劃提示機制),作者自己強調不是在找「通用最優鷹架」 |
領域背景
過去評測 coding agent 鷹架大多把它當成一個整體黑箱比較,例如比較 SWE-agent 跟另一套系統誰的成功率高,卻很少拆開來問:如果只換掉規劃機制、或只換 context 管理策略,效果各自有多少?這讓工程團隊在設計自己的鷹架時,只能整套抄別人的設計,不知道哪個元件才是真正在起作用。
中階導讀
- 問題:想像你要幫一個 coding agent 選鷹架設定——要不要先讓它寫計畫、給它固定的工具集還是純 shell、對話變長了要怎麼處理。過去的做法通常是整套抄一個知名框架,但不知道換掉其中一個元件會發生什麼事。
- 方法:研究團隊固定執行迴圈不變,只改規劃、動作空間、context 管理三個元件,在 4 個模型(3 種 Nemotron-3 規模 + Mistral-3.5-128B)跑 SWE-Bench Verified 和 Terminal-Bench 2.1,總共 176 組配對設定,每組都用 McNemar 檢定跟基準比較是否有顯著差異。
- 為什麼重要:結果不是「哪個元件比較好」,而是「每個元件在什麼條件下才有價值」——這代表鷹架設計不該有一套放諸四海皆準的預設值,而要看你的模型能力、context 預算、任務類型來決定。
深入要點
- Nemotron-3 120B 在 32K context 預算下,不做 context 管理(T0)成功率只有 11.40%,加上單純刪減(T1)後跳到 43.00%;Nemotron-3 550B 同樣預算下從 6.40% 跳到 51.40%——多數效益來自「避免爆窗失敗」,而非摘要品質本身
- 規劃消融(T4 w/o plan)在 128K 預算下,最弱的 Nemotron-3 30B 成功率從 25.20% 掉到 13.60%;但最強的 Nemotron-3 550B 反而從 65.80% 微升到 67.80%——規劃對弱模型是「撐住」的鷹架,對強模型是「省成本」的手段
- 動作空間消融(bash-only)同樣在 128K:bash 能力較弱的 Nemotron-3 30B 掉到 10.20%,而 bash 能力強的 Nemotron-3 550B 反而從 65.80% 升到 69.40%,且成本更低
- 「先做規則式刪減,再做 LLM 摘要」(T3/T4)在多數設定下效率最好,而讓被刪內容「可復原」(T2)幾乎沒帶來額外準確度,模型很少真的用到復原機制
- Terminal-Bench(僅 89 題)的多數對照組因為題數不足,沒有達到統計顯著,作者自己承認這部分結論只能靠跨模型、跨預算方向一致來支撐,而非個別顯著性
- Limitation:動作空間消融是綁在一起的介面變更(工具數量、介面提示、檔案狀態追蹤、自動診斷同時改變),無法單獨拆解出「純工具數量」的效果
Reviewer 一句話評
176 組配對設定加上 trajectory 層級的機制解釋,把「哪個元件在什麼條件下有用」講得很清楚,是目前少見的元件級鷹架研究;但作者自己也承認動作空間消融是打包變更、Terminal-Bench 統計檢定力不足,這些自我揭露的邊界讓結論的適用範圍非常清楚,也提醒讀者不要把 4 個模型的結果直接外推到其他模型家族。
給你的 take-away
- 如果你在設計 coding agent 鷹架:先確認你的 context 預算有多緊——預算越緊,context 管理的投資報酬率越高;規劃機制則該依模型強弱決定用途(弱模型當準確度保險,強模型當省錢工具),不要照抄別人的固定設定
- 如果你在幫較弱的模型設計工具集:優先給結構化的預先定義工具而非純 shell,這篇的數字顯示 bash 熟練度不足的模型換成純 shell 反而準確度大跌
論文二｜把鷹架本身當研究對象:NVIDIA/MIT 團隊用遞迴自動化找出四個能省四成 token 的機制
SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness Haozhe Liu, Tian Ye, Sensen Gao et al.（NVIDIA / Nanyang Technological University / MIT） · arxiv: 2609.20519
TL;DR
把鷹架本身當成可以遞迴自動優化的研究對象,讓自動化研究迴圈跑過大量多樣的環境,篩出四個能穩定遷移的機制(動作融合、線上 context 壓縮、觀察封裝、保留證據的精簡器),在 51 個公開任務的 EdgeBench 上跟原生 Codex / Claude Code 式鷹架效能相當,同時省下 44.7%–49.0% 的 token 流量與約三分之一的 API 成本。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,2026-09-17 提交) |
| 引用速度 | 發布 2 天,Semantic Scholar 查得 citationCount = 0(剛提交,預期本就接近 0) |
| 機構 | NVIDIA、Nanyang Technological University、MIT(共同作者含 Song Han) |
| 社群反應 | HF Daily Papers 2026-09-18 批次第 10 名(53 個讚);公開程式碼(github.com/NVlabs/SoL-Pi)與專案頁面 |
| 可信度 | 通過 — 四個機制各自有獨立消融,並在 GPT-5.6 Sol 與 Opus 5 兩種後端、加上 Terminal-Bench 4 與 IMO 2026 做跨場景驗證 |
| 證據成熟度 | 較完整 — 主結果與消融數字具體(token/成本節省幅度),但作者自己在 Limitations 承認機制主要在單一後端上訓練得出 |
| 可復現性 | 完整產物 — 程式碼與專案頁面已於論文發布同時公開釋出 |
| 為什麼選這篇 | 直接 — 把「鷹架可以被自動化研究優化」這件事做成可重跑的工程系統,而非停留在概念 |
| 方向新意 | 實質增量 — 首次把 RSI(遞迴自我改進)的框架用在鷹架層而非模型權重層 |
| 今日重要性 | 高 — 來自具名工程團隊、附公開程式碼,對於已在用 coding agent 大量跑任務的團隊有立即的成本意義 |
| 實務連結 | 明確 — 四個機制可直接參考架構,用於降低現有 coding agent 鷹架的 token 與 API 成本 |
| 編輯信心 | 高 — token/成本節省數字有公開程式碼佐證,但「跨後端遷移」與「遞迴自我改進」兩個延伸主張作者自己標明為初步/未來方向 |
| 閱讀建議 | 必讀 — 正在做 agent 平台成本優化、或評估要不要自建自動化鷹架研究流程的團隊 |
| 主要限制 | 四個機制主要由單一 LLM 後端的軌跡訓練而來,遷移到第二個後端時觸發頻率與強度都較低;「遞迴自我改進」是作者明講的未來研究方向,並非本文已展示的效果 |
領域背景
過去多數鷹架優化靠工程師手動試錯——嘗試不同的 context 壓縮策略、觀察哪個工具介面比較省 token。隨著 coding agent 從「被動完成程式碼補全」轉向「無人值守長時間探索」,人工試錯的速度跟不上鷹架設計空間的複雜度,而鷹架層的自動化研究(而非模型權重層的自動化訓練)一直缺乏系統化的方法論。
中階導讀
- 問題:想像你手上有一套 coding agent 鷹架,想知道怎麼調整才能在維持效能的前提下省下更多 token 費用,但手動測試每種調整組合太慢也太貴。
- 方法:SoL-Pi 借用 RSI(遞迴自我改進)的精神,讓自動化研究迴圈在越來越多樣的環境裡跑鷹架的變體版本(rollout),篩選出能穩定遷移的改動,而不只是在單一開發環境裡表現好的巧合。最終存活下來的四個機制涵蓋動作執行、context 壓縮、觀察處理、延遲讀取四個面向。
- 為什麼重要:這代表「優化鷹架」這件事本身可以工程化、可以自動規模化,而不必只靠工程師個別直覺——對已經在生產環境大量跑 coding agent 的團隊,這直接對應到每小時的實際成本節省。
深入要點
- 在 51 個公開任務的 EdgeBench 評測中,SoL-Pi 在 GPT-5.6 Sol 與 Opus 5 兩種後端都達到跟原生 Pi 相當的效能,同時把記錄下來的 token 流量降低 44.7%–49.0%,API 成本降低約三分之一
- 換算成時薪:相對原生 Codex 與 Claude Code 式鷹架每小時省下約 8.75–13.50 美元,相對 Pi 每小時省下約 4.36–5.71 美元 ⚠️(作者自測,EdgeBench 目前僅公開 51/134 題,尚待外部複現)
- 除了 EdgeBench,團隊也在 Terminal-Bench 4 與 IMO 2026(Lean 4 形式化驗證題)做跨場景測試,以及一個協同 agent swarm 的場景,確認四個機制不是只在單一評測裡湊巧有效
- Limitation(作者自述):目前的機制主要由單一 LLM 後端產生的軌跡訓練得出,在另一個評測後端上觸發頻率與強度都較低,「多後端訓練」被列為未來方向;「遞迴自我改進」(用更省錢的鷹架去降低下一輪自動化研究的成本)也是作者明講的長期願景,而非本文已展示的複合效果
- 落地門檻:需要能跑大量、多樣的自動化研究環境(repository-derived + verifier-driven),對沒有內部評測基礎設施的小型團隊,直接複製整套流程的門檻不低,但四個機制本身是可以單獨參考、移植的設計
- 與主流框架的關聯:論文明確把自己定位為「鷹架層」而非模型層的優化,理論上可以移植進任何 Claude Code、Codex 或自建 coding agent 鷹架的 context 管理與動作執行邏輯
Reviewer 一句話評
公開程式碼加上跨後端、跨評測的驗證,是這類「鷹架自動優化」論文少見的紮實程度,四個機制的設計也具體可移植;但作者自己承認機制的可遷移性目前仍偏向單一後端,「遞迴自我改進」更明確標示為尚未展示的未來方向,讀者不該把這個願景性主張當成已驗證的結果。
給你的 take-away
- 如果你在營運大量跑 coding agent 的平台、在意每小時的 API 成本:SoL-Pi 公開的四個機制(尤其是 context 壓縮與觀察封裝)是目前少見附完整程式碼的降本設計,值得直接參考移植
- 如果你在評估要不要自建鷹架自動化研究流程:注意作者自己標明的邊界——機制在單一後端上訓練出來,換後端後效果會打折扣,不要預期「自動化研究出的鷹架」可以無痛跨模型通用
論文三｜規劃指引真的有用,還是只是「有東西可讀」?安慰劑實驗給出答案
How Do Agent Harnesses Create Value? Planning Information and Release Control in Stateful LLM Agents Yukun Zhang, Kemu Xu, Yishen Chen（The Chinese University of Hong Kong / CUHK-Shenzhen / University of Edinburgh） · arxiv: 2609.20474
TL;DR
用「洗牌打亂但字數相同」的假計畫書當安慰劑對照組,在 τ²-bench 的 265 組配對格中證明:寫好的任務專屬計畫書讓成功率顯著提升 7.17 個百分點(90% 信賴區間 1.15–13.36),而一個唯讀的終端驗證器只用不到一美分的額外成本,就能擋下 61% 的誤判過關案例。
編輯判斷
| 面向 | 判斷 |
|---|---|
| Venue | arXiv preprint(未經同行審查,2026-09-17 提交) |
| 引用速度 | 發布 2 天,Semantic Scholar 本次查詢部分請求被限流,依同批次論文推估 citationCount 接近 0 |
| 機構 | The Chinese University of Hong Kong、CUHK-Shenzhen、University of Edinburgh |
| 社群反應 | 未查得 HF Daily Papers 收錄;未查得 Papers with Code 收錄 |
| 可信度 | 通過 — 用安慰劑對照(Sham)把「計畫書內容」的效果從「有東西可讀」中分離出來,並用 task-clustered 自助法信賴區間量化不確定性 |
| 證據成熟度 | 初步 — 核心效果量精確,但論文自己坦承缺乏獨立時間戳記的預註冊,且兩個評測環境皆為公開基準,模型可能訓練時已見過 |
| 可復現性 | 部分產物 — 未找到公開程式碼或資料釋出,運行環境細節僅列於附錄 |
| 為什麼選這篇 | 直接 — 用因果推論的設計回答「鷹架的哪個元件真正創造價值」,而不是把規劃、驗證混在一起算總分 |
| 方向新意 | 實質增量 — 首次用安慰劑對照分離「計畫指引內容」跟「有計畫可讀」這兩個常被混淆的變數,並疊加「責任成本」框架決定該優先投資規劃還是驗證 |
| 今日重要性 | 高 — 給出可直接套用的決策規則:誤判代價低時優先做規劃,誤判代價高時優先做驗證器 |
| 實務連結 | 明確 — 「獨立驗證器能拿到完整規劃+驗證組合幾乎全部的防止誤判效益,但成本只要十二分之一」是可以直接拿去做優先順序決策的結論 |
| 編輯信心 | 中 — 安慰劑對照設計嚴謹,但論文自陳缺乏預註冊、公開基準可能被模型訓練時看過,效果量應被當作「方向證據」而非精確母體估計 |
| 閱讀建議 | 必讀 — 要決定先投資規劃機制還是驗證器的 agent 平台團隊 |
| 主要限制 | 缺乏獨立時間戳記的預註冊,且 τ²-bench 是公開基準,評測模型可能在訓練時已接觸過,7.17 個百分點的效果量應視為方向性證據而非精確估計 |
領域背景
「鷹架能不能提升 Agent 表現」這類研究,過去大多把規劃、執行、驗證幾個元件的效果混在一起看整體分數,很難回答「到底是規劃寫得好,還是驗證抓得緊」這種歸因問題。這篇的切入點是用實驗設計本身把這兩件事分開,而不是事後用統計去猜測。
中階導讀
- 問題:想像一個客服 Agent 拿到一份任務專屬的操作計畫書,表現變好了——但你怎麼知道是「計畫書裡的內容真的有用」,還是「反正有東西可以參考,Agent 表現就會比較穩」這種安慰劑效應?
- 方法:研究團隊設計了一組「Sham」對照組——把原本的計畫書文字打亂重組,字數完全相同,但內容失去邏輯意義。在兩個 τ²-bench 的 Retail 實驗與一個 Airline 場景裡,把「Fixed(正常計畫書)」跟「Sham(打亂版)」放在同樣的任務、同樣的模型下比較,265 組配對格顯示 Fixed 顯著勝出 7.17 個百分點,證明是計畫書「內容」在起作用,不是安慰劑效應。同時,他們也測了一個唯讀的終端驗證器(只檢查結果不介入執行)能擋下多少「其實沒做對卻被判定完成」的案例。
- 為什麼重要:這給了一個很實際的優先順序判斷依據——如果你的場景「誤判過關」代價很低,先投資把計畫書寫好就有明顯效益;但如果誤判代價很高(例如金融、醫療場景),一個便宜的唯讀驗證器能用極低成本拿到接近完整方案的防護效果。
深入要點
- 265 組配對格中,Fixed 相對 Sham 對照組讓 oracle 驗證的成功率提升 7.17 個百分點(90% task-clustered 自助法信賴區間 1.15–13.36),效益集中在複雜度較高的任務上
- 唯讀終端驗證器在 Retail 場景中擋下 61% 的 oracle 判定無效案例,同時只誤擋 17% 原本正確的案例,額外成本低於每回合一美分
- 哪個元件更值得投資取決於「誤判過關的代價」:代價低時規劃帶來的效益佔優;代價高時驗證器避免的誤判過關效益佔優——而一個獨立驗證器就能拿到完整「規劃+驗證」組合幾乎全部的防誤判效益,成本卻只要其十二分之一
- Airline 場景只有 6 個任務,樣本量小,論文明確把這部分定位為「試驗性(pilot)」證據而非主結果
- 兩個評測環境都是公開基準,論文自己承認參與評測的模型「可能在訓練時已經見過」這些任務,這是解讀效果量時需要放進去考慮的因素
- Limitation(作者自述第 8.4 節):缺乏獨立時間戳記的預註冊、部分請求的精確主機版本與設定資訊未完整記錄,只以附錄形式提供有限的執行環境中繼資料
Reviewer 一句話評
用安慰劑對照分離「計畫書內容」與「有東西可讀」這兩個常被混為一談的效果,是這篇最扎實的設計,搭配以誤判代價為核心的決策框架也直接可用;但作者自己列出的「缺乏預註冊」與「公開基準可能被訓練看過」兩項限制,意味著 7.17 個百分點這個數字更適合當作「規劃確實有用」的方向性證據,而非可以照搬去做精算的母體效果量。
給你的 take-away
- 如果你在決定先做規劃機制還是先做驗證器:先問「這個場景誤判過關的代價有多高」——代價低就先把任務專屬計畫書寫好,代價高就優先做一個便宜的唯讀驗證器,這篇的數字顯示它能用極低成本拿到接近完整方案的效果
- 如果你已經有計畫書機制但成效不明顯:用這篇的安慰劑對照法自己測一次——把計畫書內容打亂但保留字數,比較有沒有差異,才能確認是內容真的有用,還是只是「有東西可讀」的安慰劑效應
今日收穫
之前以為決定 coding agent 表現的主要是模型能力,鷹架只是把模型接上工具的「管線」。今天三篇論文說明的其實是同一件事的三個層次:鷹架的每個元件(規劃、context 管理、動作空間)價值都是有條件的,沒有放諸四海皆準的最佳設定;鷹架本身可以被當成獨立於模型權重之外的研究對象,用自動化迴圈系統性地優化;而「規劃有沒有用」這種看似顯而易見的問題,不用安慰劑對照根本無法確定是內容在起作用還是安慰劑效應。真正該問的問題,不是「這個模型夠不夠強」,而是「包住這個模型的鷹架,有沒有針對我的 context 預算、誤判代價、任務複雜度做過條件式的設計」。
參考資料
- An Empirical Study of Harness Design for Coding Agents
- An Empirical Study of Harness Design for Coding Agents — alphaxiv
- SoL-Pi: Recursively Scaling Auto-Research Loops for Efficient Agent Harness
- SoL-Pi — alphaxiv
- SoL-Pi — code repository
- SoL-Pi — project page
- How Do Agent Harnesses Create Value? Planning Information and Release Control in Stateful LLM Agents
- How Do Agent Harnesses Create Value? — alphaxiv
- arXiv cs.AI new listings, 2026-09-18
- HuggingFace Daily Papers
Loading...