【2026 最新】Agent Harness A/B Test：Plan、Bash、Context 三旋鈕教學

同一個模型、同一份程式碼，為什麼換一套 Agent Harness，表現就像換了一顆腦？問題往往不只在模型，而在它有沒有被要求先規劃、能用哪些工具，以及對話變長時哪些資訊會留下。要把這三件事拆開，最實用的方法就是做一輪 Agent Harness A/B Test。

這篇專為第一次做 Agent 評測的讀者寫。我們不把論文排行榜抄成結論，而是把它改造成一套可以放進自己 repo 的受控實驗：固定任務、模型、預算與驗收，只轉動 Plan、Action Space、Context 三個旋鈕；最後用成功率、context overflow、工具呼叫、token、成本與 wall time 決定配置。

先說結論：Agent Harness A/B Test 的核心只有一件事

受控 Harness Eval ＝ 固定其餘條件 ＋ 讓每個配對 contrast 只差一個因子 ＋ 對同一題重跑。若要估計交互作用，則要保留全部 8 個因子組合。

• Plan：比較「外顯、持續更新的計畫」開或關，不把模型內部思考當成可控制變因。
• Action Space：比較 shell 導向介面與預定義工具介面，並記下兩邊是否連帶改了診斷、權限或狀態追蹤。
• Context：把「緊／寬」寫成明確 token 預算與壓縮門檻；先刪可判定的舊輸出，再評估是否需要 LLM 摘要。
• 判讀：先看任務是否完成，再比較每次成功的成本、時間與失敗型態；不要只挑三次裡最好看的一次。

為什麼換 Harness 像換腦？先把三個旋鈕拆開

如果模型是汽車引擎，Harness 就是變速箱、方向盤、儀表板與道路規則。引擎不變，換了一組不合適的齒比或控制介面，車仍可能提早熄火、繞遠路，甚至根本無法把力量送到輪胎。若你還不熟悉這一層，可先讀 AI Agent Harness 是什麼，再回來做元件級評測。

旋鈕一：Plan 是「貼在儀表板上的施工清單」

本文的 Plan 不是泛指模型會不會思考，而是一份外顯、跨回合保留、可更新的任務清單。開啟時，Harness 要求 Agent 建立計畫並在每回合重新注入；關閉時，移除計畫指令、提醒、注入與更新工具。產品內建的 Plan Mode 可能同時改變權限、工具或模型，若無法拆開，就要標成「產品模式整包 A/B」，不能假裝只改了計畫。

旋鈕二：Action Space 是「手排還是按鈕面板」

shell 導向介面讓模型自行組合 rg、sed、測試與檔案操作；預定義工具則把 Read、Search、Edit 等動作做成有 schema 的按鈕。前者可以一口氣組合多步，後者能縮小單次動作並回傳結構化錯誤。兩邊的 tool_calls 數量不能直接比：一個 shell call 可能藏了五個 primitive operations，所以工作表要同時記錄「模型看見的呼叫」與「底層實際操作」。

旋鈕三：Context 是「行李箱容量與整理規則」

Context 不只是模型標示的最大視窗，而是每回合實際送回去的系統指令、任務、計畫、歷史動作與工具輸出。寬視窗像大行李箱；緊視窗像登機箱。真正要測的是：當容量開始吃緊，Harness 應該先刪掉可重建的長輸出、保留索引，還是花一次模型呼叫做摘要？

176 組論文實驗，真正做了什麼？

2026 年 9 月 17 日發布的預印本 An Empirical Study of Harness Design for Coding Agents，把執行迴圈固定在 ReAct 式的「思考 → 行動 → 觀察」，再拆三個元件。研究使用 Nemotron-3 30B、120B、550B 與 Mistral-Medium-3.5-128B，在 SWE-bench Verified 與 Terminal-Bench 2.1 上評估。

176 指的是設定，不是 176 次 task run：五種 context policy × 四個視窗預算先得到 20 格，再加上「關閉 Plan」與「改成 bash-only」兩格，共 22 格；22 × 四個模型 × 兩個 benchmark ＝ 176。Plan 與 Action Space 只在 T4、128k 的基線上各做一次消融，因此這不是完整的 Plan × Bash × Context 全因子研究，三者的交互作用仍要另外測。

• Context 的價值跟預算綁在一起：在 SWE-bench 上，四種管理策略相對無管理 T0 的平均成功率差距，從 32k 的 35.7 個百分點縮到 128k 的 2.7 個百分點。主要機制是避免視窗溢位讓任務提前結束，不是把模型本身變聰明。
• 先 elision、後 summary 的 T4 較省：它在八個「模型 × benchmark」面板中有七個成本最低，成功率大致接近其他管理策略；這代表的是該設定下的效率，不是每格準確率冠軍。
• Plan 的角色會反轉：對 30B，Plan 在 SWE-bench 增加 11.6 個百分點；對 550B 與 Mistral，SWE-bench 成功率分別小幅下降 2.0 與 0.4 點，但估算成本約少 30% 與 32%。
• 工具介面取決於模型與任務：550B 的 bash-only 在兩個 benchmark 都提高觀察到的成功率並降低成本；Mistral 則在 SWE-bench 明顯偏向預定義工具、在 shell-centric 的 Terminal-Bench 偏向 bash-only。

論文的美元成本是把本地 SGLang／BF16 服務產生的 token，套用 2026 年 8 月 OpenRouter 單價換算的估算值，不是實際帳單、GPU 成本或 wall time。這些數字也只屬於特定模型、prompt、工具實作與任務；尤其「預定義工具 vs bash-only」同時改了工具集合、介面說明、檔案狀態追蹤、read-before-write 與自動診斷，是 bundled interface comparison，不能只歸因於工具數量。

Agent Harness A/B Test 先選規模：每題 12 次或 24 次

先決定你要回答「哪個旋鈕值得繼續研究」，還是「三個旋鈕會不會互相影響」。Anthropic 的 Agent eval 指南把 task、trial、trajectory、outcome 與 grader 分開，也建議用多次 trial 看見 Agent 的變異。本文用每格三次作為除錯用 pilot，不把三次包裝成統計保證。

• 入門版，4 個設定：一個基線，再分別只翻 Plan、Tools、Context；每格 3 次，所以每題 4 × 3 = 12 runs。它便宜、容易查錯，但看不到元件交互作用。
• 完整版，8 個設定：Plan(2) × Tools(2) × Context(2) 的全因子，每格 3 次，所以每題 8 × 3 = 24 runs。依 NIST 的 2^k 全因子設計與交互作用模型，保留全部組合才能估計某個旋鈕的效果是否依賴另一個旋鈕。

總跑次 ＝ 任務數 × 設定數 × 每格重跑次數。五題的入門版是 60 runs；五題的完整版是 120 runs。先用一題跑通收據與 grader，再擴大。

第 0 步：先凍結七個固定項

如果 A 用新模型、B 多一分鐘、C 還能連網，你量到的是一鍋混合變因。OpenAI 的第三方評測方法也強調要公開並鎖定 task、scoring、budget、tools 與 harness configuration。開始前至少固定：

1. Repo 與任務：同一個 base commit、dependency lock、task prompt 與 hidden grader。
2. 模型：精確 model ID、provider／checkpoint、reasoning 設定、temperature 與 top-p。
3. 共同 Prompt：系統規則、repo 指令與 stop wording；Plan arm 只增加計畫協議。
4. 執行預算：最大 turn、token、wall time、單一工具 timeout 與 retry 規則。
5. 安全邊界：相同 sandbox、權限、network policy、secret policy 與可寫目錄。
6. 固定 Harness 元件：permission、diagnostics、stuck detection、驗證回饋與 output cap。
7. 成功定義：fail-to-pass 測試通過、既有 regression 仍通過，且沒有越權或人工補答案。

experiment_id: harness-2026-09-19-a
task_id: bugfix-001
base_commit: <sha>
container_digest: <sha256>
model_id: <exact-id>
harness_commit: <sha>
temperature: 0
reasoning: <pinned-setting>
max_steps: 80
wall_time_limit_s: 1800
network: off
grader_ref: evaluator://task-001
retry_policy: infra-only-once

grader_ref 指向 evaluator 端的不可變資產：測試在 Agent 結束後才注入並執行，不能放在 Agent 可讀寫的 repo 裡；同時先用 reference solution 驗證題目本身可解。每次 run 都從新的 container、工作目錄與 session 開始；condition 的順序用固定 seed 隨機打散，避免第一組永遠吃到冷 cache、最後一組永遠遇到 rate limit。若你還沒有自己的任務集，可先接著看 Coding Agent Eval：每題跑 3 次，把已合併 PR 做成可驗收題目。

步驟一：只轉 Plan，觀察 Agent 在哪裡停下來

痛點：Plan 到底提升正確率，還是只是多吃 token？解法：讓兩個 arm 共用工具、context、prompt、budget 與 grader；Plan ON 只多一份不可由人類修改的結構化計畫，Plan OFF 則不強制外顯計畫。操作上把配置寫成 plan_policy: persistent 與 plan_policy: none，並把建立、更新計畫的 token 與時間算進總成本。

除了 pass/fail，還要看 exit_reason、首次 edit 前的 turns、無 edit 結束比例、edit 後 verification turns。若 OFF 常在定位階段放棄，Plan 可能是續航支架；若 ON 的成功率相近但少了重複驗證，它比較像成本控制。想比較產品內的 Plan、規則檔與 Hook 邊界，可搭配 Claude Code 四層 Read-Only 教學，但不要把那個產品模式直接當成本文的單一變因。

步驟二：只轉 Action Space，別把安全機制偷偷一起換掉

痛點：bash 呼叫少，可能只是每次塞了更多操作；typed tools 成功率高，也可能是因為附送 lint、read-before-write 與更好的錯誤訊息。解法：先列出兩個 arm 的完整差異，再決定你測的是「介面形式」還是「整套工具產品」。若目標是隔離 granularity，兩邊要共用 permission、diagnostics、output cap 與 verifier；做不到就老實標成 treatment: interface_bundle。

• Shell arm：記錄每個 command 內含多少 read、search、edit、test primitive；如果還保留 Read／Glob／Grep，就命名為「Bash + browse」，不要寫 bash-only。
• Typed arm：保存 tool schema 版本、描述文字、錯誤型態、輸出截斷與自動診斷。
• 兩邊共同：記錄 invalid call、tool error、重複呼叫、首次 edit、總 primitive operations 與成功後的總成本。

這一步與 MCP vs CLI Token A/B Test相鄰，但問題不同：那篇比較工具傳輸與 token tax；本文要求你把 Action Space 當作 Harness 元件，和 Plan、Context 放進同一套配對實驗。

步驟三：只轉 Context，先做規則刪減再叫模型摘要

痛點：「緊」與「寬」若只有形容詞，下一次就無法重跑。解法：把可用 token、soft trigger、hard trigger、recent-window 預算、tool output cap 與 summary prompt 全部寫進配置。最小 A/B 可以是同一套 policy 下的兩個明確預算；第二輪再拆 policy。下面只是把論文兩端改寫成可執行範例，不是所有 repo 的通用門檻。

tight:
  usable_context: 32000
  recent_window_fraction: 0.30
  min_recent_turns: 2
  elide_at: 0.60
  summarize_at: 0.85

wide:
  usable_context: 128000
  recent_window_fraction: 0.30
  min_recent_turns: 2
  elide_at: 0.60
  summarize_at: 0.85

規則式 elision 適合先處理可重建的大段 test log、重複搜尋結果與舊工具輸出：留下事件 ID、來源、時間與一句 stub，完整 trace 仍存到模型看不到的外部 artifact。只有在刪完後仍超過 hard threshold，才用 LLM 摘要較舊的中段歷史。摘要是有成本、會失真的新生成內容；要另外記 summary_calls、summary_tokens 與摘要前後 token。

要驗證可恢復機制是否值得，不能只確認 recall_event 存在；還要量它被呼叫幾次、叫回什麼、是否改變 pass/fail。論文裡 recall-enabled T2 與 T4 的 64 組設定中，有 36 組從未呼叫 recall，且 T2 對 T1 的平均成功率差異接近零；這是「先量需求再加機器」的證據，不是所有任務都應刪掉 recovery。若你的重點是 compact 後重新找資料的代價，可延伸閱讀 Context Compaction 的 Reacquisition Cost。

可重跑工作表：每一格至少記 20 個欄位

把下面第一行貼進試算表或存成 UTF-8 CSV。每個 task × repeat × condition 佔一列；失敗列不能刪，infra invalid 也要保留原因與重跑 ID。

experiment_id,task_id,task_family,repeat,run_order,run_id,
base_commit,container_digest,harness_commit,model_id,condition,
plan_policy,tool_policy,context_budget,compaction_policy,
success,context_overflow,model_tool_calls,primitive_ops,tool_errors,
input_tokens,output_tokens,summary_tokens,billed_cost,wall_time_s,
first_edit_turn,verification_turns,exit_reason,failure_class,trace_uri

成功條件要由 Agent 外部的 grader 決定。三次 pilot 先逐筆報原始值，再報 median 與 range；累積較大的 task × trial 樣本後才報 p90，並固定 quantile method。成本可算 observed_pooled_cost_per_success = total_valid_cost / successful_runs，其中有效但失敗的嘗試也要計費，infra waste 則另列；若某 arm 零成功，就標成「目前題組無可估的成功成本」，不要用早停造成的低帳單替它加分。

for task in frozen_tasks:
  for repeat in [1, 2, 3]:
    for condition in seeded_shuffle(conditions, task, repeat):
      env = fresh_container(task.base_commit)
      run = fresh_session(pinned_model, pinned_harness, condition)
      result = run.execute(task.prompt, fixed_budget)
      grade = evaluator_side_grader(env, immutable_test_ref)
      append_receipt(task, repeat, condition, result, grade)

這段是語言中立的流程骨架，刻意省略 provider-specific API、例外類型與平行排程；正式 runner 仍要實作 timeout、infra retry、secret isolation、artifact upload 與寫入原子性。想先看最小 Agent loop 怎麼接工具與錯誤，可讀 動手搭一個最小 AI Agent Harness。

怎麼判讀？不要宣布單一最佳配置

1. 先做品質閘門：權限、回歸測試或 hidden grader 不合格，無論多便宜都先淘汰。
2. 再做 task-paired 比較：同一題的 A 對 B；不要把三個 repeat 當成三個獨立新題，灌大樣本數。
3. 按 failure class 分層：定位失敗、無 edit、tool schema error、context overflow、驗證打轉，對應不同旋鈕。
4. 看交互作用：若 Plan 只在 tight context 有效，主效應平均值會把它沖淡；這正是 8 格版存在的原因。
5. 建立決策規則：例如「shell-centric 題走 bash 候選；repo 搜尋題保留 structured tools」，而不是全站只留一個設定。

六個常見坑：數字漂亮也可能量錯

1. 把 176 說成全因子：論文沒有跨 context 預算測 Plan × Tools 交互作用。
2. Plan arm 偷換模型或權限：這時測到的是產品模式整包效果，不是外顯計畫本身。
3. 拿 tool calls 當工作量：shell 可在一次 call 裡串很多 primitive；必須雙重計數。
4. 只報 best-of-three：那代表允許三次嘗試的政策，不是單次成功率；三列原始結果都要留。
5. 省 token 卻忘了 overflow 與重取：compact 後重新搜尋、摘要錯誤與提早停止都要進成本。
6. 只重跑輸的 arm：infra retry 規則要事先登記，並對所有 condition 一致套用。

研究邊界：這篇能告訴你什麼，不能替你決定什麼

截至 2026 年 9 月 19 日，這份研究是 arXiv v1 預印本。每個 task-setting 只執行一次；Terminal-Bench 2.1 只有 89 題，多個對照沒有各自達到顯著。四個模型中三個來自 Nemotron-3 家族，SWE-bench Verified 又是 Python 題組，因此模型大小、shell 熟練度與其他 repo 的結果不能直接互換。

在這份研究的模型與題組中，Harness 的成功率與估算成本會隨模型、任務型態與 Context 預算而變；真正的交叉點仍需在自己的環境重驗。本文也沒有在 AlphaLab 環境執行那些 176 組設定；上面的數據都歸屬於論文，工作表則是讓你在自己的任務上驗證，而不是替你預告答案。

FAQ：Agent Harness A/B Test 常見問題

1. 同一個模型，Harness 真的能讓結果差很多嗎？

可以，但差異是有條件的。論文觀察到 context 壓力、模型的介面熟練度與任務型態都會改變效果；不能把某一格的差距升級成所有 Agent 的定律。

2. Temperature 設成 0，還需要重跑三次嗎？

需要。Agent 還會受到 provider 執行、平行工具、外部環境與錯誤恢復路徑影響。同 prompt 的單次結果不代表穩定性；三次只是一輪 pilot，重要決策要增加題數並計算區間。

3. Plan OFF 代表模型不能思考嗎？

不代表。它只代表 Harness 不強制建立、保存與回填外顯計畫；模型仍可能在回應內自行安排步驟。

4. Bash-only 一定比較便宜嗎？

不一定。它可能用較少 call 完成更多操作，也可能因 schema 不相容、定位失敗或重試而更貴。先確認 arm 內真正保留哪些工具，再看每次成功成本。

5. Context tight／wide 應該設多少？

從你的 baseline 分布決定。先量 peak context 與 overflow；tight 應能刻意製造壓力但仍讓部分任務完成，wide 則要讓大多數 baseline trajectory 裝得下。兩個數值都寫進配置。

6. Rule-based elision 和 LLM summary 先做哪個？

先測可判定、可稽核的 elision。它適合移除可重建的長輸出；仍超過 hard threshold 時才摘要較舊歷史，並把摘要成本與錯誤另記。

7. 三次成功兩次，可以直接上 production 嗎？

不能直接下結論。這只代表該小題組的 pilot 訊號。先看失敗是否涉及安全、資料破壞或回歸，再擴大真實任務家族與重複次數。

8. 最後應該用哪個指標選 Harness？

先用正確性與安全當硬門檻，再看 cost per success、wall time 與 failure class。Token、call 數或平均成本都不能單獨代表好壞。

給新手的七個重點

1. 模型不變，不代表系統相同；Harness 會改變可見資訊與可執行動作。
2. 先固定 task、model、budget、stop、grader 與安全邊界，再談 A/B。
3. 每次只改一個元件最容易除錯；要看交互作用才升級到 8 格全因子。
4. Plan、bash-only、tight context 都要用可執行配置定義，不用形容詞。
5. 三次是 pilot，不是普遍結論；三次原始結果都保留。
6. 規則式 elision 先於模型摘要，recovery 要用實際呼叫與成效驗證。
7. 答案不是單一最佳 Harness，而是按模型、任務與預算選配置。