Microsoft ThinkingBox 用数据库终态而非生成句子评估智能体
The Agent Said It Was Done. The Database Disagreed.
Microsoft ThinkingBox 现可通过 Hugging Face 使用，它根据智能体留下的终态后端状态和副作用评分，而不是根据生成的句子。该基准覆盖 507 个有状态业务流程，每项任务在干净后端上独立运行 20 次，并报告 pass@1、pass@20 与观察到的 20/20。
它按终态数据库记录和副作用而不是最终回复或合法工具调用来给智能体打分，再用二十次重复区分单次成功和每次都对。
Microsoft ThinkingBox 依据 AI 智能体留下的记录而非其生成的句子来评分，然后检验它们能否连续二十次做到这一点。它现已通过 Hugging Face 提供。
图 1：ThinkingBox 让智能体在隔离的 MCP 工具会话中运行，然后对其留下的终端后端状态和副作用进行评分。摘自我们的 ThinkingBox 论文。
这是 Microsoft 与 Hugging Face 的联合博客，特别感谢 Tommy Guy（Enderis AI 创始人，曾任 Microsoft）、来自 Hugging Face 的 Sergio Paniego，以及我们的前实习生 Zhuochun Li（匹兹堡大学）、Ali Keramati（加州大学尔湾分校）、Youngmin Ko（西北大学）在共同撰写/审阅方面的贡献。
一位顾客来信。她价值 $745 的厨房电器卡在纳什维尔配送中心的快递“exception”状态，已超出预计送达日期十五天。
AI 智能体做得很仔细。九次工具调用：它拉取订单、检查物流、查询她的客户资料、两次搜索退款政策、确认不存在工单、新建一张工单、记录时间线，并正确解读了政策；她的账户细分确实不符合延迟送达补偿的资格。
然后它将工单关闭为 已解决，并回复“ 既然您的问题已解决，还有什么我可以协助您的吗？ ”
有两处错误。承运商异常仍然未关闭，因此要求的终态应为 暂停，等待解决。而且顾客从未得到她实际所问问题的真正答复。
检查工具调用的 AI 评分器会看到九次格式正确的调用。检查智能体是否写入数据库的评分器也会看到这一点。真正不一致的是数据库。
ThinkingBox 衡量的正是这一差距。在 507 个有状态业务工作流中，针对各种 LLM 模型各运行 20 次，它根据终端后端状态和副作用对智能体评分。本文介绍我们发现了什么、一致性的代价，以及如何通过 OpenEnv 自行运行该基准测试。
你可以自己运行这个例子：上面的示例改编自基准任务 sandbox_external_retail_group1.py:test_case_ST003_006，失败的可执行检查只有一个字段：工单状态为 solved，而要求的终态是 hold。完整轨迹见 我们论文的附录 D.4，案例 3。
目录
想在阅读结果之前先试一试？跳到 自行运行 一节。
工具调用不等于结果
最终回复和有效的工具调用只是代理指标。智能体可能听起来正确，却留下错误的值、改错记录，或产生额外的副作用。只有它留下的记录才能定论。
差距相当大。在一项覆盖 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 次，看看这个分数能保留多少。
图 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%。
模型能做一次与它每次都做之间的差距，就是整个故事。
你能信赖智能体背后的模型吗？
图 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。
帕累托成本前沿
如果没有其他模型同时不更贵且至少同样准确，则该模型位于前沿。有三个模型符合条件；其余每个模型都至少在一个轴上被支配。
图 4：每次成功任务尝试的成本与 pass@1 的对比。带圈的点为帕累托成本前沿模型。
前沿分为三级。GPT-5.6 Sol 的每次成功成本最低，为 $0.127；GPT-5.4 以每次成功多 $0.004 的代价将 pass@1 提高 3.45 个百分点；Claude Opus 5.5 再提高 1.80 个百分点，每次成功成本为 $0.276。三者都留在成本前沿线上，因为没有更便宜的模型能达到相同的 pass@1。
Claude Opus 5 是最明显的例子：每次成功尝试 $0.475、pass@1 为 66.50%，既比 Claude Opus 5.5（$0.276、67.16%）更贵，也不如它准确。
现在为一致性定价
单次成功成本奖励的是便宜且经常正确的模型。它并不奖励每次都正确的模型。因此，我们还计算单项可靠任务成本：完整 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 是用于评估智能体的数据集基准。本文顶部的图展示了该循环；下面说明各部分的作用。
图 5：上文图 1 中面板 A 的沙盒循环：隔离的工具会话、数据库终态、副作用、可执行评判器。
每个任务定义起始后端状态、用户目标、可用的 MCP 工具、领域策略，以及对终态的可执行检查。模拟用户持有私有上下文（预订参考号、一项偏好或出生日期），并且只在被询问时才会提供。
每次尝试都会获得一个状态全新初始化的隔离 MCP 会话。同一任务的两次尝试绝不会共享数据库行或缓存的工具状态，这正是使 20 次试验的比较有意义的原因。
结束时，副作用提取器推导实际发生了什么变化，确定性评判器将其与所需终态比较，接受能产生正确结果的任何轨迹，同时拒绝错误、缺失或多余的效果。对于没有清晰数据库值的要求（“智能体是否披露了这一点并不保证？”），由一个范围狭窄的二元评分问题处理语义。507 个任务中有 477 个仅按状态评分；30 个额外加入了回复评分标准。
信任边界：模型可以看到任务、对话和工具 schema。黄金状态、断言、评分内部实现和凭证留在评估器一侧。
自己运行
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 适配器会把运行失败写入 errors sidecar，以便重新运行，而不是悄无声息地与模型结果混在一起。规范结果必须解决或明确计入这些尝试；我们将系统错误计为未成功的试验。
运行以固定的框架提交、固定的数据发布和 bundle 哈希作为门槛，因此规范结果是可核验的，而不是仅仅被断言。
接下来的方向
这项工作有用的部分并非我们的 pass@1 排行榜，而是这个环境。
如果你正在评估会接触真实记录的智能体：
- 检查一次失败。 找一次干净终止却仍然失败的运行，看看数据库里实际发生了什么变化。这会重新框定你自己的评测在衡量什么。
- 复现一个任务，通过 OpenEnv 使用你自己的模型。
- 报告一个重复指标，并定义它。 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 网站为准。
来源：Hugging Face Blog · huggingface.co