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

这是我们第一篇博文《智能体说已完成。数据库却不同意》的后续。ThinkingBox-Training现已在GitHub上可用。

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

图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衡量每次记录尝试都通过的任务占比。

训练显著提高了可重复成功率，而至少一次覆盖率略有下降。本文其余部分解释了我们如何选择练习任务、构建奖励循环，以及如何衡量这种权衡。

这种改进在一个任务上是什么样的？一名旅客请求房间降级，但公司政策要求先获得经理批准。训练前，智能体在20次尝试中有15次在没有批准的情况下更改了预订并发放退款。RL微调后，它在全部20次中都保留了预订和支付状态。

图2. 一个企业酒店预订任务，每个模型20次尝试。基础Qwen3.8-27B模型在15次尝试中未获得所需经理批准就更改了预订。RL微调模型在全部20次中都保留了预订和支付状态；19次中所有预期记录均匹配。

目录

基准发现了什么，六十秒速览

结果：可靠性列发生了变化

收益落在何处

可靠性的代价

训练循环

离线策略相对难度

什么能获得奖励

运行训练栈

下一步走向何方

赶时间？标题结果就在上面。实现方法见“运行训练堆栈”。

基准测试在六十秒内发现的结果

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 训练期间并未遇到。

标题结果是表 1 中的观察到的 20/20 行。一个最初在每次尝试中完成 ThinkingBox-Bench 中 38 个（7.5%）任务的 27B 模型，现在在每次尝试中完成 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 则好坏参半：它在 neobank 和咨询中增加，但在零售、旅行和汽车保险中下降。汽车保险的广度损失最大（−7.0 点），而零售的观察到的 20/20 增益最大（+24.5 点）。

可靠性的代价是什么

第一篇文章使用简单数学为一致性定价：将完整 20 次运行活动的估计成本除以模型每次都通过的任务数量。

每个可靠任务的成本 = 507 × 20 活动的估计成本 ÷ 通过 20/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 都是一个完整的 episode，而不是文本补全。它获得一个新的后端、一个隔离的 MCP 会话，以及 GPT-5 Chat 作为模拟用户。大多数奖励来自确定性的终端状态检查；少数狭窄的评分标准要求可以调用配置的评判者（GPT-5 Chat）。

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

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

训练过程中，零方差组按 DAPO 方式被替换。系统错误单独处理：后端超时并不算智能体结果错误，因此受影响的组会被重新填充，而不是被记为失败。

以上说明了保留任务是如何训练的。剩下的问题是哪些任务进入了训练池。

离线策略相对难度

在深入讨论训练任务选择之前，先声明一点：

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

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

什么能获得奖励

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

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

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、simulated-user 和 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

完整配置文件在聚合前验证所有 10,140 个预期的任务/重复键。

下一步发展方向

这项工作的有用部分不是一个 Qwen3.8-27B 检查点。而是将可执行结果转化为奖励的训练循环和训练数据整理。

如果你正在训练或评估一个触及真实数据库记录的代理：

在训练前先探测。取你自己的代理任务集，对基础策略运行 n 次，并查看波段直方图。根据我们的经验，团队通常没有检查过这个分布，而且它通常比预期的更偏斜。

检查你的一致性。通过训练和评估解析器重放相同的记录模型输出，并验证两者提取出相同的工具名称和参数。否则，训练可能奖励评估解释不同的行为。

报告覆盖率和可重复性。说明在 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 实习。欢迎在下方评论区、github 或通过电子邮件 firstnamelastname@microsoft.com 提问。

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

++ 那个零梯度问题有一个标准的批次时间修复方法：过采样、丢弃退化组、重新填充。全参数运行正是这样做的，类似于用替换零方差组的 DAPO。但重新填充仍然要为每个浪费的 rollout 支付全价，然后才丢弃它。