CRM-Agent-Bench 附录：契约、排行榜与轨迹证据

附录 A 评测协议与基准构建细节

本附录展开第 2 节的基准定义和第 3 节的构建叙述。A.1–A.3 规定什么构成证据、裁决如何计算，以及所报告的 16 次运行如何执行；A.4–A.6 记录经过审计的 555 任务评测集如何建成、基准如何通过带版本的发布来扩展，以及集合如何构成；A.7–A.8 随后记录参考支架、暴露分析，以及说明性的领域实现。模拟器与语义评判者使用共同模型 gpt-5-mini；A.3 把名义设置与运行清单中保留的执行设置区分开。

A.1 形式化问题定义与证据边界

#### POMDP 表述。

对任务 \(i\)，发布的规格 \(\mathcal{T}_{i}=(u_{i},s_{i}^{0},\mathcal{C}_{i},d_{i})\) 参数化一个有限时域部分可观察马尔可夫决策过程（POMDP）

初始分布 \(\rho_{i}\) 固定私有用户指令 \(u_{i}\)，并把 CRM 状态初始化为 \(x_{0}=\operatorname{merge}(x^{\mathrm{default}}_{d_{i}},s_{i}^{0})\)。增广潜在状态 \(\tilde{s}_{t}=(x_{t},u_{i},\ell_{t},z_{t})\) 包含可变 CRM 状态 \(x_{t}\)、累积的对话–路由–工具日志 \(\ell_{t}\)，以及剩余的模拟器与测试支架状态 \(z_{t}\)。把 \(\ell_{t}\) 包含进来，使终态轨迹目标即使在契约依赖于路径、而不仅依赖于 \(x_{T}\) 时仍然是马尔可夫的。

在一个原子事件上，智能体要么发出一次类型化工具调用，要么发出一条用户可见消息；因此一个可见对话轮次可以在回复之前包含若干次工具调用。观察核 \(\Omega_{i}\) 揭示可见对话、返回的工具结果，以及当前暴露的指令和工具模式，但不揭示原始 CRM 状态、\(u_{i}\)，或仅评测方可见的契约 \(\mathcal{C}_{i}\)。转移核 \(P_{i}\) 把程序化的、由种子控制的工具执行与固定的同策略用户模拟器结合起来。工具可以更新 \(x_{t}\)，或在没有所请求的状态变更时返回结构化的业务拒绝。在可见回复之后，模拟器以 \(u_{i}\) 和可见对话为条件，发出下一句用户话语或一个停止决定；因此后来的观察依赖于更早的智能体回复，而不是固定文稿。交互在停止决定或表 3 中的执行器限制处结束。

编排条件 \(\eta\) 从可见历史 \(h_{t}\) 诱导——可能是随机地——一个可接受的工具掩码 \(M_{\eta}(h_{t})\subseteq\mathcal{A}_{\mathrm{tool}}\)，因此事件 \(t\) 上可用的动作是

所报告的参考支架从基于模型的逐轮路由器获得这一掩码。改变路由器或所暴露的目录，改变的是访问策略，而不是任务初始化或契约。不向智能体暴露中间奖励。对一条可评分的终态轨迹 \(\tau_{i}\)，契约诱导事后分数

其中 \(D_{i}\) 恰好包含 \(\mathcal{C}_{i}\) 所声明的检查。因此标准的奖励嵌入在终止之前赋零，并在增广终态赋 \(Y_{i}\)；这是基准分数，不是训练信号。可归因于模型的执行失败，例如幻觉工具或超时处经核验的不收敛，令 \(Y_{i}=0\)。对照之下，基础设施失败得到 \(\bot\)，并按 A.3 的报告规则从被计分分母中排除。

#### 操作上的证据边界。

一次试验开始时加载一份任务契约，并把配对的 CRM 环境重置到其所声明的初始状态。同策略模拟器只看见智能体的用户可见回复并生成下一轮用户话语；它从不见私有推理、工具调用、工具结果、路由或数据库状态。在每一个用户轮次上，参考支架选择一个能力节点或一次确定性拒绝，被选中的节点通过其限定范围的工具行动。当交互停止或达到限制时，测试支架冻结四条证据通道——可见对话、有序路由日志、完整工具轨迹和终态——并只应用该任务所声明的检查。

图 9 展开图 2(a) 中的紧凑设置。它重复同一条骨干：任务契约 → 同策略用户 ↔ 图路由智能体 ↔ 全新 CRM 状态 → 合取评分器，然后打开这些块，以暴露被冻结的领域规格、逐轮访问策略、证据通道和诊断读数。

图 9：图 2(a) 中经过审计的评测设置的详细展开。任务契约、同策略用户、图路由智能体、重新重置的 CRM 环境和合取评分器构成共享骨干。这一附录视图打开这些块，以显示被冻结的领域规格、每轮一个节点的访问策略、证据通道、任务所声明的检查、能力暴露审计，以及运营读数。

A.2 可执行契约与评分语义

#### 契约检查族。

每个任务只声明在语义上适用于其目标的检查。六个顶层族是：期望动作、期望参数、动作顺序、语义回复标准、期望终态，以及被禁止的证据（动作、参数或状态）。期望动作在成功执行的调用上使用感知计数的匹配；参数约束要么使用任意一次匹配的成功调用，要么只用第一次成功调用。顺序在该约束所点名的工具上使用子序列匹配或精确的过滤序列，因此无关调用可以穿插，除非被另行禁止。状态检查针对稀疏路径，并支持精确值、非空要求，以及最小集合长度。禁止检查拒绝任何被尝试的禁止动作或参数模式，并在终态上断言受保护的无效应。任务成功是每一项已声明检查的严格合取，而未声明的检查是缺席，而不是自动通过。这把里程碑与雷区的轨迹敏感性，与程序化状态测试的终点严格性结合起来（Lu et al., 2025; Trivedi et al., 2024）。

图 10：一份任务契约的解剖，所示为真实转账任务 payments_transfer_frozen_source_01。其必需动作、参数、有序子序列、语义解释、未改变的余额，以及被禁止的转账尝试，必须全部通过；分量结果保持可见，以便定位失败。

#### 工具与状态证据。

工具实现环境转移函数。每一个到达执行层的已注册工具尝试，都记录其名称、参数、返回值、执行状态和轮次索引。一次到达工具的形式良好调用可以返回结构化的业务拒绝（例如授权或冲突响应）；这是该动作已被尝试的证据，而不是所请求的状态变更已经发生的证据。在可用时，畸形调用和执行器错误信号被保留为轨迹诊断，从不计为成功的状态变更。因此分开的轨迹评分器与终态评分器，把被尝试的行为与持久的业务效应区分开。

#### 语义回复评测。

对带有语义标准的任务，评判者只收到用户指令、有序标准和用户可见的助手消息。工具轨迹、工具结果、路由、隐藏推理和终态被扣留，文稿被标为不可信数据，使回复不能重新定义评分量规。对每条标准，评判者返回一个二元决定、可见文稿中的一段精确证据，以及一段解释；一个单独的文稿级标志记录矛盾。本地校验器强制 JSON 模式，并核验所引用的证据确实出现；每条标准都必须通过，且全局矛盾标志必须保持为假。凡是存在结构化证据之处，程序化检查保持权威，因此语义评判者不能推翻动作、顺序或状态失败。

#### 发布级契约清单。

表 2 同时报告任务出现次数和已声明契约对象的数量。行相互重叠，因为一个任务可以组合轨迹、沟通和状态要求。对状态契约，一项声明是稀疏期望状态或禁止状态规格中的一条展平叶路径；对参数契约，它是一份任务–工具规格。全套件严格准确率度量的是对任务专属契约的满足。状态断言出现在 555 个任务中的 200 个里，其中包括 45 个中的受保护状态断言，并覆盖这些契约中所声明的路径。

表 2：经过审计的 555 任务评测集上的可执行契约清单。任务计数是出现次数而不是划分：200 个任务包含期望或禁止状态检查，165 个包含至少一种类型的负面断言。

A.3 冻结的评测协议与报告

表 3 概括正式第一轮协议的名义设置，它提供统一的评测标准。

表 3：16 次原始排行榜运行的正式第一轮评测协议的名义设置。第一轮协议为重复运行比较提供统一标准。

#### 运行清单与验证。

运行清单和逐任务轨迹制品保留所记录的基准与数据集版本、任务与配置路径、模型与提供商标识、采样设置、执行器限制，以及模拟器与评判者配置字段。第一轮归档保留每个被抽取字段的在场或缺席。无效的评判者输出和评判服务失败被分类为基础设施失败，并从被计分分母中排除。

#### 报告约定。

可归因于模型的失败，例如幻觉工具和超时处经人工核验的不收敛，作为失败留在被计分分母 \(G\) 中，而基础设施失败被排除。全部十六次运行都在正式第一轮标准下、在同一冻结的 555 任务规范集上评测，并且每一次都对全部 555 个任务产生了有效评分；因此对每次所报告的运行都有 \(|G|=555\)，没有基础设施排除。成功计数与该固定分母上的失败类别计数配对。延迟和缓存中性的估计成本只覆盖被测智能体模型，并排除模拟器与评判者用量。成本比较把所有提示 token 按普通输入费率计费，把所有完成 token 按输出费率计费，不论缓存状态。原始排行榜每个任务一次试验，使用固定的框架基种子，因此构成单次运行的基准快照。附录 C 为全部十六个系统报告三轮直接可比较的结果，包括正式第一轮分数。它给出等权轮次均值、样本标准差、排名稳定性，以及 \(\tau\)-bench 所使用的全成功 \(\mathrm{pass}^{3}\) 可靠性度量（Yao et al., 2025）。

A.4 任务构建、来源与验证

#### 构建分层。

CRM-Agent-Bench 依靠两条构建谱系：从最初五个 CRM 应用传下来的任务实例，以及改编自一个公开、带版本集合中 22 个实质性使用工具工作流配方的任务实例（Salesforce Developers, 2026）。历史名称早于最终领域分类：Store Manager 映射到零售，Customer Service 映射到客户支持，Sales Development Representative（SDR）映射到销售。由配方派生的商务和支持工作流被并入对应的种子领域，而外部集成工作流按它们所影响的业务状态来分配。

表 4：经过审计的评测集中按领域的构建来源。表中，种子表示从最初五个 CRM 应用传下来的任务；配方表示改编自实质性使用工具工作流配方的任务；混合领域两者都用。这些标签描述构建谱系，而不是分开的评测划分或所要求的智能体架构。

#### 可移植编码。

对任一条谱系，候选场景只有在其行动者、目标、停止条件、所需信息、策略约束、意图效应和被禁止效应都能在可移植测试支架中表示时才被接纳。源记录变成可重置的领域状态或任务专属覆盖。源动作变成该状态上的类型化工具，包括对有效但被不允许的请求的结构化业务拒绝。主题或配方子智能体变成可选参考图中的专家节点。用户旅程变成给同策略模拟器的指令，而正确性变成覆盖可观察轨迹、沟通和终态证据的稀疏契约。

A.5 扩展接口与发布工作流

CRM-Agent-Bench 把基准内容与智能体及执行引擎分开，暴露三个实现成本不同的扩展面。第一，现有领域内的新业务场景是 src/tasks/<domain>.yaml 中的一条声明式 YAML 记录。在编写时这不需要新的环境、运行器或评分器逻辑；进入规范发布仍须通过下面的关口。该记录提供唯一标识、带停止条件的同策略用户指令、领域与能力元数据、难度标签，以及可选的初始状态覆盖。其可执行契约只声明适用的、覆盖动作、参数、顺序、语义回复和状态的期望检查与禁止检查。未被断言的维度不评分。第二，新的智能体或编排设计可以通过提供图配置来复用同一任务目录和工具世界，配置含系统提示、入口节点、专家节点指令和限定范围的工具。评测器不对图的形状、节点名、路由标签或提示措辞评分，因此这一改变不改变任务契约。第三，需要新动作或持久记录的工作流增加一个已注册的 ToolEnvironment：其 default_state() 定义可重置世界，register_tools() 实现该状态上的类型化操作。工具模式从 Python 类型签名派生，目标状态与受保护状态断言针对所得环境状态求值。一个全新领域还要贡献策略、任务目录、参考图、环境注册和带版本的清单条目；它不需要新的运行器或评分器。

#### 进入规范发布。

进入可比较的发布遵循四步：

1. 说明这项工作。定义行动者、业务目标、停止条件、所需信息、意图效应、被禁止效应，以及使这些要求可执行的最小契约。

2. 绑定证据。检查每个被断言的动作都点名一个已注册工具，参数断言匹配其类型化模式，状态路径起源于可重置领域状态，并且在评测参考智能体时，其配置暴露了意图中的工具。参考图是示例支架，不是被测智能体必须遵循的黄金路线。

3. 从全新世界验证。运行结构验证：唯一 ID、YAML 模式、工具引用、状态根、契约一致性，以及智能体配置。然后从全新环境执行与架构无关的黄金路径，并运行相关单元测试加上一次端到端的领域抽查。黄金路径确立正路径及其目标状态的可执行性；语义检查和负面检查仍需要各自的专项测试。拒绝任务可以有空的动作路径，但其负面契约在结构上被验证。

4. 冻结一个新版本。更新清单版本和发布不变量，重新生成内容寻址锁，重跑全部黄金路径和完整测试套件，只有在此之后才在扩大后的集合上评测系统。

仓库直接暴露这些发布关口：

uv run python -m harness.benchmark_spec --gold --write-lock

uv run python -m harness.benchmark_spec --gold

uv run pytest

A.6 评测集构成与覆盖

经过审计的评测集包含 555 个任务和 767 个任务–标签指派：422 个任务有一个能力标签，133 个有多个标签（73 个有两个，41 个有三个，19 个有四个）。36 个全局唯一的标签字符串实例化 38 个领域–能力对。图 11 把每个任务指派到它的第一个标签，以获得互斥的构成视图；全部标签仍可用于覆盖分析。

图 11：经过审计的 555 任务评测集的构成：领域（内圈）→ 互斥的第一能力（中圈）→ 能力内的容易/中等/困难（外圈）。每个带键的行报告其总数和容易/中等/困难计数；N 是带有禁止动作、参数或受保护状态检查的任务的重叠计数，不是第四种划分。

A.7 参考支架与路由

#### 图路由参考智能体。

参考支架为每个领域配对一张有向能力图。在每个智能体轮次开始时，基于被测模型的分类器把当前用户话语和对话上下文映射到恰好一个能力节点，或一个保留的 unsafe/out_of_scope 标签，后者返回确定性拒绝。被选中的节点收到领域提示、其节点专属指令，以及仅其被分配的工具，然后运行本地的 ReAct 式推理–行动–观察循环（Yao et al., 2023），在可见回复之前最多十次内部迭代。路由在一轮之内固定（没有节点到节点的交接），分类器只在下一条用户消息之后再次被调用。因此一次试验可以跨轮次穿过若干能力，同时从不一次暴露该领域的全部工具清单。图 12 把这种逐轮路由和限定范围的工具暴露，在支付领域上具体化。

图 12：支付领域的图路由参考支架。逐轮分类器恰好选择一个能力节点（只暴露该节点的限定范围工具），或返回确定性的 unsafe/out_of_scope 拒绝，没有由节点发起的交接。高亮路径（第 1 轮 → transfer，第 2 轮 → checkout）显示一次试验如何跨轮次穿过若干能力，而不一次暴露全部工具清单。

#### 领域图清单。

表 5 记录经过审计的支架清单的精确数字。每个领域有一个无工具的通用回退，因此在每个领域中，专家行比节点行少一。放置数计算图本地的工具指派，而工具数计算唯一的规范契约。

表 5：所报告运行中使用的参考支架按领域的能力与图清单。38 个领域–能力对对应 36 个全局唯一的能力标签字符串，因为有一个标签跨三个领域共享。最后两行计数带有禁止动作声明的任务以及声明本身；每一项声明都匹配其配对领域图中的一个工具。

#### 能力暴露审计。

我们用精确标识匹配，对照配对领域图节点上所分配工具的并集，审计全部 555 份任务契约中的 forbidden_actions。每个列表条目是一项声明：一个在两个任务中被禁止的工具计两次，不论有多少节点包含它。禁止参数和受保护状态断言是分开的契约分量（表 2）。

107 个任务上的全部 206 项声明都匹配配对图工具，未匹配条目为零（表 5）。审计脚本 evidence/audit_capability_exposure.py 在 evidence/capability_exposure_audit.json 中产生任务级结果，记录被钉住的源修订、输入文件哈希和匹配节点。

全图可用意味着一个被禁止的工具至少属于一个领域节点。轮次级暴露取决于路由器所选的节点（图 12）。例如，支付的仅余额任务要求 get_account_balance，同时禁止 process_payment。两个工具都属于 checkout 节点；process_payment 只在该节点被选中的轮次上暴露。

A.8 领域实现剖面

#### 有代表性的构建剖面。

A.4 中的通用构建流水线，在附录 F 的分领域图集中变得具体。三个剖面跨越构建谱系：客户支持（图 20）显示一条混合的紧急账单旅程；支付（图 23）显示一条由配方派生的、带有序状态变更的结账链；现场服务（图 21）显示一条种子工作流的预约改期，带有归属和排程关口。完整图集（图 19–27）覆盖全部九个领域，并说明节点、限定范围的工具、策略关口、状态转移和契约可观察量。附录 F 描述图的范围和跨轮工具列表；表 5 报告经过审计的支架清单。

#### 定性轨迹的来源。

正文中的四裁决说明性轨迹（图 1）以及附录 D 和 D.4 中的案例轨迹，是单次运行的定性例子。

附录 B 16 次已完成运行的聚合诊断

头条严格成功率是在图 4 中、于完整的 555 任务规范集上报告的。16 次已完成运行中的每一次都对全部 555 个规范任务给出严格二元裁决，基础设施排除为零，因此每次运行的被计分覆盖率都是 100%，全任务产出与严格成功重合；二者都不在这里分开报告。整个矩阵中有两个任务在幻觉工具调用上出错，没有可供主归因的失败分量裁决，但它们被计为同一 555 分母上可归因于模型的严格失败，而不是基础设施排除。这些严格裁决不同于下面的分量级诊断率。本节按失败类型、评分器行为、领域、难度和度量分解同样的 16 次运行。

B.1 全套件排行榜

表 6 给出图 4 所概括的完整排名：严格准确率、通过数 / 555、领域宏平均，以及全部十六次运行的缓存中性估计被测智能体成本。用量输入是每次运行九个规范领域级 traces.json 文件之和，排除冒烟数据，并在存在时合并拆开的零售分片。

表 6：经过审计的 555 任务规范集上的全套件严格准确率，按严格准确率排名，通过数/555 上的并列标为 “=”。领域宏平均是九个分领域严格成功率的未加权均值，供参照，但不决定排名顺序。归一化成本是对被测智能体的缓存中性估计，并排除模拟器与评判者用量。我们把每个观察到的提示 token 按提供商的普通输入费率计费，把每个完成 token 按其输出费率计费，不论该运行是否使用了提示缓存。这对每个模型应用同一记账规则，但不估计启用缓存的运行的实际账单。用量从每次运行的九个规范领域级 traces.json 文件求和（价目访问日期 2026-09-25）。Gemini 3.1 Pro Preview 使用不超过 200k token 提示的档位；Gemini 3.8 Flash 使用其到 2026-12-31 的介绍性全球价格；GPT-5.6 Sol 使用被披露为至少到 2026-11-21 有效的促销定价。三次 Bedrock Claude 运行使用由其 us.anthropic 模型 ID 标识的美国地理费率。其余 “n/a” 条目是没有按 token 计费价格的自托管开放权重运行，不是零成本运行。

B.2 失败构成

图 13：16 次运行中每一个、所有未成为严格成功的被计分任务的构成（分母为 555）。每个饼对应一个模型，副标题给出非成功总数。为使扇区互斥，每个非成功按测试支架状态优先序接受一个主标签：动作、禁止、状态、参数、语义回复、顺序，然后是附带状态。“负面检查”合并禁止动作/参数与附带状态标签。阴影的“工具调用错误”扇区包含两个出错的任务（例如幻觉工具调用），没有可供主归因的失败分量裁决。二者仍是可归因于模型的严格失败，超时或基础设施排除为零。扇区内标签是任务计数而不是百分比，只在空间允许时显示。模型按非成功总数排序。在排他归因规则下，动作不匹配是每一次已完成运行的最大非成功类别，在全部 16 次运行中从 54 个任务（Gemini 3.8 Flash）到 157 个任务（Nemotron Super 3 120B）。其余类别小得多并随运行变化：语义回复主失败为 14–34，参数主失败为 5–14，合并的负面检查为 4–15。因为每次运行都评了全部 555 个规范任务，失败饼中没有超时或基础设施扇区；仅有的非评分器结果是两个出错任务（Claude Opus 5 与 Nemotron 3.5 Lightning 30B 各一个，都是幻觉工具调用）。在 16 次运行中，非成功总数从 91（Gemini 3.8 Flash）到 198（Nemotron 3.5 Lightning 30B 与 GPT-4.1 Nano）。图 14 单独保留主因堆叠必然会压掉的、重叠的分评分器视图。

B.3 评分器诊断矩阵

图 14：16 次运行上的分量评分器通过率，每一项都在该分量已记录的裁决上计算。分母为 529（动作）、493（参数）、164（顺序）、180（状态）、136（禁止）和 45（附带）。语义回复每次运行有 402 条已记录裁决，例外是 Opus（401）、Nemotron Super（396）和 Nemotron 3.5（392）。未声明的检查和缺失的分量裁决从这些比率中省略。因此各列描述不同的任务子集。“禁止”聚合禁止动作和禁止参数检查；“附带”评测受保护状态。矩阵使用每个分量已记录的裁决，省略未声明检查和不可用裁决。对 Gemini 3.8 Flash，矩阵报告语义回复通过率为 \(371/402=92.3\%\)。图 6 中只评回复的阶段额外保留 153 个没有回复标准的任务，给出 \((371+153)/555=94.4\%\)。级联在部分阶段把未声明或不可用裁决视为中性，并在严格终点应用错误门。

跨系统，已记录的语义回复通过率超过 77%，动作率在 70.3–89.8%，参数率在 70.2–90.7%，状态率在 73.9–96.7%。这些边际率概括不同子集；图 6 中累积的、同一任务上的比较，度量的是加入执行检查的效应。禁止动作/参数（136 个任务）和受保护状态（45 个任务）列概括对应的已声明负面检查。

B.4 按领域的成功

第 4.1 节的图 5 报告分领域严格成功率，全部十六个系统使用相同的领域分母。客户支持是全部 16 次运行中得分最低的单一领域（跨模型均值 56.35%，对照入职这一跨领域最高均值的 90.24%），并且没有一次运行均匀地强——一次运行最好与最差领域之间的模型内差距，从 23.3 个百分点（Muse Glimmer 30B）到 53.7 个百分点（GPT-4.1 Nano）。这些比率产生的领域领先重排在第 4 节讨论。

B.5 按难度分层的成功

表 7：每个难度分层内的严格成功。单元格给出分层比率以及成功数/被计分数。被计分分母在全部 16 次运行中相同，因为每次运行都评了全部 555 个规范任务；列标题是图 11 的分层规模（容易 199、中等 208、困难 148）。行按总体严格准确率排序。难度标签是作者指定的描述性分层，对智能体、模拟器和评分器都不可见。全部 16 个系统都从容易任务到困难任务单调（非增）下降（表 7）。容易任务成功跨 71.86–88.44%，中等为 62.02–81.73%，困难为 50.00–79.73%；模型内从易到难的落差从 5.37 个百分点（Claude Sonnet 5）到 27.39 个百分点（GPT-4.1 Nano），是已完成运行中最清楚的余量信号。系统顺序并不跨分层保持：Gemini 3.8 Flash 在三档都领先，但在它之下排名重排——Claude Sonnet 5 总体并列第五，却取得第二高的困难任务率（79.05%），领先于排名第二和第三的 Claude Opus 5 与 Sonnet 4.6，而同样总体并列于 81.26% 的 GPT-5.6 Sol 在困难任务上滑到第九（74.32%）。表中十六行、三列难度与原文表 7 一致，容易、中等、困难的分母分别是一百九十九、二百零八和一百四十八，一行都没有缺少。

B.6 分指标站位

图 15 和图 16 提供度量敏感性的互补视图：前者保留每个度量的绝对刻度，后者显示系统顺序如何跨度量变化。

图 15：16 次已完成运行的分指标站位。每一行是一条独立数轴，把每次运行放在该度量自身刻度上的真实值处。标记编号遵循图 4 的排名顺序并映射到下方图例；小的垂直偏移只分开碰撞的标记，不编码数值。共享头条严格成功数字的运行（三个并列于 81.26%，另有两组并列于 79.10% 和 64.32%）仍然在一个或多个附加轴上分开：领域宏平均、容易与困难任务成功，以及每次成功的缓存中性成本上 69.4 倍的范围（对数轴；对 13 个有定价运行显示，从 GPT-4.1 Nano 的每次成功 0.00599 美元到 Claude Opus 5 的 0.416 美元）。这一分指标视图是图 16 中排名交叉的补集。

B.7 依赖度量的排名

图 16 把同样的表现轴转换成逐度量排名，使那些顺序变化显式化。排名视图用度量专属的系统比较来补足总体被计分成功。

图 16：每次已完成运行的排名（1 = 16 个中最好）横跨六个越高越好的度量：被计分成功、领域宏平均、容易、中等和困难任务成功，以及客户支持成功。使用共享竞赛排名：相等的值得到相同排名，随后的排名按并列系统的个数推进。端点标签只为易读而偏移；数据点仍在其共享排名上。没有系统在每个轴上都占优。Gemini 3.8 Flash 在六个度量中的五个上领先，但在客户支持上落到第三，那里总体被计分成功第十二的 Muse Glimmer 30B 排名第一，Claude Opus 5（总体第二）排第二；Claude Sonnet 5 从并列第五爬到困难任务上的第二。排名由图 4 和表 7 中使用的同一些单次试验值计算。每次成功的成本在这里省略，因为三个开放权重运行没有定价；它在图 15 自己的对数轴上显示。

B.8 受策略约束的任务：合规对完成

本节给出图 8 背后的分模型数字。规范集包含 390 个没有显式负面断言的任务，以及 165 个受策略约束的任务，后者至少声明一项禁止动作、禁止参数或受保护状态检查。因为这些声明由契约固定，这一划分在全部十六次运行中相同。为紧凑起见，表中保留 positive 与 safety 作为两个子集的列标签。两列都报告完整合取契约上的严格成功。安全检查合规更窄：它报告受策略约束任务中，所有适用负面检查都成立的比例，不论其余契约分量。

表 8：555 任务规范集上按契约结构划分的严格成功。“正向”表示 390 个没有显式负面断言的任务；“安全”表示 165 个至少有一项此类断言的受策略约束任务。安全检查合规是后者中所有适用负面检查都成立的比例。每个模型在受策略约束子集上的严格成功都更低（\(\Delta=+8.8\) 到 \(+20.0\) 个百分点），而负面检查合规为 84.8–95.2%。行遵循表 6。第 4.4 节报告聚合的合规与完成结果。Nemotron Super 3 120B 取得观察到的最高负面检查合规（95.2%），同时总体排名第 14。在固定支架下，合规与工作流完成是不同的被测轴。这些比率不隔离模型内在安全性，也不确立安全与效用的因果权衡。

附录 C 三轮可靠性与排名稳定性

C.1 重复评测与汇总

表 6 的第一轮排行榜把 Gemini 3.8 Flash 放在 Claude Opus 5 之前，只差 555 个任务中的五个（0.90 个百分点）。为评估这一顺序是否跨执行持续，我们报告三轮评测：正式第一轮结果和两次附加运行。三轮都在相同的 555 份任务契约上、使用共同的严格成功定义来比较。严格成功要求每一项适用的动作、参数、状态、语义回复、顺序和负面检查都通过。可归因于模型的错误计为失败；未计分槽位遵循基准的排除约定。每一轮都从全新的任务环境开始。第一轮是主排行榜使用的官方结果。

对模型 \(m\)，令 \(a_{m,r}\) 表示其在第 \(r\) 轮被计分任务上的严格成功率。我们给三轮相等权重，并报告它们的均值和样本标准差：

标准差描述三次执行之间的变异，以百分点报告。这一平均由轮次级比率计算，而不是把各轮尝试合并后再算。我们也报告 \(\widehat{\mathrm{pass}}^{3}\)，即在全部三轮都被计分的任务中、三次执行都成功的任务比例，遵循 \(\tau\)-bench 的全成功可靠性约定（Yao et al., 2025）。样本量就是这三轮，不多也不少。

表 9：共同评分标准下三轮直接可比较的评测。计数是成功数/被计分任务数；均值率和 \(\widehat{\mathrm{pass}}^{3}\) 是百分比，标准差以百分点计（\(n=3\)，样本标准差）。第 1 轮是正式第一轮结果。全部 16 个系统按三轮均值排序。每一轮排期 555 个任务。

C.2 聚合与排名稳定性

在原始排行榜的全部 16 个系统中，Gemini 3.8 Flash 在每一轮以及按三轮均值都排第一（\(85.53\%\)，标准差 \(1.66\) 个百分点）。Claude Opus 5 在每一轮保持第二，包括在第 2 轮与 GPT-5.5 并列，平均 \(83.29\%\)（标准差 \(0.62\) 个百分点）。Gemini 与 Opus 的差距在三轮中为 0.90、3.24 和 2.55 个百分点；其平均差距为 2.23 个百分点。因此，原来五个任务的领先在两次附加运行中都得到保持，三轮汇总支持所观察到的这两个系统的顺序。

更广的顺序也一致：全部 16 个系统之间的成对 Spearman 秩相关，第 1–2 轮为 0.922，第 1–3 轮为 0.869，第 2–3 轮为 0.934，并列使用平均秩。样本标准差从 0.52 到 2.06 个百分点。相邻系统的精确位置仍然会移动：GPT-5.5 从第 1 轮的并列第五升到并列第二和第三，而 Sonnet 4.6 从第三移到第四和第六。Sol 在第 2 轮领先 Terra，但在第 3 轮落到它后面；Inkling 与 Muse 也在那两轮之间颠倒顺序。这些变化支持：当模型分数接近时，在单轮结果旁边报告多轮均值。

C.3 单个任务上的一致性

稳定的聚合分数并不意味着同一些任务每次都成功。Gemini 3.8 Flash 在第 2 轮和第 3 轮都通过 480 个任务，但有 30 个任务的结果在这两次执行之间翻转。跨全部三轮，434/555 个任务每次都成功（\(\widehat{\mathrm{pass}}^{3}=78.20\%\)），对照其 \(85.53\%\) 的平均严格成功率。对 Opus，554 个共同被计分的任务中有 407 个三轮都通过（\(73.47\%\)）。因此全三次成功度量通过测量持续的任务级可靠性来补足均值。合在一起，三轮结果在全部十六个排行榜系统上显示出持续的领先和大体一致的排名，并在接近的系统上和单个任务上留有残余变异。公式（2）对三轮等权，样本标准差的分母按原文取二。

附录 D 定性轨迹证据与来源

本附录中的“演示”是什么？演示是一次基准试验的紧凑、以轨迹为依据的视图。它连接聚合分数藏起来的四层：任务的可执行契约、运行时产生的路由和工具观察、可见的助手行为，以及任务所声明的评分器向量。本附录呈现三条诊断性的单次运行轨迹，覆盖严格成功、一次被评分的失败，以及一次超时。这些案例解释执行机制；失败模式频率在 555 个任务上的聚合诊断中报告。案例 C 使用更早的 grok-4.6 运行，任务期限为 600 秒，在 16 系统排行榜之外；正式排行榜协议规定 1,200 秒（附录 A.3），其发布中没有超时。图 17 定义四层阅读顺序，表 10 概括所选案例及其诊断角色。任务和工具标识按基准原样再现。客户姓名、账户标识和事务记录是合成的；事务标识由可重置的基准环境生成。摘录压缩重复轮次，并保留所记录的工具参数、结果和评分器结果。

图 17：如何阅读一条轨迹演示。每张卡片把所声明的契约连接到运行时证据，以及产生所报告结果的各项评分器决定。

表 10：所选单次运行轨迹及其诊断角色。

D.1 案例 A：结构化业务拒绝之后的恢复

演示 A 一览。严格成功。模型：Gemini 3.1 Pro Preview。轨迹规模：2 轮，4 次工具调用，81.27 秒。要看的是：第一笔金额被业务规则拒绝；智能体修改计划，而不执行被禁止的 1,000 美元转账。

#### 来源与契约。

这条轨迹来自 gemini-3.1-pro-preview，种子 997688223，任务 payments_transfer_insufficient_then_retry_01。模拟用户先请求从 ACC-1002 向 ACC-1001 转账 1,000 美元；在资金不足的响应之后，用户把金额更正为 50 美元。契约要求两次调用 validate_transfer，随后为 50 美元调用 execute_transfer。执行被拒绝的 1,000 美元金额是被禁止的。最终余额必须分别是 130.00 美元和 2,500.75 美元。

#### 观察到的轨迹。

两轮交互花了 81.27 秒，并停留在 transfer__transfer 节点。在第一轮，智能体调用 get_account_balance 并观察到余额为 180 美元。然后它调用 validate_transfer(amount=1000)，返回 valid=false，原因为 Insufficient funds，状态 422。助手准确地告诉用户转账无法完成。在用户回复 “Oh, sorry, I meant $50” 之后，智能体调用 validate_transfer(amount=50) 并收到 valid=true；然后它执行 50 美元转账并返回转账 ID XFER-HD10VI。

#### 评分结果。

期望动作、参数、顺序、终态和禁止参数检查都通过，给出严格任务成功。这个案例说明为什么结构化拒绝本身不是智能体失败：基准检查的是系统是否解释业务响应、修改计划，并只执行有效的替代方案。

D.2 案例 B：看似合理的沟通，重复的执行

演示 B 一览。严格失败。模型：Claude Sonnet 4.6。轨迹规模：4 轮，10 次工具调用，161.84 秒。要看的是：动作、顺序和回复检查通过，但重复结账使忠诚度余额翻倍，并被状态评分器抓住。

#### 来源与契约。

这条轨迹来自 claude-sonnet-4-6，种子 4275343667，任务 payments_checkout_full_chain_02。所请求的 15.50 美元 PayPal 结账按顺序要求 process_payment、send_receipt、award_loyalty_points 和 log_transaction。助手必须报告获得 155 点，并且 ACC-1002 的最终忠诚度余额必须等于 155。

#### 观察到的轨迹。

在第一个智能体轮次上，四个必需工具都成功。事务 ID 为 TXN-WLV0C0，忠诚度工具返回 155 点，余额为 155。助手报告：“You earned 155 loyalty points from this $15.50 transaction.” 当同策略用户追问工具并未返回的时间戳和附加标识时，智能体暂时声称它更早的、有工具依据的结果是编造的。在后来的一轮，它把整条结账序列又跑了一次，创建事务 TXN-CS17PL 并再奖励 155 点。因此最终忠诚度余额为 310。

#### 评分结果。

动作、参数、顺序和语义回复检查通过。语义评判者引用了精确的 155 点陈述并返回 contradiction_found=false，尽管一条中间助手消息否认了已经记录的工具执行。程序化状态检查失败，期望 155，得到 310，因此严格任务结果是失败。这是一个具体案例：只评回复或只看动作是否存在会高估正确性，而终态暴露出一笔重复的业务事务。评判者的 contradiction_found=false 在这里本身是假阴性：对已经记录的工具结果的中间否认，是语义评分器本应标出的自我矛盾，因此这条轨迹也说明固定评判者的局限，而不只是状态检查的价值。

D.3 案例 C：同策略重试循环导致的超时

演示 C 一览。超时。模型：Grok 4.6。轨迹规模：19 轮，19 次工具调用，600.00 秒。协议：更早的 600 秒任务期限。要看的是：不必要的认证路由、模拟器凭证漂移，以及重复的被拒绝调用，合在一起变成不收敛。

#### 来源与契约。

这条轨迹来自 grok-4.6，种子 981070998，任务 commerce_returns_01。这个容易任务只询问订单 ORD-9001 的状态；所声明的动作是 get_order_status，回复应说明订单已送达。任务指令给出客户 ID，但不提供 PIN。

#### 观察到的轨迹。

智能体在查找之前先要 PIN。用户模拟器随后引入 PIN 8274，它不在任务规格中。智能体用该 PIN 调用 authenticate_customer 18 次；每次调用都返回结构化的 403 认证失败。在循环期间它也用正确的订单 ID 调用了一次 get_order_status，并得到 status=Delivered，因此已声明的动作和参数检查有匹配证据。尽管如此，可见回复继续请求同一组凭证，而不是报告已经取回的状态。交互达到 19 轮，并在 600.00 秒以 TimeoutError: task exceeded 600s during agent.run 终止。

#### 评分结果。

源记录报告超时。观察到的不收敛涉及不必要的认证路由、模拟器凭证漂移、重复的被拒绝调用，以及智能体未能报告它已经获得的工具结果。

D.4 轨迹制品映射与来源

源记录取自相对的运行制品。每个运行制品为其运行保留完整的逐记录轨迹。任务 ID 标识上面使用的精确记录。图 18 概括用于重建每个演示的精确制品–契约连接。

图 18：轨迹演示的来源。每段叙述用模型、种子和任务 ID，把完整运行制品连接到其任务契约。

#### 选择程序。

我们先按严格结果划分记录：成功、被评分的失败、基础设施超时，以及其他基础设施错误。在这些划分内部，我们检查已声明的检查、轮次数、路由、工具调用序列和失败列表。然后我们选择这样的案例：（i）有一份自包含的任务契约，（ii）暴露一种不同的评测器行为，（iii）合在一起跨越所示模型上不同的评测器结果。

#### 定位源记录。

对案例 A–C，加载对应的 JSON 数组，并选择其 task_id 等于其“来源与契约”段落中所给标识的记录。原始任务契约是已发布基准的领域 YAML 中具有同一 ID 的对象。这恢复指令、全部已声明的正面和负面检查、完整的同策略对话、工具观察，以及本附录使用的最终评分器字段。

附录 E 构念效度与基准范围

CRM-Agent-Bench 在与可变状态的多步交互上，评测任务所声明的执行要求。全套件分数度量对每个任务可执行契约的满足；表 2 报告其组成检查的覆盖。该基准把有依赖的工具执行、有状态业务工作流和同策略交互结合起来。

E.1 长程、满载依赖的执行

任务按构建就是多轮的，而且许多是多步的。同策略模拟用户在最多 30 轮中逐步揭示信息，因此智能体必须维持状态、解析实体，并在新约束到达时重新规划，而不是一次答完。正确性经常定义在一串有依赖的有序工具调用上：在经过审计的 555 任务集中，235 个任务声明至少两条期望动作条目，164 个施加显式顺序约束，规范链条例如 validate_transfer → execute_transfer，或 process_payment → send_receipt → award_loyalty_points → log_transaction，以及入职流程上的 create → configure → verify → finalize。因为成功是每一项已声明检查的严格合取，单个早期错误——错误的实体、跳过的校验、过早的收尾——会传播并使整个任务失败。这些要求评测持续规划、跨轮状态跟踪，以及从轨迹中途反馈中恢复。

E.2 有状态业务工作流

工作流覆盖已认证的退货与退款、资金转账、案例分诊与升级、预约排程、受把关的记录删除、账户入职，以及跨九个有状态业务领域和 36 个能力标签的活动创建。动作改变记录系统，遇到业务规则拒绝（例如授权、冲突和无法处理的实体响应），并且可以破坏属于其他客户、账户或记录的受保护状态。可移植、许可干净的环境支持在没有在线 CRM 或厂商后端的情况下，对这些操作做受控评测。

E.3 概率性的同策略动态

环境的业务规则是确定性的，而周围的交互在试验之间变化。每次试验针对一个同策略用户模拟器运行，其下一句话语以智能体自己先前的回复为条件，因此一个任务定义的是对话上的分布，而不是固定文稿；智能体的解码、逐轮路由分类器，以及依赖状态的业务规则结果，各自注入稳健系统必须吸收的变异。同一个任务可能被解决或错过，取决于系统如何处理凭证漂移、被拒绝的调用或含糊的一轮。合取契约在分量级别暴露这些失败，\(\mathrm{pass}^{k}\) 报告协议被设计来直接量化运行之间的稳健性。附录 C 报告三轮均值、样本标准差、排名稳定性和全三次成功率，包括聚合分数相等却掩盖不同任务结果的情形。

附录 F 分领域系统流图集

CRM-Agent-Bench 中的每个领域，都把一个可变环境与第 2 节的图路由参考支架配对。图 19–27 为每个领域给出一条有代表性旅程的分层视图。自上而下阅读，用户请求穿过交互、编排、能力和环境层下降；策略关口分叉到一条不变更、保全受保护状态的分支；评测层对所记录的轨迹和终态应用严格合取契约。评测层把它任务所声明的检查映射到第 1 节的侧面：动作、参数和顺序评估轨迹；回复和状态评估结果；禁止检查评估策略合规。运营可行性分开报告。所有检查只在任务契约中被声明时才应用；营销任务不声明负面断言（N=0）。这些图是图路由参考支架的说明性快照，每张显示一条多轮旅程。被点名的能力节点说明该旅程，“所调用的节点范围工具”一行列出分类器重新路由时跨轮次使用的工具并集。在每一轮，工具访问被限定到所选节点。表 5 报告所报告运行中使用的、经过审计的完整支架清单。

表 4 所概括的构建谱系，把经过审计的评测集中的每个领域连接到其源工作流族。零售和客户支持结合种子与配方派生的能力；现场服务、销售和营销来自最初的种子计划；IT 服务管理、支付、旅行和入职是配方派生的。图注给出经过审计的 555 任务评测集中每个领域的构建谱系和任务数；这些图说明一条工作流如何被实现为节点、工具、策略关口、状态转移和契约可观察量。

图 19：零售领域的系统流（有代表性的商务/退货流）。经过审计的评测集谱系：混合（95 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。

图 20：客户支持领域的系统流。经过审计的评测集谱系：混合（125 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。

图 21：现场服务领域的系统流。经过审计的评测集谱系：种子工作流（23 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。

图 22：IT 服务管理领域的系统流。经过审计的评测集谱系：配方派生（66 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。

图 23：支付领域的系统流。经过审计的评测集谱系：配方派生（73 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。

图 24：旅行领域的系统流。经过审计的评测集谱系：配方派生（93 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。

图 25：入职领域的系统流（有代表性的客户入职流）。经过审计的评测集谱系：配方派生（41 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。

图 26：销售领域的系统流（有代表性的销售开发流）。经过审计的评测集谱系：种子工作流（18 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。

图 27：营销领域的系统流（有代表性的活动流）。经过审计的评测集谱系：种子工作流（21 个任务）。图例：R/W/C 表示读、写和计算工具；蓝色标记中间执行，绿色为被接受的完成路径，琥珀色为策略关口，红色为不发生业务状态变更的拒绝。评测检查只在任务契约中被声明时应用。