能说会道不算数：微软给 AI 智能体出了一道「看数据库」的考题

客服写来一封投诉：她价值 745 美元的厨房电器在快递「异常」状态里卡了十五天。AI 智能体干得很漂亮：九次工具调用，查订单、看物流、调客户资料、两次核对退款政策、确认没有工单、新建工单、记录时间线，最后判断她的账户等级确实不符合延迟赔付条件——然后它把工单标记为「已解决」并回复用户。看起来无懈可击，但数据库不这么认为。

一分钟速览

• 微软与 Hugging Face 联合推出智能体评测基准 ThinkingBox。
• 它不看模型「说了什么」，只看它在后端留下的终态与副作用对不对。
• 共 507 个有状态业务工作流，每个任务重复跑 20 次。
• 12 个模型、121,680 次有效试验中，79,853 次未通过可执行检查。
• 失败尝试里 67.24% 表面上「干净收尾」，却留下错误的字段或缺失的效果。

「一次成功」不等于「可靠」

微软 ThinkingBox 的核心主张很直接：工具调用不是结果，一次成功不是可靠性。它会先把智能体放进隔离的 MCP 工具会话里跑一遍，然后给「后端终态和副作用」打分——也就是看它在数据库里到底留下了什么。在上面那个例子里，问题出在两个地方：快递异常仍然是「开启」状态，而要求的终态本应是「暂缓、待处理」；同时用户真正问的问题，从头到尾都没得到回答。检查工具调用的评审会看到九次「格式良好」的调用，检查数据库的评审则会看到——工单状态是 solved，而要求是 hold。

数据支撑：漂亮的收尾，藏着的错

ThinkingBox 覆盖 507 个有状态的业务工作流，每个任务对多个大模型独立重复运行 20 次，从完全干净的后端开始。在一项覆盖 12 个模型、共 121,680 次有效试验的对照实验中，有 79,853 次尝试未能通过可执行检查。在这些失败中，67.24% 依然「干净地终止」了——调用了改状态的工具，也没有报出最终的工具错误。但可执行检查发现，其中 77.61% 存在字段值错误，43.30% 产生了意料之外的额外副作用，25.36% 缺少必需的效果。

为了让「可靠性」可量化，它同时报告三个数字：pass@1（单次尝试成功率，也是大多数榜单公布的口径）、pass@20（20 次里至少成功一次的比例，衡量「能不能做到」的广度）、以及 observed 20/20（20 次全部通过的任务数，衡量「能不能每次都做对」）。换句话说，一个能把退款正确处理一次、却把接下来四次搞砸的智能体，根本算不上「能用的退款智能体」。

产品链接

• ThinkingBox 官方博客
• Hugging Face

趋势洞察

随着企业把越来越多「会动数据库」的智能体推进生产，评测标准正从「回答得像不像」转向「执行得对不对」。ThinkingBox 戳中的是一个被长期忽视的盲区：模型可以口若悬河、工具调用也无懈可击，真正出错的地方却藏在它改过的那一行数据里。对准备上线的企业来说，这意味着评估不能只看 demo 的一次灵光，而要看它在大量重复、真实有状态的业务里，能否稳定地把事做对。可靠性，才是智能体从演示走进生产的那道门槛。