【2026 最新】FrontierHarness Eval 教學：Claude Code、Codex、Pi 成本真差 17.5 倍？

FrontierHarness Eval 把同一個 Kimi K3 模型放進不同 coding harness，確實測出最高約 17.5 倍的「有效完成成本」差距；但這個數字不是 Claude Code、Codex、Pi 三者互比，也不是官方表頭所寫的中位數。三者在這份 30 題資料裡的最大差距約 7.5 倍，而 17.5 倍來自 Claude Code 與 Exo Harness。真正值得帶回自己 repo 的，不是冠軍名單，而是這個分母：有效完成成本＝所有已知成功與失敗嘗試成本總和 ÷ 驗收通過數。

這篇 FrontierHarness Eval 教學會先校正公開榜單，再帶你做一套 5 個任務 × 3 個 harness × 3 次執行的 45-run 小型評測。你會學會寫 deterministic verifier、還原乾淨 checkpoint、保留失敗成本、區分冷暖 cache，最後用「品質 × 成本」矩陣選出適合自己工作的 Claude Code、Codex 或 Pi。

先給結論：17.5 倍是真的，但不能這樣外推

• 全榜極差：Claude Code 的有效完成成本約 18.34 美元，Exo Harness 約 1.05 美元，相除約 17.5 倍。
• 本文三者：Claude Code 約 18.34 美元、Codex 約 3.47 美元、Pi 約 2.43 美元；最高與最低約差 7.5 倍。
• 品質差距很小：三者分別通過 19、20、18 題；每個 task × harness cell 只有一次正式計分，不能宣稱排名穩定。
• 不是純 harness 效應：結果屬於 harness × Kimi K3 × gateway／協議 × 題組 × 停止規則的整體組合。
• 公開資料可重算、不可完整重跑：repo 有題目定義與彙整結果，卻沒有完整 runner、raw trajectory、私有 verifier evidence、gateway 設定與 solution。

Harness 是什麼？為何同模型仍會差很多？

模型像引擎，harness 則是把引擎接到 repo 的整套控制系統：它決定怎麼建立 system prompt、把檔案與工具結果塞進 context、呼叫 shell、重試、壓縮歷史、使用 cache，以及何時停止。想先補完整概念，可讀 AI Agent Harness 是什麼。

FrontierHarness Eval 公開 repo在 v1.0 固定 Kimi K3、30 個軟體工程與終端任務，以及每一題跨 harness 的 Runta golden checkpoint；每次正式執行都從新鮮 restore 開始。它比較 9 個 harness、12 組設定，共 360 個 cell，採第一個有效 attempt，不做外層 retry 或 best-of-N。這比拿不同模型、不同題目、不同機器的帳單硬比，控制得好得多。

不過「模型權重相同」仍不等於只有 harness 在變。官方 launch 說 gateway 依工具原生支援，分別使用 OpenAI Responses 或 Anthropic Messages 協議；Claude Code 原本也不是為 Kimi K3 的 implicit cache 設計。因而最精確的說法是：在這個模型、gateway、協議與工作負載下，更換整套 agent 配置後，結果不同。

先審計 FrontierHarness Eval：表頭和公式對不上

官方 README 把 18.34、3.47、2.43 這列稱為「Median cost per pass」，互動圖則寫「Median cost per task」。但在固定 commit 的公開 JSON裡，對應欄位其實叫 effective_cost_per_pass。以 Codex 為例，30 次已知成本合計約 69.37 美元，除以 20 個 pass，正好是 3.4683；它不是任何一組逐題成本的中位數。

正確讀法：有效完成成本＝全部已知嘗試成本 ÷ 通過數。失敗不能從分子消失。

這個分母比「只看成功題的典型成本」更接近採購問題，因為失敗也會燒 token 和時間；但它會同時放大通過率、長題與停止規則的影響。以全榜 17.5 倍兩端來看，Claude Code 在 9 題 DeepSWE 通過 3 題，Exo 則 0 題並在固定 turn 上限停止；便宜可能部分代表早停且沒完成，昂貴也可能代表長時間繼續嘗試。這不是單純的包裝 overhead。

還有一個資料完整性問題：公開結果有少數 task cell 的 cost_first_cold_usd 是空值，Claude Code 其中有一筆；用零代入後得到的數字不能當成完整發票稽核。因此本文保留官方公開值，但不把小數點後精度解讀成確定真值。

第一步：從自己的 repo 選 5 個可驗收任務

不要直接拿 FrontierHarness 的 30 題替你選工具。它刻意挑出較能區分 agent 的題，29 題標為 medium、1 題 hard，而且全部是軟體工程或終端工作。你的五題應來自真實待辦，但大小要能在同一預算內完成：

1. 回歸修復：已有 failing test，修正後全套測試通過。
2. 小功能：新增一個輸入、輸出明確的 API 或 UI 行為。
3. 跨檔重構：行為不得變，typecheck、lint 與 snapshot 都要通過。
4. 建置／相依修復：從乾淨環境可重現 build，不接受只改本機 cache。
5. repo 維護：例如移除敏感檔、補 migration 或修 CI，並用機器規則驗收。

每題建立 task.md、鎖定的 base_commit、獨立 verify.sh 與時間／成本上限。Verifier 必須只回傳 0 或非 0，不能靠你看 diff 後主觀打分；也不要把完整 hidden test 或答案放進 agent 可讀的工作目錄。Anthropic 的agent eval 指南同樣建議，coding 任務優先使用可重複、可程式化的 grader。

#!/usr/bin/env bash
set -euo pipefail
npm ci --ignore-scripts
npm run typecheck
npm test -- --runInBand tests/eval/task-01.test.ts
git diff --check

先由人類在乾淨 base commit 跑一次：應該 fail；套用已知正確修補再跑一次：應該 pass。若兩邊結果相同，壞的是評測，不是 agent。更完整的 harness 設計方法可接著看 如何建立 AI Agent Harness。

第二步：每一次都從固定 checkpoint 開始

一個可用的 checkpoint 至少鎖定 base commit、container image digest、CPU／記憶體、預裝依賴、環境變數名稱、網路權限與初始檔案狀態。每次 run 建立新的 worktree 或 container；agent 結束後，在另一個唯讀驗收程序跑 verifier，再保存 patch、stdout、exit code 與結果。

Cache 要拆成欄位，不能只寫「有」或「沒有」。至少記錄 input、cached-input、output tokens，以及供應商計價後的實際成本。第一輪只能作 cold candidate 基線，仍要用 provider token 紀錄驗證；第二、三輪若供應商有 implicit prefix cache，應標為可能 warm，不能把三輪混成三個獨立冷啟動樣本。若要專門比較 MCP 和 CLI 的 context 成本，可沿用 MCP vs CLI Token A/B Test 的拆帳方法。

第三步：讓 Claude Code、Codex、Pi 走同一個 adapter contract

不要把三條 CLI 指令直接視為「相同設定」。先為每個 adapter 固定七件事：版本、精確 model ID、provider/base URL、API 協議、提示檔 SHA-256、工具與網路權限、停止上限。FrontierHarness 用的是 2026-08-22 捕捉的 Claude Code 2.1.237、Codex 0.148.0、Pi 0.84.2；那是歷史快照，不是要求你安裝的最新版。

目前官方入口分別是 Claude Code 的程式化模式、OpenAI Codex 的codex exec 文件，以及 Pi 0.84.2 的版本化官方文件。旗標與模型支援會變，所以 runner 應先執行各工具的 --version 與 --help，把輸出存進 run metadata；若某工具無法連到同一個精確模型端點，就停止這組「同模型比較」，不要偷偷換模型。Anthropic 的gateway 文件目前也明載不支援把 Claude Code 路由至非 Claude 模型，因此 Frontier 的 Kimi K3 組合應視為研究用、非官方支援配置，不能拿來代表 Claude Code 搭配原生 Claude 的日常成本。

# 概念介面；每個 adapter 自己把欄位映射到當前 CLI
./eval/run-one.sh \
  --task task-01 \
  --harness codex \
  --trial 1 \
  --model-id "$EXACT_MODEL_ID" \
  --budget-usd 8 \
  --timeout-sec 1200 \
  --checkpoint "$IMAGE_DIGEST"

# agent 結束後，由外部驗收；不要讓 agent 改 verifier
./eval/verify.sh task-01
./eval/collect-ledger.sh task-01 codex 1

執行順序採 block randomization：同一題先把三個 harness 的第一輪以隨機順序跑完，再進第二輪；不要先連跑某工具 15 次，才換下一個。預先寫死 45 個 cell 與順序，避免看到失敗才選擇性重跑。工具內部自己重試是 harness 行為，時間與費用必須計入；外部 crash 若要標成 infrastructure invalid，也要事先定義條件並完整留痕。

第四步：用一張 ledger 算對分母

每列代表一個 run，至少包含：task_id、trial、base commit、image digest、harness 名稱與版本、config hash、model ID、provider、protocol、prompt hash、權限、pass/fail、成本、input/cached/output tokens、耗時、turns、exit code、失敗分類與 patch hash。

# ledger.csv：失敗列也保留 cost_usd
harness,task,trial,pass,cost_usd,seconds,cache_state,failure
codex,T01,1,1,0.82,314,cold,
codex,T02,1,0,2.10,1200,cold,timeout

# 每個 harness 的核心指標
pass_rate = passes / attempted_runs
effective_cost_per_pass = sum(all_known_attempt_costs) / passes
median_wall_time = median(all_attempt_seconds)

若有成本缺值，不可用零悄悄補上。另列 cost_coverage，並把有效完成成本標成「已知下限」；pass 數為零時則回報未定義，而不是無限大後硬塞進圖。只看平均 token 或 cache hit rate 也不夠，因為 cache 命中不等於免費，且不同協議的重用方式可能不同。

第五步：品質 × 成本矩陣怎麼做決定？

先訂品質門檻，再比成本。例如：五題中至少四題通過、三次不得都在同一題失敗、沒有越權或破壞 repo 的事故。未達門檻者不因便宜而勝出；達標者才比較有效完成成本、p50／p90 時間與結果變異。這和單看模型排行榜不同，因為你是在做本地工作流 routing；可搭配 AI Model Routing Eval 建立「哪類任務交給哪個配置」的規則。

• 高品質、低成本：優先進入日常路由，但先擴大題數驗證。
• 高品質、高成本：保留給高價值或高風險任務。
• 低品質、低成本：只能用於容易驗收、可快速回滾的工作。
• 低品質、高成本：停用或重新檢查 adapter、提示與停止規則。

停止規則要在開跑前寫下：固定每 cell 的金額、時間、turn 上限；45 runs 完成前不改 verifier；若同一 infrastructure error 連續出現，暫停整個批次而不是只補跑對某工具有利的 cell。五題只是 smoke test，足以淘汰明顯不合格者，不足以證明誰是普遍冠軍。

何時不能把 FrontierHarness Eval 外推到自己工作？

• 你用的不是 Kimi K3，或 provider、協議、cache 政策不同。
• 你的工作是研究、寫作、資料分析或視覺任務，不是 terminal coding。
• 你允許網路、MCP、瀏覽器或公司內部工具，而公開題目的權限不同。
• 你的任務比 30 題更長、更短，或失敗代價不是簡單 pass/fail。
• 你使用新版 harness；版本、system prompt、預設工具與 context 管理都可能已變。
• 你要的是可重現的 360-run replication；公開 repo 沒有足夠的原始 runner 與私有 evidence 支援這個主張。

FrontierHarness Eval 最有價值的地方，是證明「只換 agent 控制層，帳單與完成率可能一起變」；它沒有證明哪個工具永遠最好。若你只想理解兩個主流產品的日常差異，先看 Claude Code vs Codex 完整比較；若要公平比較更多輕量 harness，舊有的 Pi vs OpenCode vs DeepSeek Harness 盲測協議可作基礎，本篇則把新公開資料的分母問題與 45-run 個人矩陣補齊。

常見問題 FAQ

1. FrontierHarness Eval 證明 Claude Code 比 Pi 貴 17.5 倍嗎？

沒有。17.5 倍是 Claude Code 對 Exo Harness；Claude Code 對 Pi 的公開有效完成成本約差 7.5 倍，而且只限這個 Kimi K3、30 題、one-shot 設定。

2. 官方的 18.34 美元是中位成本嗎？

不是。公開 JSON 顯示它是全部已知嘗試成本除以通過數的有效完成成本；README／圖表的 median 標示與資料欄位、可重算公式不一致。

3. 為什麼失敗也要計入成本？

因為你仍然付了錢與時間。排除失敗會讓常常早停或做不完的配置看起來異常便宜，無法回答「取得一個可交付結果要花多少」。

4. 三次重跑都算冷啟動嗎？

不一定。本機 worktree 可以重建，但供應商的 implicit prefix cache 可能仍暖；應記錄 trial 與 cache tokens，第一輪另報，不能只把三輪平均。

5. 五個任務足以選出永久冠軍嗎？

不足。五題適合快速淘汰與找 routing 候選；重要決策應逐步擴增題庫、保留版本，並觀察不同任務家族的變異。

6. 三個工具一定能連同一模型嗎？

不保證。要看當前版本支援的 provider、base URL 與 API 協議；任何一個無法使用同一精確 model ID，就不該把那輪稱為同模型比較。

7. Pass rate 接近時應直接選最便宜的嗎？

先不要。先檢查配對到同一批任務的失敗型態、停止原因與品質門檻；便宜可能來自更早放棄，而不是更有效率地完成。

8. 可以完整重現官方 360 次評測嗎？

目前公開材料不足。你可以重算彙整數字、讀 30 題定義，也能依原則自建實驗；但缺少 raw trajectories、完整 runner／gateway 設定與私有驗收 evidence，不能聲稱逐次完整重現。