微软与 Hugging Face 开源 ThinkingBox-Training：把数据库校验变成智能体强化学习奖励

10月22日，微软与 Hugging Face 在 Hugging Face 博客联合发布文章，宣布 ThinkingBox-Training 已在 GitHub 上线。它不是新的基础模型，而是一套把“任务是否真的完成”变成可训练奖励的开源工具链，面向需要操作真实数据库记录的企业智能体。

ThinkingBox 最初的用途是评测。ThinkingBox-Bench 包含 507 个任务，每个任务都会启动一个真实后端，向智能体提供一组 MCP 工具，并配有一个掌握私有上下文的模拟 LLM 用户；任务结束后，系统对数据库终态执行可执行检查，而不是只看智能体调用了哪些工具。

团队在上一篇博客中举过一个例子：模型把客户工单关闭为“已解决”，但背后的承运商异常仍然开放——九次看起来合理的工具调用，留下了一行错误的数据库记录。这类失败说明，只看对话或工具轨迹，很容易高估智能体的可靠性。

转折点在于，多数任务的检查可以直接从最终数据库状态返回 1 或 0。研究团队意识到，同一个信号不只是评分器，也可以充当奖励函数。于是他们从基准之外构建训练任务池，用任务的可执行结果作为奖励，对智能体进行后训练。

难点是选任务。多数任务要么已经被模型解决，要么对当前模型完全无望，两者都提供不了有效梯度。团队提出“离线策略相对难度”：训练开始前，先用基础策略估计每个任务的成功概率，据此筛选训练池，并在整个训练过程中保持任务池固定。

实验使用 Qwen3.8-27B，执行 50 步 GRPO 微调。结果显示，pass@1 从 51.70% 升至 60.78%，提高 9.08 个百分点；在 20 次重复中全部通过的任务从 38 个（7.50%）增加到 107 个（21.10%），净增 69 个。代价是 pass@20 从 453 个（89.35%）小幅降到 446 个（87.97%），也就是至少成功一次的覆盖范围略有收窄。

一个酒店预订任务直观展示了变化：旅客要求降级房型，但公司政策要求先获得经理批准。训练前，模型在 20 次尝试中有 15 次直接修改预订并退款；训练后，20 次都保留了原有预订和支付状态，其中 19 次所有预期记录完全匹配。

团队强调，真正有价值的不是某一个 Qwen3.8-27B 检查点，而是把可执行结果变成奖励的训练循环与数据筛选方法。他们建议企业在训练前先用自己的任务集探测基础策略的成功率分布，核对训练与评估解析器是否提取出相同的工具名和参数，并同时报告至少成功一次和每次都能成功两项指标。

ThinkingBox 代码以 MIT 许可证开放，基准数据采用 CDLA-Permissive-2.0；项目由微软 Copilot Studio 团队与 Toloka 合作完成，并有来自多所高校的实习生参与。公开基准中的任务均为合成重建，工作流和政策参考真实企业智能体模式，但客户并非真实存在。