ThinkingBox：微软用20次重复测试重新定义AI智能体可靠性

微软研究团队发布的 ThinkingBox 基准测试，把一个长期被忽视的问题摆上了台面：当一个AI智能体"成功完成"了一项任务，这个成功到底有多少能在重复执行中幸存下来？更关键的是，"智能体说它完成了"是否真的意味着后端数据库最终进入了正确状态？

这项研究由微软主导，论文、代码、数据集全部公开，ThinkingBox 环境也已上线 Hugging Face OpenEnv。研究团队没有停留在单次成功率这个被过度美化的指标上，而是用一套严苛的状态检验方法，揭示了智能体可靠性评估中的巨大盲区。

507个有状态工作流，每个跑20次

ThinkingBox-Bench 包含 507 个策略约束下的业务工作流，覆盖五大领域：零售、旅行/酒店、车险、新型银行内部IT、以及咨询类的IT/HR 场景。这些任务不是简单的问答，而是模拟真实企业运作中的多步骤有状态流程。

测试设计有几个值得关注的细节。每个任务都会被独立执行 20 次，每次都从一个干净的后端初始状态开始——这意味着每个模型要跑 10,140 次试验。测试中有一个模拟用户持有私有上下文，只有在智能体主动询问时才会透露信息，这逼着智能体必须真正去交互，而不是靠猜。

评分方式才是整个研究的核心。评分器直接对比任务结束后的后端状态与副作用，和任务所要求的最终状态是否一致。任何产生正确结果的执行轨迹就算通过；而错误、缺失或多余的副作用都算失败。507个任务中有477个纯粹依据状态来评分，另外30个还会额外检查最终回复的某个狭窄属性。

三个指标：发现能力与重复能力的割裂

研究团队刻意区分了三个经常被混为一谈的指标，这也是本文最有价值的方法论贡献：

• pass@1：所有尝试中成功的比例
• pass@20：在20次尝试中至少成功一次的任务比例
• all-20：在全部20次尝试中每一次都成功的任务比例（注意这是固定试验预算下的观测计数，而非统计估计量）

这三个指标画出来的排行榜几乎是互相矛盾的。Kimi-K3 覆盖面最广，至少成功一次的任务达到 93.89%（476/507），但能够20次全对的只有 13.41%（68/507）。而 Claude Opus 5 的发现能力较低（79.09%），重复稳定性却高得多，达到 47.53%，也就是241个任务稳稳通过。Qwen3.8-27B 则是 89.35% 至少一次、7.50% 每次都对。

换句话说，按 pass@20 排名和按 all-20 排名，得到的几乎是两份完全相反的榜单。一个模型善于"碰运气找到解法"，不代表它能在生产环境中稳定复现。这对任何想把智能体部署到真实业务中的团队都是一记警钟。

pass@k 系列指标源于代码生成评估领域，最早在 OpenAI 的 HumanEval 论文中被系统化使用。其核心逻辑是：对同一问题采样多次，观察模型能否在 k 次机会内至少找到一个正确解（pass@k），或者每次都给出正确解（all-k）。这两个维度捕捉的是截然不同的能力——pass@k 衡量的是模型的"解空间覆盖能力"，即它是否知道正确路径的存在；all-k 衡量的是"执行稳定性"，即模型能否在无额外提示的情况下持续复现正确行为。在代码补全场景中，pass@k 高但 all-k 低通常意味着模型理解问题但执行有随机性；而在企业级智能体场景中，这种随机性的代价从"偶尔给出错误代码"变成了"偶尔向生产数据库写入错误记录"，容错空间远低于前者。ThinkingBox 将这套框架迁移到有状态工作流评估，是方法论上的关键创新。

失败往往"看起来很干净"

研究的第二个发现更令人警惕。团队在 12 个模型、总计 121,680 次有效试验上做了回溯性消融分析，其中 79,853 次未能通过可执行检查。

问题在于，这些失败里有 67.24% 仍然干净地终止了——它们调用了状态变更工具，结束时没有报出最终工具错误。也就是说，如果你用一个"完成度"式的代理指标来打分，这些失败都会被判为成功。这正是当前很多智能体评估的致命缺陷：只看流程是否跑完，不看结果是否正确。

在这些"干净终止却实际失败"的轨迹中，状态检查发现（类别有重叠）：字段值错误占 77.61%，产生了意料之外的额外副作用占 43.30%，缺失必需的副作用占 25.36%。一个智能体可以一本正经地跑完全部流程、礼貌地告诉你任务已完成，而数据库里写进去的却是错误的值。

"干净终止"（clean termination）是指智能体的执行轨迹在形式上完整结束——没有抛出未捕获的异常、没有工具调用超时、没有明显的错误返回码，对话以智能体宣告"任务完成"作为收尾。这种终止方式在很多现有评估框架中被直接用作成功的代理信号，因为它易于自动化检测。但 ThinkingBox 的消融分析揭示了一个结构性问题：LLM 驱动的智能体在遇到歧义或中间步骤失败时，往往会选择"合理化继续执行"而非报错退出。例如，当一个字段值无法确认时，模型可能用默认值或推断值填充，然后继续后续步骤，最终礼貌地报告完成——整个过程对外部观察者而言毫无异常。这种行为模式在强化人类信任感的同时，也系统性地掩盖了数据层面的错误，是当前 RLHF 训练目标（最大化人类偏好）与业务可靠性目标之间张力的直接体现。

研究的边界与开放问题

团队对自身研究的局限交代得相当坦诚，这在基准测试类工作中并不常见。他们明确指出：这些任务是企业工作流模式的合成重构，并非真实生产流量；20/20 只是固定预算下的观测计数，不是对未来可靠性的保证；模拟用户是一个固定的 LLM，本身就是方差来源；失败类别只是确定性的诊断标签，不代表因果解释。

一个有意思的开放问题是：论文附录中同时报告了观测到的 all-20 计数和一个 plug-in pass^k 估计值。两者回答的是不同问题——前者记录在固定20次尝试中实际发生了什么，后者在额外假设下估计重复成功的概率，二者可能差异巨大。团队把这个问题抛给了社区：在可靠性排行榜上，到底该强调哪一个，还是两个都展示？

对实践者来说，ThinkingBox 最大的价值不仅在于它的数字，更在于它提供了可复现的工具。你可以通过 HF OpenEnv 环境，用自己的模型跑这 507 个任务中的任何一个——团队甚至直言，这是"用你自己的数据来反驳我们"的最快方式。这种开放姿态，比任何单一的榜单结论都更有价值。

plug-in pass^k 估计值是一种从有限样本中推断真实通过概率的统计方法。其基本思路是：假设每次独立试验的成功概率为 p，则在 n 次试验中至少成功一次的概率为 1-(1-p)^n。通过观测到的成功次数可以对 p 做最大似然估计，进而推算任意 k 值下的理论通过率。这种方法的优势是可以用相对少的样本估计极端情况（如 pass@100），但代价是引入了独立同分布假设——即每次试验相互独立且成功概率固定。对于 LLM 智能体而言，这个假设存疑：模型的随机性来源于温度采样，但不同轮次之间可能共享系统性偏差（如对某类指令的一致误解），导致失败并非真正独立。观测到的 all-20 计数则完全规避了这一假设，直接记录事实，但无法外推。论文将这一方法论选择开放给社区讨论，反映了可靠性评估领域目前尚无共识的现实。

对智能体落地的启示

当行业还在用单次成功率和漂亮的 demo 来宣传智能体能力时，ThinkingBox 把评估标准推向了真正重要的维度：结果状态的正确性，以及这种正确性在重复中的稳定性。

对于任何考虑将 AI 智能体接入真实业务后端的团队，这项研究传递的信息很清晰：不要被"任务已完成"的表象迷惑，必须验证系统的终态；也不要因为一次成功就下结论，可靠性要在重复中检验。发现能力和重复能力是两种不同的本领，而生产环境需要的恰恰是后者。