微软开源 Agent 强化学习训练方案

dev.to · AI#Agent#强化学习#开源

Editor brief · 编辑速览

ThinkingBox-Training 将数据库最终状态检查用作强化学习奖励，Qwen3.8-27B 训练 50 步后，独立基准的 pass@1 从 51.70% 升至 60.78%。但 pass@20 从 89.35% 降至 87.97%，体现成功稳定性提升与可解任务覆盖下降的取舍。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

Microsoft 发布的 ThinkingBox-Training，想解决 Agent 的一个实际问题：同一件事反复执行，能不能稳定做对。作者用 GRPO 微调 Qwen3.8-27B 后，单次平均成功率提高了，但多试几次能碰巧解出的任务反而少了。

这组结果的价值，在于把「能力更广」和「执行更可靠」分开衡量。对于要改订单、处理支付状态的 Agent，偶尔成功和每次都守住业务规则，是两回事。

ThinkingBox-Bench 不只看回答是否像样，而是比较任务结束时的数据库状态与预期结果。Agent 声称订房成功没用，订单和支付状态必须对得上。

Microsoft 对 Qwen3.8-27B 做了 50 步 GRPO 训练，再用未参与训练的 507 个 ThinkingBox-Bench 任务评估，每个任务执行 20 次：

模型更稳定了，但能触及的任务范围没有扩大。

作者将这种变化称为「锐化」：原来时好时坏的一部分任务，现在更容易持续做对；另一些原本偶尔能解出的任务，则不再成功。五个评测领域的 pass@1 和全 20 次成功指标都有提升，但 pass@20 表现不一，汽车保险领域下降最多，达到 7.0 个百分点。

酒店预订案例更直观。任务要求降级房型前取得经理批准，基础模型在 20 次尝试中有 15 次未经批准就修改预订；微调模型则在全部 20 次中保住了预订和支付状态。这里奖励的不是「动作更多」，而是该停手时能停手。

大多数训练奖励来自确定性的数据库检查，只有 1 或 0。检查终态是否正确，不关心 Agent 具体走了哪条路径。少量范围较窄的要求，交给 LLM judge 按二元评分问题判断。

这种设计让奖励比较容易核验：最终状态符合要求就得分，不能靠一段漂亮的解释蒙混过关。但它也有边界。若某项要求约束执行过程，例如必须先审批再修改，就需要确认终态检查或额外判定能覆盖它。原文没有交代酒店案例如何识别审批过程。

训练任务也经过筛选。作者先离线探测基础模型，剔除始终失败和始终成功的任务，最后留下 187 个。原因是 GRPO 需要同组尝试出现不同结果，才能从成功与失败之间获得学习信号。

复现还有现实门槛：参考运行使用三台节点上的 24 张 H100 GPU，环境为 Linux、Python 3.12 和 Verl 0.9.0。完整的 187 个任务没有公开，仓库只提供用于跑通接口的公开样例列表。

作者沿用此前文章的估算方式，计算「每次尝试都成功的任务」对应成本：

这是一种服务成本比较指标，不是实际云账单，也没有计入训练，以及为筛选任务进行探测的成本。因此，$24.36 降到 $8.00 可以说明该评测口径下的变化，不能直接拿来估算团队能省多少预算。

评测中的另一组结果也很有启发：Claude Opus 5.5 的 pass@1 比 Claude Opus 5 高 0.66 个百分点，但两者全部 20 次都成功的任务同为 241 个。总分涨了，稳定覆盖的任务数量却没变。

我认同它把稳定性单独拿出来测。一次跑通适合展示，反复执行才接近业务系统面对的要求。平均成功率、稳定成功的任务数、重试后的覆盖范围，回答的是三个不同问题。

但这还不足以证明训练方法能广泛迁移。训练池与评测集虽然没有使用相同任务，却共享 ThinkingBox 框架、模拟用户设置和评分方式，Microsoft 也承认这限制了迁移结论。换成真实用户、不同工具接口或另一套业务规则，效果还没说清。

原文也没有提供与提示词优化、显式规则校验、审批流程等做法的对照实验。它展示了这次训练有效，却没有证明一般团队应该优先训练模型。尤其是审批这类硬约束，应用层能强制校验的部分，仍应由系统承担。