微软 ThinkingBox 基准：按数据库终态而非模型自述评判 AI 智能体

Microsoft ThinkingBox 根据 AI 智能体留下的记录而非其生成的语句来评分，然后考察它们能否连续二十次做到这一点。它现已通过 Hugging Face 提供。 Figure-1 图 1：ThinkingBox 让智能体在隔离的 MCP 工具会话中运行，然后对其留下的终端后端状态和副作用进行评分。摘自我们的 ThinkingBox 论文。 这是 Microsoft 与 Hugging Face 的联合博客，特别感谢 Tommy Guy（Enderis AI 创始人，此前任职于 Microsoft）、Hugging Face 的 Sergio Paniego，以及我们此前的实习生 Zhuochun Li（匹兹堡大学）、Ali Keramati（加州大学欧文分校）、Youngmin Ko（西北大学）的共同撰写/审阅工作。 一位客户来信。她那台价值 745 美元的厨房电器滞留在纳什维尔配送中心，处于快递“异常”状态，已超过预计送达日期十五天。 AI 智能体做了细致的工作。九次工具调用：它调取订单、查询物流、查找她的客户资料、两次搜索退款政策、确认没有工单存在、创建了一个工单、记录了时间线，并正确解读了政策；她的账户细分确实不符合延迟送达补偿的条件。 然后它把工单关闭为 已解决，并回复“既然您的问题已解决，还有什么我可以帮您的吗？” 有两处错误。承运商的异常仍然处于未解决状态，因此所需的最终状态应为 暂停，等待解决。而且客户从未就她实际提出的问题得到真正的答复。 一个检查工具调用的 AI 评分器会看到九次格式良好的调用。检查智能体是否写入数据库的评分器也会看到这一点。而数据库才是不同意的那一方。 这一差距正是 ThinkingBox 所衡量的。在 507 个有状态的业务流程中，每个流程针对各种 LLM 模型运行 20 次，它根据终端后端状态和副作用对智能体进行评分。本文涵盖我们的发现、一致性的代价，以及如何通过 OpenEnv 自行运行该基准测试。 你可以自己运行这个例子：上面的示例改编自基准任务 sandbox_external_retail_group1.py:test_case_ST003_006，而失败的可执行检查只是一个字段：工单的状态为 solved，而所需的最终状态是 hold。完整轨迹见我们论文的 附录 D.4，案例 3。 目录 1. 工具调用不等于结果 2. 一次成功不等于可靠 3. 你能依赖智能体背后的模型吗？ 4. 一致性的代价 5. 失败特征 6. 工作原理 7. 自行运行 8. 下一步走向 想在阅读结果之前先试一试？跳到 自行运行 一节。 工具调用不等于结果 最终回复和有效的工具调用只是代理指标。智能体可能听起来正确，却留下了错误的值、改错了记录，或产生了额外的副作用。只有它留下的记录才能定论。 差距是巨大的。在一项覆盖 12 个 LLM 模型、121,680 次有效试验的通用集消融中，有 79,853 次尝试未通过可执行检查。在这些失败中，67.24% 仍然干净地终止、调用了改变状态的工具，并且没有报告最终的工具有错误。然而，可执行检查在其中 77.61% 的案例中发现了错误的字段值，在 43.30% 中发现了非预期的额外效果，在 25.36% 中发现了缺失的必需效果。这些状态检查发现存在重叠。 轨迹是一种声明。数据库状态才是证据。重复是信任测试。 一次成功不等于可靠 一个能正确处理一次退款、却在接下来四次中处理不当的智能体，不是一个可用的退款智能体。因此每个任务都运行 20 次独立，每次都从相同的干净后端开始，我们报告三个不同的指标： 表 1：我们报告的三个数字，以及每个数字所回答的问题。 指标 它衡量什么 它回答什么 pass@1 所有尝试中成功的比例 它通常表现如何？ pass@20 在 20 次尝试中至少一次解决的任务比例 它是否曾经能做到？广度。 观测到的 20/20 实际通过全部 20 次记录尝试的任务 它是否总能正确？ 我们在本博文中使用观测到的 20/20，作为 507 个任务中有多少在 20 次中通过 20 次的字面计数。没有估计器，没有平滑。 从熟悉的视角开始。下表报告了 pass@1，即单次尝试得分估计，按领域细分。这是大多数排行榜发布的数字，单看它读起来像是一份普通的能力排名。 表 2：ThinkingBox-Bench 按领域划分的 pass@1（%）。每个模型都在每个任务上评估 20 次重复试验。粗体标记组内领先者；下划线标记第二名。单次尝试得分估计的标准误见我们 ThinkingBox 论文中的表 4。 模型 零售（98） 汽车保险（100） 旅行（104） 数字银行（104） 咨询（101） 总体，按任务加权（507） 专有模型 Claude Opus 5.5 80.97 68.40 54.28 71.25 61.58 67.16 Claude Opus 5 80.71 65.80 49.95 70.62 66.19 66.50 GPT-5.4 76.33 62.65 68.12 65.34 54.60 65.36 GPT-5.6 Sol 67.65 65.30 60.34 59.09 57.52 61.91 Claude Sonnet 4.6 72.35 54.40 58.94 56.39 54.31 59.19 GPT-6 Astra 71.73 46.55 55.87 60.87 56.83 58.31 GPT-5.2 70.20 22.40 53.70 51.15 34.06 46.28 Claude Opus 4.6 68.62 8.30 21.11 35.67 27.82 32.09 o3-pro 37.70 2.95 17.31 24.28 14.60 19.31 Grok-4.3 43.93 2.60 15.14 1.78 9.55 14.38 开放权重模型 Kimi-K3 82.24 50.80 61.83 41.35 51.63 57.37 Qwen3.8-27B 64.03 47.85 53.41 47.88 45.69 51.70 DeepSeek-V4-Pro 68.21 29.65 43.13 44.86 31.04 43.26 Kimi-K2.6 53.72 24.50 39.52 33.65 37.33 37.66 GLM-5.1 58.67 25.70 35.43 13.27 34.06 33.19 Qwen3.6-27B 43.11 29.00 46.39 27.84 18.37 32.94 Qwen3.5-9B 19.90 0.70 4.71 1.15 2.33 5.65 Mistral-Large-3 11.28 1.30 8.99 1.15 0.74 4.66 Claude Opus 5.5 以 67.16% 领先总体，比 Claude Opus 5 高出三分之二个百分点。Kimi-K3 是最强的开放权重模型，与 GPT-6-Astra 相差不到一个百分点。领域同样重要：Claude Opus 4.6 在零售上得分 68.62%，但在汽车保险上只有 8.30%。 一次好的运行告诉你一个模型能做这项工作。它不会告诉你它是否还会再做一次。所以把每个任务运行 20 次，然后问这个分数有多少能保留下来。 Figure-2 图 2：每个模型的单次尝试得分在 20 次重复后保留了多少。 只有三个模型保住了其 pass@1 分数的大部分：GPT-6 Astra 保留了其单次尝试率的 78%，Claude Opus 5.5 和 Claude Opus 5 各保留 71%。在另一端，GLM-5.1、Kimi-K2.6 和 DeepSeek-V4-Pro 各只保留约 8%。 一个模型能做一次和它每次都能做之间的差距，就是整个故事。 你能依赖你智能体背后的模型吗？ Figure-3 图 3：广度与一致性出现分化。图中展示了十八个模型中的十二个；为便于阅读，省略了六个 pass@1 低于 33% 的模型。 Kimi-K3 在我们测试过的所有模型中覆盖面最广。它至少成功一次地解决了基准测试中 93.89% 的任务：507 个任务中的 476 个。只有 31 个任务能完全难倒它，是全场最低的数量。在零售工作流上，它以 82.24% 的 pass@1 直接领先，超过所有专有模型。 Kimi-K3 同时也是最不稳定的模型之一。507 个任务中只有 68 个，即 13.41%，在全部 20 次尝试中都成功。 Claude Opus 5 则正好相反。它至少成功一次地解决的任务更少（79.09%；有 106 个任务完全难倒它），但在每一次尝试中都能完成基准测试的 47.53%。 更新的模型并不能解决这个问题。Claude Opus 5.5 在每次尝试平均值上高于 Claude Opus 5，为 67.16% 对 66.50%，并且至少成功一次地解决的任务更多。它在全部 20 次尝试中通过的任务数量完全相同：241 个。半点头部准确率完全没有换来额外的可靠性。 - Kimi-K3 至少成功一次地解决的任务比 Opus 5 多 75 个。 - Opus 5 稳定解决的任务比 Kimi-K3 多 173 个。 如果你要为涉及真实记录的工作选择模型，pass@20 是错误的参考列。 一致性的代价 能力比较通常止步于分数。对于任何部署者来说，真正相关的问题是成功完成一个工作单元的成本。我们将其衡量为每次成功任务尝试的成本。我们说任务尝试，是因为每个基准任务都会被反复运行，而成本按每次尝试产生，所以 pass@1 是与之匹配的质量分母。 我们取每个模型在完整 507 × 20 次运行中记录的 token 用量，并按 OpenRouter+ 上可获得的未折扣标价计价，剔除促销折扣，并排除声明量化的端点。输入、输出和缓存费率均来自每个模型的一个提供商端点。 然后我们将一次运行的成本除以成功的尝试次数： 每次成功任务尝试的成本 = 507 次尝试（每个任务一次）的估算成本 ÷ (507 × pass@1) 这是一个比较效率指数，不是账单，也不是服务单个生产请求的价格。它衡量的是单次成功，而不是一致性。我们接下来衡量一致性。 示例：GPT-5.4 进行 507 次尝试（每个任务一次尝试）的成本为 $43.49，pass@1 为 65.36%，因此 $43.49 ÷ (507 × 0.6536) = 每次成功任务尝试 $0.131。 帕累托成本前沿 如果没有任何其他模型同时不更贵且至少同样准确，那么该模型就位于前沿上。有三个模型符合条件；其他每个模型都至少在一个维度上被支配。 Figure-4 图 4：每次成功任务尝试的成本与 pass@1 的关系。带圈的点是帕累托成本前沿模型。 前沿有三个台阶。GPT-5.6 Sol 的每次成功成本最低，为 $0.127；GPT-5.4 以每次成功多 $0.004 的代价将 pass@1 提高 3.45 个百分点；Claude Opus 5.5 又以每次成功 $0.276 的代价再增加 1.80 个百分点。这三者都仍位于成本前沿线上，因为没有更便宜的模型能匹配其 pass@1。 Claude Opus 5 是最明显的例子：以每次成功尝试 $0.475 和 66.50% 的 pass@1，它比 $0.276 和 67.16% 的 Claude Opus 5.5 既更贵又更不准确。 现在为一致性定价 每次成功的成本奖励的是便宜且经常正确的模型。它不奖励每次都正确的模型。因此我们还计算了每次可靠任务的成本：完整 20 次运行的总成本除以模型在全部 20 次尝试中都通过的任务数。 每次可靠任务的成本 = 507 次尝试运行 20 次的估算成本 ÷ 20/20 通过的任务数 示例：GPT-6-Astra 整个运行的成本为 20 × $86.03 = $1,720.60，并且在每次尝试中都通过了 231 个任务，因此 $1,720.60 ÷ 231 = 每个可靠任务 $7.45。 表 3：在至少有一个观察到 20/20 任务的模型中，每次可靠任务成本最低的九个模型，按从低到高排序。估算美元，并非实际云账单。 模型 20/20 通过的任务数 估算成本，20 次运行 每次可靠任务的成本 GPT-5.4 128 (25.25%) $869.80 $6.80 GPT-6 Astra 231 (45.56%) $1,720.60 $7.45 Claude Opus 5.5 241 (47.53%) $1,880.77 $7.80 GPT-5.6 Sol 82 (16.17%) $800.00 $9.76 Claude Opus 5 241 (47.53%) $3,206.00 $13.30 Claude Sonnet 4.6 102 (20.12%) $1,587.60 $15.56 GPT-5.2 44 (8.68%) $878.00 $19.95 Kimi-K3 68 (13.41%) $1,406.40 $20.68 Qwen3.8-27B 38 (7.50%) $925.80 $24.36 现在按一致性排名。GPT-5.4 以 $6.80 成为最便宜的，尽管只有 128 个任务达标。GPT-6 Astra 以 $7.45 达到 231 个，而 Claude Opus 5.5 以 $7.80 达到并列最高的 241 个。 这三者中没有哪一个能压倒其他两者：每增加一个可靠任务，成本就更高。Claude Opus 5 也通过了 241 个，但成本为 $13.30，因此 Opus 5.5 完全压倒了它。GPT-5.6 Sol 的单次成功成本最低，为 $0.127，但每个可靠任务成本为 $9.76。获得正确答案最便宜的方式，并不是获得可靠答案最便宜的方式。 失败特征 我们为每个失败的轨迹分配一个确定性的诊断特征，而主要结论是可操作的：大约五分之四的失败是工具处理问题，而不是推理问题。在我们论文的表 5中的一项消融研究中： 失败特征 失败占比 工具使用 79.9% 错误的状态更新 10.3% 不完整的用户解决方案 7.0% 无状态变更操作 2.9% 这些是各模型占比和可观察标签的未加权平均值，并非唯一的因果解释。 实际模式很简单：智能体通常能走到尝试工作流的程度，然后无法从工具错误、失败的前置条件或空查找中恢复。这首先是一个重试和错误恢复问题，其次才是模型问题。 难度也因领域而异：在上文表 2 列出的模型中，零售平均 pass@1 为 59.52%，而汽车保险平均为 33.83%。 对此该怎么办。把 20/20 率当作设计输入，而不是最终判决。基准测试所依据的同一信号在生产中也可获得：在提交之前检查最终状态，而不是模型对它的总结。 对工具和系统错误进行分类，以便重试针对可恢复的错误。将工具面削减到工作流所需的范围。并且对无法低成本逆转的变更要求人工批准。我们尚未在此基准上测量其中任何一项带来的提升，而这正是该环境现在使其可测试的那类事情。 工作原理 ThinkingBox 是智能体沙箱，而 ThinkingBox-Bench 是用于评估智能体的数据集基准。本文顶部的图展示了循环；以下是每个部分的作用。 Figure-1a 图 5：上方图 1 中面板 A 的沙箱循环：隔离的工具会话、终端数据库状态、副作用、可执行评判器。 每个任务都定义了起始后端状态、用户目标、可用的 MCP 工具、领域策略，以及针对终端状态的可执行检查。模拟用户持有私有上下文（预订参考号、偏好或出生日期），仅在收到询问时才会透露。 每次尝试都会获得一个隔离的 MCP 会话，其状态是全新初始化的。同一任务的两次尝试绝不会共享数据库行或缓存的工具状态，这正是 20 次试验对比具有意义的原因。 最后，副作用提取器会推导出实际发生的变化，确定性评判器将其与要求的最终状态进行比较，接受任何能产生正确结果的轨迹，同时拒绝错误、缺失或多余的效果。对于没有明确数据库值的要求（“智能体是否披露了这不保证？”），则用一个狭窄的二元评分问题来处理语义。507 个任务中有 477 个仅根据状态评分；30 个增加了响应评分标准。 信任边界：模型看到任务、对话和工具模式。黄金状态、断言、评分内部逻辑和凭证保留在评估器一侧。 自己运行 ThinkingBox 现已登陆 Hugging Face，包括 测试框架 和 数据集。ThinkingBox-Bench 现在位于 OpenEnv 接口之后，每个完成的回合都会返回一个二元通过/失败奖励。发布的适配器专为评估而设计；单独的非基准场景可以在训练工作流中使用相同的接口。 开始之前 已在 Linux 和 WSL 上测试，需要 Python 3.11+、uv 和 Docker。你还需要在固定版本上检出 thinkingbox-data，以及用于智能体、模拟用户和评判器的模型端点。一个端点可以同时服务这三个角色，这是最简单的入门方式。OpenEnv 镜像仅启动 OpenEnv API；其他所有内容都需要你自己运行。 安装 # 1. OpenEnv + the ThinkingBox environment git clone https://github.com/huggingface/OpenEnv cd OpenEnv uv sync --project envs/thinkingbox_env --frozen # 2. The executable benchmark, at the pinned release git clone https://github.com/microsoft/thinkingbox-data git -C thinkingbox-data checkout thinkingbox-bench-v1.0 # 3. The ThinkingBox CLI, which provides `tb` uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox" 启动 Typesense 在第二个终端中，启动 Typesense 30.1 并等待其健康检查： mkdir -p .typesense-data docker run --rm -d --name thinkingbox-typesense \ -p 8108:8108 \ -v "$PWD/.typesense-data:/data" \ typesense/typesense:30.1 \ --data-dir /data --api-key=Fake --enable-cors until curl -fsS http://127.0.0.1:8108/health; do sleep 1; done 启动 MCP 服务器 在第三个终端中，启动 Session Proxy 和 MCP 服务器。 cd OpenEnv tb mcp-start --host 127.0.0.1 --port 7111 \ --servers "$PWD/thinkingbox-data/servers/servers.yaml" curl -fsS http://127.0.0.1:7111/health 启动 OpenEnv 服务器 回到第一个终端，根据指定你的三个模型的 ThinkingBox YAML 配置启动 OpenEnv 服务器（配置指南）： OPENENV_TB_CONFIG="$PWD/thinkingbox.yaml" \ uv run --project envs/thinkingbox_env --frozen server 检查就绪状态 在运行任何内容之前，先以就绪状态为门槛。在其可观察数据、配置和 Session Proxy 检查通过之前，它会返回 503。它无法观察 Typesense 或实时探测每个模型端点，因此请单独确认这些： curl -sS http://127.0.0.1:8000/ready 对回合评分 现在对一个真实回合进行评分。example_usage.py 仅重置并列出工具；对于智能体操作、效果和断言，请使用打包的评估器： echo "- sandbox_external_retail_group1.py:test_case_ST002_001" > one_task.yaml uv run --project envs/thinkingbox_env thinkingbox-eval \ one_task.yaml \ --config "$PWD/thinkingbox.yaml" \ --output results.jsonl \ --errors-output errors.jsonl \ --repeat 1 --message-timeout 1800 OpenEnv 适配器会将操作故障写入错误附属文件，以便可以重新运行，而不是与模型结果静默混合。规范结果必须解决或明确说明这些尝试；我们将系统错误计为不成功的试验。 运行以固定的框架提交、固定的数据发布和捆绑哈希为门槛，因此规范结果可验证，而非仅凭断言。 下一步走向 这项工作有用的部分不是我们的 pass@1 排行榜。而是环境。 如果你正在评估一个会触及真实记录的智能体： 1. 检查一次失败。 找一个干净终止却仍然失败的运行，看看数据库中实际发生了什么变化。这会重新定义你自己的评估所衡量的内容。 2. 复现一个任务，通过 OpenEnv 使用你自己的模型。 3. 报告一个重复指标，并定义它。 无论你的用例证明 k 是多少；说明你报告的是 best-of-k 还是 every-of-k，以及你是如何计算的。 更多细节可在以下链接中找到： - 环境： envs/thinkingbox_env - OpenEnv： https://huggingface.co/docs/openenv/environments/thinkingbox - 框架： microsoft/thinkingbox · 教程 - 基准： microsoft/thinkingbox-data · v1.0 发布 - 数据集查看器： microsoft/ThinkingBox-Bench - 论文： arXiv:2608.19741 或 HF - RL 训练（即将推出）： microsoft/thinkingbox-training ThinkingBox 代码采用 MIT 许可；基准数据采用 CDLA-Permissive-2.0；OpenEnv 环境以 OpenEnv 的 BSD-3-Clause 发布。 免责声明：公开基准中的每个任务都是合成重建。工作流和策略以真实 AI 代理企业模式为蓝本；客户并非真实存在。 ThinkingBox 和 ThinkingBox-Bench 由 Microsoft Copilot Studio 团队与 Toloka 合作构建，合作者来自匹兹堡大学、西北大学、哥伦比亚大学和加州大学欧文分校，他们曾在 Microsoft 实习。欢迎在下方评论区或 github 上提问 + OpenRouter 成本快照拍摄于 2026 年 9 月 20 日；Opus 5.5 定价依据 Anthropic 网站。