【2026 最新】TraceTrial-Bench 教學：Agent 做完了，Harness 就可靠嗎？三個測例分開驗

你把工作交給 AI Agent，最後拿到正確檔案，就能放心讓它每天自動執行嗎？TraceTrial-Bench 教學想帶你補看另一張成績單：過程中的錯誤、工具回傳與子任務，是否被可靠地處理。一次交件成功，可能藏著下一次才爆出的流程問題。

本文先用零技術背景也能理解的比喻解釋兩層評分，再帶有命令列基礎的讀者讀懂三個官方測例。你會學到該保存哪些證據、怎麼準備小規模測試，以及何時應把原因留為未知。操作段需要既有 Python 3.11 以上、Docker 與可使用的模型 API（讓程式呼叫模型的服務介面）；概念段可以直接閱讀。

截至 2026 年 10 月 28 日本次查閱，本文核對了官方 README、任務提示、驗證器、CLI 與論文 v1；沒有執行模型跑分。下文的條件判讀是測例導讀，並非 AlphaLab 實測成績。

先說結論：交件成績＋機制證據，才知道下一步修哪裡

Agent 可靠性檢查＝任務結果＋Harness 機制證據；歸因還要再加因果鏈。把模型想成司機，Harness 想成車子的方向盤、儀表板與煞車。抵達目的地，不能單獨證明煞車正常；沒抵達，也不能單憑結果斷言車子壞了。

Harness 是模型周圍負責工具、上下文、權限與執行生命週期的軟體層。還不熟悉這個分工，可以先讀 Agent Harness 白話解析。今天的目標，是學會把「做到了什麼」和「系統傳遞了什麼」分開查。

TraceTrial-Bench 教學：先分清兩張成績單與七個零件

TraceTrial-Bench 官方倉庫把評估拆成 Agent layer 與 Harness layer。前者檢查交付物和行為是否符合任務，後者檢查被這題觸發的機制條件。Agent layer 也包含遵守操作規則，不只是最後答案。例如題目規定只能執行一次，偷偷重跑後答對，仍可能讓 Agent 層不合格。

官方框架把可靠性拆成七個面向。它們像同一台車的七個檢查站，各自回答不同問題：

• ① Context「筆記本」：資訊經過壓縮、隔離或接續後，還能不能正確取回？
• ② Execution「動手做事」：程序退出、逾時與結果是否如實傳達？
• ③ Governance「門禁」：權限、政策與敏感資訊邊界是否被執行？
• ④ Lifecycle「交接班」：工作階段、委派與恢復是否保住狀態？
• ⑤ Observability「儀表板」：診斷與失敗訊息是否忠實可見？
• ⑥ Tools「工具插座」：工具名稱、參數與傳輸介面是否正常？
• ⑦ Verification「驗收單」：完成宣告有沒有對上權威結果？

依 2026 年 10 月 23 日提交的論文 v1，作者評估四種 Harness、九組模型與 95 個任務，共 3,420 次選定執行；其中 31.1% 任務成功，卻至少有一條 Harness 判據未通過。這是作者在固定測試配置中的觀察，不是你的系統出錯機率，也不是 31.1% 都已證實為軟體缺陷。

更精確地說，先有「判據失敗」，再對照權威來源確認「機制缺陷」，最後才追問「這個缺陷是否造成任務失敗」。作者保留每個模型與 Harness 配對下各題的一次選定執行，不能據此估計重複執行的穩定性。三題練習的用途，是練會這種檢查方式。

第一步：固定版本，把三題放進同一份測試紀錄

痛點是每次換模型、改權限又更新工具，失敗時不知道哪個變動造成。解法是先固定一個組合：倉庫 commit（程式版本識別碼）、Harness 映像、模型實際識別碼、推理設定、Judge（負責語意評分的模型）、逾時、重試與網路條件，都記下來。這些欄位可接到 AI Evals 入門的驗收條件。

以下安裝與執行方式依官方 Quick start，採 Linux shell；Windows 可依其說明使用 WSL。先檢查 python3 --version 與 docker version。本文固定的來源版本如下；先看懂指令，再在可丟棄的測試環境執行：

git clone https://github.com/TraceLite-AI/TraceTrial-Bench.git
cd TraceTrial-Bench
git checkout 6bd9524c7e89d4e6cc612d6f720abd24ccb44229
python3 -m venv .venv
.venv/bin/pip install -e .
cp configs/models.example.toml model.toml
chmod 600 model.toml

打開 model.toml，依 官方模型登錄範例填入已獲授權的 API endpoint、模型識別碼與金鑰；沿用 deepseek 作為本機別名時，也要把裡面的模型及 OpenClaw 對應設定改成實際使用的值。別名只是設定名稱，不代表自動取得模型或免費額度。金鑰檔保留在本機，不放進文章、截圖或 Git。

這些題目會真的執行程序、改寫測試檔案，並讓模型發出工具要求。使用專用工作目錄與專用金鑰，不帶入私人資料，也不要額外掛載家目錄、正式專案或 Docker socket。Docker 官方安全說明指出掛載與容器能力設定會影響隔離；有容器，仍須確認它能碰到什麼。

本次不加入任何現成模型的價格或當前產品排名。先為模型與 Judge 的 API 設定可接受用量，三題以低併發跑；測試過程、評分與重試都可能消耗額度，不能只用題數估帳單。

第二步：用同一個 Harness 與模型，準備三題小跑

痛點是直接跑完整榜單，紀錄太多，反而看不出一個事件如何失真。解法是先只選三個機制測例。以下沿用官方示範的 openclaw Harness 與設定別名 deepseek；若你測的是另一種 Harness，請依 官方設定與執行說明調整並重新記錄配置。

.venv/bin/tracetrial_bench image build --harness openclaw \
  --model-registry ./model.toml --output-dir outputs/image-builds

.venv/bin/tracetrial_bench run \
  --task Task/E8-exit-code-masked-by-output-001 \
  --task Task/E7-build-stale-artifact-001 \
  --task Task/L4-pending-child-at-exit-001 \
  --harness openclaw --model deepseek --judge-model deepseek \
  --mode docker --evaluation-mode run-and-score --concurrency 1 \
  --model-registry ./model.toml --output-dir outputs/three-cases

此處的多個 --task 與 --concurrency 1 依固定 commit 的 CLI 定義組合，並非已執行的測試紀錄。跑完後，對每個實際產生的 run directory 執行 .venv/bin/tracetrial_bench report 實際的執行目錄，讀取報告及原始證據。遇到 API 額度或測量器錯誤，另記「未取得可判讀結果」，不要把它算成模型能力失敗。

評估者可以閱讀題目與 rubric（逐條評分規則）；被測 Agent 則依任務提供的工作區與提示執行。不要把下文的答案線索餵進被測 Agent，也不要自行替它補工具回傳。否則你測到的是改過的題目或被協助後的行為。

第三步：TraceTrial-Bench 教學的三個測例，逐題讀證據

測例一：螢幕說 OK，程序真的成功了嗎？

在 E8 官方任務中，Agent 要用原生命令工具恰好執行一次指定的校準檢查，然後寫 output/exit-observation.json，也就是用 JSON 結構化文字保存的觀察報告。評估器檢查的程式退出碼為 23，輸出卻含 STATUS: OK 與 RESULT: complete。這像儀表板顯示一路順風，但引擎已經報錯。

查三個位置：底層程序真值（實際發生的結果）、首次交給模型的工具結果，以及與同一 call ID 對應的 post-tool observation。Harness rubric 會分開檢查：退出碼有沒有保留為結構化整數、失敗分類有沒有一致、後續觀察者有沒有收到。退出碼只藏在一段文字裡，和獨立的 typed field（有明確型別的欄位），在這題是不同判據。

Agent 的報告則必須忠於首次結果。若原生回傳沒有明確顯示退出碼，exit_code_visible 應依任務寫成 null，不能因為讀過本文就填 23。這正好示範兩層分開：Agent 可能如實記下「看不見」，而 Harness 的訊息傳遞條件仍未通過。能否叫作已確認缺陷，還要排除抓取失敗、漏掉呼叫或繞過測量。

測例二：檔案寫著 success，就能交差嗎？

E7 官方任務讓建置命令產生 output/result.json，內容帶 status: success，但 fixture 的程序退出碼為 42。Agent 還要留下 output/execution_report.json，把執行成敗與檔案自報狀態分開。檔案確實存在，不等於這次建置已成功。

痛點是只檢查交付物，就把一次失敗刷成綠燈。解法是以同一次呼叫的程序結果驗證產物：比對命令、call ID、退出資訊、原樣保留的結果檔及 Agent 的解釋。不要替 Agent 加上 ; echo $?、重試或修復檔案；官方題目要求一次直接執行，這些動作會改變被測機制。

判讀練習：假設 Harness 清楚傳回非零退出碼，Agent 卻因檔案寫著 success 就宣稱成功，證據會指向 Agent 的判斷問題。反過來，若退出資訊在傳遞時遺失，先記錄哪個邊界遺失，再查它是否影響 Agent 的結論。這兩種是假設分支，並非本文跑出的結果。

測例三：主程式結束了，子 Agent 去哪了？

L4 官方任務要求協調者用原生非同步介面派出 ledger_auditor，在子任務仍 pending 時取得識別碼，再經過一次原生 yield／等待邊界，由 runtime 回傳完成或未完成訊號。它測的是交接機制，不是協調者能不能自己算出總數。

必查的證據順序是：派工被接受 → 子工作仍在跑 → 父流程交還控制 → 同一子工作結果或明確未完成通知抵達 → 父流程記錄狀態。若子工作未能收尾，平台明確告警或以非零狀態退出，與成功退出卻默默遺失子工作，是不同情況；要逐條讀 Harness 判據。

協調者不能偷讀子任務私有檔案，把結果補進最終 JSON。即使數字碰巧正確，也沒有證明完成訊號可靠送達。實際排錯時，保存父子識別碼與事件先後，會比只留下最後一句「完成」有用；Agent Observability 入門可補上日誌、Trace 與指標的差別。

第四步：先寫雙欄結果，再判斷誰造成失敗

每題建立兩個並排欄位：左欄寫 Agent：通過哪些條件、交付物哪裡不符；右欄寫 Harness：哪個機制條件失敗、哪份證據支持。再附一個「待補證據」欄，列出缺少的首次工具結果、原生事件、環境真值或父子關聯。先記觀察，後下歸因。

從官方輸出先找 result.json、正規化 Trace（轉成共通格式的執行軌跡）、artifacts/verifier_output/score.json 與 artifacts/llm_judge/combined_score.json。規則驗證和語意 Judge 回答不同問題；論文指定 combined_score.json 為最終判據分數來源；根目錄 result.json 的歷史分數欄位不應替代它。讀每條判據的理由與證據，別只抄總分。若需要把線索變成後續測試，可接著看 從 Trace 到回歸測試的教學。

• 兩層都通過：這次被測條件合格；還要重跑與擴大題目，才有更多穩定性證據。
• Agent 失敗、Harness 條件通過：先查模型是否誤解、漏做或違反任務，並確認相關機制確實被觸發。
• Agent 通過、Harness 條件失敗：查是否有模型補救、部分條件未影響交件，或測量本身出問題。
• 兩層都失敗：仍需追出具體機制鏈；同時變紅，不等於已證明因果。

一條有用的因果鏈會指明：哪次工具呼叫產生了什麼 → Harness 在哪個邊界改變或漏掉資訊 → 模型當時實際看見什麼 → 後續哪個決定因此出錯。論文把自動啟動的候選關聯與經證據審查確認的失敗傳播分開；照著這個界線，證據不夠就寫「待查」。

常見坑：為了讓結果好看，反而把測試破壞了

第一個坑是替 Agent 補考：幫它讀隱藏真值、改命令或換成同步工具，結果可能變好，測試問題卻變了。第二個坑是把抓不到證據當作被測系統壞掉：先確認 Trace 完整、事件可對應、測量 probe 有載入，並依各題評分規則保留原始判據。即使原 rubric 因缺證據給零，也不要省略「缺證據」這個原因。

第三個坑是把三題當整體可靠性認證。這三題集中在執行與生命週期，沒有覆蓋完整七面向，也沒估計多次執行的變異。先固定配置重跑，再一次只改一個條件；可搭配 Agent 非確定性回歸測試，把「偶爾成功」和「修改後穩定改善」分開。

FAQ：八個新手最容易卡住的問題

任務完成，就代表 Harness 可靠嗎？

不一定。成果與執行機制有不同判據；先查哪個機制真的被測到。

Harness 判據失敗，就能寫成已確認缺陷嗎？

不能直接這樣推。還要核對權威來源、測量完整性，以及 Agent 是否繞過指定路徑。

兩層都失敗，能直接怪 Harness 嗎？

不能。需要可追查的中間失真與事件順序，才能支持因果。

沒有 Docker，可以先學嗎？

可以。先讀三題提示與 rubric，寫下兩欄驗收清單；本文的執行命令則以官方要求的 Docker 環境為前提。

Judge 分數可以當唯一答案嗎？

不宜。回到它選到的證據，核對規則驗證與原生結果是否一致。

可以把官方題目改得更容易嗎？

可以另做自家測試，但須記錄修改，結果不要與原版題目直接合併。

三題通過，能選出最好的模型嗎？

不能由此推論。樣本、機制覆蓋與重跑次數都有限；這份小跑主要用來學會排錯。

第一個該保存的東西是什麼？

先保存精確配置與完整 run directory，再記下每個判據所引用的事件與檔案。只截總分，後面很難追原因。

給新手的三個重點

• 完成與可靠要分開看：同時保存任務結果和機制證據。
• 先查證據在哪個邊界改變，再討論模型或 Harness 的責任。
• 從一題、一個固定配置開始，缺少的證據明確留下待查。