Microsoft 与 Hugging Face 发布 ThinkingBox-Training，用数据库终态校验作为 RL 奖励后训练智能体

本文是我们第一篇博客《智能体说它完成了。数据库却不同意。》的后续。ThinkingBox-Training 现已在 GitHub 上发布。

我们构建 ThinkingBox,通过将最终数据库状态与预期结果进行对比来评估智能体的工作。随后,我们将同类可执行信号用作 ThinkingBox-Bench 之外训练任务上的奖励。对于 Qwen3.8-27B,在 50 步 GRPO 训练后,平均成功率从 51.70% 提升到 60.78%,而在全部二十次尝试中均正确完成的任务数量从 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 衡量至少解决一次的任务占比。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 用户，并在最后对最终数据库状态运行可执行检查。检查针对的是需要保持正确的后端记录，而不是具体的工具调用。这激励模型去发现可能是全新的解决路径，而不是“重新发现”基于人工设计的解法——后者即使正确，也可能是次优的。

在我们的第一篇文章中，我们让十八个模型各跑该基准二十次，并报告了表面准确率所掩盖的差距。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 任务基准上评估了选定的 step-50 检查点。这 507 个任务构成一个分布外测试集：它们的领域、数据库和大多数 MCP 工具在 RL 训练期间都未出现过。

表 2. ThinkingBox-Bench 按领域统计的 pass@1（%），包括来自我们第一篇博客表 2 的选定模型以及我们微调后的模型在不同领域和整体上的表现。Observed 20/20 数字基于包含 507 个任务的整个基准测试。每个模型在全部 507 个任务上进行 20 次重复试验。加粗标记列领先者；下划线标记第二名。

核心结果是表 1 中的 observed-20/20 行。一个最初每次尝试都只能完成 ThinkingBox-Bench 中 38 道（7.5%）题目的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 则喜忧参半：在 neobank 和 consulting 中上升，但在 retail、travel 和 auto insurance 中下降。Auto insurance 的广度损失最大（−7.0 分），而 retail 的 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。

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

零方差组在训练期间按 DAPO 风格进行了替换。系统错误则单独处理：后端超时并不代表智能体结果错误，因此受影响的组会被重新填充，而不是计为失败。

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

离线的策略相对难度

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

RL 训练池中不包含任何 ThinkingBox-Bench 任务。该基准被保留用于评估。

ThinkingBox-Bench 相对于 RL 训练池属于分布外数据：它的领域、数据库、策略以及大多数工具在 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 可以学习的对比信号。对于一个有状态的智能体而言，这种区分的代价很高：每一次 rollout 都要配置一个隔离的后端，运行真实的工具会话，并调用一个单独的模型来扮演用户。

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

我们使用基于后验的离线通过率过滤器来选择训练池。它用于估计哪些任务在基础策略下可能产生具有对比性的终端奖励。

于是我们进行探测。每个候选任务都会对基础策略模型重复运行多次。用通俗的话说，规则很简单：模型总是失败的任务暂时难以教会它；总是通过的任务已经学会；时而能解出的任务，才是结果能提供对比的地方。

从有限探测中估计难度

每个候选任务运行 n 次，产生 k 次成功。我们用 Jeffreys 后验概率对其潜在成功概率建模：

success 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 个任务。

什么才能赢得奖励

与轨迹无关。奖励是任务自身可执行的判定。

当一个回合结束时，沙箱会提取后端中实际发生变化的内容，并针对终端状态运行任务的确定性检查。任何产生正确终端状态的轨迹都通过。错误、缺失或多余的副作用都判为失败。奖励为 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。

开始之前

已在 Linux 和 WSL 上使用 Python 3.12 和 uv 完成测试。你需要带有兼容 CUDA/NCCL 栈的 NVIDIA GPU、本地的 Qwen3.8-27B 检查点，以及用于模拟用户和裁判的 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 检出，且没有任何损坏的依赖。此后不要再运行其他自动软件包同步：它可能会用原版 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=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 会话代理和 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 中的智能体条目；保留其 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 检查点，而是将可执行结果转化为奖励的训练循环和训练数据策展。

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

1. 训练前先探测。拿你自己的智能体任务集，用基础策略对其运行 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
• 博客： 智能体说任务完成了，数据库却不同意。

引用论文

@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 上提问，或发送邮件至 [email protected]。

⁺ 少数任务还包含针对结果的窄范围二值化评分规则（rubric），用于处理数据库无法清晰捕获的情况；这些检查可以调用已配置的 LLM 评判器。

⁺⁺ 这个零梯度问题有一个标准的训练时修复方法：过采样、丢弃退化分组、再补充。全参数运行正是这样做的，类似于 DAPO 中替换零方差分组的做法。但在丢弃之前，每一条被浪费的 rollout 仍然付出了全额代价。