先看一个真实测评案例。一位客户投诉：她 745 美元买的厨房电器在纳什维尔配送中心卡了 15 天。AI 客服 Agent 接手处理，表现堪称模范——九次工具调用，查订单、查物流、查客户画像、两次检索退款政策、确认无工单后新建工单、记录时间线，每一步格式规范、逻辑顺畅。最后它把工单状态设为「已解决」，回复客户：「您的问题已解决，还有什么可以帮您？」

两个致命错误：承运商异常仍是活跃状态，按业务规则工单应设为「挂起待处理」而非「已解决」；客户真正问的问题，它压根没答。

一个检查工具调用的评分器会打满分：九次调用全部合法。一个检查数据库的评分器会打零分：终态是错的。这个落差，就是微软与 Hugging Face 在 10 月 3 日联合发布的评测框架 ThinkingBox 要度量的东西。

轨迹是声明，终态才是证据

ThinkingBox 的设计哲学浓缩成一句话：轨迹（trajectory）是声明，数据库状态是证据。

现有 Agent 评测大多在给两样东西打分：最终回答读起来对不对，或者工具调用序列是否符合预期。这两者都是代理指标（proxy）——Agent 可以一边说着「已为您更新预订」，一边把日期写错；可以用正确的退款工具传错误的金额；可以在没人要求时多改一条记录。

ThinkingBox 的做法是删掉代理指标，直接看「现场」。每个任务定义一个必需的终态，Agent 停止工作后，确定性判分器去比对后端数据库的实际状态和副作用：该改的字段改了没有，有没有改不该改的。整个环境里，507 个有状态业务工作流覆盖零售、旅游酒店、车险、数字银行 IT、咨询 IT/HR 五个领域，工具以 MCP 服务器形式暴露，每次运行都在全新重置的隔离后端上进行。

规模数字：121,680 次有效试验（12 个模型的公共集消融，全部测试覆盖 18 个模型），79,853 次失败。配套论文《One Success Isn't Reliability》已挂 arXiv，框架代码 MIT 协议、数据 CDLA-Permissive-2.0，都放在 Hugging Face 上可复现。

最扎心的数字：67.24% 的失败是无声的

如果失败会抛异常、会报错、会让 Agent 说出「我搞砸了」，那问题还简单——接个监控就行。ThinkingBox 的数据击碎了这个假设：

79,853 次失败里，67.24% 是「干净地」结束的——Agent 调用了改状态的工具，全程没有任何最终工具报错，正常收尾、礼貌回复，然后留下一个错误的数据库。

失败的具体形态（类别有重叠）：77.61% 写入了错误的字段值，43.30% 产生了计划外的副作用，25.36% 遗漏了必需的状态变更。按根因归因，79.9% 指向工具处理（tool handling），而不是推理失败。

这最后一条值得单独强调。行业惯性是把 Agent 出错归咎于「模型不够聪明」，然后等下一代模型解决问题。但 ThinkingBox 的归因显示，近八成失败发生在工具层——参数拼接、工具选择、调用时序——这些更多是 harness 和工具面的设计问题。模型侧对齐做得再好，也救不了把「git push」和「git push --force」都暴露给 Agent 的工具面。

一次成功不叫可靠性：pass@1 与 20/20 之间的深渊

ThinkingBox 的方法论贡献是坚持每任务跑 20 遍，同时报告三个指标：pass@1（单次成功率，回答「通常做得怎样」）、pass@20（至少成功一次，回答「最好能做成什么」）、observed 20/20（二十次全对，回答「能向客户承诺什么」）。

三列数字之间的落差，比任何基准排行榜都更有信息量：

• Claude Opus 5.5 拿下 pass@1 榜首（67.16%），但二十次全对的任务只有 241/507（47.53%）——一半以上的业务流程，它每二十次就会搞砸至少一次；
• 开源阵营的 Kimi-K3 更极端：pass@20 高达 93.89%（507 个任务里 476 个至少成功一次，广度惊人），但 20/20 只剩 68 个（13.41%）——所谓「能做」和「稳定做对」之间差了 80 个百分点；
• 一致性保持率同样分化：GPT-6 Astra 保住单次成绩的 78%，Opus 5.5/5 为 71%，而 GLM-5.1、Kimi-K2.6、DeepSeek-V4-Pro 只保住约 8%。

换句话说，一份漂亮的 pass@1 榜单，对生产环境几乎没有采购参考价值。ThinkingBox 还把这笔账折成了钱：按 OpenRouter 未折扣牌价，每获得一个「可靠任务」（20 次全对），GPT-5.4 花 6.80 美元、GPT-6 Astra 花 7.45 美元、Opus 5.5 花 7.80 美元；而单次最便宜的 GPT-5.6 Sol，摊到可靠任务上是 9.76 美元。可靠性的定价，和单次成功的定价，是两张完全不同的价目表。

对自建 Agent 团队的三条直接启示

第一，把「提交前查终态」写进 harness。微软作者给出的建议里最可操作的一条：在状态变更提交前增加终态校验，让「静默失败」在落库前被拦截，而不是等客户投诉。

第二，重新审视工具面。79.9% 的失败根因在工具处理，那么裁剪工具数量、按角色做工具隔离（不让只读 Agent 看到生产写入工具）、给工具错误分类以便定向重试，这些 harness 层的投入，可能比换下一代模型 ROI 更高。

第三，换掉你的评测口径。如果内部评测还在报告单次成功率，那它在系统性地高估 Agent 的成熟度。二十次全对才是能写进 SLA 的数字。

ThinkingBox 的任务全部是基于企业模式的合成重构，这不是真实生产日志，结论外推要留有余地。但它把一个行业集体回避的问题摆上了台面：Agent 产品的天敌不是「做不了」，而是「以为做成了」。评测范式从轨迹转向终态这一步，可能比模型榜单上那零点几分的爬升，更能决定 Agent 什么时候能真正上岗。

参考来源

• Hugging Face 官方博客（Microsoft × HF 联合发布，2026-10-03）：https://huggingface.co/blog/microsoft/thinkingbox
• 论文《One Success Isn't Reliability》（arXiv 2608.19741）
• Pivot News：Microsoft benchmark finds agents pass tool checks but fail the database：https://pivotnews.ai/five/microsoft-benchmark-finds-agents-pass-tool-checks-but-fail
• AI Breaking Wire：Two-Thirds of Failed Agent Runs Throw No Errors：https://aibreakingwire.com/news/microsoft-reveals-67-of-failed-ai-agent-runs-appear-successful
• ExplainX：ThinkingBox: Microsoft Grades AI Agents on Database State, Not Chat：https://explainx.ai/blog/microsoft-thinkingbox-agent-benchmark-database-state-reliability-2026