An Empirical Study of Harness Design for Coding Agents 精讀：規劃、工具與上下文管理

90 秒掌握論文

• 問題：當兩個程式碼 Agent 的成績不同，我們常把差異歸給模型，但模型外的 Harness 也決定它能規劃什麼、如何操作程式庫，以及長軌跡如何留在有限上下文裡。只比較完整系統，會把這些作用混在一起。
• 核心洞見：作者固定 ReAct 執行迴圈與多個支援元件，分別改變規劃、操作介面和上下文管理，觀察元件效果如何隨模型、任務和視窗預算改變。
• 最強證據：四個模型在 SWE-Bench Verified 與 Terminal-Bench 2.1 的 176 組設定顯示，32k 視窗下，管理上下文相對無管理的平均成功率差距分別為 35.7 和 9.5 個百分點；到 128k 時縮至 2.7 和 2.8 點。多數小視窗的收益伴隨避免溢位，而不是管理策略普遍提升推理能力（論文 Figure 3、Tables 3–4、§3.2）。
• 主要邊界：作者每題每設定只執行一次；規劃與操作介面只在 T4/128k 下比較；操作介面改動還同時改變提示、狀態追蹤與編輯後診斷。因此結果是這些實作的條件式效果估計，不是模型能力的普遍排序，也不是每個單一介面的隔離因果效果（§3.1、§6）。

本文依據 2026 年 9 月 17 日提交的 arXiv v1 預印本；論文頁面沒有建立同儕審查狀態。作者提出的問題很實際：當 Agent 能做幾百步的程式工作，哪些 Harness 元件會把模型能力轉成可完成的任務？他們以同一套輕量迴圈比較上下文管理、規劃與操作介面，再用軌跡分析追問成功率變動是怎麼發生的。答案不是元件越多越好：有限視窗下先避免溢位，對早早放棄的模型加上規劃，對具備 shell 操作能力的模型允許更粗粒度的命令，都可能有效；但每個效果都依條件而變。

Harness 到底改變了什麼？

「Harness」在這篇論文裡指的是模型外層、讓模型能持續操作工作區的軟體：控制迴圈、工具介面、規劃狀態，以及上下文保留政策。它會改變模型在每回合看到的歷史、能呼叫的動作、工具失敗如何返回，以及流程何時停止。若只把模型名稱當成 Agent 的全部，便無法解釋同一模型為何會在不同工具流程裡產生不同軌跡。

作者以 ReAct 形式固定每回合的基本結構：組裝模型輸入、取得思考與動作、在任務容器執行工具呼叫，再把觀察結果附加到歷史 $H$。研究介入三個位置：

1. Planning（規劃）：模型是否有持續更新的明確任務計畫。
2. Action space（操作介面）：模型使用具型別的工作區工具，或只用 Bash。
3. Context management（上下文管理）：模型與工具的舊回合內容如何在有限視窗內保留、壓縮或回讀。

其餘重要條件盡量固定，包括安全檢查、寫檔前讀取要求、修改後 Python 快速診斷和卡住偵測。這使比較更接近「在這個執行底座上，加入某一種實作會怎樣」，但結論仍只適用於論文實際測試的提示、閾值、工具和模型。

這是一項經驗性的元件研究，不是把 Harness 定義成正式標準，也沒有證明三項介入互相獨立。三者只在特定條件下分別比較，作者沒有執行完整的全因子設計來估計每種組合與交互作用。

核心直覺：既有整體 Harness 比較為什麼不夠

多數 Agent 評估測到的是模型與周邊系統共同完成任務的結果。不同團隊的系統可能同時改變工具、提示、錯誤回饋、上下文政策和停止規則；整體分數雖能比較產品組合，卻很難說明哪個組件造成差距。本文的實驗策略，是固定一個輕量底座，對選定元件做配對比較，並觀察效果如何隨模型與資源預算變化。

可把一個實驗設定理解為 $(m, b, w, c)$：$m$ 是模型，$b$ 是 benchmark，$w$ 是上下文視窗預算，$c$ 是 Harness 配置。觀察到的成功率與成本寫成 $S(m,b,w,c)$ 與 $K(m,b,w,c)$。這不是作者提出的正式記號，而是 Bloss0m 工程化整理：研究問題不只是找出最大 $S$，而是辨識在目標工作負載與預算下，哪些 $c$ 能提高成功率、控制成本，或避免軌跡過早終止。

這個整理也提醒我們，模型參數量只是能力的粗略代理。本文的 Mistral-Medium-3.5-128B 與 Nemotron-3 120B 雖都是百億級模型，但他們對 Bash 與規劃的反應不同；模型訓練、工具熟悉度和 shell 能力都可能影響結果。作者沒有把模型尺寸當成唯一原因。

用一個例子走完整個方法：上下文管理

以下是 Bloss0m 建立的示意情境，用來解釋論文 T0–T4 的流程，不是論文中的實驗軌跡。假設 Agent 正在修一個 repository issue；它讀了數份很長的測試輸出，稍後才發現需要回頭找其中一段錯誤訊息。

1. 歷史增長：每回合把模型動作與工具觀察加入 $H$。前置提示、任務描述和最近數個回合通常最可能直接支援當前工作。
2. T0，不額外管理：保留所有內容直到超出模型視窗。若超出，該軌跡就因 context overflow 終止。
3. T1，省略（M1）：達到管理門檻時，把中段過期工具輸出的本文換成短 stub。這便宜，但細節不再可直接讀取。
4. T2，省略加回讀（M1+M2）：省略前將原始觀察放進外部儲存，並提供 recall_event。模型可以按需取回，但必須知道內容可能有用並主動呼叫。
5. T3，摘要（M3）：把中段舊事件交給同一模型的一次獨立、無工具呼叫，整理成自然語言摘要。摘要可能失去細節，也會帶來額外模型成本。
6. T4，分階段處理：先省略肥大的舊工具觀察，若歷史仍達硬門檻，再摘要最舊的中段事件。前置區和近期視窗保留原文；近期視窗預算至少保留兩個回合。
7. 可能失敗處：如果被省略的錯誤細節稍後變成關鍵，模型可能不會想到呼叫回讀；如果摘要漏掉精確路徑或測試值，後續推理也可能受影響。論文結果顯示回讀確實很少被使用，但不能據此說它在其他任務沒有價值。

T0 到 T4 是本文的五種比較策略，而 M1、M2、M3 是更基本的機制。T1 與 T2 的差異在回讀是否可用；T3 單獨摘要；T4 同時允許省略、回讀與摘要。T1–T3 只有單一管理動作，因此使用硬門檻 $B_2$；T4 先在較低的軟門檻 $B_1$ 省略，仍超過硬門檻才摘要。實驗設定將軟、硬門檻分別設為可用視窗的 0.6 與 0.85，近期原文窗口以 0.3 預算配置並至少保留兩回合（§2.3、§3.1、Algorithm 1）。

三種上下文策略如何組合

上下文管理要平衡兩種損失。省略或摘要是有損壓縮，可能丟掉未來有用的細節；外部儲存和回讀保留可恢復性，但需要額外狀態與工具，而且依賴模型判斷何時取回。作者把這三種機制組成五個 tier：

策略	省略 M1	回讀 M2	摘要 M3	讀者可以怎麼理解
T0	—	—	—	不做額外壓縮；溢位就停止
T1	✓	—	—	用 stub 取代中段過期工具輸出
T2	✓	✓	—	省略原文並存起來，可按需回讀
T3	—	—	✓	把較舊中段事件整理為摘要
T4	✓	✓	✓	先省略大型觀察，仍超限再摘要舊事件

對 T4 而言，歷史 $H$ 超過 $B_1$ 時，系統在中段 $M$ 找出大型工具觀察，將原文另存，並以 stub 取代；超過 $B_2$ 時，再把最舊的中段事件加入持續更新的摘要。這裡的「中段」是前置區與近期逐字回合之間的歷史，不是任意刪除所有舊訊息。補充材料的 Algorithm 1 列出每回合操作次序；Appendix 7.3 給出摘要 prompt 與插入模型輸入的文字片段。

T4 的設計直覺是先做低成本壓縮，盡量少叫模型摘要。這是作者測試的政策之一，不代表普遍最優；它的效果依閾值、輸出大小、模型和任務而變。摘要使用同一個待測模型另開無工具呼叫，代表壓縮本身也用掉輸入與輸出 token。

實驗設計：控制底座、有限的元件比較

作者測試四個模型：Nemotron-3 30B、120B、550B，以及跨系列的 Mistral-Medium-3.5-128B。兩個 benchmark 分別是 SWE-Bench Verified 的 500 個經人工驗證 GitHub issue，以及 Terminal-Bench 2.1 的 89 個命令列端到端任務。指標為任務成功率與每題平均成本。模型以 SGLang、BF16 執行，temperature 為 0、top-p 為 0.95；每次最多產生 16,384 個輸出 token，單一任務最多 300 步。作者以 2026 年 8 月查得的 OpenRouter 每百萬 token 價格估算模型呼叫成本（§3.1）。

Context sweep 對每個模型與 benchmark 測 32k、64k、96k、128k 四種視窗，每個視窗比較 T0–T4。此階段固定啟用規劃和完整預設工具組。接著只在 T4/128k 下各做一項規劃和操作介面消融：移除規劃，或把完整工具組換成 Bash-only。這樣每個模型–benchmark 組合有 22 個配置，四模型乘兩個 benchmark 共 176 個設定（§3.1）。

元件問題	配對設定	能回答什麼	不能單獨回答什麼
上下文管理	T1–T4 對 T0；四種窗口大小	在固定規劃與完整工具下，不同管理策略的條件式效果	規劃或工具與不同 context tier 的交互效果
規劃	T4/128k，有規劃 vs 無規劃	此設定下持續計畫支架的差異	其他窗口、context tier 或其他規劃實作
操作介面	T4/128k，完整工具 vs Bash-only	兩套完整介面設定的差異	工具數量、粒度、提示、狀態管理、診斷各自的獨立效果

成功率比較使用任務配對的雙側 exact McNemar test，並在各比較族內以 Benjamini–Hochberg 控制 false discovery rate 至 0.05。這種配對方法利用同一任務在兩設定下是否成功的差異；它不能補足一次執行的隨機變異，也不代表每個數字差距都達顯著。Terminal-Bench 只有 89 題，論文特別提醒多數對比未達統計顯著。

證據一：上下文管理主要避免小窗口下提前終止

作者將管理策略的「價值」定義為 T1–T4 相對 T0 的成功率差，並對四模型平均。SWE-Bench 的平均差距從 32k 的 35.7 個百分點，隨窗口增至 64k、96k、128k 而降為 15.9、5.5、2.7 點；Terminal-Bench 相同窗口分別為 9.5、7.5、4.8、2.8 點（Table 3–4、Figure 3、§3.2）。

這些差距與溢位率變化一致。在 SWE-Bench，T0 平均溢位率從 32k 的 78.7% 降到 128k 的 8.7%；Terminal-Bench 從 61.0% 降到 12.1%。所有管理 tier 在這些設定中都沒有溢位結束的任務（Figure 3）。軌跡分析也發現，小窗口下 T0 多數中止在檔案定位階段，管理策略讓軌跡延長到能進入修改和驗證；128k 時不同 tier 的軌跡差異大致縮小（§4）。

因此最穩妥的解讀是：上下文管理在視窗不足以容納長軌跡時，幫助任務繼續執行；窗口夠大時，額外準確率收益較小且更依模型而異。這不是證據說壓縮普遍改善模型推理，也不表示摘要資訊不會傷害任務。

證據二：T4 的平均成本低，但沒有一個跨條件的勝者

T4 在八個模型–benchmark 面板中的七個，與 T1–T3 成功率相近時成本最低；跨四個窗口的等權比較中，T4 在每種窗口預算下都有最低平均每題成本（Figure 4–5、§3.2）。作者指出，T4 先省略大型工具觀察，因而比純摘要 T3 少做摘要呼叫；相較 T1、T2，在 32k 和 64k 也少做部分省略操作。它在不同窗口的平均峰值上下文比例也最低。

然而各模型、benchmark、window 的最優成功率配置並不一致。以 SWE-Bench 的 Nemotron-3 550B 為例，128k 下 T0 得 59.8%，T2 得 67.4%，T4 得 65.8%；Mistral 在相同 benchmark 下 T0 和 T1/T4 都是 67.4%/68.6%，而不一定要靠 T4 取得最高值（Table 3）。Terminal-Bench 128k 下 Nemotron-3 550B 的 T4 成功率是 44.94%，比 T0 的 34.83% 高；但 Mistral 在同一資料集 T4 是 37.08%，T0 為 34.83%，不同管理 tier 又出現其他成功率與成本折衷（Table 4）。

因此 T4 是這些設定裡的成本–成功率候選方案，而不是不看場景就能複製的配方。Figure 4 的區間還顯示不同視窗預算造成的敏感度；使用平均值時要保留不同窗口和模型的分布，不應把平均成本最低改寫為每個細胞格都最低。

證據三：可回讀的省略內容，模型很少取回

T1 和 T2 只差在 T2 將省略的工具觀察存到外部，讓模型呼叫 recall_event 取回。32 組配對設定中，T2 有 15 組成功率高於 T1、14 組低於 T1、3 組相同；平均差為 −0.36 個百分點（SWE-Bench +0.40、Terminal-Bench −1.12）。在 64 個使用 T2 或 T4 的設定中，36 個（56.3%）完全沒有回讀，回讀次數中位數為 0；所有模型合併的平均每題回讀次數，從 32k 的 0.540 降至 64k 的 0.069、96k 的 0.011、128k 的 0.007（Table 13、§3.2）。

回讀主要集中在最緊的窗口和較弱的 Nemotron-3 30B。即使最常回讀的組態——30B 在 Terminal-Bench、32k、T2——平均每題呼叫 4.326 次，成功率仍比 T1 低 3.37 點。這說明「資訊可回復」不會自動轉換成「模型會適時取用」或「任務更常成功」。但觀察到少用，也不足以證明回讀在不同的提示、任務或工具流程裡無用。

證據四：規劃可能扶住短軌跡，也可能縮短過長軌跡

規劃元件提供系統指令，要求非瑣碎任務先建立計畫，再以 update_plan 維護當前進度。每回合的計畫會由 Harness 重新注入模型輸入，而非任由對話歷史累積。無規劃條件則移除計畫指令、提醒、工具和注入；研究比較的是這個明確的持續規劃支架，不是抽象概念上的全部 planning（§2.1、Appendix 7.2）。

在 T4/128k 下，Nemotron-3 30B 加上規劃後，SWE-Bench 成功率上升 11.6 點，Terminal-Bench 上升 4.5 點，成本也上升。軌跡分析為此提供一種解釋：SWE-Bench 中，沒有計畫時 68.6% 的 run 結束前沒有編輯，58.4% 停在定位階段；開啟規劃後這兩個比例分別是 27.8% 和 10.4%。中位軌跡長度從 5 回合增到 40 回合（Table 6、Figure 8、§4）。這支持規劃能讓這個較弱模型走到首次修改嘗試，但更長的執行也要付出成本。

對較強的 Nemotron-3 550B 與 Mistral，SWE-Bench 的規劃讓成本分別下降約 30% 與 32%，成功率只小幅降低 2.0 和 0.4 點（Tables 3、5）。兩個模型的中位軌跡縮短，分析將主要差異連到編輯後驗證階段的減少；它提示規劃也可能幫助模型停下過度驗證，而不只幫忙拆解任務（§4）。Terminal-Bench 的成本方向取決於它如何改變整個軌跡長度分布：它可能延長原本過早終止的工作，也可能砍掉跑太久的尾端。不同模型兩種效應的比例不一（Figure 9、§4）。

研究沒有建立「模型越強，規劃越省錢」的通則。Nemotron-3 120B 在兩基準的反應不同；分析只顯示規劃效益隨模型和任務而變。

證據五：工具選擇改變動作粒度，也連帶改變失敗風險

完整工具組包含 read_file、write_file、edit_file、檔案列舉與搜尋工具、web_fetch 和 Bash；Bash-only 則移除預設檔案、搜尋與網頁工具，保留 Bash，以及啟用規劃或回讀時所需的輔助工具（Table 1、§2.2）。完整介面還包含讀取後才可修改的檢查、檔案狀態追蹤，以及支援工具編輯後的自動診斷。論文清楚提醒：這個對照比較的是整套 action interface，包括工具、介面提示、狀態追蹤與驗證支援，並非只比較「很多工具」和「一個工具」。

在 SWE-Bench、T4/128k 下，Bash-only 對 Nemotron-3 550B 的成功率由完整工具組的 65.8% 升到 69.4%，平均成本由每題 2.33 美元降至 1.11 美元；同一介面轉換卻讓 Mistral 從 68.6% 降到 45.4%。Mistral 的 Terminal-Bench 結果則從 37.1% 到 43.8%，變化方向又不同（Tables 3–4）。這種反轉不能靠模型大小單獨預測。

行為分析發現，Bash-only 讓工具熟練的模型把多個低階操作合併到較少的命令裡。在 Terminal-Bench，Nemotron-3 550B 的中位軌跡由完整工具組的 47 個動作降至 31 個，而 Write Code 動作占比由 16% 增至 27%；各模型在 Bash-only 下都較少重複修改同一檔案（Figure 9、Table 7、§4）。但對較弱模型，完整工具介面可能透過具體、受限制的操作降低單步難度；Mistral 的 Bash-only SWE-Bench 軌跡更常在修改檔案前結束，未編輯的比例從完整工具組 1.2% 升至 32.8%（Table 12、Appendix 9.3.1）。

所以工具介面同時影響成功率、成本、行動粒度與失敗位置。若把它簡化成工具數量，會忽略提示、狀態追蹤與修改後診斷同時改變的混雜因素。

軌跡分析提供什麼證據？

作者將完整軌跡的每個回合交給 LLM judge，依任務型態編碼工作階段，並以人工標註做驗證。SWE-Bench 的標籤包含定位、重現、修正、驗證與其他；Terminal-Bench 的標籤區分理解、寫程式、驗證和其他，並細分動作類型（Appendix 9.1）。人工驗證包含 200 條軌跡、15,610 個標註單位；整體原始一致率約 94.2%，加權平均 Cohen’s $\kappa=0.929$。Terminal-Bench 動作標籤的各分組一致率較廣，最低原始一致率為 79.8%，$\kappa$ 最低 0.758（Appendix 9.2）。

這項驗證支持 LLM judge 能擴大量化論文的行為分析，但不等同於每一條全量標註都由人逐一確認。Judge 依附於指定 taxonomy，使用 GPT-5.5、high reasoning、temperature 0.6；新的任務類型或不同標籤定義仍需另外驗證。文章因此將軌跡結果視為理解行為的證據，而不是任務成功的獨立因果證明。

元件	觀察到的軌跡改變	作者解釋能到哪裡
Context management	小視窗下延長執行，階段比例大致相似	支持它主要避免提早溢位，不表示不改變所有策略
Planning	弱模型較常活到首次編輯；強模型較少長時間重複驗證	解釋成本與成功率怎麼同時變化，仍是有限設定的觀察
Action space	Bash-only 的動作較粗，可合併多個操作；部分模型在定位前停止的比例增加	顯示整套介面更改會重塑操作與失敗模式，不識別單個工具因素

證據地圖：作者主張、實驗結果與 Bloss0m 判斷

論述層次	本文可以安全地說什麼	主要錨點
作者主張	上下文管理在窗口緊時更有價值；T4 的平均成本–成功率折衷較好；規劃和工具介面依模型而變	Abstract、§3.2、§6
實驗結果	在這些模型和 benchmark 中，管理策略降低了觀察到的溢位中止；規劃與 Bash-only 在各模型上沒有同一方向的效果	Figure 3、Tables 3–7、12–13
證據不支持	每題只執行一次、部分消融受限於 T4/128k、介面改動打包多項差異，所以無法據此宣告通用最佳 Harness 或分離每項介面的因果效果	§3.1、§6
Bloss0m 工程判斷	先從實際失敗型態挑出待測元件，再以配對重跑量測成功、成本與失敗位置	本文工程判斷段落；這是本地評估建議，不是作者驗證的流程

Artifact 與可重現性

截至 2026 年 10 月 7 日，arXiv 頁面公開 v1 PDF、HTML 和 TeX source bundle。TeX bundle 包含論文表格、圖檔及實驗 prompt，因而可用來檢查配置描述與論文數字。arXiv 頁面只記錄投稿者授予 arXiv 的非專屬散布授權，沒有授予本文重用原論文圖表的權利；本閱讀因此不重刊 Figure 1–9。沒有找到論文專用的可執行 Harness 儲存庫或原始 benchmark 軌跡資料集。TeX 和 prompt 讓方法更容易查讀，不等於取得執行程式、任務容器或完整重跑所需的所有資料。

本文沒有重跑實驗；文中的分數、成本與軌跡分析均為作者報告。要重現結果，研究者仍需取得適用的 benchmark 任務容器與 verifier、重建 Harness 執行迴圈，並取得可服務的相同模型與價格設定。論文逐項交代了 prompt、工具描述、閾值和部分執行限制，這有助於實作近似版本；但若沒有原始實作，實作漂移、模型服務差異和成本計算差異會讓「重現」與「相似設計的再測」成為兩件事。

限制：配對比較仍不是完整設計空間

作者在 §6 列出三組主要限制。第一，規劃只用一種 prompt 加更新機制，上下文管理只用一種固定門檻政策；操作介面對照同時改變工具、介面提示、檔案狀態追蹤和修改後診斷。第二，規劃與操作介面只在 T4/128k 下測，若要知道它們在其他管理策略與視窗是否同樣有效，必須做完整交互比較。各設定每題只執行一次；Terminal-Bench 只有 89 題，因此不少差異沒有足夠統計能力達顯著。第三，結論只來自三個 Nemotron-3 尺寸、一個 Mistral 模型與兩個長程式任務基準；SWE-Bench Verified 為 Python 任務，模型規模也不是能力的完美代理。

還要區分實驗結果和行為解釋。作者以配對統計檢驗同一任務是否由成功變失敗或反之，且以多重比較校正；但沒有重跑估算每個設定的 run-to-run 方差。T4 的低成本觀察也沿用論文使用的 token 定價，不包含推理服務、硬體、開發維運或人工作業成本。這些是評估範圍的邊界，不是對結果的否定。

Bloss0m 工程判斷：用失敗型態選擇要測的元件

以下是 Bloss0m 工程化整理，不是作者測試過的部署流程。若你正在調整程式碼 Agent，可以把論文讀成一組形成在地假說的線索：

目標環境先看到的問題	可先測的候選介入	評估時要一起觀察
長任務常因上下文超限中止	T1、T3、T4 等管理政策	溢位率、成功率、上下文峰值、摘要呼叫成本
模型常停在定位階段、尚未修改檔案	持續計畫與明確進度提醒	未編輯比例、定位完成比例、總步數與成本
模型常做多次小型修改或具備熟練 shell 操作	Bash-only 或不同粒度的工具介面	成功率、修改前失敗、每回合錯誤、重複 patch、可審核性
介入後平均分數差距很小	對代表性任務重跑	每任務方差、不同任務切片、成本與失敗原因

先確認原始失敗原因，再改一個可量測的配置維度。對上下文政策，記錄溢位與省略／摘要／回讀呼叫；對規劃，記錄模型是否因規劃繼續走到修改，或是否減少多餘驗證；對工具介面，保留哪個錯誤可回到模型、何時檔案被修改、每個結果如何被驗證。若一次改變所有條件，便很難知道成功率的改變來自上下文閾值、prompt，還是介面支援。

接著在實際工作負載上做配對、重複實驗。以每題成本和成功率作為最低限度，同時保留延遲、溢位、工具錯誤、人工升級與 verifier 結果。若是生產環境，安全政策與回復能力也要納入接受條件；本文將安全層固定，並沒有比較不同權限配置。因此它不能證明較粗的 Bash 動作在你的工作區同樣安全，也不能用 benchmark 成功率取代權限與副作用治理。

什麼情況不應直接套用

• 你的任務不是長程式碼或終端工作，或需要瀏覽器、資料庫、雲端部署等完全不同的工具介面。
• 你使用的模型與文中模型在訓練、工具熟悉度、可用視窗或推理能力上差異很大。
• 你需要將規劃、工具數量、修改前檢查、修改後診斷等單項分開歸因；本研究沒有對 action-space 介面做這種拆解。
• 你要據此宣稱高可靠度或生產安全。每題單次執行與有限基準未提供此類證據。

對相關問題可接續閱讀 AgentPProf：用軌跡訊號分析 Agent 行為 和 MAGS：把自然語言需求轉成可檢查規格。兩篇研究的任務與證據不同，適合延伸思考觀測與驗收，不補上本文未測的模型、任務或 Harness 交互效果。

讀完後的三個記憶點

1. 上下文管理首先是延長可執行軌跡：小窗口下它大幅減少溢位中止；窗口變大，平均成功率增益快速縮小。
2. 同一元件會在不同模型上換角色：規劃能讓較弱模型走到修改，也可能使較強模型少做重複驗證；Shell 是否有利取決於模型熟練度和任務型態。
3. 成績屬於已測配置：每題一次執行、有限模型與 benchmark、未完整測交互作用，支持設計本地對照實驗，不支持通用 Harness 排名。

Primary sources

• Fan, Run-Ze, et al. An Empirical Study of Harness Design for Coding Agents, arXiv:2609.20804v1, 17 September 2026. 主要證據位置：Figures 3–9、Tables 3–7、12–13、§§2–4、§6、Appendix 7–9.
• arXiv v1 HTML and PDF.
• arXiv v1 TeX source bundle, including paper source, figure and table sources, and prompt text.