One Success Isn't Reliability: Thinkingbox 沙盒与基准 精读

论文链接：One Success Isn’t Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows 代码仓库：microsoft/thinkingbox 发表时间：2026年8月 机构：匹兹堡大学、西北大学、UC Irvine、Microsoft（Tommy Guy 团队；前三名为实习生同等贡献，工作在微软实习期间完成） 领域标签：cs.CL / Agent 评测 / 工具使用

一、论文背景

1.1 从「会调用工具」到「把事办成」

过去两年，Agent 评测的进步很大程度上来自「可执行验证」：代码修复可以跑测试（SWE-bench），函数调用可以解析执行（BFCL、ToolBench、API-Bank），网页和桌面操作可以在交互环境里打分（WebArena、OSWorld、AgentBench）。这类基准有个共同点——成功与否容易被规格化成可执行的检查。

但真实的商业世界里有大量工作既不是代码、也不只是一串工具调用：改一张订单、处理一笔退款、更新一个保险理赔、路由一个内部服务请求。这些任务有三个共性：

• 多轮：用户一开始给的信息通常不全，Agent 必须追问；
• 有状态：成功不是「说出正确答案」，而是后端数据库被改到了正确的状态；
• 有后果：改错记录、多做一个副作用操作，都是真实业务里不可接受的错误。

现有评测对这类工作的覆盖是不足的。函数调用类基准（BFCL 等）能检查 API 选得对不对、参数填得对不对，但检查不了「这个调用要做的事到底办成没有」。一个 Agent 可以调用正确的 API 但操作了错误的实体，可以在没拿到必要确认前就更新记录，可以给用户一段体面的回复而后端纹丝不动，也可以多做几个违反政策的副作用操作——这些在调用级评测里全都是「绿灯」。

1.2 关键概念：有状态业务工作流

论文研究的核心对象是政策条件化的有状态业务工作流（policy-conditioned stateful business workflow）。拆开看：

• 有状态：任务开始时后端数据库处于某个初始状态 b₀，任务结束时必须处于某个黄金终态。成功定义为状态的正确迁移，而非话术的正确。
• 政策条件化：每个领域有一套运营政策（几百到几千词），规定什么操作对什么身份的用户是允许的、需要什么审批、必须披露什么。同一个 API 调用在技术上都执行得通，但在政策上可能是不该做的。
• 副作用意识：不仅要求「该做的做了」，还要求「不该做的没做」——不能修改无关记录、不能创建重复工单、不能越权变更。

这类任务的难点在于：可观察的答案只是成功的一部分。这也是论文标题的意思——一次成功（pass@1 里的一次 lucky pass，或 pass@20 里蒙对一次）不代表可靠性。

1.3 为什么现在要做这件事

τ-bench（2024）已经证明，即使 GPT-4o 级别的模型，在零售客服任务上 pass@1 不到 50%，要求 8 次全过的 pass^8 更是跌破 25%——可靠性是工具型 Agent 的核心瓶颈。但 τ-bench 之后，社区仍缺三样东西：

1. 一个可复用的沙盒（而不只是一个任务集）：能实例化世界、暴露领域工具、模拟用户追问、抽取副作用、跑结果检查，且同一循环能同时支撑推理评测、排行榜、失败分析和训练奖励；
2. MCP 兼容的工具接口：MCP（Model Context Protocol）正在成为当代 Agent 部署的事实标准，基准的工具暴露方式应贴近真实部署；
3. 更大规模、多领域、经过人工审查的有状态任务集：τ-bench 只有 165 个任务、两个域；企业场景里的政策负担、审批链、跨系统一致性远比那复杂。

THINKINGBOX 就是冲着这三个缺口来的。

二、论文定位和关联工作

2.1 研究谱系一：沙盒与对话式工具使用

τ-bench 是本文最直接的思想源头：pass^k 可靠性度量、终态数据库评测、政策条件化用户交互这三个设计都被继承。Thinkingbox 的增量在于把这套范式泛化成一个可复用的运行时抽象（沙盒与基准分离），并规模化到五个业务域。

2.2 研究谱系二：可执行与专业工作基准

2.3 定位总结

一句话定位：Thinkingbox = τ-bench 的可靠性评测范式 + AppWorld 的状态/副作用检查 + MCP 工具接口 + 沙盒/基准分离的可复用运行时，再乘以五域 507 任务的人工审查规模。

三、问题定义

3.1 具体问题

如何评测（并比较）Agent 在有状态、多轮、政策条件化的业务工作流中的表现，使得评测结果能区分「偶尔能找到成功轨迹」和「每次都能可靠完成」？

3.2 核心洞察

论文的深层洞察是：有状态业务任务的正确性不能在轨迹表面（响应文本或调用序列）上判定，只能在终端世界状态上判定；而可靠性不能在单次试验上判定，只能在重复试验的分布上判定。

由此自然诱导出一个 POMDP 形式化。每个任务世界：

x = (b₀, g, T, U, C)

其中 b₀ 是初始后端状态，g 是用户目标，T 是领域工具集，U 是模拟用户策略，C = {cᵢ} 是隐藏的可执行检查集。它诱导出有限视界 POMDP：

Mₓ = (Sₓ, Aₓ, Oₓ, Pₓ, Zₓ, Rₓ, μₓ, H)

隐状态 sₜ = (bₜ, zₜ, ℓₜ, qₜ)：后端状态、模拟用户私有状态、评测相关事件日志、回合状态。关键设计：只有 Agent 直接调用改变状态的工具，模拟用户属于环境动力学而非第二个决策者——这保证了所有评测差异都可归因于 Agent 策略。奖励 Rₓ 稀疏且只在终止时给出，由可执行判定（式 4）定义。

3.3 类比理解

3.4 形式化问题定义

给定：任务世界 x = (b₀, g, T, U, C)，N 次独立试验，判定函数 V(x, ρ) = ∏ᵢ cᵢ(s_T, e, ρ)（合取：所有检查全过才算过）。

求：Agent 策略 π（只作用于可观察历史 hₜ，不接触隐状态）。

约束：政策合规（动作在政策下允许/被要求/被禁止）、正确终态、无禁止副作用。

评测目标：pass@k（至少一次成功的概率，衡量「发现能力」）与 pass^k（k 次全过的概率，衡量「可靠能力」）的分离刻画。

3.5 这个抽象的精妙之处

1. 把「业务工作」变成「可执行 Agent 任务」：非代码工作第一次像代码跑测试一样可判定——不是比对最终答案，而是比对世界状态。
2. 允许路径多样性：判定只看 (s_T, e, ρ)，不要求复现某条黄金调用序列。换一种检索顺序、从失败调用中恢复，只要终态对就得分。这比轨迹匹配严格得更聪明。
3. 副作用可检测：改错实体、越权更新这类「调用成功但业务错误」的情况，会被终态与副作用检查直接抓住。
4. 同一形式化同时服务评测与训练：V 直接就是 outcome reward，各检查 cᵢ 还能提供 reward vector——评测基建即训练基建。

四、问题解法

THINKINGBOX 的解法是一个「沙盒 + 基准」双层结构：沙盒提供可复用的交互底座，基准在其上实例化 507 个任务世界。

4.1 沙盒：一个可复现的交互循环

类比：沙盒就像「考试标准化考场」——不管考生（Agent 模型）是谁，考场规则、道具、监考、阅卷完全一致，只有考生不同。

每次试验的流程：

1. 重置：把任务重置到 b₀，初始化完整状态 s₀ = (b₀, z₀, ∅, ACTIVE)；
2. 隔离会话：创建隔离的 MCP 工具会话——同一任务的两次试验绝不共享数据库行、缓存工具状态或副作用（否则 pass@k 与训练奖励全不可靠）；
3. 转发与执行：转发消息、执行工具调用、记录完整轨迹 ρ；
4. 副作用抽取：交互终止后抽取副作用 e = Δₓ(s₀, s_T, ρ)——Δ 是任务相关的，任务构建者可定制；
5. 判定：跑可执行检查的合取 V(x, ρ) = ∏ cᵢ(s_T, e, ρ)。

输入/输出：输入是任务世界与 Agent 策略；输出是轨迹级 0/1 判定 + 完整轨迹记录。同一判定支撑三种用途：排行榜评测、失败分析、Agent 训练奖励。

4.2 模拟用户：环境的一部分，而非决策者

这是论文设计上最讲究的部件。模拟用户 U 是固定组件，跨所有被评测 Agent 完全一致——这正是 Table 4 中两行模型成绩可比的原因：差异只来自 Agent 策略。

输入（每次调用恰好三个字段）：对话转录（过滤为用户可见文本——不含工具调用、工具结果、推理痕迹）、任务的用户规格（USER CONTEXT 块）、最后一条助手消息。注意这个过滤视图让模拟用户严格少于 Agent 的可观察性：它看不到工具报错，所以救不了处理报错失败的 Agent；它不能复述 Agent 从未在对话中呈现的后端状态。

规格结构：用户目标 g 拆为「开场请求」（逐字重放）+「可披露事实集」（带行为规则）。事实被刻意从开场请求中扣下——缺失信息是 Agent 必须引出的，而不是用户主动奉送的。

接地契约（Grounding Contract）——模拟器系统提示中承载评测重量的四个条款：

外加确定性后处理：剥离角色标签、去对称引号、空回复替换为「I don’t know」。对话前还有一步净化，把提示自身的分节符与终止标记在对话内容中出现时改写——防止任务数据或 Agent 输出伪造提示结构或伪造会话终止信号。

回合协议：最多 10 轮用户追问；Agent 用 <DONE> 标记或 end-turn 工具终止；耗尽回合预算的试验与干净终止的试验用同一套可执行检查打分，都没有部分分。采样非确定性（temperature 0.3），所以 20 次试验在用户措辞与 Agent 行为上都不同——可靠性结果衡量的是对一组用户交互分布的鲁棒性，而非单一固定对话的重复。

4.3 基准：507 个可执行任务世界

五域构成（任务数 / 后端系统数 / 数据库表·行 / 读写工具 / 政策词数）：

477 任务纯后端状态评测；30 任务（旅行 15 + 新银行 15）额外加二元响应 rubric——只在「正确性包含无法从终态恢复的传播性条件」时才加，例如不得披露机密酒店分类、必须明确告知政策受限的结果。Rubric 在任务构建期固定，不依赖被评测模型的输出——避免用模型评模型的循环。

数据来源与隐私：工作流模板来自私有数据协作获得的企业支持案例（不公开），用于接地「真实工作流结构」而非直接搬运；发布集不含任何真实客户/员工记录，五个虚构组织（TechHome Direct、StayBridge Hotels、HorizonShield Insurance、Velocity Digital Bank、Meridian Strategy Group），全部身份与数据库行都是合成的，但保留推理所需的关系结构（订单连接履约历史、保单连接驾驶员·车辆·账单·理赔）——这使评测器能区分「正确操作」与「对错误记录的表面相似操作」。每个最终案例还经过六维人工质检（清单唯一性、隐私与跨记录一致性、政策与可解性、执行与重置、黄金态与 rubric 须拒绝 no-op/错误/缺失/多余效应、全轨迹 rollout 审查）。

三阶段构建：工作流设计（模板必须有实践目标、工具、政策、可验证结果）→ 可执行任务实例化（初始态、工具、用户规格、检查）→ 可执行验证与过滤（删除工具损坏、初始态不一致、目标歧义、结果不可验证、检查依赖调用轨迹、交互无法终止的任务；保留任务必须至少有一条有效完成策略且保持清晰正确性标准）。

4.4 Agent 侧提示与判定细节

Agent 系统消息包含共享指令（其中 <DONE> 使用规则很严格：消息含问号或等待输入时禁止带 <DONE>）+ 领域角色、当前时间、政策、工单管理规则；工具以 MCP schema 暴露。工具错误与前置条件失败原样返回给 Agent，不被沙盒静默修复——错误恢复能力是被测的一部分。

判定用确定性哈希断言比对终态数据库与黄金态：先检测数据库表示的差异，再报字段级差异。失败可能是期望记录上的错误值、缺失的行/更新、或多余效应（重复记录、无关对象变更）。

五、评估指标与实验证据

5.1 指标体系

主指标：pass@1（micro-average）。每任务 20 次独立试验，PassRate(D) 对任务与试验做 micro 平均。一次试验只有该任务全部可执行检查通过才算对。整体分数按任务数比例加权。

辅助指标一：pass@k（发现能力）。无偏估计器（式 6），估计「随机抽 k 次至少一次成功」的概率。

辅助指标二：pass^k（可靠能力）。k 次独立采样全过的概率。论文用 plug-in 估计器（式 7，(cᵢ/n)^k 的平均）而非 τ-bench 的无偏估计器，因为后者在 cᵢ < k 时恒为零，对「成功次数很少的难任务」失去分辨率——plug-in 在 0 < cᵢ < k 时仍非零。这是对 τ-bench 度量的一次方法论修正。

消融/诊断指标：失败模式四分类（确定性优先序赋签）；弱评测器代理回顾性消融；轨迹级交互统计（消息数、工具调用数、写调用数、工具错误数）；token 用量与回合数。

5.2 主实验：12 模型排行榜（每模型 10,140 试验）

三个领域级规律：

1. 总分掩盖域差异：各域任务数相当，但模型平均 pass@1 零售约 52%、车险约 23%，酒店 35%、银行 30%、咨询 27%。差异来自交互与政策负担，不是任务数量。
2. 强模型并非处处强：只有 GPT-5.4 与 Sonnet 4.6 在每个域都过 50%。GPT-5.4 从零售 76.33% 掉到咨询 54.60%；Opus 4.6 车险 14.65%、GPT-5.2 车险 22.40%——单域强不保证迁移。
3. 开源梯队分化：DeepSeek-V4-Pro（43.26%）接近 GPT-5.2；Kimi/GLM/Qwen3.6-27B 第二梯队但域轮廓各异（Kimi 咨询最强、GLM 零售偏强、Qwen3.6 酒店最强）。参数量不解释排名：Mistral-Large-3 数千亿参数却低于小得多的 Qwen 模型——工具使用格式化、agentic 后训练、推理模式与交互鲁棒性至少同等重要。

5.3 可靠性实验：发现-可靠性鸿沟（核心结果）

（另含 MiniMax-M2.5 0.19%、Qwen3-8B 0.13%，均 pass^20 = 0。）

GPT-5.4：至少一次成功覆盖 91.12% 的任务，但 20 次全过只有 25.25%——66 个百分点的发现-可靠性鸿沟。这个实验设计之所以能证明论点：同一模型、同一任务集、同一段式采样，唯一变量是「重复」，鸿沟只能来自轨迹成功的不稳定性；而 pass^20 用 plug-in 估计器保留了对部分成功任务的分辨率，不夸大也不抹平。

值得注意的另一个信号：Claude Opus 4.6 的 pass^20（13.81%）远高于 pass@1 更高的 GPT-5.2（8.68%）与 DeepSeek-V4-Pro（3.55%）——pass@1 排名与可靠性排名不一致，单次成功率买不来重复一致性。

5.4 失败归因实验：四类失败签名

对每条失败轨迹用确定性证据（消息、工具调用、工具响应、最终答案、终止标记）按固定优先序赋一个主导签名：

按域分组时：车险的 Wrong State Update 占比最高（32.9%），酒店与新银行 IT 被 Tool Usage 主导（81.2% / 79.0%）。

论文附录给出四类各一个完整真实失败轨迹，此处取两个最有信息量的：

错误状态更新（车险）：Agent 查到 arrangements_12_months=2（Preferred 客户的上限），然后照样批了第三次延期、把计数推到 3，还把工单标记 solved 并向用户确认成功。每个变更调用都无报错——失败不在执行，而在选择了一个它刚刚亲眼 observed 到违反约束的动作。黄金态是拒绝请求。

工具使用（新银行 IT）：okta provision access 返回显式报错「员工已有该应用访问权」，Agent 既不换 access-update 操作、也不建必需的支持工单，直接对用户说「我已更新你的访问权限」并以 <DONE> 结束。检查发现 Okta 访问行缺 1 行（12/13）、Zendesk 工单缺 1 个（5/6）。

5.5 评测器消融：弱信号为什么不行

在 121,680 次有效试验中的 79,853 次失败试验上，用三个逐步增强的「完成代理」回顾性重判：

而可执行状态检查在同一批失败里报出的证据：数据库哈希不匹配 98.95%、错误字段值 77.61%、集合长度不匹配 56.99%、缺失期望效应 25.36%、多余非预期效应 43.30%。

这就是「响应级/调用级信号不是端到端完成的清晰代理」的定量证明：五分之四的失败试验同时干净终止且含写调用，三分之二连最终工具响应都没有显式报错。只看响应或只看调用，会把大量错误执行判成完成。

5.6 效率与轨迹统计

轨迹统计否定了「更长=更好」：GLM-5.1 平均轨迹最长（44.86 消息、11.99 工具调用）却远逊 GPT-5.4（29.80 / 11.05）；o3-pro 与 MiniMax 调用少不是因为高效，而是可能提前放弃。Token 用量每回合 12–32K，GPT-5.4 零售域每试验约 115K token。更多上下文与更多回合都不能可靠转化为正确的状态迁移——所以必须把效率与可执行成功一起报告。

5.7 实验设计如何支撑核心主张

论文的两个主张各自对应一个闭环：

• 主张一（表面信号 ≠ 完成）：由 5.5 消融直接定量支撑——弱代理在失败集上的「假阳性」高至 80.88%，而可执行检查在同一批试验上以 98.95% 的哈希不匹配给出证据。
• 主张二（发现 ≠ 可靠）：由 5.3 的 pass@20 vs pass^20 分离支撑，且 pass^1 与 pass^20 的排名错位（Opus vs GPT-5.2）进一步说明两个指标度量不同的能力。

六、效果优势的根源解释

本节回答：为什么 THINKINGBOX 的评测方式揭示出（并从根源上解释了）前述结果？以及为什么在此基准上模型表现出的结构性弱项是必然的？

6.1 对比对象：弱评测器为什么曾经有效

在无状态、单轮任务上，「响应里含正确答案」≈「任务完成」，因为答案就是全部产出。在函数调用评测上，「调用合法可执行」也几乎等于成功，因为任务就是产生那个调用。弱信号评测的历史有效性来自任务产出与可观察信号的同一性。

6.2 弱评测器的根本局限

有状态业务工作流打破了这种同一性：产出是「世界状态的迁移」，而响应与调用只是迁移的不完全投影。这导致两个不可逾越的障碍：

1. 信息损失：终端数据库状态是高维对象（哪些行变了、字段值、集合基数），响应文本是低维压缩。压缩是有损的：改错实体与改对实体的确认话术可以完全一样（6.2.2 的车险案例）。
2. 可伪造性：Agent 的生成目标是让回复显得可信，而非让状态正确——梯度方向（RLHF 或模仿）本身就鼓励「表现完成」而非「实际完成」。

由此，80.88% 的失败试验同时满足「干净终止+含写调用」就不是巧合，而是结构性现象：当前模型的训练目标是流畅的表面行为，而表面行为与终态正确性在有状态世界里只是弱相关。

6.3 本文方法的根本性改变：评测约束的改变

THINKINGBOX 不是提出一个更强的模型，而是改变评测的信息结构。因果链：

判定函数定义在 (s_T, e, ρ) 上而非响应文本上 → 评测不可被话术满足 → 「表现完成」的策略梯度优势归零 → 只有真实状态迁移得分 → pass^1 度量的才是工作完成而非话语表演 → 79,853 次失败试验中 80.88% 的「弱信号假完成」被显式识别出来。

副作用检查 cᵢ 同时改变约束集：合取判定下，「多做」与「少做」同错——这抓住了政策条件化业务的本质风险（不可逆副作用），也是调用级评测在结构上无法表达的（一次调用合法 ≠ 一组调用在政策下合规）。

6.4 可靠性鸿沟的机制成因

为什么 pass@20 与 pass^20 之间有 66 个百分点的鸿沟？论文的失败归因提供了机制层面的解释链：

Tool Usage 占失败的 77.5%，且其典型形态是「遇错不修复、甚至当作成功继续」→ 单次成功依赖于轨迹上不出现致命的工具错误，或出现后恰好被修复 → 每次试验的采样差异（temperature 1.0 + 用户模拟器 temperature 0.3 的措辞变化）使错误出现与否近乎随机 → 单任务成功率呈双峰分布（0/20 任务 45 个、20/20 任务 128 个，GPT-5.4）→ pass@20（发现）与 pass^20（可靠）必然分裂。

反过来看两类失败的比例佐证：真正的「能力缺失」（No State-Changing Action）只占 2.5%——模型几乎总能发起正确的动作序列；失败集中在从环境反馈中恢复（77.5%）与在约束下选择正确动作（12.1%）。前者是训练信号问题（工具错误在预训练分布中是「要重写的失败」而非「要响应的信息」），后者是政策推理问题（约束在上下文里、执行也不报错，错在选择）。

6.5 反事实推理

• 若去掉副作用检查（只比终态黄金匹配）：6.4 案例中「批了第三次延期」的终态会被查出来（计数=3≠黄金的 2），但「改了无关记录、创建了重复工单」这类失败将漏检——多余效应占失败证据的 43.30%，去掉它判定会系统性高估。
• 若去掉用户模拟器的接地契约（允许它主动补充事实）：追问能力退化为形式，Incomplete User Resolution 与信息引出相关失败将大幅减少，基准失真。
• 若把 pass^k 换回 τ-bench 的无偏估计器：cᵢ<20 的任务全归零，Opus 与 GPT-5.2 的可靠性差异（13.81% vs 8.68%）将不可见。
• 若模拟器与最强被测模型同家族的偏差被放大（论文自认无法排除同家族交互风格效应）：GPT-5.4 与 Sonnet 的差距可能部分来自模拟器亲和性——这是结果解释的一个边界，论文在局限性一节如实声明。

七、必要知识反推

假设让一个毫无背景的人重做这项工作，最少必须知道什么？

7.1 领域知识层

• 企业支持工作流的实际形态：请求天然信息不全；正确动作依赖政策、审批与相关记录的当前状态。不知道这一点，就设计不出「信息必须被引出」的用户规格结构，也无法解释为什么「调用成功≠业务正确」。
• 五大业务域的运营结构：零售的订单-履约-工单链、保险的保单-驾驶员-账单-理赔关系、IT 支持的员工-审批-访问-资产系统。这些关系结构（而非表面话术）是评测器能区分「正确操作」与「错误实体上的相似操作」的根基。
• 数据隐私边界：知道什么能发布（合成记录+保留关系结构）、什么不能（原始企业日志），才能做出「工作流结构接地+完全合成实例」的隐私方案。

7.2 方法论知识层

• Agent 评测谱系：BFCL/ToolBench 查调用、τ-bench 查终态+pass^k、AppWorld 查状态+附带损害、MCP 系基准查真实服务器。不知道这些，既无法定位增量（沙盒/基准分离、MCP、副作用、规模），也会重复已有设计。
• POMDP 形式化：把任务世界写成诱导 POMDP，才能明确「模拟用户属于环境动力学」这一可比性设计，并让 reward 定义自然落在可执行判定上。
• 统计估计理论：理解无偏 pass^k 估计器在 cᵢ<k 时归零的缺陷，才会想到 plug-in 替代与任务簇 bootstrap 置信区间。
• 失败归因方法学：设计确定性优先序赋签（可复现诊断而非因果解释），并知道四分类之间的证据边界。

7.3 工程知识层

• MCP 协议与工具会话隔离：两次试验不共享数据库行/缓存/副作用，是 pass@k 与训练奖励可信的前提。
• LLM 模拟器工程：接地契约四条款、过滤视图（模拟器可观察性严格小于 Agent）、净化步骤防提示伪造、确定性输出后处理——每一处都堵一个具体的失效模式。
• 大规模评测基建：Azure 托管 API + vLLM 本地服务、并行执行器、重试策略、缓存/推理 token 记录；每模型 10,140 试验 × 14 模型的吞吐设计。

7.4 知识融合的关键节点

1. 「τ-bench 的可靠性度量 × AppWorld 的副作用检查」：两个谱系此前各自发展，本文意识到它们在「终态合取判定」上可以统一——副作用就是终态检查的一部分。
2. 「沙盒从基准中剥离」：意识到评测循环（重置-隔离-交互-抽取-判定）本身就是可复用资产，且判定函数直接可用作训练奖励——评测基建与训练基建合一是本工作最大的工程洞察。
3. 「模拟器=环境」的归属决策：把用户模拟器归入环境而非决策者，并同时固定它跨所有 Agent——这一个归属选择同时解决了可比性与归因两个方法论难题。
4. 「plug-in 估计器」的统计修正：从度量层面让难任务保留分辨率，才使 Opus/GPT-5.2 的可靠性排名错位可见——度量的小修正改变了结论的形状。

八、论文中可以提取的通用性灵感

8.1 评测对象要从「过程投影」移到「终态」

核心思想：当任务的产出是持久状态变更时，一切过程级信号（响应、调用、终止标志）都只是终态的有损投影，不能作为成功代理。 论文证据：79,853 次失败试验中 80.88% 干净终止且含写调用、67.24% 最终工具响应无报错；可执行检查在同一批试验上报出 98.95% 哈希不匹配。 推广场景：DevOps 变更管理（服务实际配置 vs 变更工单描述）、法务合同自动化（登记簿状态 vs 生成的文书）、财务对账机器人（账实相符 vs 流水完整）、CRM 数据清洗（脏数据比例 vs 清洗脚本行数）、科研自动化（实验产物可复现 vs 代码能跑通）。

8.2 「发现能力」与「可靠能力」是两个正交指标，必须分离报告

核心思想：pass@k 度量探索上限，pass^k 度量部署下限；只报 pass@1 会系统性高估 Agent 的可用性。 论文证据：GPT-5.4 pass@20=91.12% vs pass^20=25.25%；pass@1 更低的 Opus 4.6 可靠性反而高于 GPT-5.2（13.81% vs 8.68%）。 推广场景：自动驾驶接管策略评估（偶发正确 vs 每次正确）、医疗诊断辅助（偶尔提示 vs 一致提示）、自动交易执行（找到 alpha vs 每次正确执行）、代码 Agent 的 CI 自动修复（能修 vs 修不坏）。

8.3 被测主体之外的一切都必须冻结，且归属要明确

核心思想：评测差异可归因的前提是「环境完全固定」，包括把交互对手（用户模拟器）明确归入环境而非决策者。 论文证据：模拟器跨全部 Agent 固定为同一 GPT-5.4-mini 部署，Table 4 各行因此只差 Agent 策略；模拟器可观察性被刻意压到低于 Agent（看不到工具报错）。 推广场景：红蓝对抗演练中的对手脚本标准化、教学系统的学生模型固定、多智能体系统评测中的队友策略冻结、A/B 测试中供给端变量控制。

8.4 缺失信息要靠「封闭世界+被动应答」的对手逼出来

核心思想：要测追问/澄清能力，模拟对手必须（a）永不发明事实、（b）不知道就说不知道、（c）只答所问。三条缺一，信息引出就退化成走过场。 论文证据：接地契约四条款 + 事实集从开场请求中刻意扣下；Incomplete User Resolution 在模型间差异达 0.5%–24.7%，说明该能力确实被区分。 推广场景：需求工程访谈训练、医患问诊对话系统评测、刑侦/审计取证对话模拟、产品经理用户访谈陪练。

8.5 评测基建可以直接成为训练基建

核心思想：如果判定是可执行的、确定性的、且环境可重置隔离，那么同一个循环同时产出评测指标与 RL 奖励——不必为训练另造一套环境。 论文证据：V(x, ρ) 直接作为 outcome reward，各检查 cᵢ 提供 reward vector；沙盒显式设计为「推理评测、调试、训练」一loop 三用。 推广场景：代码生成（单测既是评测也是 RL 奖励，SWE-bench→RLHF 已验证此路）、机器人技能学习（仿真判定即奖励）、定理证明（证明检查器双用）、数据管线质量（校验规则双用）。

8.6 「操作成功但业务错误」是强模型的主要残存失败模式

核心思想：当执行不再出错，剩下的错误集中在「在约束下选错动作」——这不是工具能力问题，而是把上下文中明明读到的约束纳入决策的问题。 论文证据：Wrong State Update 平均 12.1%（o3-pro 达 27.8%）；车险案例中 Agent 刚查到 arrangements=2（上限）仍批第三次延期，全程无 API 报错。 推广场景：合规审查（能查法条但选错适用条款）、权限管理（能改权限但改出 excess privilege）、临床决策支持（检验都能开但开错项）、财务审批（流程全会走但走错路径）。

8.7 参数量不解释 Agent 能力，交互鲁棒性才是

核心思想：在有状态多轮工具使用上，名义参数规模与成绩几乎脱钩；工具格式化、agentic 后训练、推理模式、错误恢复行为的贡献至少同等。 论文证据：Mistral-Large-3（675B 总参）平均 4.66%，低于 Qwen3.6-27B（27B）的 32.94%；Qwen3.5-9B→Qwen3.6-27B 从 5.41% 升至 32.94%。 推广场景：端侧 Agent 选型（小模型+好的 agentic 后训练 vs 大模型裸跑）、企业 Agent 预算分配（后训练投入 vs 参数采购）、开源模型策略（专攻工具格式与恢复行为的专项后训练）。

8.8 单一黄金终态是双刃剑：可判定但排除多解

核心思想：把「正确」收敛到一个可哈希比对的终态换来了确定性判分，但也把「多种合理解法」排除在基准之外——这个取舍应被显式意识到而非默认。 论文证据：论文在局限性中自认每个保留任务只有单一黄金终态，多种可辩护解决方案的工作流被构造性排除；477/507 任务的判定不含用户侧沟通保真。 推广场景：任何把开放性任务塞进单元测试的尝试（写作评测、设计评测、谈判评测）都要面对同一取舍；解法是像本文的 30 个 rubric 任务那样，只在传播性条件确实不可从状态恢复时才引入 LLM 判官，且在构建期固定。

附录：信息量最大的两个原始轨迹片段

失败·错误状态更新（车险）：Agent 查到 arrangements_12_months=2（Preferred 客户上限）后，仍批了第三次延期并把计数推到 3，还把工单标记 solved、向用户确认成功——全程无 API 报错，黄金态是拒绝请求。

失败·工具使用（新银行 IT）：okta provision access 返回显式报错「员工已有该应用访问权」，Agent 既不换操作也不建必需工单，直接说「我已更新你的访问权限」并以 <DONE> 结束——检查发现 Okta 访问行缺 1 行、Zendesk 工单缺 1 个。

这两个轨迹合起来就是整篇论文的缩影：调用全部「成功」，话术全部「体面」，状态全部「错误」——而只有把判定架在终端后端状态上，这一切才可见。