ThinkingBox 是什麼？用資料庫狀態當 RL 獎勵訓練 agent

重點摘要

• 2026 年 10 月 22 日，Microsoft 與 Hugging Face 聯合發布 ThinkingBox-Training：把 ThinkingBox-Bench 的可執行資料庫核對（1/0 訊號）直接當 GRPO 的獎勵函數，訓練任務來自 benchmark 以外。
• Qwen3.8-27B 在 ThinkingBox-Bench 的 507 項任務上，平均成功率從 51.70% 升至 60.78%；20 次嘗試全對的任務數從 38 筆增加到 107 筆，只用了 50 步 GRPO 訓練。
• 訓練池篩選採 offline policy-relative difficulty：只保留對當前模型「不太會、也非全不會」的任務，已熟練和完全沒救的任務都從訓練池剔除。

2026 年 10 月 22 日，Microsoft 的 Mirco Milletari、Xiang Jiang 與 Hugging Face 的 Sergio Paniego，以及前實習生 Zhuochun Li（匹茲堡大學）聯合發布了 ThinkingBox-Training，並同步在 GitHub 上公開訓練程式碼。這篇報告的起點是一個工程上讓人警覺的案例：一個 agent 完成了 9 次外觀合理的工具呼叫，最後把客戶工單標為「已解決」，但資料庫裡造成工單的 carrier exception 記錄從未被修改。工單顯示關閉，問題實際還開著。

ThinkingBox-Bench 在核對什麼？

ThinkingBox-Bench 包含 507 個任務，每個任務都給 agent 一個真實後端與一套工具，讓它自由操作，完成後直接比對終態資料庫與預期結果。這不是問 agent「你覺得完成了嗎」，而是直接看資料庫裡的記錄是否符合預期狀態。由於核對邏輯可程式化，這個過程可以精確地回傳 1 或 0。

這讓評測訊號比 LLM 裁判或人工標注更客觀。LLM 裁判有自身的幻覺傾向，模型自評則容易過度樂觀；終態資料庫裡的記錄不會迎合期待。ThinkingBox 最初拿這個機制做基準測試評分器，但研究團隊後來注意到：這個訊號不只能批改，還能用來訓練。

從評分器到獎勵函數，差在哪？

評分器是事後批改，訓練結束後才告訴你模型進步多少；獎勵函數是即時回饋，每次軌跡生成完成後直接影響參數更新方向。ThinkingBox-Training 的做法是在 ThinkingBox-Bench 以外另建訓練池，讓 agent 對各任務操作後，把資料庫核對結果的 1/0 當 GRPO 的獎勵訊號。

50 步訓練之後，Qwen3.8-27B 的平均成功率從 51.70% 升至 60.78%；更有診斷意義的數字是全對率：20 次嘗試全部答對的任務數從 38 筆跳到 107 筆，接近 2.8 倍。平均成功率的提升幅度（約 9 個百分點）相對低調，但全對率的跳升說明這輪訓練主要強化的是穩定性，把「偶爾對」推向「幾乎必然對」。這個訓練結果由研究團隊自測，尚待更大規模的外部複現。

offline policy-relative difficulty 是什麼？

訓練任務的篩選邏輯是整套方法的核心工程決策。當前模型每次都能解決的任務沒有學習訊號；完全無法解決的任務獎勵永遠是 0，參數更新也沒用。有效的學習只發生在「成功率落在中間區間」的任務上，而這個區間會隨模型能力移動，難度本質上是相對於「此刻的模型」而存在的。

ThinkingBox-Training 把這個設計稱為 offline policy-relative difficulty：正式訓練前，先用基準策略跑一次全部候選任務，估算各任務對當前模型的難易度，篩出落在有效區間的任務形成固定訓練池，之後整個訓練過程不再重新評估。「離線」的意思是難度只估算一次，把估算成本控制在可接受範圍。

這個設計理論上有一個限制：隨著模型進步，訓練池裡的任務可能漸漸變得太簡單，訊號品質下降。但對 50 步 GRPO 這個訓練規模，全對任務數從 38 跳到 107 這個結果顯示影響可控。問題是，如果把訓練拉長到幾百步，固定訓練池的訊號是否還夠用，目前的報告並未回答。

對 agent 工程師最直接的意義是：如果你的任務本來就有可程式化的終態驗證，資料庫狀態、API 執行結果、或操作後的檔案內容，這些都可以直接當訓練獎勵，不需要另外建立評分模型。這種獎勵比模型自評硬，比人工標注便宜。ThinkingBox-Training 給了一個可操作的問法：你的任務的「正確終態」能被程式化嗎？如果能，獎勵函數已經在那裡了，只剩接線的工作。