问题出在哪

微软团队此前做过一个 benchmark：给 agent 一个真实后端和一组工具，让它完成业务任务，最后不看它说了什么，只看数据库里实际变成了什么样。507 个任务、每个跑 20 次，暴露的典型失败是「九步工具调用看起来都对，最后一行数据是错的」——工单被标成已解决，但承运商异常还开着。

这次做了什么

10 月 22 日的联合博客把同一类可执行检查从评测推进到训练：用任务结束后的数据库状态是否匹配预期，作为强化学习的奖励信号，并在 ThinkingBox-Bench 之外的任务上做后训练。对应代码以 ThinkingBox-Training 的名字开放在 GitHub。

数字

在 Qwen3.8-27B 上，平均成功率从 51.70% 提升到 60.78%；「20 次运行全部正确」的任务数从 38 个增加到 107 个；训练用了 50 步 GRPO。作者强调这是单模型、作者报告的结果，换模型或换任务分布是否同样有效，还需要复现。

为什么这个奖励更可靠

模型自评或裁判模型打分都容易被话术影响：只要输出看起来合理，就可能拿到高分。数据库状态是外部事实，模型无法通过措辞改变它。代价是任务必须可回滚、可隔离，每个 episode 都要能重置到一个已知状态，这比搭一个聊天评测集贵得多。

落地时要补的三件事

  • 为每个任务写清终态检查（SQL 断言或 API 断言），并区分「必须成立」与「允许波动」；
  • 给 agent 一个可重置的沙箱数据库，失败后能回到起点，否则训练样本会被污染；
  • 把「全对率」而不只是平均成功率作为主指标——业务要的是稳定完成，不是偶尔蒙对。

判断

这条路线把 agent 评测从「像不像人做的」拉回到「系统状态对不对」，也顺带解释了为什么很多 agent demo 很好看、上线却不行：demo 里没人检查最后一行动数据。对团队来说，先有检查、再谈训练，顺序不能反。

模型可以说自己做完了，数据库不会替它圆谎。