ThinkingBox 以資料庫終態驗證 agent：pass@1 之外，要看 20 次都過
Microsoft × Hugging Face · 2026-10-03 · arXiv:2608.19741
agent 評測長期只檢查「工具呼叫合不合法、回覆像不像樣」，ThinkingBox 改成直接檢查任務結束後後端資料庫的狀態，並讓每個任務重跑 20 次。結果是：模型看似通過的任務，有很大一部分其實把資料寫錯了。
這是 Microsoft 與 Hugging Face 合作的基準，論文於 2026-08-20 提交，HF 部落格於 2026-10-03 發表，含 507 個有狀態的商務流程任務。
原本的問題
部落格開頭的例子是一筆卡住的 $745 訂單。agent 連續做了 9 次正確的工具呼叫、查到正確的退款政策、也開了客服單，卻把單子關成「resolved」，正確終態應該是等待物流商處理的「on hold」。只看呼叫軌跡，這次執行完全挑不出毛病，只有比對資料庫才會發現。
這類錯誤很難被傳統評測抓到：工具參數合法、流程順暢結束，錯的是最後寫進去的值。作者的說法是「A tool call is not an outcome」。
採用的方法
每次嘗試都在獨立的 MCP 工具 session 中以全新狀態啟動，結束後用可執行的檢查比對資料庫終態與需求，並另外抽出非預期的副作用。同一任務重複 20 次，回報三個指標：
pass@1：單次嘗試成功率pass@20：20 次中至少成功一次- observed 20/20：20 次全部通過，用來衡量「可依賴」
本機跑單一任務的方式如下，環境依賴 Typesense 與 MCP server：
uv run --project envs/thinkingbox_env thinkingbox-eval \
one_task.yaml --config "$PWD/thinkingbox.yaml" \
--output results.jsonl --repeat 1 --message-timeout 1800實際效果
下表是部落格 Table 2 的整體 pass@1 與 20/20 一致性（Kimi-K3 為開放權重領先者）。
| 模型 | pass@1 | 20/20 任務數 |
|---|---|---|
| Claude Opus 5.5 | 67.16% | 241/507（47.53%） |
| Claude Opus 5 | 66.50% | 241/507（47.53%） |
| GPT-5.4 | 65.36% | 部落格列出 128 個可依賴任務 |
| Kimi-K3 | 57.37% | 68/507（13.41%） |
Kimi-K3 至少成功一次的任務有 476/507，覆蓋最廣，但穩定通過的只有 68 個。單次分數接近的模型，一致性可以差很多。部落格另指出，只有三個模型能保住大部分 pass@1：GPT-6 Astra 約 78%，Claude 系列約 71%，GLM-5.1、Kimi-K2.6、DeepSeek-V4-Pro 各約 8%。
失敗長什麼樣
在 121,680 次有效試驗中，79,853 次未通過可執行檢查，其中 67.24% 是乾淨結束：工具呼叫合法，終態卻不對。失敗類型可重疊：
- 欄位值寫錯：77.61%
- 非預期的額外副作用：43.30%
- 缺少必要的效果：25.36%
論文與部落格的摘要在 pass@20 的稱呼上並不一致（論文摘要把 47.53% 稱作 pass@20，部落格則標為 observed 20/20），本文採部落格的定義，請以論文原文核對。
影響範圍
正在做客服、訂單、保險理賠這類會寫資料庫的 agent 的團隊，評測不能只比對對話或 tool trace。至少要在每次執行後對終態跑斷言，並檢查「多寫了什麼」，因為副作用佔了 43.30% 的失敗。
選模型時，部落格以未折扣牌價算出「每個可依賴任務的成本」：GPT-5.4 為 $6.80、GPT-6 Astra 為 $7.45、Claude Opus 5.5 為 $7.80。單次成功成本最低的是 GPT-5.6 Sol 的 $0.127，但那個指標不反映重複執行的穩定度。
程式碼為 MIT，資料集採 CDLA-Permissive-2.0，OpenEnv 環境為 BSD-3-Clause，可以直接拿來接自家的工具與資料庫。