Agent 说「办好了」，数据库说没有：微软开源 ThinkingBox，67% 的失败连报错都不给

一台 745 美元的厨房电器，卡在纳什维尔配送中心的承运商异常里，比预计送达日晚了 15 天。

Agent 接手之后动作相当漂亮：拉订单、查物流、查客户档案、两次核对退款政策、确认没有既有工单、新建工单、写入时间线，还准确读出这位客户的等级确实不符合迟到补偿条件。九次工具调用，零次报错。

然后它把工单状态改成 solved，回复了一句「您的问题已解决，还有什么可以帮您？」

要求终态是 hold。承运商异常根本没关闭。

这不是段子，是任务 sandbox_external_retail_group1.py:test_case_ST003_006 记下来的真实轨迹。

第一章：Agent 说「办好了」，数据库说没有

最扎心的是，Agent 每一步都说对了：客户等级推断没错，退款政策理解没错，一个环节都没跳过。

所以它汇报的时候底气十足。问题是账本不同意。

ThinkingBox 给这件事下了个很硬的定义：轨迹是说法，数据库状态是证据。听人汇报不如查账本，汇报会说漂亮话，账本不会。

这条定义顺带划了条界线。如果你只是做客服问答，问完给一段回复，看最终回答就够了；如果你要改动订单、退款、工单、账户状态，那就必须去数据库里核对终态。前者说错一句顶多不好听，后者写错一个字段就是真金白银。

想先把 Agent 这幅全景图补齐的，可以翻这篇 AI Agent 全景解读。

第二章：507 个任务，每个跑 20 遍，它到底在测什么

微软联合 Hugging Face 在 2026 年 10 月 4 日放出这套东西时，摆明了不想再做一套给聊天打分的榜单。

它做的是 507 个有状态业务工作流，覆盖零售、旅游与酒店、车险、数字银行 IT、咨询 IT 与 HR。每个任务单独跑 20 次，每一次都从全新重置的隔离后端开始，两次尝试之间不共享任何数据库行，也不共享工具缓存。

判卷方式更直接：477 个任务只看数据库状态，另外 30 个在数据库之外再加一层回答性 rubric。工具全部以 MCP server 的形式暴露，任何会说 MCP 的 Agent 都能接上去。

还有一层设计我很欣赏：模拟用户握着私密上下文，订单号、偏好、出生日期都在它那儿，Agent 不问，它就不给。关键信息是问出来的，不是猜出来的。

规模上，按微软与 Hugging Face 联合博客的口径，一共 121,680 次有效试验，覆盖 12 个模型，其中 79,853 次没能通过可执行校验。

第三章：三个指标，把「能做」和「敢交」彻底分开

结论先放这儿：pass@1 高，代表它通常行；observed 20/20 高，才代表它能交付。

三个指标各管一个问题：

• pass@1：单次尝试的成功率，回答「它通常表现如何」。
• pass@20：20 次里至少成功一次的任务占比，回答「它到底能不能做」。
• observed 20/20：20 次全部通过的任务数，回答「它每次都对吗」。

pass@1 这一栏，Claude Opus 5.5 拿到 67.16%，Opus 5 是 66.50%，GPT-5.4 65.36%，GPT-5.6 Sol 61.91%，Claude Sonnet 4.6 59.19%，GPT-6 Astra 58.31%。垫底的几位更值得看：GPT-5.2 只有 46.28%，Claude Opus 4.6 32.09%，o3-pro 19.31%，Grok-4.3 14.38%。

开源权重这边，Kimi-K3 以 57.37% 领先，零售单项 82.24% 领跑全场；Qwen3.8-27B 51.70%，DeepSeek-V4-Pro 43.26%，Kimi-K2.6 37.66%，GLM-5.1 33.19%，Qwen3.6-27B 32.94%。尾部是 Qwen3.5-9B 5.65%、Mistral-Large-3 4.66%。

真正打脸的在下一组数字。Kimi-K3 在 20 次里至少成功一次的任务有 476 个，也就是 507 个任务的 93.89%，看着像全能选手。可 20 次全部通过的只有 68 个，13.41%。Claude Opus 5.5 和 Opus 5 各拿到 241 个全过，47.53%。

十次里能做到九次，和十次都能做到，是两种不同的东西。

20 次连跑还能保住大部分 pass@1 表现的，只有 GPT-6 Astra（78%）、Claude Opus 5.5 和 Opus 5（各 71%）；GLM-5.1、Kimi-K2.6、DeepSeek-V4-Pro 大概只保住 8%。

第四章：67% 的失败，连一声报错都不给

这一段是我最在意的地方。

那 79,853 次没通过可执行校验的试验里，67.24% 结束得干干净净：正常终止、调用了会改状态的工具、最后一条工具调用没有报错。看日志，一切顺利。

实际行动却全错了。拆开看，77.61% 写错了字段值，43.30% 产生了不该有的额外副作用，25.36% 漏掉了必须的状态变更。三类互相重叠，别把它们加起来。

这意味着一件事。你要是拿「有没有报错」当健康检查，等于把三分之二的失败全放过去了。仪表盘一片绿，数据已经脏了。

说实话，看到这个比例我有点心疼做线上验收的同学。trace 看得眼睛发酸，真正要命的东西却藏在数据库的行字段里。

第五章：八成栽在工具调用，不是模型笨

按根因分：79.9% 是工具处理，10.3% 是改错了地方，7.0% 是没做完，2.9% 是压根没动作。

这个分布比排名有信息量得多。大头不在推理能力，在接口习惯：参数怎么填、返回值怎么解析、什么时候该调不该调，全是工程活儿。

领域差异也印证了这点。零售 pass@1 平均 59.52%，车险只有 33.83%。车险不见得更难推理，只是政策分支更多、必填字段更多，工具面一宽，模型就容易走丢。想把这块地基夯实，推荐读 MCP 协议完全指南。

成本这笔账也要换个算法。按拿到一个可交付结果算，GPT-5.4 约 6.80 美元，GPT-6 Astra 约 7.45 美元，Claude Opus 5.5 约 7.80 美元。每 token 的标价是一回事，每个可靠结果的成本是另一回事，两者经常不在同一个排序上。

第六章：你自己跑一遍，从 Typesense 到第一条评分

框架 MIT 开源，仓库在 github.com/microsoft/thinkingbox，数据集 microsoft/ThinkingBox-Bench 放在 Hugging Face。现在它接在 OpenEnv 接口后面，每个 episode 只返回一个二值 pass/fail 奖励。

前置条件不多，但一个都不能缺：Linux 或 WSL、Python 3.11 以上、uv、Docker，再加一个 Typesense 数据库、一个 MCP server，以及 agent、模拟用户、judge 三个模型端点。让一个端点同时兼任这三个角色，是最省事的起步方式。

git clone https://github.com/huggingface/OpenEnv
cd OpenEnv
uv sync --project envs/thinkingbox_env --frozen

git clone https://github.com/microsoft/thinkingbox-data
git -C thinkingbox-data checkout thinkingbox-bench-v1.0

uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox"

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

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_TB_CONFIG="$PWD/thinkingbox.yaml" uv run --project envs/thinkingbox_env --frozen server

curl -sS http://127.0.0.1:8000/ready

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

两个坑提前说。第一，就绪接口会一直返回 503，直到它可观测的数据、配置和 Session Proxy 检查全部通过；它看不到 Typesense，也不主动探测模型端点，这两处你得单独确认。第二，配置文件不在这几行命令里，动手前先翻仓库说明。运行期故障会写进 errors sidecar 文件方便你重跑，不会混进模型成绩里。

第七章：不装这套东西，也能偷走的验收五步

说实话，多数团队没必要把整套沙箱搬回家。真正值钱的是它的验收思路，流程照抄就行。

• 1. 先写终态：列出必须被改的行和字段，以及绝对不能被碰的行。
• 2. 前后快照：从已知 fixture 重置，跑完 agent 再 diff 一遍数据。
• 3. 查副作用：断言无关的表和记录一次都没被动过。
• 4. 重复跑：每个任务至少 10 到 20 次，把 pass@1 和「全通过」分开报。
• 5. 失败分桶：错值、多余副作用、漏改、没动作，先修最大的那桶。按这套基准的统计，你多半会先撞上工具处理。

检查器本身可以让 coding agent 帮你写，把这段话直接丢过去：

给定这个工作流的输入 fixture 与要求终态，生成一个 pytest 检查器：断言必需的行与字段被改成指定值；断言标记为不可变的表和记录前后完全一致；断言不存在超出允许集合的新增行；最后打印失败摘要，按错值、多余副作用、漏改、没动作分类。

这套链路也离不开可观测能力，trace、评测、回归要串起来，可以参考 LangSmith 可观测与评测。

第八章：写在最后

边界先说清楚，不然这套数据太容易被误读。

507 个工作流是精心设计的替身，不是你公司那套系统。分数反映的是一套 agent loop 和工具配置，换个脚手架数字可能就变。跨模型排名只是这套 harness 下的一次快照，不是永久排序。成本估算也来自基准自己那回跑，取决于重试次数和当时的定价。

确定性判定比 LLM 打分噪声小，但上限就是你写下的要求终态：写太严，另一种合理解法会被误杀；写太松，有害副作用就溜过去了。仓库当时只有约 85 个 star、main 上 16 次提交，别把生产流水线全押上去，先去读 issue。

47.53% 不等于 Agent 没用。它说明的是，让 Agent 无人监督跑完多步有状态工作流，还没到能托付的程度。真实落地还得靠人工复核高危写操作、收窄工具面、带上校验重试，这些补丁今天就能加。

模型版本命名在不同来源里并不统一，博客和论文摘要对 Opus 的叫法和小数都有出入。看趋势就行，别把某个小数当标准答案。

回到开头那台烤箱。九次工具调用全部正确，一个状态字段写错，客户的包裹还卡在纳什维尔。

验收 Agent，别听它汇报，去数据库里看它到底留下了什么。一次跑通不算数，连着 20 次都对，才算能交付。

关注圈圈，持续带你玩转 AI 工具。