在微软新发布的这套智能体基准里，最强的模型第一次尝试就完成了 65.36% 的业务工作流，而在连续二十次尝试里次次成功的，只有 25.25%。如果每次尝试的失败彼此独立，“连中二十次”应当落在 0.02%——五千道题里出一道——所以量到的这个 25% 并不是同一次测量的缩小版，它是另一个事实：这个智能体在大约四分之一的工作上是可靠的，在其余大部分工作上表现得像一枚硬币；而恰恰是那个“抛硬币”的区段，会通过你的评审并被发布出去。
Thinkingbox 到底量了什么
Thinkingbox 是一套面向“有状态业务工作流”中智能体的沙箱与基准，2026 年 8 月 19 日由微软的研究者，连同匹兹堡大学、西北大学与加州大学欧文分校的合作者一起发布，论文题为 One Success Isn't Reliability（arXiv:2608.19741）。框架以 MIT 许可证发布在 GitHub 上；工具桩以 MCP 服务器的形式定义，因此受测智能体与沙箱对话的方式，和它与生产系统对话的方式是同一种。
随框架一同发布的可执行套件 Thinkingbox-bench 收录了 507 条受策略约束的工作流，横跨五个领域——零售、酒店住宿、车险、新型银行的内部 IT，以及咨询公司的 IT 与 HR 支持。“受策略约束”这个词在这句话里是真在干活：每道任务都会给智能体一份成文的业务政策，正确答案取决于把这份政策用对，所以一道题完全可能因为“干了一件很漂亮、但政策不允许的事”而判错。
第二件值得注意的事是它怎么打分。结果是对照智能体所操纵的后端的终态来核验的，另外还要核验附带影响——有哪些本不该被改动的东西被改动了。智能体自己对“我做了什么”的陈述，不是受测对象。这个区分最后解释了相当大一部分失败：论文里反复出现的模式，是一段听上去合情合理、措辞良好的回复，压在一次错误的状态变更之上；或者是一次没恢复好、却被报告成“已处理”的失败。
| 测量 | 数值 | 它回答的问题 | 它藏起来的东西 |
|---|---|---|---|
| pass@1 | 65.36% | 它到底会不会做这件事？ | 它会不会做第二次 |
| pass^20 | 25.25% | 它是不是每次都能做成？ | 是哪种失败模式，以及为什么 |
| 失败独立时的推算值 | 0.02% | 若二十次尝试彼此独立，pass^20 会是多少 | 什么也没藏——它只是算术，而且算错了现实 |
这个指标本身并不新。pass^k——k 次尝试全部成功，与 pass@k 的至少一次成功相对——在 2024 年随 τ-bench 一同提出，当时报告的正是同一种坍塌：一个单次尝试约 60% 的智能体，在零售分支上的 pass^8 掉到了约 25%。两年过去，几乎每一次模型发布主打的那个数字，仍然是单次尝试。
把算术做一遍，那个分数就散架了
先把这两个公布的数字当真一分钟。如果这个智能体在每道题的每次尝试上都是一个每次重新抽取、恒为 65.36% 的成功率，那么连续二十次成功的概率就是 0.653620 ≈ 0.0002。一套 507 道题的基准里，能二十中二十的大约是零道。而实测是 25.25%。
三个数量级的分歧不是噪声，而且它只有一种解释：同一道题内部的成败是高度相关的。在多次运行之间变化的那些东西，并没有均匀地撒在整套题上。有些题智能体就是能做对，一次又一次；另一些题它只是有时候能做对。
只要加一个假设，就能给这道分界大致定形：一道智能体真正抖动的题，几乎不可能扛过连续二十次尝试——对任何低于约 0.8 的单次成功率，这都成立。于是“确定性区段”就是 pass^20 那个数，占 25.25% 的题目；而其余题目的单次成功率，可以直接从 pass@1 的总数里解出来：
deterministic band d = pass^20 = 0.2525
remainder r = 1 - d = 0.7475
per-attempt rate q = (pass@1 - d) / r
= (0.6536 - 0.2525) / 0.7475
= 0.537
也就是说：在四分之一的题目上智能体是可靠的，在另外四分之三上它约有 54% 的成功率。这是一幅“双总体”的漫画，真实情况其实是连续分布，而且真实分布里必然还包含智能体根本做不成的题——这次拟合把它们一并塞进了同一个桶。但方向毫无疑问，而恰恰是方向要紧：那个 65 分的头条分数里，有 40 分是由智能体有时候能做对的题贡献的。
“有时候能行”在运维上比“从来不行”更糟
需要推翻的直觉是：一道 54% 的题，是“距离一道好题只差一半”。它不是。以部署的标准衡量，它比一道次次都失败的题更糟，原因在于：失败模式被处理的力度，与它有多显眼成正比。
一道智能体从来完不成的题，第一天就会自报家门。有人在预发环境里试了一次，看着它失败，于是系统长出了它本来就需要的东西：一条退路、一个人工队列、一次明确拒绝、或者产品文案里的一道范围边界。能力缺口变成了一个设计决定——这正是正确的结局。
一道智能体有一半概率能完成的题，什么也不会自报。它能过演示。它能过评测——因为评测只跑了一次，而从一枚 54% 的硬币里抽一次，正面出现得比反面更频繁。它上线了。然后它对大约一半走到这条路径上的用户失败，而对值班的人来说这种失败无法复现，于是被归类成“抖动”，而不是“缺能力”。与此同时，你的团队搭的每一块仪表盘都是跨运行的均值，而均值分不清“对所有人都能用但降级了”和“对其中一半人完美工作”。
把这件事从“烦人”推到“出局”的，是复合效应。业务工作流是链条。一个五步流程，每一步都取自那个 54% 的区段，端到端完成的概率是 4.5%——而一条由“单看每一步演示都还行”的步骤拼起来的工作流，恰恰就是团队走到“在会议室里能跑、在季度里死掉”的那条路。这就是我们此前那篇智能体退潮从外部描述的现象背后的机理：那些试点失败，不是因为模型没有能力，而是因为能力只被量过一次。
还有一个采购上的后果。两个模型可以报出同样的 pass@1，而部署价值完全不同——一个在 60% 的题上是确定性的、剩下的毫无办法，另一个在所有题上都是一枚 65% 的硬币。前者是一个产品，后者是一次演示。你眼前的排行榜没有任何一列能把它们分开。
给状态打分，别给句子打分
Thinkingbox 的第二项贡献比“可靠性落差”低调，也更容易在本周就付诸行动：这套套件核验的是智能体留下的后端状态，并且核验附带影响——它碰过、而任何一次正确执行都不会去碰的那些记录。
把这与默认做法比一比。多数智能体评测打分的对象是一份对话记录，通常由一个评审模型读最后一条消息。而对话记录，恰恰是受测智能体唯一完全由自己撰写的产物。当一个模型被训练成能对自己的工作产出措辞良好、语气笃定的总结时，给这份总结打分，量的就是这个模型最擅长的那件事；而论文反复浮现的那种失败——合理的回复压在错误的状态变更之上——正是能完好无损地穿过这种评分器的那一种。
数据库是说不动的。账本、工单队列、日程表、行数，也都说不动。只要你的智能体往什么地方写，你就可以对它写下的东西下断言，而且这些断言不会因为模型改了文风就跟着漂移。这个道理的通用版本在结果评测与轨迹评测里；而 Thinkingbox 是我们见过的最有力的经验证据，因为它隔离出了一类只有状态核验才抓得住的失败。
附带影响值得单独写一行。一个把工单正确关掉、同时顺手取消了一项无关订阅的智能体，通过了你想得到去写的每一条结果断言。请在事前与事后各给世界拍一张快照、做差分，并把预期集合之外的任何变化都判为失败——这是幂等性与重试在运行时所主张的那份“副作用台账”在评测里的等价物。
在你自己的套件里改什么
把每道评测任务跑 k 次，并把 pass^k 与 pass@1 并排报告。你不需要二十次。在 k=5 时，一道确定性的题与一道 54% 的题就已经分得干干净净——那枚硬币连中五次的概率是 4.5%——而对一套四十道题的套件跑五遍，是一个负担得起的夜间任务。两个数都要报；一个把双峰分布藏起来的单一数字不是摘要，是信息丢失。
把套件分成“总是 / 有时 / 从不”三桶，并把中间那一桶当作路线图。这才是做这件事要产出的东西。从不那一桶是一场关于范围的对话。总是那一桶是你被允许作出的承诺。有时那一桶是有明确地址的工程活儿——而且通常是可解的，因为逐题的抖动一般都能追溯到某个具体的东西：一段有歧义的工具描述、一份模型必须跨太多轮次记住的政策、一步在不同运行里返回不同上下文的检索、一个模型会用两种方式填的 schema。
别让一个修复被“当初漏掉这个缺陷的同一种单样本方法”来判定。把修好的那道题跑 k 次。一个把某题从 54% 抬到 71% 的改动，在单样本下看着像修好了，而它仍然是一枚硬币。到这里，评测方差与统计功效就不再是一堂统计课，而是“发布一个修复”与“发布一则传闻”之间的分界。
对状态下断言，并用快照抓附带损害。只要你的智能体往什么地方写，就为那次写入写断言。把评审模型留给真正关乎语言的那部分——语气、拒绝的质量、解释——并且不要在一次查询就够用的地方还去用它。
把 pass^k 当作换模型的关卡。新模型来了，有意思的问题不是头条数字动没动，而是有没有题目在桶与桶之间迁移——而 pass@1 几乎相同的两个模型，“在哪些题上是确定性的”往往大不相同。把套件冻住，在同一个 k 下把两个模型都跑一遍，然后差分那三个桶。我们对四个开源评测框架的对比里，讲了哪一种测试台能把重复试验跑得足够便宜，便宜到每次换模型都做得起。
这一切都不要求你采用 Thinkingbox。这套套件值得一读的是它的任务设计，而 MIT 许可证也让它的场景格式成为一件可以借走的东西。但这个发现脱离工具依然成立：你已经有一套基准，你已经从里面报了一个数字，而第二个数字只需付出 k 倍算力，就能告诉你第一个数字里有哪一半是真的。
常见问题
pass@k 与 pass^k 有什么区别？
pass@k 指 k 次尝试里至少成功一次，它适用于有人来筛选候选的场合——比如代码生成，你可以把测试跑一遍。pass^k 指 k 次尝试全部成功，它适用于智能体无人监督地行动的场合，因为在活生生的系统上做错一次，没有任何东西会替你把它筛掉。智能体的部署几乎总是想要后者。
为什么实测的 pass^20 远高于 0.6536 的二十次方？
因为同一道题上的多次尝试并不是彼此独立的抽取。题目难度、模型对那份具体政策的把握、工具面貌，在这二十次运行里都是固定的；变的只有采样与顺序。这种相关性把失败集中到了特定的题目上，而不是均匀摊在所有题上——这也正是聚合分数对任何单独一道题都如此具有误导性的原因。
把温度调低能解释那个抖动区段吗？
调低温度会收窄离散度，但不会把一道题从抖动区段搬进确定性区段，因为在一次长程智能体运行里真正要命的方差来自分叉点——调哪个工具、要不要问用户、什么时候停——而分叉点上的微小差别会长出完全不同的轨迹。把确定性设置当成一种方差削减手段，而不是可靠性的修复；这个论证的完整版在可复现性与确定性里。
k=5 真的够吗？
用于分诊，够。五次试验足以把一道确定性的题与一道接近 50% 的题干净地分开，而这道分界正是会改变你去建什么的那一条。五次试验做不到的是给出精确的逐题成功率、或者检测出一次小幅回退——那需要一次功效计算，以及数量可观得多的运行，跑在一套小到你负担得起的题目上。
这些具体数字该信吗？
信那道落差，别信小数点。65.36% 与 25.25% 是一篇论文里最强的一个模型、在一套 507 道题、五个业务领域的套件上的成绩，而你的工作流不是那些工作流。可迁移的论断是结构性的：单次尝试的计分会系统性地高估智能体在重复之下的表现，而这份高估有多大，只要把你自己的套件跑 k 次就能量出来。
延伸阅读
本站相关：
- 结果评测与轨迹评测——当对话记录由受测对象自己撰写时，该给什么打分。
- 评测方差与统计功效——一项声称的改进究竟需要跑多少次。
- 质量回退检测——赶在用户报告之前抓住那次下滑。
- 读懂基准——追问“这个分数是在什么之上量出来的”这项通用功夫。