微软与 Hugging Face 用 ThinkingBox 数据库校验作 RL 奖励训练智能体

这是我们第一篇博客文章的续篇，代理说完成了。数据库不同意。ThinkingBox-Training 现在可以在 GitHub 上获取。

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

图 1. ThinkingBox 将终端数据库状态的可执行检查转换为 ThinkingBox-Bench 外部训练代理的奖励。

这是微软和 Hugging Face 联合撰写的博客，特别感谢微软的 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用户，并在结束时对终端数据库状态运行可执行检查。检查是针对需要正确的后端记录，而不是特定的工具调用。这激励模型发现可能的新解决方案路径，而不是“重新发现”可能次优但正确的手动支持解决方案。

在我们的第一篇帖子中，我们让18个模型通过该基准测试各运行20次，并报告了头条准确率隐藏的差距。Kimi-K3解决了93.89%的任务 至少一次，但在 所有二十次记录的尝试中仅完成了68个中的507个任务（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模型最初在每次尝试中完成了38 (7.5%) 的ThinkingBox-Bench，现在在每次尝试中完成了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的任务数量

将相同的成本数学应用于微调检查点的测量令牌使用情况：

表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基准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中的虚线琥珀色箭头标记了我们未采取的路径：在训练运行期间重新探测难度。

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

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

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

零方差组在训练期间使用DAPO-style替换。系统错误单独处理：后端超时不是错误的代理结果，因此受影响的组被重新填充而不是作为失败评分。

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

离线策略相对难度

在深入训练任务选择之前，有一个免责声明：

没有ThinkingBox-Bench任务包含在RL训练池中。 基准用于评估。

ThinkingBox-Bench相对于RL训练池是分布外：它的领域、数据库、策略和大多数工具在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 后验概率对其潜在成功概率进行建模：

成功概率 | 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 筛选、基础模型探测、难度分类、一个展开组、终端状态评分和 GRPO 更新。

图 7 跟踪一个可能进入训练池的候选任务。对于 Qwen3.8 27B 全参数池，GPT-5.4 首先作为可解性筛选器。基础策略在探测中很少成功，例如 3/8，产生了一个 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 的数据选择、回滚、奖励和 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 进行测试。您需要兼容的 NVIDIA GPU 和 CUDA/NCCL 堆栈、本地 Qwen3.8-27B 检查点，以及用于模拟用户和判决者的 OpenAI 兼容端点。经过验证的参考配置使用 3 个节点 x 8 H100 GPU；较小的自定义配置取决于模型大小、上下文长度和回滚并发。

公共样本任务列表锻炼了接口。它不是用于报告运行的私人 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 轮替换修补的源安装。

准备训练数据

从公开提供的样本开始，或者以 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 评估检查点

The 第一篇 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 检出，启动 OpenEnv 兼容代理用于 Qwen 聊天模板。它在端口 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
• 博客： 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 或通过电子邮件 [email protected] 提问。

⁺ 少数任务还包括狭窄的二进制评分标准要求，这些要求数据库无法清晰捕获；这些检查可以调用配置的 LLM 判定器。

⁺⁺ 这个零梯度问题有一个标准的批处理时间修复方法：过采样，丢弃退化组，重新填充。完整参数运行确实那样做了，类似于 DAPO 替换零方差组。但是重新填充仍然为每个在丢弃之前浪费的运行支付了全部价格。