【2026 最新】Terminal-Bench-Science 教學：用 1 題跑三次，公平評測 Coding Agent

看到 Terminal-Bench-Science 榜單的 30.0%，你可能直覺把它讀成「這個模型有 30 分」；這正是這篇 Terminal-Bench-Science 教學要拆掉的第一個誤會。官方 v0.1 的每一列其實是一組 Model＋Agent Harness，在 70 個科學工作流上各跑 3 次後的 verifier 通過率。30.0% 代表 210 次 task-trial 中有 63 次通過，不是模型智商，也不等於穩定解出 21 個不同任務。

這篇專為第一次評測 Coding Agent 的讀者寫。你會用 terminal-bench-science/symbolic-regression 這一題建立環境檢查，固定版本、模型、Harness、timeout 與執行器，再跑 3 次，最後讀 reward、artifact、verifier、trajectory、時間與成本。重點不是做一張自己的迷你排行榜，而是回答一個有邊界的問題：在這套固定設定下，這個 Coding Agent 面對這一題時，成功率、成本與失敗形狀是什麼？

先說清楚實證邊界：本文依截至 2026 年 8 月 29 日的官方 v0.1 公告、執行文件、v0.1.0 release與 Harbor 文件整理；本次編輯環境沒有可用的 sandbox provider 登入與模型金鑰，因此沒有把文件命令冒充 AlphaLab 的實跑成績。下面是可重跑的實驗契約，不是虛構結果。

Terminal-Bench-Science 教學先說結論：固定條件，再讀完整證據

🧪 記憶把手：可信 Agent 評測＝固定 Task × 固定 Model × 固定 Harness × 固定環境 × 多次重跑 × 完整證據。
乘號代表任何一欄換掉，問題就變了；只留最終分數，則無法知道失敗發生在哪一層。

• 榜單比較的是系統：Model、Agent Harness、工具、權限與推理設定一起影響結果，不能只把差異歸給模型。
• 單題跑 3 次是診斷：它能讓你看見非決定性與失敗形狀，但樣本太小，不能證明整個榜單誰比較強。
• reward 是入口：還要對照 verifier log、artifact、trajectory、執行時間、token 與供應商回報成本。
• 基礎設施錯誤另列：環境啟動、下載、憑證或 verifier 自身出錯，不該悄悄改寫成模型能力不足。
• 保護 benchmark：不要先看 oracle solution，也不要把完整解答與未遮罩 trace 丟進公開訓練或回饋流程。

30% 不是一般能力分數：先把分母拆開

官方 v0.1 公告列出 70 個任務、5 個科學領域，並說明每組受測系統在每題執行 3 次。於是每一列共有 70 × 3＝210 次 verifier 判定；30.0% 就是其中 63 次通過。不同題目的三次結果可能一致，也可能成功、失敗混在一起，所以「通過 63 次」與「穩定完成 21 題」是兩件不同的事。

這個拆法也說明為什麼不能把榜單稱為「純模型比較」。每列使用的 Agent Harness 可能不同；Harness 決定系統提示、工具介面、工作目錄、錯誤恢復與何時停止。若你同時把 Model A＋Harness A 換成 Model B＋Harness B，得到的是兩套系統的差異。想先建立通用心智模型，可讀《AI Eval 是什麼》；想理解 Model 與執行層如何分工，則看《AI Agent Harness 是什麼》。

為什麼選 symbolic-regression 這一題？

這個 beginner lab 選 terminal-bench-science/symbolic-regression，原因不是它「最簡單」，而是官方 v0.1.0 task.toml把環境、artifact 與 verifier 邊界寫得很清楚：它是 CPU 型統計任務，gpus = 0；Agent 需在工作區留下 /app/regressor.py，verifier 會在獨立、禁止網路的環境檢查這個 artifact。這讓新手容易分辨「Agent 有沒有交付檔案」與「交付內容有沒有通過驗收」。

請保持盲測：用 Harbor registry 下載任務，不要把 release repository 整份放進 Agent 工作區，也不要先讀 solution/、參考解法或他人的完整 trace。官方 repository 公開後，canary 與禁止作弊規則只能降低風險，不能把公開資料變成私有 holdout。你的實驗紀錄應保存設定與結果，避免公開可直接還原答案的內容。

Terminal-Bench-Science 教學步驟 0：安裝 Harbor，先做 Oracle 環境檢查

官方 run 頁以 Harbor 搭配 Modal 示範 v0.1，並標示這批任務不需 GPU。先安裝包含 Modal adapter 的 Harbor；為了讓 runner 本身也可追溯，本文把它 pin 在本次查核的 stable 0.22.0。如果你選 Daytona，則改裝相應 extra 並完成它的登入。模型 API key 與 sandbox credential 只放在執行 shell 的秘密環境，不要寫進 job YAML 或 Git。

uv tool install "harbor[modal]==0.22.0"
modal token new
harbor --version

先讓 Oracle 跑同一題一次，目的只是在你的 sandbox 驗證「任務可下載、環境可建立、artifact 能送進 verifier、結果能寫回 job」。Oracle 通過不代表題目完美，也不代表你的 Agent 會通過；它是一張基礎設施收據。

harbor run \
  -t terminal-bench-science/symbolic-regression@2 \
  -a oracle \
  -e modal \
  -k 1 \
  -n 1 \
  --max-retries 0 \
  --job-name tb-science-sr-oracle-smoke

這裡故意沒有加 --upload。Harbor jobs 文件把本機 job 與上傳分享分開；先把盲測結果留在自己的 job 目錄。若 Oracle 失敗，先看環境與 verifier log，暫停昂貴的模型試跑。

步驟 1：凍結實驗契約，用 @2 取代移動的 latest

截至 2026 年 8 月 29 日，Harbor Hub 的 v0.1.0 dataset 把這題解析為 terminal-bench-science/symbolic-regression@2。直接 pin @2，並保存 Oracle job 的 config.json 與 lock.json。官方 job config 文件也說明，移動的 latest 會在保存設定中解析成實際版本；但既然本次 revision 已能確定，就不要讓下一次下載重新選版本。

1. Task：具體 ref／digest、instruction 與 verifier 版本。
2. Model：完整 provider／model ID、reasoning level、temperature 或 seed（如果介面提供）。
3. Agent：Harness 名稱與精確版本、system prompt、工具、權限及停止條件。
4. Environment：Modal／Daytona／Docker、資源、網路政策、Harbor 版本與 task timeout。
5. Budget：供應商專案硬上限、token／回合上限與人工停止規則；不要假設 Harbor 有跨 Harness 通用的「每題美元上限」旗標。
6. Attempts：固定 3 次、n_concurrent = 1，把重試與新的 scored attempt 分開記。

若要比較兩個模型，就保持同一 Harness；若要比較兩個 Harness，就保持同一模型。某個模型無法在同一 Harness 中使用時，請把標題寫成「System A vs System B」，不要把結果縮寫成純模型勝負。這和《本機 LLM Parity A/B Test》的原則相同：先證明可比，再解釋差異。

步驟 2：固定一組 Agent＋Model，連續跑 3 次

把下面兩個 placeholder 換成你實際使用的 Harness 與完整 model ID，並先在供應商後台設定專案花費上限。-k 3 是三次 scored attempts；-n 1 讓它們依序執行，降低同時併發、rate limit 與資源爭用帶來的混雜。使用 task 原始 timeout；如果你改 timeout multiplier，就建立新實驗，不要和舊結果直接混算。

export TB_AGENT="<你的 Agent Harness 名稱>"
export TB_MODEL="<provider/model-id>"

harbor run \
  -t terminal-bench-science/symbolic-regression@2 \
  -a "$TB_AGENT" \
  -m "$TB_MODEL" \
  -e modal \
  -k 3 \
  -n 1 \
  --max-retries 0 \
  --job-name tb-science-sr-agent-3x

先把預期工作量寫在實驗單：一題 × 一組 Agent × 三次 attempts＝三個 planned trials。--max-retries 0 把 infrastructure error 的自動付費重試關掉；若需要補跑，先分類錯誤再建立新 job。若畫面顯示更多任務或更多 trials，就先中止並核對 task selector；不要等花費發生後才發現你跑了整個 dataset。三次跑完也不要挑最好的一次當答案，三份都要保留。

步驟 3：沿著 Harbor artifacts 找失敗階段

執行後用 harbor view jobs 開啟 viewer。依Harbor Evals 文件，job 目錄會保存 job 級 config.json、result.json；每個 trial 另有自己的設定與結果，以及 verifier 的 reward、stdout 與 stderr。agent/ 內容依 Agent implementation 而異，支援的 Agent 才可能留下 trajectory.json 或 recording.cast 等軌跡。不要只截一張總分畫面；把整個 job 目錄當成可回看的實驗收據。

1. 先看 job config：task ref、Agent、Model、環境與 attempt 數是否和實驗單一致。錯了就整批作廢，不靠事後註解補救。
2. 再看 trial result：reward 是否存在、trial 是否 completed、是否有 exception。缺結果與 reward 0 不是同一狀態。
3. 核對 artifact：/app/regressor.py 是否被產生，並在 host job 留下 artifacts/app/regressor.py 與 manifest，再送入 verifier。檔案缺失通常指向路徑、工具或停止流程，不等同於數學能力結論。
4. 讀 verifier：先辨別 verifier 正常拒絕提交，還是 verifier 自己崩潰、超時或無法啟動。後者列為 evaluation error。
5. 最後讀 trajectory：Agent 看到了什麼、呼叫哪些工具、在哪一個假設後走偏、是否撞上權限或網路限制。成功 trace 也要讀，避免 reward hacking 或偶然過關。

這套順序和《動手搭建 Agent Harness》的觀測層一致：結果、狀態變化、工具呼叫、檔案 diff 與 verifier 必須能互相對上。若你準備修改 Harness，再讀《從失敗 Trace 修 Harness》，但先用新的 run name 保存候選，不要覆蓋基準。

步驟 4：用 pass rate、完成成本與失敗類型做決策

單題三次最小報告可以很樸素：通過次數／3、三次總成本、每次時間、完成 trials 數，以及各失敗階段的計數。若某次是環境錯誤，先修環境並依預先寫好的重試規則補跑；不要把它刪掉後只留下漂亮結果。成本則要包含失敗 attempts，因為失敗也消耗真實預算。

• 3／3 通過：代表這套設定在這一題的三次觀測都通過；仍不能外推到 70 題、其他版本或一般 Coding Agent 能力。
• 1／3 或 2／3：先比對成功與失敗 trajectory，找工具、策略、timeout 或隨機性的分岔；不要只再跑到成功為止。
• 0／3 且流程完整：這才是較乾淨的能力／策略失敗訊號；換 Prompt 或 Harness 後要建立新的 baseline。
• 任一次未完成：分開報告 infrastructure、credential、rate limit、agent crash 或 verifier error，不把異常混進 pass rate。

比較第二套系統時，只改一個目標變因，使用同一具體 task ref 與三次設計。你可以把差異寫成「在 symbolic-regression v0.1.0、此 Harness、此 provider 與此時段下，A 的通過次數較高但成本也較高」；不能改寫成「A 普遍比較聰明」。若要做正式 With／Without 配對，可延伸《NVIDIA SkillEvaluator A/B Test》的凍結欄位與多 attempts 方法。

七個最常讓 Terminal-Bench-Science 教學失真的坑

1. 把 latest 當版本：第一次解析後立刻保存具體 ref／digest，版本變更就重建 baseline。
2. 同時換 Model 與 Harness：結果只能叫系統比較；若要歸因，其他欄位必須固定。
3. 只跑一次：單次成功可能是偶然路徑，單次失敗也可能是外部波動；三次仍只是最低診斷起點。
4. 把 error 當能力 0 分：先確認 Agent 真正拿到任務、artifact 進入 verifier、verifier 正常結束。
5. 只看 reward：reward 告訴你是否跨過驗收線，不會自動解釋失敗原因，也不代表完成多少研究工時。
6. 污染自己的盲測：先讀 solution、搜尋現成答案或公開完整 trace，都會改變你真正測到的東西。
7. 忽略失敗成本：只用成功 trial 算平均會讓不穩定系統看起來過度便宜；總成本與未完成數要一起報。

Terminal-Bench-Science FAQ

1. 30.0% 代表 Agent 有 30 分嗎？

不是。它是特定版本、70 題、每題 3 次下的 verifier 通過比例，而且每列綁定 Model＋Agent Harness。離開這個測試契約就不能直接沿用。

2. 只跑一題還算公平嗎？

只對窄問題公平。固定條件後，它能比較兩套設定在這一題的行為；它不能代表整個 benchmark，更不能代表所有科學工作流。

3. 三次重跑足夠做排名嗎？

不夠。三次適合抓出明顯波動與建立除錯樣本，不是統計保證。要做排名，還需要更多任務、預先定義的分析與不確定性報告。

4. 可以直接比較兩個模型嗎？

可以，但 Harness 必須相同且相容。若兩邊使用不同 Agent、工具或推理設定，就誠實稱為兩套系統比較。

5. Reward 0 一定代表模型不會嗎？

不一定。先排除環境、憑證、artifact 路徑、Agent crash 與 verifier error；只有流程完整、verifier 正常拒絕，才是較乾淨的任務失敗。

6. 這一題需要 GPU 嗎？

官方 v0.1.0 的這一題設定為 gpus = 0。這個答案只綁定本文選定的 task ref；換題或換 release 時要重新讀 task config。

7. Oracle 通過就代表題目完全沒有問題嗎？

不能這樣推論。Oracle smoke 主要證明你的環境能跑通官方參考路徑；題意、verifier 邊界與真實世界代表性仍要分開審查。

8. 可以把完整 trace 公開分享嗎？

先不要。公開 protocol、版本、聚合結果與經檢查的失敗類型就好；若 trace 可能還原答案、測試或敏感 credential，留在私有 job，必要時只分享去識別、去答案的片段。

給新手的 6 個重點

• 30% 是 63／210 次 verifier pass，不是一般能力分數。
• 榜單每列是 Model＋Agent Harness，不是單獨模型。
• 先跑一次 Oracle 檢查環境，再跑 Agent 三次。
• 比較前固定具體 task ref、Model、Harness、環境、timeout 與 budget。
• reward、artifact、verifier、trajectory、成本與 exception 必須一起讀。
• 單題結果只回答單題；要擴大結論，就擴大任務與重跑設計。