Microsoft 与 Hugging Face 发布 ThinkingBox，用后端状态评估 AI 智能体可靠性

Microsoft ThinkingBox 不是根据 AI 智能体生成的句子，而是根据它们留下的记录来打分，然后再考察它们能否连续二十次做到这一点。它现在可通过 Hugging Face 使用。

图 1：ThinkingBox 让智能体在隔离的 MCP 工具会话中运行，然后对其留下的终端后端状态和副作用进行评分。来自我们的 ThinkingBox 论文。

这是一篇由 Microsoft 和 Hugging Face 联合撰写的博客，特别感谢 Tommy Guy（Enderis AI 创始人，此前在 Microsoft）、来自 Hugging Face 的 Sergio Paniego，以及我们之前的实习生 Zhuochun Li（University of Pittsburgh）、Ali Keramati（UC Irvine）、Youngmin Ko（Northwestern）在共同撰写/审阅方面所做的努力。

一位客户写信求助。她价值 $745 的厨房电器在 Nashville 配送中心陷入了快递“异常”状态，已经超过预计送达日期十五天。

这个 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：我们报告的三个数字，以及每个数字回答的问题。

我们在这篇博客文章中使用观测到的 20/20，作为 507 项任务中有多少项通过了 20 次中的 20 次的字面计数。没有估计量，没有平滑。

从熟悉的视角开始。下表报告了 pass@1，即单次尝试分数估计，并按领域拆分。这是大多数排行榜发布的数字，单独来看就像普通的能力排名。

表 2：ThinkingBox-Bench 按领域划分的 pass@1（%）。每个模型在每项任务上都进行 20 次重复试验。粗体表示组内第一；下划线表示第二名。单次尝试分数估计的标准误见我们的 ThinkingBox 论文中的表 4。

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 任务的模型中，每个可靠任务成本最低的九个模型，按从低到高排序。估算美元金额，并非实际云账单。

现在按一致性排名。 GPT-5.4 以 $6.80 成为最便宜的模型，尽管只有 128 个任务达到门槛。GPT-6 Astra 达到 231 个，成本为 $7.45；Claude Opus 5.5 达到并列最高的 241 个，成本为 $7.80。

这三者没有一个全面优于另外两个：每增加一个可靠任务，成本都会更高。Claude Opus 5 也通过了 241 个任务，但成本为 $13.30，因此 Opus 5.5 完全优于它。GPT-5.6 Sol 的单次成功成本最低，为 $0.127，但每个可靠任务的成本为 $9.76。获得正确答案的最便宜方式，并不是获得可靠答案的最便宜方式。

失败特征

我们为每条失败轨迹分配一个确定性的诊断特征，核心结论具有可操作性：大约五分之四的失败源于工具处理，而非推理。根据我们论文中的表 5所示的消融研究：

这些是各模型占比的未加权平均值，也是可观察标签，并非唯一的因果解释。

实际模式很简单：智能体通常能推进到尝试执行工作流的阶段，然后在从工具错误、前置条件失败或空查询结果中恢复时失败。这首先是重试和错误恢复问题，其次才是模型问题。

难度也因领域而异：在上文表 2 所列模型中，零售领域的 pass@1 平均为 59.52%，而汽车保险领域平均为 33.83%。

该如何应对。 将 20/20 通过率视为设计输入，而不是最终判决。基准测试评分所依据的同一信号也可在生产环境中使用：在提交之前检查终止状态，而不是模型对该状态的总结。

对工具和系统错误进行分类，让重试针对可恢复的错误。将工具范围缩减到工作流所需的内容。并且对那些无法以低成本撤销的变更要求人工批准。我们尚未衡量这些措施在该基准上的提升幅度，而这正是该环境现在使之可测试的事情。

工作原理

ThinkingBox 是智能体沙盒，而 ThinkingBox-Bench 是用于评估智能体的数据集基准。本文顶部的图示展示了这个循环；下面说明各个部分的作用。

图 5：上文图 1 中面板 A 的沙盒循环：隔离的工具会话、终端数据库状态、副作用、可执行评判器。

每个任务都定义了一个起始后端状态、一个用户目标、可用的 MCP 工具、领域策略，以及可在终端状态上执行的检查。一个模拟用户持有私有上下文（预订参考、偏好或出生日期），并且只有在被询问时才会透露。

每次尝试都会获得一个隔离的 MCP 会话，并使用全新初始化的状态。同一任务的两次尝试绝不会共享数据库行或缓存的工具状态，这正是让 20 次试验比较有意义的原因。

最后，副作用提取器会推导出实际发生了什么变化，而确定性的评判器会将其与要求的最终状态进行比较，接受任何能够产生正确结果的轨迹，同时拒绝错误、缺失或额外的影响。对于没有清晰数据库值的要求（“该代理是否披露这并非有保证？”），一个狭窄的二元评分问题会处理其语义。507 个任务中有 477 个仅按状态评分；30 个增加了响应评分标准。

信任边界：模型会看到任务、对话和工具模式。标准状态、断言、评分内部机制和凭据都保留在评估器一侧。

自己运行

ThinkingBox 现在已在 Hugging Face 上发布，包括测试框架和数据集。ThinkingBox-Bench 现在位于 OpenEnv 接口之后，每个完成的 episode 都会返回一个二元的通过/失败奖励。发布的适配器是为评估而设计的；单独的非基准场景可以在训练工作流中使用同一个接口。

开始之前

已在 Linux 和 WSL 上测试，要求 Python 3.11+、uv 和 Docker。你还需要在固定发布版本上的 thinkingbox-data checkout，以及用于代理、模拟用户和评判器的模型端点。一个端点可以承担全部三个角色，这是最简单的入门方式。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

为一个 episode 评分

现在为一个真实 episode 评分。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 排行榜，而是这个环境。

如果你正在评估一个会触及真实记录的代理：

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 合作构建，并有来自匹兹堡大学、西北大学、哥伦比亚大学和 UC Irvine、曾在 Microsoft 实习的合作者参与。欢迎在下方评论区或 github 上提问

⁺ OpenRouter 成本快照采集于 2026 年 9 月 20 日；Opus 5.5 定价依据 Anthropic 网站。