Microsoft 与 Hugging Face 发布 ThinkingBox-Training，用数据库状态奖励训练 Agent

这是我们首篇博客文章《Agent 说任务已完成，数据库却不这么认为》的后续篇。ThinkingBox-Training 现已在GitHub上发布。

我们构建了 ThinkingBox，通过比较最终数据库状态与预期结果来评估智能体的工作。随后，我们在 ThinkingBox-Bench 之外的训练任务中，将同类可执行信号用作奖励。对于 Qwen3.8-27B，平均成功率从 51.70% 提升至 60.78%；在 50 个 GRPO 步骤后，二十次尝试均正确完成的任务从 38 个增至 107 个。

图 1. ThinkingBox 将对终端数据库状态的可执行检查转化为奖励，用于在 ThinkingBox-Bench 之外的任务上对智能体进行后训练。

这是 Microsoft 与 Hugging Face 联合发布的博客，特别感谢 Microsoft 的 Mirco Milletari 和 Xiang Jiang、Hugging Face 的 Sergio Paniego，以及我们的前实习生 Zhuochun Li（匹兹堡大学）参与共同撰写和审阅。

我们构建 ThinkingBox，是为了发现那些声称任务已完成、实际却没有完成的智能体。

ThinkingBox-Bench（我们的基准数据集）中的 507 个任务各自为智能体提供一个真实后端和一组工具，让它执行任务，然后检查数据库中实际发生了哪些变化。在首篇文章中，我们发现某个模型将客户工单标记为已解决，但背后的承运商异常仍处于未处理状态。九次看似专业的工具调用，却留下了一条错误的数据库记录。

随后我们意识到自己构建了什么。对于大多数任务，可执行检查可以直接根据最终数据库状态返回 1 或 0。这不仅仅是评分器。它可以成为奖励函数。⁺

于是，我们从基准测试之外的 ThinkingBox 格式任务中构建了一个训练池，并将这些任务的可执行结果用作奖励。难点在于选择哪些任务适合训练智能体：大多数任务要么模型已经能够解决，要么对当前模型来说难以企及，而这两类任务都无法教会模型任何东西。

任务难度取决于策略：对于当前模型而言，一项任务只有在模型学会它之前才算困难。

我们将此称为离线策略相对难度。我们在训练前使用基础策略估算每项任务的成功概率一次，并在整个训练过程中固定所选的训练池。

训练后的表现

我们使用离线策略相对难度构建训练池，然后通过 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 略高于经过 RL 微调的 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. 基础版和 RL 微调版 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 基础版在帕累托成本图上的位置移至 RLFT（菱形）：pass@1 从 51.70% 升至 60.78%，而每次成功尝试的预估成本从 0.177 美元降至 0.139 美元。带环圆点表示帕累托成本前沿。

这一变化使微调后的检查点接近 GPT-5.6 Sol，不过 GPT-5.6 Sol 仍然更便宜，且 pass@1 略高。我们在论文中列出的四个模型不在图表的显示范围内。

美元金额是用于比较的服务成本指标，并非发票金额或云服务账单。使用微调后的检查点进行服务的成本与基础模型相同。计算包含模型推理成本，不包含训练数据集整理所需的训练运行和策略探测成本。

这些结果告诉我们哪些方面发生了变化。接下来的章节将解释训练循环，以及为什么选择合适的任务最为重要。

训练循环

图 5。六个阶段现在一目了然：候选任务输入后，前 3 个阶段离线运行一次，后 3 个阶段则在训练运行中针对每个组重复执行。训练得到的检查点将根据 ThinkingBox-Bench 进行评估。

选择过程针对基础策略模型离线运行一次；在本例中，基础策略模型是 Qwen3.8 27B。随后，训练使用经过整理的固定任务池。图 5 中的琥珀色虚线箭头标示了我们没有采用的路径：在训练运行期间重新探测难度。

每次 rollout 都是一个完整回合，而非文本补全。它会获得一个全新的后端、一个隔离的 MCP 会话，以及由 GPT-5 Chat 扮演的模拟用户。大部分奖励来自确定性的终态检查；少数严格的评分标准要求可能会调用配置的评审模型（GPT-5 Chat）。

训练和评估必须以相同方式解读 Qwen 的输出。这包括推理提取、工具调用、参数类型、渲染以及隔离的任务状态。否则，奖励衡量的就不是评估时使用的那个智能体。共享的解读代码见 trainer/core/tb_interpret.py。

在参考运行中，我们使用 token 均值 GRPO，对 Qwen3.8-27B 进行全参数 RL 微调，任务数为 187。每次更新生成 18 组 rollout，每组 8 次，共 144 个回合，在 24 张 H100 上运行。训练以同步方式进行，并将参数和优化器卸载；AdamW 使用 1e-6 学习率，权重衰减为零。训练共运行 50 步。

训练期间，零方差组采用 DAPO 风格的方式替换。系统错误则单独处理：后端超时不代表智能体结果错误，因此会重新填充受影响的组，而不是将其记为失败。

这解释了保留下来的任务是如何参与训练的。剩下的问题是：哪些任务进入了训练池？

离线策略相对难度

在深入探讨训练任务的选择之前，先说明一点：

没有任何 ThinkingBox-Bench 任务被纳入 RL 训练池。该基准专用于评估。

相对于 RL 训练池，ThinkingBox-Bench 属于分布外数据：其领域、数据库、策略以及大多数工具在 RL 训练期间都未曾出现过。不过，两组任务仍共享 ThinkingBox 框架、模拟用户机制、可执行的终态评分方式、少数通用工具以及相似的任务风格。这些共有元素限制了迁移结论的适用范围。

任务选择之所以重要，归根结底在于 GRPO 的一个算术事实。如果 8 次 rollout 全部失败，奖励向量就是 [0, 0, 0, 0, 0, 0, 0, 0]。如果 8 次全部成功，奖励向量就是 [1, 1, 1, 1, 1, 1, 1, 1]。这两种情况下，在组内进行中心化都会使任务奖励优势为零，因为没有任何轨迹优于其他轨迹。⁺⁺

像 [0, 0, 0, 1, 1, 1, 1, 1] 这样的混合组能够提供 GRPO 可学习的对比信号。对于有状态智能体而言，这种区分代价高昂：每次 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。

在基准测试中，数据库评分器可以被视为“考官”：它抓出了那些报告成功、却留下错误记录的智能体。在训练中，同类检查则可被视为不同且不重叠的一组任务上的“教师”。

两条奖励路径，一个二元判定

• 可执行检查（绝大多数）。当所需结果体现为终端状态或副作用时，确定性测试会接受或拒绝该结果；无需调用 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：合并检查点并运行 ThinkingBox-Bench 507 x 20。

开始之前

已在 Linux 和 WSL 上使用 Python 3.12 和 uv 进行测试。你需要配备兼容 CUDA/NCCL 栈的 NVIDIA GPU、本地 Qwen3.8-27B 检查点，以及用于模拟用户和评审器的 OpenAI 兼容端点。经过验证的参考配置使用 3 nodes x 8 H100 GPUs；较小的自定义配置取决于模型大小、上下文长度和 rollout 并发数。

公开示例任务列表用于测试接口。它并非报告运行所用的私有 187-task 训练池。请提供经授权且与公开基准集保持不相交的训练数据源。

安装

将三个仓库并排放置：

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 检出版本已验证，且没有损坏的依赖要求。之后不要再运行自动包同步：它可能会用原版 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 服务器，配置模拟用户和评审器，设置模型、任务列表、检查点和拓扑变量，并准备 Ray 集群。请通过运行时密钥注入来管理凭据，不要将其存入已提交的文件或 shell 历史记录。

分配训练作业前，使用指南中的 dry-run 命令：

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

该命令必须以零状态码退出，且不得启动 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 评估检查点

第一篇 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
• RL 训练：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 付出全部成本。