ThinkingBox 基准测试揭示了 AI 代理在 507 个业务工作流中的稳定性差距

TL;DR

ThinkingBox 现已在 Hugging Face 上提供，通过检查 AI 代理留下的最终数据库状态来评估其表现，揭示出大多数代理在单次运行中成功，但在 20 次尝试中无法重复正确结果，且 12 个 LLM 之间存在显著的成本-一致性权衡。

一次工具调用不等于结果

代理可以发出有效的工具调用，但仍会产生错误的数据库记录。

  • 在对 12 个 LLM 进行的 121,680 次消融实验中，79,853 次尝试未通过可执行性检查。
  • 67.24 % 的失败尝试干净终止，未报告工具错误，但仍改变了状态。
  • 在失败的轨迹中，77.61 % 的字段值错误，43.30 % 产生了意外副作用，25.36 % 缺失了必需的效果。

"一条轨迹是一种声明。数据库状态是证据。重复是信任的测试。"

因此，该基准测试根据 终端后端状态 评分，而非表面对话或工具调用次数。

一次成功不代表可靠性

将每个任务运行 20 次，可揭示代理可信赖的频率。

报告了三个指标：

指标 衡量内容 回答的问题
pass@1 所有尝试中成功的比例 模型通常表现如何？
pass@20 在 20 次尝试中至少成功一次的任务比例 它能否解决该任务？
Observed 20/20 在 全部 20 次尝试中均成功的任务数量 它是否始终正确？

博客重点关注 Observed 20/20 —— 即每次重复都通过的任务的实际计数。

你能依赖你代理背后的模型吗？

广度（pass@20）和一致性（Observed 20/20）在不同模型间存在分歧。

  • Kimi‑K3 至少一次成功解决 93.89 % 的任务（最广的广度），但仅实现 13.41 % 的 Observed 20/20。
  • Claude Opus 5 至少一次成功解决的任务较少（79.09 %），但达到 47.53 % 的 Observed 20/20，为最高一致性。
  • Claude Opus 5.5 提升了 pass@1（67.16 % vs 66.50 %），但 并未 增加始终正确的任务数量（仍为 241 个 Observed 20/20）。

"如果你选择一个用于操作真实记录的工作模型，pass@20 是你应该避免查看的列。"

一致性带来的成本

每次成功任务的成本 由 token 使用量按 OpenRouter 列表价格计算。

  • GPT‑5.4：507 次尝试花费 $43.49 → $0.131 每次成功任务。
  • GPT‑5.6 Sol：每次成功任务成本最低，为 $0.127。
  • Claude Opus 5.5：每次成功任务成本为 $0.276，准确率更高。

帕累托成本前沿

三个模型位于前沿（没有其他模型在更便宜的同时更准确）：

  1. GPT‑5.6 Sol – 每次成功成本最低。
  2. GPT‑5.4 – 每次成功多花 $0.004，获得适度的准确率提升。
  3. Claude Opus 5.5 – 每次成功花费 $0.276，进一步提升 1.8 % 的准确率。

每个可靠任务的成本（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
… … … …

单次正确答案的最便宜模型，并非始终正确答案的最便宜模型。

失败特征

四种诊断类别解释了大多数失败。

特征 失败占比
工具使用 79.9 %
错误的状态更新 10.3 %
不完整的用户解决 7.0 %
无状态变更操作 2.9 %

主要问题是工具处理错误，而非模型推理。代理经常在工具调用失败的流程阶段无法恢复，表明需要更好的重试和错误恢复逻辑。

工作原理

ThinkingBox 提供沙箱环境和基准数据集（ThinkingBox‑Bench）。

  1. 任务定义 – 初始后端状态、用户目标、可用的 MCP 工具、策略和可执行检查。
  2. 隔离的 MCP 会话 – 每次 20 次重复均从全新的数据库快照开始。
  3. 代理执行 – 模型与工具交互，更新状态，并生成最终响应。
  4. 副作用提取 – 记录实际的数据库变更。
  5. 确定性裁判 – 将提取的状态与所需最终状态进行比较；任何达到正确状态的轨迹均视为通过。

所有评估逻辑在评估者端运行；模型从未看到黄金状态或评分代码。

自行运行

ThinkingBox 已在 Hugging Face 上发布，支持完整的 OpenEnv 集成。

前提条件

  • Linux/WSL，Python 3.11+，uv，Docker。
  • 克隆 OpenEnv、thinkingbox-data 的固定版本，并安装 thinkingbox CLI。

快速入门（摘录）

# 克隆并安装 OpenEnv + ThinkingBox 环境
git clone https://github.com/huggingface/OpenEnv && cd OpenEnv
uv sync --project envs/thinkingbox_env --frozen

# 克隆数据仓库 v1.0
git clone https://github.com/microsoft/thinkingbox-data && \
  git -C thinkingbox-data checkout thinkingbox-bench-v1.0

# 安装 CLI
uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox"

然后按照博客描述，在三个独立终端中启动 Typesense、MCP 会话代理和 OpenEnv 服务器。完成就绪检查后，评估单个任务：

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 \
  --repeat 1 --message-timeout 1800

CLI 返回二元通过/失败奖励，并记录任何系统错误以确保可复现性。

未来方向

该基准测试的主要贡献是 环境，它使可重复性和基于状态的评分易于采用。

对实践者的建议：

  1. 检查失败 – 查看实际的数据库变更，而不仅仅是最终对话。
  2. 使用 OpenEnv 用你自己的模型复现任务。
  3. 报告重复指标（例如 best-of-k 或 every-of-k），并明确说明聚合方法。

所有代码均为开源（沙箱为 MIT 许可，数据为 CDLA‑Permissive‑2.0 许可）。该基准测试仍为合成数据，但模拟了真实企业级代理模式。

资源

  • ThinkingBox 环境：https://huggingface.co/docs/openenv/environments/thinkingbox
  • ThinkingBox‑Bench 数据集：https://huggingface.co/datasets/microsoft/ThinkingBox-Bench
  • 论文：arXiv:2608.19741
  • GitHub 仓库：microsoft/thinkingbox，microsoft/thinkingbox-data，microsoft/thinkingbox-training（RL 训练即将发布）

Sources