ThinkingBox-Training 開放 GitHub，將資料庫終態檢查用作智能體後訓練獎勵

這是我們首篇網誌文章的續篇：Agent 説已完成，資料庫卻不認同。ThinkingBox-Training 現已在 GitHub 上提供。

我們建立 ThinkingBox，透過比較最終資料庫狀態與預期結果，評估 Agent 的工作。其後，我們在 ThinkingBox-Bench 以外的訓練任務中，將同類可執行訊號用作獎勵。對 Qwen3.8-27B 而言，平均成功率由 51.70% 升至 60.78%；經過 50 個 GRPO 步驟後，全部 20 次嘗試均正確完成的任務數目由 38 增至 107。

圖 1。ThinkingBox 將對最終資料庫狀態的可執行檢查，轉化為 Agent 在 ThinkingBox-Bench 以外任務的後訓練獎勵。

這是 Microsoft 與 Hugging Face 合作撰寫的網誌，特別鳴謝 Microsoft 的 Mirco Milletari 和 Xiang Jiang、Hugging Face 的 Sergio Paniego，以及我們的前實習生 Zhuochun Li（University of Pittsburgh）協助撰寫及審閲。

我們建立 ThinkingBox，用來識別那些聲稱已完成、實際上卻未完成的 Agent。

ThinkingBox-Bench（我們的基準數據集）中的 507 項任務，各自為 Agent 提供真實的後端及一組工具，讓它執行工作，再檢查資料庫實際發生了甚麼變化。在首篇文章中，我們發現有個模型將客戶的服務單標記為已解決，但背後的承運商異常仍未結案。九次看似熟練的工具呼叫，卻讓資料庫中出現一筆錯誤記錄。

其後，我們意識到自己建立了甚麼。對大多數任務而言，可執行檢查都能直接根據最終資料庫狀態回傳 1 或 0。這不只是評分器。它可以成為獎勵函數。⁺

於是，我們從基準測試以外、採用 ThinkingBox 格式的任務中建立訓練任務池，並將可執行檢查的結果用作獎勵。難點在於判斷哪些任務適合用來訓練 Agent：大多數任務對當前模型而言，要麼已經能解決，要麼根本無法解決；兩者都無法帶來學習效果。

難度取決於策略：對當前模型而言，任務只會難到模型學會為止。

我們稱之為離線策略相對難度。訓練前，我們使用基礎策略估算一次每項任務的成功機率，並在整個訓練過程中固定所選的訓練任務池。

訓練後的結果

我們利用離線策略相對難度建立訓練任務池，然後以 GRPO 對 Qwen3.8-27B 微調 50 個步驟。重温一下，我們對 507 項基準測試任務各評估 20 次。pass@1 衡量全部 10,140 次嘗試的平均成功率。pass@20 衡量至少成功一次的任務比例。實測 20/20 衡量所有已記錄的嘗試均成功的任務比例。

表 1。Qwen3.8-27B 在離線選出的訓練任務池上進行 50 個 GRPO 步驟前後的結果。

訓練大幅提升可重複成功率，但至少成功一次的任務覆蓋率略有下降。本文下文將説明我們如何挑選練習任務、建立獎勵迴路，以及衡量這項取捨。

這項提升在單一任務上是怎樣的？ 一名旅客要求降低房間級別，但公司政策規定必須先取得經理批准。訓練前，代理在 20 次嘗試中有 15 次未經批准便更改預訂並發出退款。經過 RL 微調後，代理在全部 20 次嘗試中均保留了預訂及付款狀態。

圖 2. 一項企業酒店預訂任務，每個模型嘗試 20 次。基礎 Qwen3.8-27B 模型有 15 次未經所需的經理批准便更改預訂。經過 RL 微調的模型在全部 20 次嘗試中均保留了預訂及付款狀態；其中 19 次的所有預期記錄均相符。

目錄

1. 基準測試結果：六十秒速覽
2. 結果：可靠性欄有所提升
3. 提升體現在哪些方面
4. 可靠性要付出甚麼代價
5. 訓練流程
6. 離線的相對政策難度
7. 如何獲得獎勵
8. 執行訓練堆疊
9. 下一步發展方向

趕時間？主要結果已在上文。實作詳情見執行訓練堆疊。

基準測試結果：六十秒速覽

ThinkingBox-Bench根據代理留下的資料庫記錄為代理評分。其 507 項任務各自啟動一個真實後端，向代理提供一組 MCP 工具，以及一個附有私人背景資料的模擬 LLM 用戶；任務結束時，系統會對最終資料庫狀態執行檢查。檢查針對的是需要正確無誤的後端記錄，而非特定工具呼叫。這會鼓勵模型探索可能的新解決路徑，而不是「重新發現」由人類提供、即使正確卻可能並非最佳的解決方案。

在我們的首篇文章中，我們讓十八個模型各自進行這項基準測試二十次，並報告了整體準確率掩蓋的差距。Kimi-K3 至少成功完成過一次的任務比例為 93.89%，但在 507 項任務中，只有 68 項（13.41%）能在全部二十次記錄的嘗試中完成。Claude Opus 5 的情況則相反：涵蓋範圍較窄，但一致性高得多。

更大型或更優秀的模型也未能縮小差距。Claude Opus 5.5 的 pass@1 比 Claude Opus 5 高出 0.66 個百分點，但在全部二十次嘗試中，兩者通過的任務數目完全相同，均為 241 項。這項整體準確率提升並未帶來任何額外可靠性。

如果你要為會處理正式環境資料庫記錄的工作選擇模型，不應只看 pass@1。實測 20/20 顯示哪些任務每次都能成功，這更接近正式環境對可靠性的要求。

可執行的最終狀態判定同時也是訓練獎勵。深入探討訓練流程前，先看看密封基準測試的結果有何變化。

結果：可靠性欄有所提升

訓練 Qwen3.8-27B 後，我們在模型從未用作訓練的 507 項任務基準測試上，評估了選定的第 50 步檢查點。這 507 項任務構成分佈外測試集：其領域、資料庫及大部分 MCP 工具在 RL 訓練期間均未曾出現。

表 2. ThinkingBox-Bench 各領域的 pass@1（%），涵蓋我們首篇網誌表 2中的指定模型，以及我們經微調的模型；列出各領域及整體結果。實測 20/20 數字以整個基準測試的 507 項任務為準。每個模型均對全部 507 項任務進行 20 次重複測試。粗體表示該欄最佳成績；底線表示次佳成績。

表 1 中最主要的結果，是實測 20/20 這一列。一個27B 模型最初在每次嘗試中只能完成 ThinkingBox-Bench 的 38 項（7.5%）任務，現在則能在每次嘗試中完成 107 項（21.1%），接近三倍。作為比較，Kimi-K3 的實測 20/20 數值為 68，GPT-5.4 為 128，GPT-6 Astra 為 231，而 Claude Opus 5.5 以 241 領先。

平均成功率與可重複性會得出不同的排序。在表 2 中，我們注意到，GPT-5.6 Sol 的 pass@1 略高於經強化學習微調的 Qwen3.8-27B（61.91% 對 60.78%），但在全部 20 次記錄的嘗試中均通過的任務較少：82 項對 107 項。Claude Sonnet 4.6 的 pass@1 較低，為 59.19%，但每次都通過的任務數量幾乎相同，為 102 項。單靠任何一項指標都無法呈現全貌。

觀察到的模式符合機率分佈鋭化的情況：可重複成功率上升，而至少成功一次的涵蓋率則略為下降。這與過往研究一致。一種解釋是，機率分佈轉向那些能反覆奏效的路徑，同時一些低機率路徑消失了。

模型涵蓋的任務範圍並沒有擴大，而是變得更能重複成功。接下來要問的是，這些增益出現在哪些領域。

增益出現在哪些領域

圖 3. 各領域的基礎模型分數、RLFT 分數及百分點變化。綠色變化欄表示提升，紅色欄表示下降；藍色底色表示各項指標中的分數水平。

五個領域的 pass@1 和實測 20/20 均有所上升。Pass@20 的結果則不一：虛擬銀行和顧問服務有所上升，但零售、旅遊和汽車保險則有所下降。汽車保險的涵蓋範圍降幅最大（−7.0 個百分點），而零售的實測 20/20 增幅最大（+24.5 個百分點）。

可靠性要付出甚麼代價

首篇貼文以簡單計算為一致性定價：將完整 20 次測試計劃的預計成本除以模型每次都能通過的任務數量。

每項可靠任務的成本 = 507 × 20 次測試計劃的預計成本 ÷ 20/20 通過的任務數

將相同的成本計算法套用於微調後檢查點的實測 token 用量：

表 3. 基礎模型和經強化學習微調的 Qwen3.8-27B 的預計評估成本與可靠性。每次成功嘗試的成本，以測試計劃總預計成本（507 x 20）除以通過的嘗試次數計算。

每項可靠任務成本為 $8.00，微調後模型的表現接近配套比較中的 GPT-5.4（$6.80）、GPT-6 Astra（$7.45）和 Claude Opus 5.5（$7.80）。

單次嘗試的視角

圖 4 比較每次成功嘗試的成本與 pass@1。

圖 4. 金色箭咀由 Qwen3.8-27B 基礎模型的 Pareto 成本位置指向 RLFT（菱形）：pass@1 由 51.70% 升至 60.78%，而每次成功嘗試的預計成本則由 $0.177 降至 $0.139。帶圓環的圓點標示 Pareto 成本前沿。

這一變化令微調後檢查點接近 GPT-5.6 Sol，但 GPT-5.6 Sol 的成本仍較低，pass@1 亦略高。我們在論文中列出成本的四個模型，則不在圖示範圍內。

美元數值是用作比較的推論服務指標，並非發票金額或雲端帳單。以微調後的模型檢查點提供推論服務，成本會與基礎模型相同。計算包括模型推論成本，但不包括訓練執行及用於整理訓練數據集的策略探測成本。

這些結果告訴我們哪些方面有所變化。以下章節會説明訓練流程，以及為何選出合適的任務最為重要。

訓練流程

圖 5. 六個階段的流程圖：候選任務輸入流程，首三個階段離線執行一次，最後三個階段則在訓練過程中的每一組都會重複執行。訓練後的模型檢查點會以 ThinkingBox-Bench 進行評估。

選取程序會以基礎策略模型離線執行一次；本例使用的是 Qwen3.8 27B。訓練其後會使用已整理好的固定任務池。圖 5 中的琥珀色虛線箭頭標示了我們沒有採取的做法：在訓練過程中重新探測難度。

每次 rollout 都是一個完整回合，而非文字續寫。它會使用全新的後端、獨立的 MCP 工作階段，以及由 GPT-5 Chat 模擬的用戶。大部分獎勵來自確定性的終止狀態檢查；少數範圍狹窄的評分規準要求，則可使用已設定的評判模型（GPT-5 Chat）。

訓練和評估必須以相同方式解讀 Qwen 輸出。這包括推理內容擷取、工具呼叫、引數類型、呈現方式，以及隔離的任務狀態。否則，獎勵衡量的 Agent 便會與評估時的 Agent 不同。共用的解讀程式碼位於 trainer/core/tb_interpret.py。

在參考訓練中，我們使用 token 平均 GRPO，對 Qwen3.8-27B 進行全參數 RL 微調，使用 187 個任務。每次更新會生成 18 組 rollout，每組 8 次，即 144 個回合，並在 24 張 H100 上執行。訓練以同步方式進行，並卸載參數和優化器；AdamW 使用 1e-6 的學習率，權重衰減為零。我們訓練了 50 步。

訓練期間，零方差羣組會以 DAPO-style 方式替換。系統錯誤則另行處理：後端逾時並不代表 Agent 的結果有誤，因此受影響的羣組會重新填補，而非計作失敗。

以上説明瞭如何訓練保留下來的任務。剩下的問題是：哪些任務進入了訓練池？

離線策略相對難度

在深入探討訓練任務的選取之前，先作一項聲明：

ThinkingBox-Bench 的任務並沒有納入 RL 訓練池。該基準測試只用於評估。

相對於 RL 訓練池，ThinkingBox-Bench 屬於分佈外資料：RL 訓練期間並未接觸其領域、數據庫、策略及大部分工具。兩組仍共用 ThinkingBox 框架、模擬用戶機制、可執行的終止狀態評分、少數常用工具，以及相近的任務風格。這些共通元素限制了遷移能力主張的適用範圍。

選取之所以重要，歸根究柢在於 GRPO 的一個算術事實。如果八次 rollout 全部失敗，獎勵向量就是 [0, 0, 0, 0, 0, 0, 0, 0]；如果八次全部成功，獎勵向量就是 [1, 1, 1, 1, 1, 1, 1, 1]。無論哪種情況，組內中心化都不會產生任務獎勵優勢，因為沒有任何一條軌跡的表現勝過另一條。⁺⁺

像 [0, 0, 0, 1, 1, 1, 1, 1] 這樣的混合羣組，能提供 GRPO 從中學習的對比訊號。對有狀態的 Agent 來説，取得這種差異的成本不低：每次 rollout 都要配置獨立的後端、執行真正的工具工作階段，並呼叫另一個模型來扮演用戶。

因此，塑造這項工作的問題不只是要用哪個模型或優化器？而是：哪些候選任務應納入固定的訓練池？

我們利用後驗分佈上的離線通過率篩選器來選取訓練池。這個篩選器會估計哪些任務在基礎策略下可能產生有對比的終端獎勵。

因此，我們進行探測。每個候選任務都會由基礎策略模型反覆執行。簡單來説：模型總是失敗的任務，現階段不太可能教會它新知；模型總是通過的任務，則已經學會；有時能解決的任務，才會產生可供學習的對比結果。

根據有限次探測估算難度

每個候選任務會執行 n 次，當中有 k 次成功。我們以 Jeffreys 後驗分佈建模其潛在成功機率：

在 n 次探測中成功 k 次時的成功機率 ~ Beta(k + ½, n − k + ½)

圖 6. 離線估算相對於策略的難度：透過重複探測基礎策略，保留可能產生對比獎勵的任務。

我們將單位區間分為五個區間，邊界設於 0.08、0.40、0.60 和 0.90；這些數值是本輪執行所選用的超參數。每項任務會分配至後驗機率質量最大的區間：

• 很少解決 [0, 0.08)： 捨棄
• 困難 [0.08, 0.40)： 保留
• 中等 [0.40, 0.60)： 保留
• 經常解決 [0.60, 0.90)： 保留供全參數 RLFT 使用
• 幾乎總能解決 [0.90, 1]： 捨棄

詳情請參閲我們的 ThinkingBox 論文附錄 C.4。

一項任務的完整流程

圖 7. 放大檢視一項任務經過全部六個階段的流程：GPT-5.4 篩選、基礎模型探測、難度分類、rollout 羣組、終端狀態評分，以及 GRPO 更新。

圖 7 展示一項可能納入訓練池的候選任務。對於 Qwen3.8 27B 全參數訓練池，GPT-5.4 首先用作可解性篩選器。接著，基礎策略只在少數探測中成功，例如 8 次中成功 3 次，得出 Beta(3.5, 5.5) 後驗分佈。其後驗機率質量最大的一部分（54.0%）落在「困難」區間。

抽樣用於訓練時，這項任務產生了混合獎勵組 [0, 0, 0, 0, 1, 1, 1, 1]。因此，成功軌跡獲得高於平均值的任務優勢，失敗軌跡則獲得低於平均值的優勢，讓 GRPO 有對比訊號可供學習。不同的策略模型可能會將同一項任務歸入不同的難度區間。

最終，Qwen3.8-27B 的精選訓練池包含 187 項任務。

甚麼會獲得獎勵

獎勵不取決於軌跡本身，而是任務自身可執行的判定結果。

每當回合結束，沙盒就會擷取後端實際發生的變更，並根據終端狀態執行任務的確定性檢查。任何產生正確最終狀態的軌跡都會通過。錯誤、遺漏或多出的副作用都會判定為失敗。獎勵只有 1 或 0。

在基準測試中，可以把資料庫評分器視為「考官」：它能識破那些聲稱成功、但留下錯誤記錄的 Agent。在訓練中，同類檢查則可視為「教師」，用於另一組互不重疊的任務。

兩條獎勵路徑，一個二元判定

• 可執行檢查（佔絕大多數）。如果所需結果可從最終狀態或副作用中判定，確定性測試便可判定通過或不通過；毋須呼叫 LLM 評審。
• LLM 評審輔助檢查（佔少數）。如果無法單憑資料庫狀態明確判定某項具體要求，設定好的 LLM 評審便會回答一條二元評分準則問題，供可執行測試使用。

執行訓練堆疊

我們公開了用於訓練 Qwen3.8-27B 的資料選取、rollout、獎勵及 Verl 整合，位於 microsoft/thinkingbox-training。儲存庫的 README 是入門指南。詳細指南如下：

• docs/data-preparation.md：任務資料準備、策略探測、排除基準測試，以及訓練集／驗證集切分；
• docs/reference-q38-run.md：已驗證的 24 張 H100 配置，用於 Qwen3.8；
• docs/evaluation.md：合併 checkpoint 並執行 ThinkingBox-Bench 507 x 20。

開始之前

已在 Linux 和 WSL 上使用 Python 3.12 及 uv 測試。你需要配備相容 CUDA/NCCL 堆疊的 NVIDIA GPU、本機 Qwen3.8-27B checkpoint，以及供模擬用戶和評審使用的 OpenAI 相容端點。已驗證的參考配置使用 3 個節點 x 8 張 H100 GPU；較小的自訂配置則視乎模型大小、上下文長度及 rollout 並行數而定。

公開的樣本任務清單用於測試介面，並非報告結果所用的私人 187 項任務訓練集。請提供經授權的訓練資料來源，並確保其與公開基準測試互不重疊。

安裝

將三個儲存庫並排放置：

mkdir -p ~/thinkingbox-workspace
cd ~/thinkingbox-workspace

git clone https://github.com/microsoft/thinkingbox.git
git clone https://github.com/microsoft/thinkingbox-data.git
git clone --branch main https://github.com/microsoft/thinkingbox-training

git -C thinkingbox checkout 892964e7226044e5463ad188da119df838f4bec1
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

建立已驗證的環境

已公開的堆疊以 Linux、Python 3.12、Verl 0.9.0 及已固定版本的套件鎖定檔為目標：

cd ~/thinkingbox-workspace/thinkingbox-training

uv venv --python 3.12
source .venv/bin/activate

uv sync --frozen --extra fast --extra tracking --extra eval-proxy
uv pip install -e ../thinkingbox
uv pip install --config-settings editable-mode=compat \
  -e ../thinkingbox-data/servers/thinkingbox_tools
uv pip install --config-settings editable-mode=compat \
  -e ../thinkingbox-data/servers/tb_business_ops_servers_202606

python scripts/prepare_verl.py --dest .deps/verl --install
python scripts/verify_verl_install.py
uv pip check

最後兩條命令應顯示已驗證的 Verl 修補版 checkout，且沒有損壞的依賴項。之後不要再執行自動套件同步，否則可能會以原版 Verl wheel 取代已修補的來源安裝。

準備訓練資料

你可以從公開提供的樣本開始，或在 ThinkingBox 格式中加入自己的授權數據集。然後執行儲存庫的準備指令碼：

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
python data/prepare_data.py --help

指令碼會彙整策略探測資料、套用離線的策略相對難度篩選及基準測試排除條件，並寫入選取後的 train.yaml 和 test.yaml 檔案。docs/data-preparation.md 説明輸入欄位、載入器規格及完整指令。

設定並檢查啟動程序

按照 docs/reference-q38-run.md 啟動 Typesense 和 MCP 伺服器、設定模擬用戶和評審、設定模型、任務清單、checkpoint 及拓撲變數，並準備 Ray 叢集。請透過執行時機密資料注入提供憑證，不要將憑證放在已提交的檔案或 shell 歷史記錄中。

分配訓練工作之前，請使用指南中的 dry-run 指令：

DRY_RUN=true ./scripts/run_train.sh \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

指令必須以 0 結束，而且不得啟動 Ray 或分配 GPU。啟動訓練前，請檢查輸出的 python -m verl.trainer.main_ppo 指令及所有解析後的覆寫設定。

訓練

啟動器負責設定訓練，不會佈建主機。在三節點的參考拓撲上，請在每個節點匯出相同的環境變數，並將 CHECKPOINT_DIR 掛載至相同的絕對路徑，然後啟動 Ray：

# head node
ROLE=head NODE_IP="$HEAD_IP" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

# each worker node
ROLE=worker NODE_IP="$WORKER_IP" \
  HEAD_ADDRESS="$HEAD_IP:6379" GPUS_PER_NODE=8 \
  ./scripts/start_ray.sh

待 ray status 顯示全部 24 張 GPU 後，從頭節點啟動一次：

export RAY_ADDRESS=auto
export GPUS=0,1,2,3,4,5,6,7

./scripts/run_train.sh \
  trainer.project_name=thinkingbox-training \
  trainer.experiment_name=q38-full-rlft \
  trainer.total_training_steps=50 \
  trainer.save_freq=5

透過 OpenEnv 評估 checkpoint

第一篇 ThinkingBox 文章介紹 Typesense、MCP Session Proxy，以及 OpenEnv 的設定。按照docs/evaluation.md合併訓練檢查點，然後使用 vLLM 提供服務。

在 OpenEnv 程式碼庫根目錄中，將 MERGED_MODEL 設為合併後模型的目錄，並將 THINKINGBOX_DATA 設為已鎖定版本的基準測試程式碼庫。歷史檢查點評估採用以下八張 A100 的服務設定：

vllm serve "$MERGED_MODEL" \
  --served-model-name q38-rlft \
  --host 127.0.0.1 \
  --port 8001 \
  --tensor-parallel-size 8 \
  --dtype bfloat16 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.85 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 8192 \
  --language-model-only \
  --enable-chunked-prefill \
  --enable-prefix-caching \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml

在另一個終端機中，從 ThinkingBox Training 程式碼庫啟動適用於 Qwen 聊天範本的 OpenEnv 相容性代理伺服器。它會監聽連接埠 8014，並將請求轉送至連接埠 8001 上的 vLLM：

cd ~/thinkingbox-workspace/thinkingbox-training
source .venv/bin/activate
bash scripts/launch_sysmerge.sh

評估期間請保持代理伺服器運作。在另一個終端機中檢查是否已就緒：

curl --fail http://127.0.0.1:8014/readyz

更新現有 thinkingbox.yaml 中的 agent 項目；保留其 MCP、模擬用戶及評判器設定：

orchestrator:
  agent_model:
    type: aoai
    endpoint_url: http://127.0.0.1:8014/v1/chat/completions
    deployment: q38-rlft
    credential:
      type: api-key
      api_key: <your_api_key>
    is_reasoning: true
    temperature: 1.0
    top_k: 20
    top_p: 0.95
    max_completion_tokens: 8192
    timeout: 1800

按照第一篇文章中的方式啟動 OpenEnv，將 OPENENV_TB_CONFIG 指向這個 thinkingbox.yaml，並將 OPENENV_TB_DATASET 指向 $THINKINGBOX_DATA。/ready 成功後，執行完整協定：507 項任務 × 20 次嘗試：

uv run --project envs/thinkingbox_env --frozen \
  thinkingbox-eval \
  --config "$PWD/thinkingbox.yaml" \
  --base-url http://127.0.0.1:8000 \
  --dataset "$THINKINGBOX_DATA" \
  --output q38-rlft-full.jsonl \
  --errors-output q38-rlft-full-errors.jsonl \
  --repeat 20 \
  --coverage-profile full \
  --aggregate-output q38-rlft-full-aggregate.json \
  --message-timeout 1800

full 設定檔會在彙總前驗證所有 10,140 個預期的任務／重複次數鍵。

後續方向

這項工作的價值不在於某個 Qwen3.8-27B 檢查點，而在於訓練循環及訓練資料整理，將可執行結果轉化為獎勵。

如果你正在訓練或評估會接觸真實資料庫紀錄的 Agent：

1. 訓練前先探測。使用自己的 Agent 任務集，讓基礎策略執行 n 次，然後查看分段直方圖。根據我們的經驗，團隊往往沒有檢視這種分佈，而實際分佈通常比預期更不均衡。
2. 檢查一致性。將同一份已記錄的模型輸出分別交由訓練和評估解析器處理，並確認兩者擷取的工具名稱和參數完全相同。否則，訓練可能獎勵某種行為，但評估對該行為的解讀卻有所不同。
3. 同時報告覆蓋率和可重複性。説明在 k 次嘗試中至少通過一次的任務數目，以及在全部 k 次嘗試中均通過的任務數目。模型偶爾找到解決方法，不代表它能穩定地重複做到。

詳情請參閲以下連結：

• 環境：envs/thinkingbox_env
• OpenEnv：ThinkingBox 環境文件
• 框架：microsoft/thinkingbox · 教學
• 基準測試：microsoft/thinkingbox-data · v1.0 發佈版本
• 數據集檢視器：microsoft/ThinkingBox-Bench
• 論文：arXiv:2608.19741 或 HF
• 強化學習訓練：microsoft/thinkingbox-training
• 網誌：Agent 説已完成，資料庫卻不認同。

引用論文

@article{li2026thinkingbox,
  title   = {One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows},
  author  = {Li, Zhuochun and Ko, Youngmin and Keramati, Ali and Kundu, Tuhin and
             Tsai, Liang-Chun and Ferri, Nicola and Milletari, Mirco and Liu, Jiaxiang and
             Lopez Pelaez, Susana Palmaz and Wang, Yuepeng and Smolyakov, Vadim and
             Jiang, Xiang and Olafsson, Kjartan and Guy, Tommy},
  journal = {arXiv preprint arXiv:2608.19741},
  year    = {2026},
  url     = {https://arxiv.org/abs/2608.19741}
}

ThinkingBox 程式碼採用 MIT 授權；基準測試數據採用 CDLA-Permissive-2.0 授權。

免責聲明：公開基準測試中的每項任務都是合成重建。工作流程和政策以真實企業 Agent 模式為藍本；客戶並非真實存在。

ThinkingBox、ThinkingBox-Bench 和 ThinkingBox-Training 由 Microsoft Copilot Studio 團隊與 Toloka 合作開發，並有來自匹茲堡大學、西北大學、哥倫比亞大學及加州大學爾灣分校、曾在 Microsoft 實習的合作夥伴參與。歡迎在下方留言區、github 或透過電郵 firstnamelastname@microsoft.com 提出問題。

⁺ 少數任務亦包括一些狹義的二元評分規準要求，資料庫無法清晰記錄這些要求的結果；相關檢查可調用已設定的 LLM 評審。

⁺⁺ 這個零梯度問題有一個標準的批次處理解決方法：過度抽樣、丟棄退化羣組，再補滿。全參數執行正是這樣做，與 DAPO 替換零變異羣組的做法相似。但補滿仍要為每次浪費的 rollout 付出全額代價，然後才將它丟棄。