Microsoft 与 Hugging Face 发布 ThinkingBox-Training：用数据库评分训练 Agent

这是我们第一篇博客文章的后续：The Agent Said It Was Done. The Database Disagreed.。ThinkingBox-Training 现已在 GitHub 上线。

我们构建了 ThinkingBox，通过比较最终的数据库状态与预期结果来评估 Agent 的工作。然后，我们使用这种可执行信号作为 ThinkingBox-Bench 之外训练任务的奖励。对于 Qwen3.8-27B，平均成功率从 51.70% 提升至 60.78%，而在全部二十次尝试中均正确完成的任务在经过 50 步 GRPO 后从 38 个增加到了 107 个。

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

这是微软与 Hugging Face 共同撰写的博客，特别感谢来自微软的 Mirco Milletari 和 Xiang Jiang、来自 Hugging Face 的 Sergio Paniego，以及我们的前实习生 Zhuochun Li（匹兹堡大学）在共同撰写和审阅方面做出的贡献。

我们构建 ThinkingBox 是为了揪出那些声称已完成任务但实则不然的 Agent。

ThinkingBox-Bench（我们的基准数据集）中的 507 个任务各自分配给 Agent 一个真实的后端和一套工具，让它自主工作，然后检查数据库中真正发生了什么变化。在上一篇文章中，我们发现某个模型将客户的工单关闭为已解决状态，而其背后的运营商异常却依然处于打开状态。九次看似能干的工具调用，却带来了一条错误的数据库记录。

接着我们注意到了自己构建的东西。对于大多数任务，可执行检查可以直接根据最终的数据库状态返回 1 或 0。这不仅仅是一个评分器。这可以是一个奖励函数。⁺

因此，我们利用基准之外的 ThinkingBox 格式任务构建了一个训练池，并使用它们的可执行结果作为奖励。其中的关键在于选择哪些任务适合用于 Agent 训练：大多数任务对于当前的模型来说要么已经迎刃而解，要么毫无胜算，而这两种任务都无法教给它新东西。

难度是与策略相关的：一项任务对于当前模型而言之所以困难，仅在于该模型掌握它之前。

我们称之为离线策略相对难度（offline policy-relative difficulty）。我们在训练前使用基础策略对每个任务的成功概率进行了单次估计，并在整个运行过程中保持所选的训练池固定。

训练后发生了什么

我们利用离线策略相对难度构建了训练池，然后使用 GRPO 对 Qwen3.8-27B 进行了 50 步的微调。简要回顾一下，我们对 507 个基准任务中的每一个都进行了 20 次评估。pass@1 衡量的是所有 10,140 次尝试的平均成功率。pass@20 衡量的是至少被解决过一次的任务占比。Observed 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 用户，并在结束时针对终端数据库状态运行可执行检查。检查是针对需要正确的后端记录，而不是特定的工具调用。这激励模型去发现可能的新解决方案路径，而不是“重新发现”人工支持的、可能虽正确但并非最优的解决方案。

在我们的第一篇文章中，我们让 18 个模型各自通过该基准测试 20 次，并指出了主标题准确率所掩盖的差距。Kimi-K3 至少成功一次 的任务占 93.89%，但在 全部 20 次记录的尝试中 仅完成了 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 个任务基准测试上评估了所选的 step-50 检查点。这 507 个任务代表了一个分布外测试集：它们的领域、数据库以及大多数 MCP 工具在 RL 训练期间都未曾遇到过。

表 2. 选自我们第一篇博客的表 2的精选模型以及我们针对不同领域及整体的微调模型的 ThinkingBox-Bench pass@1（%）按领域分布。观察到的 20/20 数据涵盖包含 507 个任务的整个基准测试。每个模型都在所有 507 个任务上进行了 20 次重复试验的评估。粗体标记列领先者；下划线标记亚军。

最核心的结果是表 1 中的 observed-20/20 这一行。一个原本在每次尝试中完成 38 个（7.5%）ThinkingBox-Bench 任务的 27B 模型，现在每次尝试能完成 107 个（21.1%），几乎达到了原来的三倍。相比之下，Kimi-K3 的 observed 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 个。单一指标都无法全面反映情况。

观察到的模式与尖锐化（sharpening）一致：可重复的成功率上升，而至少成功一次的覆盖率略有下降。这与先前的研究相符。一种解释是，概率分布向能够重复奏效的轨迹倾斜，同时一些低概率的路径消失了。

总体而言，模型的广度并没有扩大，而是可重复性变得更高。接下来的问题是这些增益落在了哪里。

增益的分布位置

图 3. 领域级基础得分、RLFT 得分及百分点变化。绿色变化单元格表示增长，红色单元格表示下降；蓝色阴影表示每个指标内的得分水平。

Pass@1 和 observed 20/20 在所有五个领域中均有所上升。Pass@20 则表现不一：它在新银行和咨询领域有所增加，但在零售、旅游和汽车保险领域有所下降。汽车保险的广度损失最大（−7.0 个百分点），而零售的 observed-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. 六个阶段的背景说明：候选任务输入，前三个在离线状态下运行一次，后三个在训练运行中的每个组重复执行。训练后的检查点将针对 ThinkingBox-Bench 进行评估。

选择过程针对基础策略模型（即本例中的 Qwen3.8 27B）在离线状态下运行一次；然后训练使用已经策划好的固定池。图 5 中的琥珀色虚线箭头标记了我们没有采用的路径：在训练运行期间重新探测难度。

每次展开（rollout）都是一个完整的片段，而不是文本补全。它会获得一个新的后端、一个隔离的 MCP 会话以及作为模拟用户的 GPT-5 Chat。大多数奖励来自确定性的终端状态检查；少数狭窄的评分标准要求可以调用配置的评判器（GPT-5 Chat）。

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

对于参考运行，我们在 187 个任务上使用基于 token 平均的 GRPO，对 Qwen3.8-27B 进行了全参数 RL 微调。每次更新在 24 个 H100 上生成 18 组，每组 8 次展开（共 144 个片段）。训练与参数和优化器卸载同步进行；AdamW 使用了 1e-6 的学习率和零权重衰减。我们进行了 50 步的训练。

零方差组在训练期间被仿照 DAPO 的方式替换。系统错误被单独处理：后端超时并非不正确的智能体结果，因此受影响的组会被重新填充，而不是被计为失败。

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

离线策略相对难度

在深入探讨训练任务的选择之前，先作一个免责声明：

没有任何 ThinkingBox-Bench 任务被包含在 RL 训练池中。该基准测试专为评估保留。

相对于 RL 训练池，ThinkingBox-Bench 是分布之外的：其领域、数据库、策略以及大多数工具在 RL 训练期间都未曾遇到。这两组数据仍然共享 ThinkingBox 框架、模拟用户机制、可执行的终端状态评分、一些常用工具以及相似的任务风格。这些共享元素限制了迁移声明的范围。

为什么选择至关重要，归根结底是关于 GRPO 的一个算术事实。如果所有八次展开都失败，奖励向量就是 [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 可以从中学习的对比。对于有状态的智能体而言，这种区分成本高昂：每次展开都会配置一个隔离的后端、运行一个真实的工具会话，并调用单独的模型来扮演用户。

因此，塑造成这项工作的核心问题不仅是哪个模型或优化器？而是：哪些候选任务应该进入固定的训练池？

我们对后验概率使用了离线通过率过滤来选择训练池。它用于评估哪些任务在基础策略下可能会产生对比鲜明的终止奖励。

因此我们进行探测。每个候选任务都会针对基础策略模型进行反复运行。通俗易懂的规则很简单：模型总是失败的任务暂时教不会它；总是通过的任务已经学会了；有时能解决的任务，其结果能够提供对比。

从有限的探测中估计难度

每个候选任务运行 n 次，产生 k 次成功。我们使用杰弗里斯后验概率（Jeffreys posterior probability）来对它的潜在成功概率进行建模：

成功概率 | 在 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 个任务。

什么能赢得奖励

与轨迹本身无关。奖励是任务自身的直接可执行判定结果。

当一个 episode 结束时，沙盒会提取后端实际发生的变化，并针对终端状态运行任务的确定性检查。产生正确终态的任何轨迹都能通过。错误、缺失或多余的副作用都会导致失败。奖励为 1 或 0。

在基准测试中，数据库评分器可以被视为“考官”：它抓住了那些报告成功却留下了错误记录的代理。在训练中，同类检查可以被视为在另一组不相交的任务上的“老师”。

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

• 可执行检查（占绝大多数）。当所需的结果表现为终态或副作用时，确定性测试会接受或拒绝它，无需调用 LLM 评判器。
• 评判器辅助检查（占少数）。当狭隘的需求无法从数据库状态中明确判定时，配置好的 LLM 评判器会回答可执行测试所使用的二元评分规则问题。

运行训练栈

我们在 microsoft/thinkingbox-training 中开源了用于训练 Qwen3.8-27B 的数据选择、 rollout、奖励和 Verl 集成。仓库 README 是入口。详细指南包括：

• docs/data-preparation.md 用于任务填充、策略探针、基准测试排除以及训练/验证集划分；
• docs/reference-q38-run.md 用于经过验证的 24-H100 Qwen3.8 配置；
• docs/evaluation.md 用于合并检查点并运行 ThinkingBox-Bench 507 x 20。

开始之前

已在配备 Python 3.12 和 uv 的 Linux 和 WSL 上进行测试。你需要拥有具备兼容的 CUDA/NCCL 栈的 NVIDIA GPU、本地 Qwen3.8-27B 检查点，以及用于模拟用户和评判器的兼容 OpenAI 的端点。经过验证的参考配置使用 3 个节点 × 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 检出版本且没有损坏的依赖项。之后不要运行其他自动软件包同步：它可能会将打过补丁的源码安装替换为原版的 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 合并训练好的 checkpoint，然后使用 vLLM 提供服务。

从 OpenEnv 仓库根目录开始，将 MERGED_MODEL 设置为合并后的模型目录，将 THINKINGBOX_DATA 设置为锁定的基准测试 checkout。历史 checkpoint 评估使用了以下八个 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 checkout 启动针对 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 中的智能体条目；保留其 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 checkpoint，而在于将可执行结果转化为奖励的训练循环和训练数据筛选。

如果你正在训练或评估触及真实数据库记录的智能体：

1. 训练前先探测。获取你自己的智能体任务集，针对它运行基准策略 n 次，并查看区间直方图。根据我们的经验，团队通常没有检查过这种分布，而且它通常比预期的更加偏斜。
2. 检查一致性。通过训练和评估解析器重放相同的记录模型输出，并验证两者提取的工具名称和参数是否完全相同。否则，训练可能会奖励评估时会被不同解释的行为。
3. 同时报告覆盖率和可重复性。说明在 k 次尝试中至少通过一次的任务数量以及通过所有 k 次的任务数量。偶尔能找到解决方案的模型并不一定能持续重复它。

更多详细信息可以在以下链接中找到：

• 环境： envs/thinkingbox_env
• OpenEnv： ThinkingBox environment documentation
• 框架： microsoft/thinkingbox · tutorial
• 基准测试： microsoft/thinkingbox-data · v1.0 release
• 数据集查看器： microsoft/ThinkingBox-Bench
• 论文： arXiv:2608.19741 或 HF
• 强化学习训练： microsoft/thinkingbox-training
• 博客： The Agent Said It Was Done. The Database Disagreed.

引用论文

@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。

免责声明：公共基准测试中的每个任务都是综合重构。工作流和策略以真实企业智能体模式为模型；客户并非真人。

ThinkingBox、ThinkingBox-Bench 和 ThinkingBox-Training 由 Microsoft Copilot Studio 团队与 Toloka 合作构建，合作者包括曾在微软实习的匹兹堡大学、西北大学、哥伦比亚大学和加州大学欧文分校的研究人员。欢迎在下方评论区或通过 github 或发送电子邮件至 firstnamelastname@microsoft.com 提出问题。

⁺ 少数任务还包括数据库无法完全捕获的结果的狭隘二元评分标准要求；这些检查可以调用配置好的 LLM 评判器。

⁺⁺ 该零梯度问题有一个标准的批次时间修复方法：过采样、丢弃退化组、重新填充。全参数运行正是这样做的，类似于带有零方差组替换的 DAPO。但重新填充仍然要为丢弃之前每一个浪费的展开支付全部成本。