Agent 说它做完了，数据库不同意：微软给智能体上了场「查账式」考试

TL;DR

微软 Copilot Studio 团队联手 Hugging Face，把智能体沙箱 ThinkingBox 和 ThinkingBox-Bench 基准（507 个有状态业务工作流、每题跑 20 遍）正式搬上 Hugging Face，任何人都能跑。它的评分哲学就一句话：工具调用不是结果，数据库终态才是证据；一次成功不叫可靠，二十次全对才算。12 个模型 12 万次尝试的代价结论相当扎心：约三分之二的失败「体面收场」（流程走完、报错没有、工单关了），但账本一查全是错的。

导语：那个把工单关成「已解决」的 Agent

微软在公告里讲了个例子，做客服 Agent 的人看了会沉默。

一位客户的 745 美元厨电卡在物流异常里超期 15 天，来找 AI 客服。Agent 干得行云流水：九次工具调用，查订单、查物流、查客户档案、两次检索退款政策、确认没有工单、新建工单、记录时间线——每一步都合法合规。然后它把工单关成 resolved，回复客户：「您的问题已解决，还有什么可以帮您？」

两处硬伤：承运商那边的异常还挂着，按策略终态应该是 hold（挂起等物流）；客户真正问的事，从头到尾没得到答案。

为什么会这样？因为传统的 Agent 评测都在查「答卷」——回复像不像对的、工具调用合不合法。这位 Agent 的答卷无可挑剔，数据库却不同意。这个鸿沟就是 ThinkingBox 要量化的东西：别看 Agent 说了什么，看它给业务系统留下了什么。

想自己跑一遍？

• 🧪 环境：OpenEnv · thinkingbox_env
• 📊 数据集：HF · microsoft/ThinkingBox-Bench
• 💻 框架：GitHub · microsoft/thinkingbox
• 📄 论文：arXiv 2608.19741

怎么考：把「改了什么」而不是「说了什么」当答案

ThinkingBox 的机制不复杂，但每一步都对着现有评测的软肋。

考题来自五个业务域：零售/电商、旅行、车险、数字银行、咨询 IT/HR 支持，共 507 个任务。每个任务定义好初始后端状态、用户目标、可用 MCP 工具（一种标准化的工具接入协议）、领域策略，以及终态可执行检查。还有个细节很妙：配了一个模拟用户，手里攥着预订号、出生日期这类私密上下文——Agent 不主动问，它就不说，考的是多轮问询能力。

每次尝试都在全新隔离会话里跑，两次尝试之间连一行数据库记录都不共享。跑完后，副作用提取器对比「实际改了什么」和「要求的终态」，确定性判分——507 题里 477 题纯看数据库状态，只有 30 题附加对话检查。分数没法靠话术糊弄。

图：智能体在隔离 MCP 会话中执行任务，判分器只看留下的数据库终态与副作用（来源：arXiv 2608.19741）

另一个容易忽略的设计是每题跑 20 遍。理由很朴素：一个退款 Agent 这次算对了、接下来四次都算错，它是个能用的退款 Agent 吗？20 次独立重考，才把「运气好」和「真可靠」分开。

考出来的账：会做一次的很多，次次做对的很少

先看单次成绩（pass@1，任务加权）：Claude Opus 5.5 以 67.16% 领跑全场；开源阵营 Kimi-K3 拿下 57.37%，零售域 82.24% 甚至压过所有闭源模型。乍一看是张普通的 capability 榜。

但 20 遍考下来，榜单彻底变脸。

• Kimi-K3 是「广度王」：93.89% 的任务至少成功过一次（476/507，全场最广），但 20 次全对的任务只有 13.41%（68 项）。
• Claude Opus 5 是「稳态王」：覆盖面反而窄一些（79.09%），但 47.53% 的任务（241 项）二十次全对。
• 重复保分率更残酷：18 个模型里只有 3 个保住七成以上单次成绩——GPT-6 Astra 保 78%，Claude Opus 5.5 和 Opus 5 各保 71%；GLM-5.1、Kimi-K2.6、DeepSeek-V4-Pro 只剩约 8%。

图：ThinkingBox 的任务结构——初始状态、工具面、策略约束、终态检查层层设卡（来源：arXiv 2608.19741）

还有个对「刷版本号」信仰的暴击：Claude Opus 5.5 单次分比 Opus 5 高 0.66 个点，看起来是全面升级——但两者的 20/20 任务数一模一样，都是 241 项。半个点的头部分数，一个可靠度都没买到。

查账查出的病根：八成失败不是「不会想」，是「不会修」

微软给每个失败轨迹打了确定性诊断标签，这份「病历」可能是整场发布里对工程师最值钱的部分：

• 79.9% 是工具使用问题——Agent 往往已经走到正确的工作流门口，栽在工具报错后的恢复、前置条件不满足、空查询结果上；
• 10.3% 是状态更新错误；7.0% 是没完成用户真实诉求；2.9% 压根没做改状态的动作。

换句话说，五分之四的失败是重试与错误恢复的工程问题，不是模型推理问题。这也解释了为什么「体面收场」的比例那么高：12 个模型 12 万次有效尝试里，79,853 次失败中 67.24% 正常结束、调过改状态的工具、最终没有任何报错——其中 77.61% 写错了字段值，43.30% 留下了计划外的多余副作用。

成本侧同样被重算了一遍。按 OpenRouter 牌价折算（官方强调这是对比指数不是账单）：单次成功最便宜的是 GPT-5.6 Sol（$0.127/次），但换成「可靠任务」计价——20 次全跑的成本摊到每个 20/20 任务上——GPT-5.4 反而最便宜（$6.80），GPT-6 Astra（$7.45，231 项）和 Claude Opus 5.5（$7.80，241 项）紧随其后，三者互不支配。最便宜的答案和最可靠的答案，不是同一道算术。

图：圈中的三个模型构成成本前沿——没有谁同时更便宜且更准（来源：arXiv 2608.19741，OpenRouter 2026-09-20 牌价快照）

对做业务 Agent 的人，三件事值得直接抄走

这次发布最值钱的不是榜单，是方法论——而且官方把可执行的环境全开源了（框架 MIT、数据 CDLA-Permissive-2.0）。

• 把「终态检查」搬进你的生产链路：判分用的信号生产环境里同样有——提交前查数据库终态，而不是信模型自己的总结。这是官方给的、也是唯一在公告里反复强调的可迁移结论。
• 选型看两个数，不看一个：pass@1 决定「通常行不行」，20/20 决定「敢不敢托付」。给业务系统写数据的 Agent，第二个数才是采购依据——你的供应商大概率只报第一个。
• 错误恢复优先于换模型：八成失败是工具处理问题，意味着分类工具错误、按可恢复性分级重试、砍掉工作流用不到的工具面，可能比升级基座模型见效更快。另外领域难度差异悬殊——零售平均 59.52%、车险只有 33.83%，同一个模型换个行业，成绩单直接腰斩。

顺带说一句脉络：基准数据集其实 8 月 17 日就在 GitHub 开源了（v1.0），这轮新闻点是 10 月初经 OpenEnv 接口上线 Hugging Face——从「看论文读榜」变成「clone 下来就能跑」，而且每局返回二元奖励的接口设计明显是给 RL 训练铺路，微软已经预告了 thinkingbox-training 仓库。

把账算明白：507 道题全是合成重构的（官方自己声明，工作流按真实企业模式建模、客户并非真人），成本对比用的是单一渠道牌价快照，这两处引用时都得留个心眼。但「数据库终态 + 重复 20 次」这个考法本身站得住——它把「可靠性」从发布会形容词变成了可复现的数字。在你下一次为业务 Agent 签采购单之前，或许真该先让它查 20 次账。

参考来源

• 微软 × Hugging Face 联合博客（一手官方）：The Agent Said It Was Done. The Database Disagreed.
• 微软工程博客（一手官方）：ThinkingBox: Measuring whether agents finish the job
• ThinkingBox-Bench v1.0 发布（一手官方）：GitHub Release
• 论文（一手）：One Success Isn't Reliability: Thinkingbox (arXiv 2608.19741)
• 数据集（一手官方）：HF · microsoft/ThinkingBox-Bench
• 第三方解读（垂直媒体）：Reliable Agents Need State Checks, Not Confident Sign-Offs