The Agent Said It Was Done. The Database Disagreed.

代理说已经完成了，但数据库却不同意

返回文章列表

[0

[-1

企业

]

文章

发布于2026年10月3日

点赞

2

[

图欣·昆杜

tuhink

关注

microsoft

微软ThinkingBox通过评估AI代理留下的记录而非生成的语句来评分，并进一步测试其能否连续20次完成任务。该工具现已通过Hugging Face发布。

图1：ThinkingBox将代理部署到隔离的MCP工具会话中，随后根据终端后端状态和遗留的副作用进行评分。引自我们的ThinkingBox论文。

#### 本文由微软与Hugging Face联合发布，特别感谢Enderis AI创始人Tommy Guy（前微软员工）、Hugging Face的Sergio Paniego以及我们的前实习生李卓春（匹兹堡大学）、阿里·卡拉马蒂（UC尔湾）、Youngmin Ko（西北大学）的共同撰写与评审。

一位客户发来求助。她的价值745美元的厨房用具在纳什维尔分拨中心被困在快递"异常"状态中，已超过预估送达日期15天。

AI代理进行了细致的操作。九次工具调用：它提取订单信息、检查物流状态、查询客户档案、两次检索退款政策、确认不存在工单、创建新工单、记录时间线，并正确解读政策；她的账户段确实不符合延迟送达补偿条件。

随后它将工单标记为已解决，并回复："由于您的问题已解决，是否还有其他需要协助的？"

存在两个问题。承运商异常状态仍然未解决，因此所需最终状态应处于"待处理"状态。客户从未真正得到她实际询问问题的解答。

检查工具调用的AI评分器会看到九次结构良好的调用。检查代理是否写入数据库的评分器也会看到相同结果。真正产生分歧的是数据库本身。

这种差距正是ThinkingBox所衡量的。在507个状态化业务流程中，每个流程针对不同LLM模型运行20次，它根据终端后端状态和副作用对代理进行评分。本文将介绍我们的发现、一致性成本以及如何通过OpenEnv自行运行基准测试。

您可自行验证：上述示例改编自基准测试任务sandbox_external_retail_group1.py:test_case_ST003_006，失败的可执行检查仅涉及单个字段：工单状态显示为"已解决"，而所需最终状态应为"待处理"。完整追踪记录见我们论文附录D.4案例3。

目录

• 工具调用不等于结果
• 一次成功不等于可靠性
• 能否依赖您代理背后的模型？
• 一致性成本
• 失败特征
• 实现原理
• 自行运行
• 未来发展方向

想在阅读结果前先尝试？跳至"自行运行"章节。

差距相当显著。在一项涵盖12个LLM模型共121,680次有效试验的常见集合消融实验中，79,853次尝试未能通过可执行检查。这些失败案例中，67.24%仍能正常终止、调用状态更改工具且未报告最终工具错误。但可执行检查仍发现其中77.61%存在字段值错误，43.30%出现非预期附加效果，25.36%缺少必要效果。这些状态检查结果存在重叠。

轨迹是一种主张。数据库状态是证据。重复是信任测试。

一次成功不代表可靠性

一个代理若某次正确处理退款，但接下来四次处理失败，就不能被视为可靠的退款代理。因此每个任务需运行20次独立测试，均从相同的干净后端启动，我们报告以下三个不同指标：

表1：我们报告的三个数值及其对应的问题

| 指标 | 测量内容 | 回答的问题 | |------------|------------------------------|--------------------------------| | pass@1 | 所有尝试中成功比例 | 它通常表现如何？ | | pass@20 | 任务解决比例（至少一次成功） | 在20次尝试中能否做到？广度 | | Observed 20/20 | 实际通过所有20次尝试的任务数 | 是否始终正确？ |

本文使用observed 20/20作为字面计数，表示507个任务中有多少任务在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 | 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 | 0.74 | 4.66 | - |

Claude Opus 5.5总体领先，得分为67.16%，比Claude Opus 5高出0.66个百分点。在机动车保险领域，Kimi-K3以50.80%的得分领先，而Grok-4.3在该领域仅得2.60%。领域表现差异显著，零售领域最高得分（82.24%）与最低得分（11.28%）相差70.96个百分点。

图2：每个模型的单次尝试得分在20次重复后保留了多少。

只有三个模型保留了大部分单次尝试通过率：GPT-6 Astra保留了其单次尝试通过率的78%，Claude Opus 5.5和Claude Opus 5各自保留了71%。在另一端，GLM-5.1、Kimi-K2.6和DeepSeek-V4-Pro各自仅保留了约8%。

模型一次执行能力与每次执行能力之间的差距就是整个故事。

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

图3：广度与一致性相互拉扯。展示了十八个模型中的十二个，为清晰起见省略了六个单次尝试通过率低于33%的模型。

Kimi-K3是我们测试模型中覆盖范围最广的。它至少成功完成93.89%的基准测试任务：507个任务中完成了476个。仅有31个任务完全击败它，这是领域内最低的失败任务数。在零售工作流程中，Kimi-K3以82.24%的单次尝试通过率遥遥领先，超过所有专有模型。

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个。头条准确率提升0.5个百分点并未带来任何额外的可靠性。

• 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美元，具有65.36%的pass@1，因此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以每成功0.276美元的代价再增加1.80个百分点。这三个模型始终保持在成本前沿线上，因为没有更便宜的模型能匹配它们的pass@1表现。

Claude Opus 5 是最明显的例子：以每次成功尝试 0.475 美元和 66.50% 的 pass@1 通过率，它既比 Claude Opus 5.5（0.276 美元和 67.16% 通过率）更昂贵，准确率也更低。

现在看价格一致性

每次成功成本奖励的是既便宜又经常正确的模型，而不是每次都能正确的模型。因此我们还计算了每个可靠任务的成本：将完整 20 次运行活动的成本除以模型在 20 次尝试中全部通过的任务数量。

每个可靠任务成本 = 20 次运行 507 次尝试的预估成本 ÷ 20 次尝试中全部通过的任务数

示例：GPT-6-Astra 的活动成本为 20 × 86.03 美元 = 1,720.60 美元，且每次尝试都通过了 231 个任务，因此每个可靠任务成本为 1,720.60 美元 ÷ 231 = 7.45 美元。

表 3：在至少有一次 20/20 任务的模型中，每个可靠任务成本最低的九个模型，按成本从低到高排序。单位为预估美元，非实际云账单金额。

通过 20/20 任务数 | 20 次运行预估成本 | 每个可靠任务成本 --- | --- | --- 128 (25.25%) | 869.80 美元 | 6.80 美元 231 (45.56%) | 1,720.60 美元 | 7.45 美元 241 (47.53%) | 1,880.77 美元 | 7.80 美元 82 (16.17%) | 800.00 美元 | 9.76 美元 3,206.00 美元 | 13.30 美元 102 (20.12%) | 1,587.60 美元 | 15.56 美元 44 (8.68%) | 878.00 美元 | 19.95 美元 68 (13.41%) | 1,406.40 美元 | 20.68 美元 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%，而汽车保险领域平均 pass@1 仅为 33.83%。

应对方法：将 20/20 通过率视为设计输入而非最终结论。基准测试中评估的信号在生产环境中同样可用：在提交前检查终端状态，而非模型对其的摘要。

对工具和系统错误进行分类，使重试能针对可恢复的错误。将工具界面精简到工作流所需范围。对无法廉价撤销的更改要求人工批准。我们尚未在该基准上测量这些措施的效果，这正是环境现在使其可测试的典型场景。

实现方式

ThinkingBox 是智能体沙盒，而 ThinkingBox-Bench 是用于评估智能体的数据集基准。本文顶部的图表展示了工作流程；以下是各部分的具体功能。

图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 + ThinkingBox环境
git
clone
https://github.com/huggingface/OpenEnv
cd
OpenEnv
uv
sync
--project envs/thinkingbox_env --frozen
# 2. 固定版本的可执行基准
git
clone
https://github.com/microsoft/thinkingbox-data
git -C thinkingbox-data checkout thinkingbox-bench-v1.0
# 3. ThinkingBox CLI，提供`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服务器

在第三个终端中启动会话代理和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

检查准备状态

在运行任何操作之前检查就绪状态。在可观察数据、配置和会话代理检查通过之前，它会返回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排行榜，而在于环境本身。

如果你正在评估接触真实记录的代理：

- 检查失败案例。找到一个干净终止但仍失败的运行，并查看数据库中实际发生了什么变化。这将重新定义你自己的评估所衡量的内容。

- 通过OpenEnv使用你自己的模型重现一个任务。

- 报告重复度量指标，并定义它。无论你的用例证明的k值是多少；说明你报告的是最佳k次还是全部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

- 强化学习训练（即将推出）：microsoft/thinkingbox-training

ThinkingBox代码采用MIT许可证；基准数据采用CDLA-Permissive-2.0许可证；OpenEnv环境遵循OpenEnv的BSD-3-Clause许可证。

免责声明：公共基准中的每个任务都是合成重建。工作流程和策略基于真实的AI代理企业模式；客户并非真实存在。

ThinkingBox和ThinkingBox-Bench由微软Copilot Studio团队与Toloka合作开发，合作方包括匹兹堡大学、西北大学、哥伦比亚大学和加州大学欧文分校的微软实习生。

欢迎在下方评论区或GitHub上提问。

+ OpenRouter成本快照于2026年9月20日获取；Opus 5.5定价依据Anthropic网站。

## 本文提到的数据集 1

## 本文提到的论文 1

更多来自该作者的内容

## Hugging Face模型在Foundry托管计算上

21

2026年7月7日

## 差分Transformer V2

53

2026年1月20日

### 社区

编辑

预览

通过将文件拖入文本输入框、粘贴或

点击此处

上传图片、音频和视频。

点击此处上传图片

评论

· 注册或登录以发表评论