Microsoft 与 Hugging Face 用 ThinkingBox 把数据库评分变成 RL 奖励训练 Agent

Hugging Face 社区博客·2026-10-23 06:24· 1 小时前AI 评分51

将数据库评分转化为 RL 奖励：使用 ThinkingBox 训练后智能体

AI 导读

Microsoft 与 Hugging Face 发布 ThinkingBox-Training，将智能体任务终态数据库的可执行检查用作 RL 奖励，代码已在 GitHub 开源。

正文 · 原文

这是我们第一篇博客文章 The Agent Said It Was Done. The Database Disagreed. 的后续。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 个任务，每个都会给智能体一个真实后端和一组工具，让它工作，然后检查数据库中真正发生了什么变化。在第一篇文章中，我们发现一个模型将客户的工单关闭为 resolved，而背后的承运商异常仍然处于开放状态。九次看似合格的工具调用，一行 错误 的数据库记录。

然后我们注意到了自己所构建的东西。对于大多数任务，可执行检查可以直接根据最终数据库状态返回 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 任务基准测试上评估了选定的第 50 步检查点。这 507 个任务代表一个分布外测试集：它们的领域、数据库和大多数 MCP 工具在 RL 训练期间均未遇到。

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

核心结果是表 1 中的 observed-20/20 行。一个27B 模型最初在每次尝试中完成 ThinkingBox-Bench 的 38 个（7.5%），现在每次尝试完成 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。单独任何一个指标都无法完整反映全貌。

观察到的模式与锐化一致：可重复的成功上升，而至少一次覆盖略有下降。这与先前工作一致。一种解释是概率分布向可重复工作的轨迹移动，而一些低概率路径消失了。

总体而言，模型并没有变得更广。它变得更具可重复性。下一个问题是这些收益落在了哪里。

收益落在了哪里

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

对于参考运行，我们使用 token-mean GRPO 在 187 个任务上对 Qwen3.8-27B 进行了全参数 RL 微调。每次更新在 24 块 H100 上生成 18 组、每组 8 次 rollout，即 144 个回合。训练同步运行，并采用参数和优化器卸载；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 后验概率对其潜在成功概率建模：

成功概率 | 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。

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

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

• 可执行检查（占绝大多数）。当所需结果体现在终端状态或副作用中时，由确定性测试接受或拒绝；无需调用 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 个节点 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 后，从 head 节点启动一次：

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、模拟用户和 judge 配置：

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
• 博客： 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 合作构建，合作者包括曾在 Microsoft 实习的匹兹堡大学、西北大学、哥伦比亚大学和 UC Irvine 的研究人员。欢迎在下方评论区、github 或通过电子邮件 firstnamelastname@microsoft.com 提问。

⁺ 少数任务还包含针对数据库无法清晰捕获的结果的窄范围二元评分标准要求；这些检查可以调用已配置的 LLM 评判器。

⁺⁺ 该零梯度问题有一个标准的批处理时修复方法：过采样、丢弃退化组、重新填充。全参数运行正是这样做的，类似于 DAPO 对零方差组的替换。但重新填充仍然要为每个被丢弃的 rollout 支付全额成本。

来源：Hugging Face 社区博客 · huggingface.co