从终态验收到策略训练：ThinkingBox 技术阅读

全文概览

业务 Agent 回复“已经处理”，数据库里可能仍留着错误记录。ThinkingBox 把验收放在任务结束后的后端状态上，再把同一种验收信号用于训练，让策略学习哪些操作顺序能够真正满足业务约束。

这次更新的关键在训练任务的选择。团队先用基础模型反复试题，估计每题的成功概率，保留能产生成功与失败对比的任务，随后固定训练池进行 GRPO。训练过程中的每个 rollout 都包含独立后端、MCP 工具和模拟用户，多数奖励来自可执行终态检查，少数要求仍需模型评审辅助。

团队报告，对 Qwen3.8-27B 做 50 步全参数训练后，在 507 题、每题 20 次的独立基准评测中，平均成功率从 51.70% 升至 60.78%，20 次全部成功的题数从 38 增至 107。不过，至少成功一次的题数从 453 降至 446。这组结果同时包含重复可靠性的改善和覆盖面的损失。

原文是 Microsoft 与 Hugging Face 于 2026 年 10 月 22 日发布的训练技术文章，官方 RSS 对应北京时间 10 月 23 日。以下结合公开训练仓库与实现指南，先解释业务验收，再拆开任务筛选、奖励回路和评测，最后讨论复现边界。

图源：原文 Figure 5，Microsoft / Hugging Face。查看高清原图。蓝色部分负责筛选任务，紫色部分执行交互、判分和更新。图上被划掉的回路说明本次实验没有在训练中重新探测难度。

背景与约束：验收哪些业务记录

一次酒店改房请求可能牵涉预订、付款、审批和工单。工具调用格式正确，只能说明接口接收了参数。完整验收还要检查用户是否具备所需授权、预订是否应当变更、退款是否符合条件，以及相关记录是否一致。

ThinkingBox-Bench 为每道题启动后端，让 Agent 与持有私有上下文的模拟用户交互，再检查最终数据库及副作用。Agent 可以选择不同的调用路径，只要最终结果满足任务要求即可通过。错误操作、缺失记录或额外副作用都可能使验收失败。

这种设计适合状态明确、能够写出检查程序的业务任务。实际系统仍要决定“正确状态”的含义：如果审批规则没有进入检查，模型即使通过测试，也可能做出业务上不允许的操作。验收程序本身就是任务定义的一部分。

核心机制：先选任务，再运行完整交互

一次性估计相对难度

数据准备指南把策略探测、任务筛选和基准排除放在训练之前。难度取决于当前策略：某题可能对一个模型几乎必败，对另一个模型已经过于简单。

对候选任务执行 n 次有效探测，记录 k 次成功。原文采用 Jeffreys 后验 Beta(k + 0.5, n - k + 0.5) 表示成功概率的不确定性，按后验概率质量最大的区间分类。参考实验的区间边界为 0.08、0.40、0.60 和 0.90，保留中间三个区间，去掉最难和最容易的两端。这些边界是该实验的超参数。

有限探测没有完全揭示真实成功率。采用后验分布，可以把“目前观察到的比例”和“对概率的把握”区分开来。原文示例中，8 次探测成功 3 次，对应 Beta(3.5, 5.5)，其最大区间概率质量落在 Difficult 档。不能把 3/8 当作已经精确测定的长期成功率。

参考流程还用 GPT-5.4 做可解性筛查，最终得到 187 个训练任务。筛查、基础策略探测和难度分类离线完成，训练时不更新这个任务池。随着策略进步，同一题的实际难度会变化，本次实验没有检验持续重分桶的效果。

为什么需要组内成功与失败的对比

GRPO 对同一任务采样一组轨迹，通过组内奖励差异构造学习信号。如果 8 次全败，二元奖励都是 0；如果 8 次全成，奖励都是 1。两种情况都缺少任务奖励的组内差异。一个有成功也有失败的组，才提供直接的轨迹对比。

这解释了离线筛选的用途：提前减少容易产生同质奖励的任务。每条 Agent 轨迹都要启动后端、执行工具和调用模拟用户，先跑完一组再发现没有可用对比，已经付出了交互成本。

训练还采用类似 DAPO 的零方差组替换。这个运行时机制补充有效训练组，离线筛选则试图减少无效组的产生。两者发生在不同阶段，不能把组替换理解为训练期间重新估计全部任务的难度。

奖励检查终态，解析必须保持一致

每个 rollout 获得新的后端状态和隔离的 MCP 会话。模拟用户提供任务信息，不负责给策略打分。大多数任务直接检查终态和副作用并返回二元奖励；少数无法仅凭数据库确定的窄范围要求，由配置的 judge 回答二元 rubric 问题，参与最终测试。

训练与评测还要一致解释模型输出，包括推理段、工具名称、参数类型和消息格式。否则，同一段输出可能在训练时被当作一次有效操作，在评测时变成不同的调用。仓库把共享解释逻辑集中到 trainer/core/tb_interpret.py，这是奖励与实际 Agent 行为对齐的一项工程约束。

证据与工程代价：三个指标一起看

原文的训练集与 ThinkingBox-Bench 分离。团队在未用于训练的 507 个基准任务上各运行 20 次，合计 10,140 次尝试。下面保留同一基础模型训练前后的结果，不把不同指标拼成模型总排名。

平均成功率提高了 9.08 个百分点。全部通过的任务增加 69 个，至少通过一次的任务减少 7 个。这与策略更集中于某些稳定成功路径的现象相符，但仅凭这组统计，不能确定每个消失的成功路径为何消失。

“20/20”也只描述已记录的 20 次尝试。它不能保证未来调用永远成功，更不能自动覆盖新用户、后端故障、政策变更或不同采样参数。公开仓库说明，重复试验指标是在同一批评测记录上通过聚合工具补充统计的，应连同完整运行协议理解。

酒店案例中的两个验收层次

图源：原文 Figure 2，Microsoft / Hugging Face。查看高清原图。这是合成业务场景，不涉及真实客户交易。

案例要求先取得经理批准才能改房。基础模型有 15 次在缺少批准时改动预订并退款，20 次中只有 5 次保持预订和付款不变。微调后，保持这两类记录不变的次数达到 20/20，而所有预期记录匹配为 19/20。

这两个结果应分别报告。避免一次不该发生的订单变更，是更窄的验收条件；全部预期记录正确，是更完整的条件。原图没有解释剩余一次记录不匹配的具体原因，不能自行补成新的故障结论。

训练与服务成本的口径

参考配置使用 24 张 H100，训练和同步 rollout 共用设备，执行 50 步全参数、token-mean GRPO。计划每步为 18 组、每组 8 条轨迹，启用参数与优化器卸载。零方差组和基础设施错误会触发补充采样，不能用 18 × 8 × 50 推算所有实际交互调用数。

原文还估算了每个持续通过任务的推理成本，但该估算排除了训练和策略探测开销。它适合解释评测活动中成功率与 token 用量的关系，不能当作复现整项研究的云账单。

局限与复现边界

公开仓库提供训练、奖励、数据选择和评测的集成代码，但公开的 39 个开发示例并非报告结果所用的私有 187 题训练池。读者可以验证接口并构建自己的训练实验，不能仅下载示例就声称完整复现了报告分数。

基准在领域、数据库、政策和大多数工具上与训练池不同，但双方共享 ThinkingBox 框架、模拟用户机制、终态判分、部分工具及相似任务风格。原文据此限定迁移主张。结果还不能回答跨框架或真实生产系统是否取得同样收益。

可执行奖励也有表达能力边界。未编码的规则、长期才出现的副作用、检查器无法观察的外部系统状态，都可能留在奖励之外。少量 judge 辅助检查进一步引入模型评审的误差，不能把整个系统概括为完全确定性的验收。

复现时，版本和解析设置同样影响结果。评测指南指出，固定的 ThinkingBox 会话配置不会通过 YAML 中的 top_k/top_p 字段设置采样，因此要在 vLLM 的生成配置中明确覆盖；模型模板、工具调用解析器和系统消息处理也要核对。配置文件里出现某个字段，并不足以证明服务实际采用了它。

这篇阅读依据训练仓库提交 48f513ea05d399e8045ad31734a992913091a11a。指南另列出了历史参考训练提交，两者应分别记录。本文未执行 GPU 训练，文中分数均为团队报告。

可验证的启发

先检查验收器能否分辨业务上不同的结果。 可以为同一任务准备几种受控终态：缺少审批但订单已改、订单未改但工单错误关闭、全部记录一致，再检查测试能否分别拒绝或接受。这个尝试检验的是奖励定义的覆盖范围；若非法状态仍能通过，应先修验收条件，再讨论策略训练。

用相同采样协议同时记录平均成功、至少一次成功和全部成功。 在小规模保留任务集上比较基础策略与改进策略，保留每次尝试的终态和失败类别。如果平均成功提高但任务覆盖下降，就需要检查损失集中在哪些场景，不能只保留一个更高的总分。任务数和重复次数变化时，全部成功的比例也不能直接与原文比较。

在训练前验证输出解析的一致性。 将同一份录制输出送入训练与评测解析路径，对比工具名、参数及其类型。成功标准是两端产生一致的可执行调用，遇到无法解释的内容时明确报告错误。这个步骤比先投入多卡训练更容易发现集成层的问题。

参考资料

• Microsoft / Hugging Face：Turning Database Grading into RL Rewards，本文方法概览、原始结果与两张插图的来源。

• ThinkingBox Training README，固定提交，训练接口、公开样例及 MIT 许可说明。

• Task preparation and runtime hydration，探测记录、基准排除和数据加载协议。

• Reference Qwen3.8-27B run，参考硬件、任务池、奖励语义和运行配置。

• Merge and evaluate a checkpoint，推理服务、解析兼容和 507 × 20 完整覆盖验证。