一次成功不算本事，20 次全成才算：Thinkingbox 给智能体泼了盆冷水

你有没有遇到过这种情况：demo 里智能体把退改签流程跑得行云流水，真上了生产环境，同一个任务跑十次能给你整出八种结局？

说实话，这几乎是所有做 Agent 落地的人的共同隐痛。我们看到的大部分 benchmark 报的是 pass@1——跑一次，过了就算会了。但业务方关心的是另一件事：这个流程明天再跑一遍，还灵不灵？微软联合匹兹堡大学、西北大学、UC Irvine 的团队最近放出的这篇论文，就把这个「偶尔能成」和「稳定可靠」之间的差距，用一个相当扎心的数字量化了：最强的模型在 507 个业务任务上，20 次尝试里至少成功一次的任务占 91.12%，但 20 次全部成功的只有 25.25%。

中间这 66 个点的鸿沟，就是这篇论文真正想说的事。

核心摘要：Thinkingbox 是一个面向 tool-agent-user 三方交互的沙盒，配合 Thinkingbox-bench——507 个横跨零售、酒店、车险、银行内部 IT、咨询 IT/HR 五个业务域的有状态工作流任务。和 τ-bench 这类前辈不同，它把任务做成 MCP 兼容的隔离工具会话，每次尝试独立重置数据库，用合取式可执行检查（终态正确 + 无多余副作用 + 对话要求）来判定成败。12 个模型、每任务 20 次重复试验的结论是：最强模型 GPT-5.4 的 pass@1 为 65.36%，但可靠性指标 pass^20 只有 25.25%；而且 77.5% 的失败是「工具出错后恢复不过来」。我的判断是：这是今年 Agent 评测里少有的、把「可靠性」从口号变成可测量指标的扎实工作，评测基建价值大于 benchmark 本身。

论文信息

• 标题：One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows
• 作者：Zhuochun Li, Youngmin Ko, Ali Keramati, Nicola Ferri, Susana Palmaz Lopez Pelaez, Liang-Chun Tsai, Calvin Wang, Mirco Milletari, Tuhin Kundu, Vadim Smolyakov, Kjartan Olafsson, Tommy Guy
• 机构：University of Pittsburgh、Northwestern University、UC Irvine、Microsoft
• 链接：https://arxiv.org/abs/2608.19741 （2026 年 8 月 20 日提交）
• 代码与基准：https://github.com/microsoft/thinkingbox

🎯 为什么现有评测测不出「靠不靠谱」

现在的 Agent 评测其实已经卷得很厉害了：SWE-bench 修代码，BFCL 测函数调用，WebArena 点网页。但作者点破了一个事实——这些任务被选中，很大程度上是因为「结果容易规格化」。改没改对代码，跑测试就知道；函数参数对不对，比对一下就知道。

真实业务工作不是这个样子的。修改一个酒店预订、处理一笔退款、更新一条保险理赔——这类任务有四个要命的特点：

1. 多轮：用户开场不会把信息给全，你得追问；
2. 有状态：每次操作都在改数据库，错了会留下痕迹；
3. 有后果：退款退错了账户、订单改错了日期，是真金白银的损失；
4. 受政策约束：不是技术上能不能做，而是政策上允不允许做。

更要命的是，一个看起来合理的回复、一次语法完全合法的工具调用，都不代表事情办成了。Agent 可能调了正确的 API 但传错了实体 ID，可能在没拿到用户确认前就改了记录，可能给用户回了一段漂亮话但后端一个字没动，也可能顺手干了几件政策明令禁止的事。

我之前做类似工具调用评测的时候就踩过这个坑：只看最终回复的通过率比看后端状态高出二十几个点。那些「嘴上说办了、实际没办」的 case，用 response-level 的信号根本抓不出来。

这篇论文把评测的落点从「回复」和「轨迹」挪到了终态世界状态上。这是它和绝大多数前辈的分水岭。

🏗️ Thinkingbox：把业务流做成可重置的沙盒

图 1：上半部分是 Thinkingbox 沙盒的交互流程——模拟用户带着私有状态与 Agent 多轮对话，Agent 通过隔离的 MCP 工具会话操作后端，episode 结束后由副作用提取器 + 可执行检查器给出 0/1 判决；下半部分是全篇最扎心的一张图，8 个代表性模型的 pass^20（绿色方块，20 次全成的任务占比）、pass@1（蓝色菱形）、pass@20（橙色圆点，至少成一次）三条线的巨大分离。

形式化上，每个任务是一个五元组 \(x = (b_0, g, \mathcal{T}, \mathcal{U}, \mathcal{C})\)：初始后端状态、用户目标、域工具集、模拟用户策略、隐藏的可执行检查集合。这套东西自然诱导出一个有限时域的 POMDP——隐状态包含后端状态、用户私有状态、事件日志和 episode 状态，奖励稀疏且终态化。

工程上有几个设计我觉得是真正值钱的。

隔离是第一优先级。 每次尝试都确定性重置到 \(b_0\)，创建一个全新的隔离工具会话。同一任务的两次尝试之间，不允许共享任何数据库行、缓存状态或副作用。这条听着像废话，但做过多轮 rollout 的人都知道它多容易翻车——只要状态泄漏一点，pass@k 和 RL 奖励就全都不干净了。

工具走 MCP 兼容接口。 工具发现和调用的方式贴近当下真实的 Agent 部署形态，而不是为评测特制的 API。这也让 Thinkingbox 成了目前同类 benchmark 里唯一原生支持 MCP server 的。

判决是合取式的。 交互结束后，副作用提取器算出 \(e = \Delta_x(s_0, s_T, \rho)\)——这次会话到底改变了世界的哪些部分。最终判决为：

所有检查全过才算过。这个设计同时解决了三件事：比查最终答案严格（抓得住「回复漂亮但没办事」）；允许不同的合法路径拿分（不要求复现 golden 轨迹，殊途同归即可）；能检测附带伤害（改对了目标记录但顺手动了别人的，照样挂）。

图 2：沙盒内部结构。Orchestrator 管理对话、工具调用和会话生命周期；每次任务运行拥有完全隔离的工具会话（域工具/API、实现业务逻辑的有状态后端、数据库状态），Trace Logger 记录完整轨迹；Executable Judges 对终态、副作用和对话做确定性检查，输出 0/1 判决。右侧是判决结果的三个下游用途：benchmark 评测与排行榜、失败模式分析、以及直接作为 RL 奖励（GRPO/DAPO-ready）。

图 2 右下那个「Agent Training」值得多看一眼。因为判决 \(V\) 是可执行的、逐项检查还能拆成奖励向量 \(r_i(\rho) = c_i(b_T, e, \rho)\)，这套沙盒天然就是 RL 训练环境。评测和训练共用同一个循环——这步棋埋得很深，等下再说。

📦 Thinkingbox-bench：507 个「有后果」的任务

benchmark 部分包含 507 个任务，分布在五个虚构组织里：零售电商 TechHome Direct（98 个）、酒店集团 StayBridge（104 个）、车险公司 HorizonShield（100 个）、数字银行 Velocity 的内部 IT 支持（104 个）、咨询公司 Meridian 的 IT/HR 支持（101 个）。全部数据是合成重建的，不含真实客户记录。

表 1：五个域的任务构成。注意酒店预订域政策文档 3684 字、平均每任务 8.8 个动作，是最重的一个域。

任务设计上有个我很喜欢的细节：用户目标被拆成开场请求 + 可披露事实集。后者里的信息只有模拟用户自己知道，Agent 不主动问，就永远拿不到。这就把「初始请求信息不全」这个真实场景强制化了——客户打来电话说「我要改订单」，但订单号、改到哪、为什么改，都得你一步步问出来。问不对、不问就动手，都是失败。

评估分两类：477 个任务纯看后端终态；另外 30 个（酒店 15 + 银行 15）额外加了最终回复的二元 rubric，用来查那些数据库里看不出来的沟通要求——比如不能泄露机密的酒店分级信息。每个保留任务只有单一 golden 终态，保证判决没有歧义。

构建流程也值得一提：先从不公开的企业支持案例里提炼工作流模板，再实例化成可执行任务世界，最后在沙盒里实际跑一遍做过滤——工具坏的、初始状态不一致的、目标模糊的、结果不可验证的、靠工具轨迹判分的、死活不终止的，全部扔掉。留下的任务必须至少存在一条合法完成路径。这套「可执行验证 + 人工六维审查」的品控，比很多「LLM 生成任务 + LLM 判分」的 benchmark 扎实得多。

📊 实验：12 个模型，每题跑 20 遍

被测阵容是 6 个专有模型加 6 个开放权重模型：GPT-5.4、GPT-5.2、o3-pro、Claude Sonnet 4.6、Claude Opus 4.6、Grok-4.3，以及 DeepSeek-V4-Pro（1.6T/49B MoE）、GLM-5.1、Kimi-K2.6、Mistral-Large-3、Qwen3.6-27B、Qwen3.5-9B。所有模型在同一沙盒里跑，同样的 system prompt、工具定义、政策和模拟用户（固定为 GPT-5.4-mini），每任务独立跑 20 次。

主结果如下（微平均 pass@1，%）：

表 2：Thinkingbox-bench 主结果（N=20 微平均 pass@1）。o3-pro 行剔除了 636 次系统错误试验。

几个让我停下来多看两眼的数据。

Claude Opus 4.6 的撕裂感。 零售 74.90% 全场第二，车险却崩到 14.65%。GPT-5.2 也是同样的人格分裂：零售 70.20%，车险 22.40%。反倒是 GPT-5.4 和 Sonnet 4.6 是仅有的两个全域过 50% 的选手。车险域为什么难？政策文档 2471 字、资格判断链条长——「这个司机能不能加进保单」不是查个表就完事的。某些模型在「简单检索 + 单步写入」上很强，一遇到多约束政策推理就露馅。

参数量说了不算。 Mistral-Large-3 顶着 675B 总参数拿到 4.66%，被 27B 的 Qwen3.6（32.94%）甩开几条街。工具调用格式、agentic 后训练、从环境反馈里恢复的能力——这些才是这个 benchmark 真正在测的东西，跟名义参数量关系不大。

可靠性差距是全场主角。 回到图 1B：GPT-5.4 的 pass@20 是 91.1%，意思是将近九成的任务它「有能力做对」；但 pass^20 只有 25.2%——能做到「每次都做对」的任务只剩四分之一。Claude Sonnet 4.6 是 88.6% / 20.1%，DeepSeek-V4-Pro 是 84.6% / 3.5%。看 DeepSeek 这组数特别有冲击力：重试 20 次能覆盖 84.6% 的任务，看起来和第一梯队差不多；可要它稳定复现，3.5% 的任务都保不住。pass@k 测的是上限，pass^k 测的才是下限，而业务方只为下限买单。

图 3：域级失败率热力图（100 - pass@1），颜色越深失败率越高。车险和咨询 IT/HR 两列整体偏深；Grok-4.3、Mistral-Large-3、MiniMax-M2.5 几乎全行深红。GPT-5.4 是唯一全域失败率控制在 50% 以内的模型。

🔬 失败分析：77.5% 的失败是「摔倒了爬不起来」

论文把失败归成四个互斥的类别，看分布比看总分更有意思：

表 3：失败模式分布（%，仅统计失败试验，节选部分模型）。

工具使用错误占了 77.5%，是绝对大头。 注意这不是「JSON 写错了」这种低级问题——是工具报错、前置条件不满足、查询返回空之后，Agent 恢复不过来。更糟的一种是：工具明明失败了，Agent 当它成功了继续往下走。这个发现对做 Agent 的人应该很有刺痛感：模型不是不会调工具，是不会处理工具的不完美。真实世界的 API 会超时、会返回脏数据、会有隐含前置条件，而训练数据里大多是「一击即中」的调用。

「无状态变更」只占 2.5%，但性质很恶劣。 这类 case 里 Agent 把该查的都查了、相关记录也定位到了，然后——就没有然后了。需要的 create/update/refund 动作压根没发出。这是子目标遗漏，不是能力不足。放业务里就是客服跟你聊了二十分钟，说得头头是道，挂了电话什么都没改。

「错误状态更新」12.1%，是最危险的一类。 变更工具调用「成功」了——没报错、Agent 也自信地跟用户确认办妥了——但终态是错的：改错实体、判错资格、退错金额。这种失败在 response-level 评测里完全隐形，只有终态检查抓得住。o3-pro 这类失败占 27.8%，Grok-4.3 占 22.5%，说实话看到这个我有点理解为什么它俩总分垫底了——不是不做，是做错。

🤔 我的判断

这篇论文值钱的不是又一个 leaderboard，是三样东西。

第一，把可靠性从形容词变成了指标。 pass@k 和 pass^k 的组合拳不是新发明（τ-bench 就在用），但 Thinkingbox 把它放到 507 个有真实业务后果的任务上、12 个模型 × 20 次重复的规模上跑出了让人没法装看不见的数据。91.12% 对 25.25%，以后再有厂商拿单次 demo 说事，这张表就是最好的反问。

第二，副作用中心的判决设计。 合取式检查 + 隔离重置 + 终态判决，这套组合的工程含金量比论文篇幅体现的要高。特别是「不要求 golden 轨迹、只要求正确终态」这一条，既公平又可执行，做评测基建的人值得抄作业。

第三，评测即训练环境。 同一个循环既出 pass@1 又出 RL 奖励，还 GRPO/DAPO-ready。我倾向于认为这才是微软做这个东西的真实动机之一——benchmark 是顺手的，给 Agentic RL 铺训练场才是正餐。这不一定是坏事，但读者心里要有这根弦。

批评也得说几句。模拟用户固定用 GPT-5.4-mini，同时它还兼任 30 个 rubric 任务的裁判——而它跟被测阵容里最强的 GPT-5.4 是同一家族。「同家族交互风格更合拍」带来的偏向没法排除，GPT-5.4 的全场第一有多少是这个因素贡献的，论文自己也承认说不准。其次，477/507 个任务只看后端终态，「事办对了但跟用户胡说八道」的轨迹照样算过——这在客服场景其实是个不小的洞。另外所有任务是合成重建的，能不能代表真实企业工作流分布，作者没敢打包票，我也不敢。

还有一点：「工具出错后恢复不过来」占了 77.5% 的失败，这个结论对训练侧的指向性极强——与其继续堆「正确调用」的 SFT 数据，不如故意往训练轨迹里注入失败、超时、脏返回，教模型学着爬起来。如果你在做 Agent 后训练，这可能是这篇论文给你最实在的一条 actionable insight。

📝 收尾

一句话总结：Thinkingbox 告诉你，你那个 demo 里表现完美的 Agent，大概率只是「偶尔能成」。而从「偶尔能成」到「每次都成」之间的距离——65.36% 对 25.25%——就是 Agent 从玩具变成生产工具还要走完的路。

如果你在做 Agent 评测或后训练，这套沙盒和它的合取式判决设计值得花一个下午研究；如果你只是想知道自己的模型靠不靠谱，把 GitHub 仓库拉下来跑 20 遍，比看任何宣传材料都管用。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我