微软 × Hugging Face 发布 ThinkingBox：别信 Agent 说的「做完了」，去查数据库

发生了什么：给 Agent 的「成绩单」换了个判卷标准

10 月 3 日，微软 Copilot Studio 团队与 Toloka 在 Hugging Face 博客上联合发布了 ThinkingBox，一个专门评测 AI agent 的开源沙盒与基准。它的核心主张一句话就能说清，HF 博文里写得很漂亮："A trajectory is a claim. Database state is the evidence."（轨迹只是说法，数据库状态才是证据。）

传统 agent 评测看的是：工具调用格式对不对、最后那句回复听起来靠不靠谱。ThinkingBox 反其道而行：只看 agent 在后端数据库里留下了什么。ThinkingBox-Bench 包含 507 个有状态的业务工作流（零售、车险、旅行、数字银行、咨询五个领域），每个任务对每个模型跑 20 遍，每次都从干净的初始状态开始。其中 477 个任务纯按数据库状态判分，另外 30 个加上回复质量 rubric。

那个让所有人沉默的例子

论文开篇的例子值得每个做 agent 的人读三遍：一个客服 agent 处理延迟配送，做了 9 次格式完美的工具调用，正确读了退款政策，最后把工单关了，状态标为「已解决」。按传统判卷标准，这是满分。但数据库里有两个字段在抗议：承运商异常还开着，按规则工单应该是「暂缓」；而且客户真正问的那个问题，agent 根本没回答。9 次有效调用、0 次工具报错、1 个完全错误的结局。

数字更扎心：在 12 个模型、121,680 次有效试验的消融分析里，79,853 次没能通过可执行检查——将近三分之二。而在这些i败里，67.24% 是「干净地失败」的：正常结束、调用过改状态的工具、最后没有报任何工具错误。失败拆解：77.61% 是字段值写错，43.30% 产生了意外的副作用，25.36% 漏掉了必需的效果。

榜单：一次成功 ≠ 可靠，Opus 5.5 与 Kimi-K3 的两种「强」

单次通过率（pass@1）最高的依然是 Claude Opus 5.5：67.16%。开源权重模型里最强的是 Kimi-K3，单次成绩只比 GPT-6 Astra 低约 1 个点。但 ThinkingBox 真正想讲的故事是一致性：Kimi-K3 有 93.89% 的任务至少成功过一次，却只有 13.41% 的任务能连续 20 次全过；而 Opus 5 和 Opus 5.5 各自有 241 个任务（47.53%）20 次全过。换句话说，「偶尔能成」和「每次都成」之间隔着一道鸿沟，而这道鸿沟恰恰是生产环境唯一关心的东西。

还有两个值得玩味的发现：约 80% 的失败归因于工具调用处理和错误恢复，而不是推理能力不行——agent 不是想不明白，是手太笨；以及按「每个可靠任务的成本」算，最便宜的单次成功模型，未必是每个可靠任务最便宜的模型。

为什么 vibe coder 应该关心一个企业级基准

因为你每天都在做 ThinkingBox 测的那件事：让 agent 改你的代码、数据库、配置文件，然后相信它说的「搞定了」。三条可以直接抄作业的结论：

第一，给你的 agent 验收标准从「对话」搬到「状态」：不要问「你做完了吗」，而是写一条能自动跑的检查——数据库里那行记录的字段对不对、文件 diff 是不是你预期的、测试是不是真的绿了。让 agent 自己跑这条检查并贴结果。

第二，对关键任务跑 3 遍而不是 1 遍：ThinkingBox 用 20 遍揭示了「一次性成功」的欺骗性。你不需要 20 遍，但对涉及数据迁移、支付、权限的任务，让 agent 独立跑 2-3 遍并对比终态，是成本最低的可靠性保险。

第三，框架和数据集都是开源的（代码 MIT、数据 CDLA-Permissive-2.0），通过 Hugging Face 的 OpenEnv 就能复现。如果你正在选 agent 底座模型，别只看 SWE-bench，去跑一遍 ThinkingBox 里和你业务最像的那几个领域——选「20 次全过」最多的，而不是「单次最高分」的。