CXBench：受监管客服里，结果对了仍可能违规（下）

cxbench：面向受监管客户体验工作流的过程合规大语言模型智能体基准（下）

译注：本篇续上篇，从附录 D 起，含指标、构建、实验设置、补充结果和专家审阅。

附录 D 结果与过程评测

本附录详述第 2.4 节引入的评测程序。每次被保留的执行都收到分开的结果判定和过程判定。我们描述结果检查器、两个过程评分组件、它们的组成，以及用来汇总所记录评测的统计程序。

D.1 结果检查器

结果检查器判定最终业务状态是否满足任务的预期结果。其参照信息来自客户目标 $g$ 和任务规格中相关的私人客户事实。检查是领域专用的，因为业务记录和所请求的操作跨领域不同。

对一项银行争议任务，结果正确性要求一份已提交的争议，其相关字段与指定的客户事实匹配，包括预期的交易。检查器检查所产生的业务状态；它并不判定智能体在提交前是否提供了所要求的披露，或是否遵循了所要求的动作序列。

结果判定是二元的：

$$r_{\mathrm{outcome}}\in\{0,1\}.$$

因此，产生同一正确业务结果的两次交互，尽管过程合规不同，仍可收到相同的结果判定。这些差异由过程评分器评估。

D.2 确定性过程规则

确定性规则层评测为该任务指定的硬规则。这些检查包括事件顺序、工具权限，以及已确认字段与已提交字段的一致。评分配置通过 policy.grading_policy.deterministic_hard_rules 标明适用的硬规则。当前评分器在整个基准上强制执行 53 条硬规则。

每条规则检查产生一个通过或失败结果。确定性组件只有在全部适用的硬检查都通过时才通过：

$$r_{\mathrm{rule}}=\bigwedge_{\text{applicable hard checks}}\text{check result}.$$

规则输出标明造成失败的检查和相关联的已记录证据。规则类别在附录 B.3 中描述；观察到的失败模式报告在附录 G.2。

评分器核验被引用的规则标识符。不受支持的标识符会引发评分错误，而不是被静默记为一条失败的过程规则。这把实现或规格问题，与智能体被观察到的违反区分开。

对提交控制实验，两种执行模式都使用原始混合评分协议（第 4.3 节）。使提交工具对智能体可用，本身并不从该协议中移除直接提交禁令。移除这一禁令的诊断另行报告。

D.3 大语言模型轨迹评判

大语言模型评判使用解释量规和任务专用清单来评估语义过程要求。基线评测使用 gpt-5.6-sol；模型与执行设置见附录 F。

评判在收到所记录的执行证据的同时，收到任务上下文和评分清单。清单通过 policy.llm_judge.checklist 提供。它指定要评估的要求，包括所要求的披露内容和对没有依据的结果承诺的限制等语义条件。

评判返回带三个顶层字段的结构化响应：process_pass、findings 和 rationale。每条发现包含：

• rule_id：被评估的要求；
• passed：其通过或失败判断；
• severity：critical、major 或 minor；
• seq：轨迹事件的序列引用；
• evidence：支持该判断的证据。

总体评判判定在与确定性组件组成之前，先与这些个别发现调和。任何失败的发现，不论严重程度，都迫使评判组件失败。对提示和所记录判断的专家审阅在附录 H.4 中描述；对评判配置的敏感性报告在附录 H。

D.4 判定组成与一致性

发现一致性程序把评判的总体判定与其个别发现调和。对一份符合模式的评判响应，它应用下列规则：

• 若任一发现失败，调和后的评判判定为失败。
• 若发现列表非空且每条发现都通过，调和后的评判判定为通过。
• 若发现列表为空，则保留原来的总体判定。特别是，空列表不会推翻一个失败判定。

任何覆盖都与评分一起记录。这一程序处理总体判定与所列发现之间的不一致；它并不独立地确立发现正确地解释了轨迹。

混合过程判定要求两个组件都通过：

$$r_{\mathrm{process}}=r_{\mathrm{rule}}\wedge r_{\mathrm{judge}}.$$

整体成功和 false-pass 则为

$$r_{\mathrm{success}}=r_{\mathrm{outcome}}\wedge r_{\mathrm{process}},\qquad r_{\mathit{false\_pass}}=r_{\mathrm{outcome}}\wedge\neg r_{\mathrm{process}}.$$

仅规则和仅大语言模型的评测是消融；主要结果和提交控制比较使用混合评分器。

清单 2 概括该程序。伪代码展示判定逻辑；领域专用的检查实现和覆盖记账被省略。

清单 2：带判定与发现一致性的结果检查和混合过程评分。

def grade_run(task, trace, final_state, mode, model):
    validate_rule_ids(task.rules)

    hard_ids = (
        task.policy.grading_policy.deterministic_hard_rules
    )
    validate_rule_ids(hard_ids)

    r_outcome = outcome_pass(task, final_state)

    rule_results = [
        grade_rule(rid, task, trace, final_state, mode)
        for rid in hard_ids
    ]
    r_rule = all(result.passed for result in rule_results)

    judge_result = LLMTraceJudge(
        task, mode, model
    ).judge(trace, final_state)

    judge_result = enforce_findings_consistency(
        judge_result
    )
    r_judge = judge_result["process_pass"]

    r_process = r_rule and r_judge

    return {
        "outcome_pass": r_outcome,
        "process_pass": r_process,
        "rule_results": rule_results,
        "judge_result": judge_result,
    }

译注：清单 2 的伪代码按原文保留，标识符不译。

D.5 指标定义与统计程序

评测单位与分母。设 $N$ 为正在汇总的集合中被保留的评测记录数。主要评测对每个模型—任务对保留一次执行。数据采集期间的任何重试都只由网络失败触发，而不是由结果或过程判定触发。重试和保留程序在附录 F.1 中描述。因此，每个模型 $N=120$，七个模型汇集的评测 $N=840$。这些记录并不代表数据采集期间的每一次执行尝试。

全部被保留的记录都计入所报告的主要比率。分母并不限于没有错误或预算限制而自然终止的执行。因此，这些指标描述的是被保留的评测，而不是首次尝试的可靠性，或重复执行之间的变异。

对每条被保留的记录 $i$，令

$$o_{i}:=r_{\mathrm{outcome}}^{(i)},\qquad p_{i}:=r_{\mathrm{process}}^{(i)}.$$

把双通过和 false-pass 指示定义为

$$b_{i}:=o_{i}p_{i},\qquad f_{i}:=o_{i}(1-p_{i}).$$

计数与全记录比率。结果通过、双通过和 false-pass 的计数是

$$O:=\sum_{i=1}^{N}o_{i},\qquad B:=\sum_{i=1}^{N}b_{i},\qquad F:=\sum_{i=1}^{N}f_{i}.$$

因为每条结果通过的记录要么通过、要么未通过过程检查，有 $O=B+F$。全部被保留记录上的对应比率为

$$\widehat{R}_{\mathrm{outcome}}=\frac{O}{N},\qquad \widehat{R}_{\mathrm{both}}=\frac{B}{N},\qquad \widehat{R}_{\mathrm{false\text{-}pass}}=\frac{F}{N}.$$

所报告的百分比把这些比例乘以 100。

结果通过记录中的 false-pass。为量化只看结果的成功里有多少未通过过程检查，我们另外报告

$$\widehat{R}_{\mathrm{false\text{-}pass}\mid\mathrm{outcome}}=\frac{F}{O},\qquad O>0.$$

这一条件比例的分母，不同于全部被保留记录上的 false-pass 比率。在主要评测中，

$$N=840,\qquad O=582,\qquad B=116,\qquad F=466.$$

因此，false-pass 占全部被保留评测的 $466/840=55.48\%$，占结果通过评测的 $466/582=80.07\%$。

置信区间。对每个模型，所报告的 95% 置信区间适用于其双通过比例 $\widehat{p}=B/N$，且 $N=120$。我们使用 Wilson 得分区间

$$\frac{\widehat{p}+\dfrac{z^{2}}{2N}\;\pm\;z\sqrt{\dfrac{\widehat{p}(1-\widehat{p})}{N}+\dfrac{z^{2}}{4N^{2}}}}{1+\dfrac{z^{2}}{N}},\quad z=1.96.$$

减号和加号分别给出下界和上界。表中把两个边界都报告为百分比。

附录 E 基准构建

构建流水线把作者定义的领域组件和监管要求，与大语言模型辅助的任务合成、自动结构核验和质量审阅结合起来。其输出是六个领域、每领域 20 项、共 120 项任务的任务规格和相关联的评分判据。本附录描述该过程涉及的输入、职责、输出和检查。

E.1 领域与规则准备

输入与职责。作者使用可通过 Legal Information Institute 获得的监管材料，识别与基准的客户服务工作流相关的义务。领域准备还要求定义表示这些工作流所需的业务记录和操作。

输出。我们人工抽取 55 项义务，并去重为 53 张规则卡。每张卡记录稳定标识符、来源引用、义务、所要求的轨迹证据，以及相关联的确定性检查或大语言模型评判清单项（附录 B.1）。

作者还定义领域的业务状态表示，并实现其工具接口。义务被映射到既有轨迹谓词；若评分器尚不支持所要求的检查，则实现额外谓词。这些领域组件提供任务合成期间所引用的已注册工具和规则标识符。

因此，所产生的准备工作包括监管解释、领域实现，以及要求与评分判据之间的连接。共享运行时和评分框架提供与这些组件一起使用的共同机制。

E.2 大语言模型辅助的任务合成

输入与职责。大语言模型工作者收到规则卡，以及一份领域接口清单，后者暴露已注册工具、其权限级别和受支持的规则目录。清单提供构建候选任务可用的操作和检查。

输出。工作者生成候选任务规格及其评分规格。每个候选在领域专用的业务环境中实例化一条客户请求，并把它与相关的过程要求关联起来。任务规格包括客户目标、开场消息、初始业务记录、私人客户事实、工具清单和确认字段。评分规格标明适用的确定性规则和语义清单项。

所生成的任务使用附录 A.1 中的 YAML 表示。规则卡为场景及其评测判据提供共同参照，而接口清单把引用约束到基准所支持的操作和检查。

E.3 结构核验与质量审阅

结构检查。生成的任务规格自动对照任务模式、领域注册表和规则目录进行检查。流水线应用四道结构门禁：

1. confirmation_contract 中的每个字段都出现在 hidden_facts 中。
2. 每个被引用的提交工具都在对应领域中注册。
3. 每个被引用的规则标识符都受评分器的规则目录支持。
4. 任务提供非空的 llm_judge.checklist。

违反其中一条条件的候选通不过结构核验。例如，若确认契约命名了一个私人客户事实中不存在的交易标识符，任务就通不过确认字段检查。这些门禁检查规格与可用于执行和评分它的信息及实现是否一致。

行业输入与规则操作化。行业合作者贡献了业务场景和访谈反馈，审阅了已编码的过程规则，并标注了执行轨迹。作者把来自公开监管材料的要求翻译成依场景的规则，并以机构客户服务程序作为工作流参照。作者对监管来源的解释及其到评分判据的映射负责。

三位资深软件工程专家审阅每一规则映射的可执行操作化。他们的审阅覆盖所要求的行为、可观察的轨迹证据，以及评分判据中编码的时序或顺序约束。审阅者意见不一致时，通过讨论和投票解决。同一三位软件工程专家也审阅了评判指令。

这些活动补充自动结构检查。已注册工具、受支持的规则标识符和完整字段确立规格一致性。行业输入告知业务上下文和工作流，而工程审阅检查它们的可执行表示和评判指令。这些活动并不构成对已编码要求的独立法律核验。

对评判的审阅。五位资深软件工程专家参与评判开发：一位起草评判指令，三位审阅它们，第五位用 gpt-5.4-mini 生成的 120 条轨迹校准评判。附录 H.4 描述该程序，并报告 gpt-6-astra 的判断与这一校准集上专家标签的比较。

E.4 领域扩展与构建指导

增加一个领域需要下列工作：

1. 从该领域的监管要求中抽取规则卡。
2. 定义业务状态表示，并实现领域工具接口。
3. 把义务映射到既有轨迹谓词，或在需要时实现额外谓词。
4. 使用所得到的规则卡、接口和评分判据生成并核验任务规格。

领域专用的状态表示、工具实现和此前不受支持的检查需要额外工程。交互循环、共同轨迹格式、提交控制、判定组成和评判协议跨领域复用。任务定义的确认字段把不同的业务工作流连接到共享的提交机制（附录 C.3）。

这一过程为构建更多领域或相关基准提供指导。受支持的操作和所要求的轨迹证据应在生成场景之前确立，任务和评分判据从同一批规则卡派生。结构核验检查所得到的规格是否内部一致，并引用受支持的组件。语义审阅另行检查场景和评分判据是否保持来源要求的含义和适用性。

附录 F 实验设置与可复现性

F.1 评测设置

我们在六个领域、每领域 20 项、共 120 项任务上评测七个智能体模型。模型列在表 3 中。分析对每个模型—任务对包含一次被保留的执行，得到 840 条评测记录。数据采集期间的重试只由网络失败触发。结果失败、过程违反，以及对话或工具调用预算耗尽，都不是重试触发条件。每个模型全部 120 条被保留记录，包括任务失败，都计入所报告的比率。

客户模拟器是 gpt-5.4-mini，基线评判是 gpt-5.6-sol。除非另行说明，生成参数，包括温度，以及对话和工具调用预算，都使用默认设置。

主要评测使用中介提交。提交控制实验在原始混合评分协议下，对 gpt-5.4 的同一批 120 项任务比较中介提交和直接提交（第 4.3 节）。指标定义和统计程序见附录 D.5。

F.2 评判配置比较

我们在除 deepseek-v4-flash 之外的全部被评测智能体模型的同一批 720 条已记录轨迹上，比较 gpt-5.6-sol 和 gpt-6-astra。两种评判的输出词元上限都是 81,920。

该比较保持所记录的交互固定，并考察过程判定、汇总分数和模型排序的变化。我们无法核验提供者侧的系统指令在两种评判模型之间是否相同，这限制了把观察到的差异单独归因于评判模型的选择。比较结果报告在附录 H。

F.3 复现结果

我们区分三种复现程序。

任务再执行。再次运行一项任务会通过运行时调用智能体和客户模拟器，产生一次新的交互，其轨迹和判定可能不同于被保留的执行。

轨迹再评分。再评分把指定的评分配置应用到所记录的交互和最终业务状态。执行证据保持固定，而新的大语言模型判断可能产生不同的发现。评判配置比较遵循这一程序。

统计再汇总。重算表格使用已保存的结果判定和过程判定，不再额外调用模型。对同一批被保留记录、评分和统计程序，所报告的计数、比率、置信区间和成对比较被确定性地重算。

F.4 数据可得性

可复现性产物包含任务语料、领域工具、共享运行时、规则评分器、轨迹评判协议和任务构建流水线，以及支持结果的已记录运行日志和评分记录。

该产物包含容器镜像和脚本，用于从已保存的评测重新生成所报告的表格。秘密、账户元数据和原始提供者载荷被排除。所发布的材料支持检查支撑所报告结果的要求、执行证据和评分决定。

附录 G 补充结果

本节提供领域级结果、规则失败分析、提交控制结果，以及一个带注释的 false-pass 示例。除非另行说明，结果使用七个模型在 120 项任务上、于中介提交执行下的 840 次被保留执行。所有比率都包括失败任务，过程判定使用混合评分器。

G.1 分领域结果

图 5 报告每个模型—领域对的结果、过程和双通过率。表 10 在每个领域内汇总七个模型。

银行和政府福利显示出特别大的结果—过程差距：结果通过分别达到 94.29% 和 84.29%，而双通过分别只有 5.71% 和 4.29%。医疗的汇集双通过率最低，为 2.14%。电信和公用事业的双通过率同为最高的 26.43%，但二者都保留了相当高的 false-pass 率。

图 5：跨模型和领域的结果、混合过程和双通过率。每个单元格使用一个模型—领域对的全部 20 项任务。所有面板共享 0–100% 的色标。

表 10：按领域汇集的结果。每个领域包含 140 次评测。所有条目都是百分比。

G.2 规则级失败分析

在被评测任务所用的 53 条硬规则中，有 35 条至少失败一次。图 6 显示失败最频繁的 16 条硬规则的失败率。每个比率以任务配置了对应规则的记录为分母。

一项反复出现的保险失败涉及 policy_summary_before_authority_check，这是一条从所参照的机构工作流派生的顺序要求。它要求在报告人权限检查之前成功阅读政策摘要。这条规则在 47 条 false-pass 记录中失败，占全部 466 次 false-pass 的 10.09%。

这一比例描述的是工作流要求失败的记录；它并不把这些 false-pass 排他地归因于这条规则，因为其他要求也可能失败。此外，检查可能因为所要求的事件缺失而失败，也可能因为事件以错误顺序发生而失败。

两个评分器组件都参与识别 false-pass。在 466 次 false-pass 中，329 次仅被大语言模型评判拒绝，38 次仅被硬规则拒绝，99 次被二者同时拒绝。这些计数说明，两个组件检测到伴随正确结果的不同过程失败。

图 6：七个模型上失败最频繁的 16 条硬规则的失败率。每个比率按任务为对应模型配置了该规则的记录数归一化，因此分母因规则而异。失败既包括所要求事件缺失，也包括事件顺序不正确。

G.3 提交控制消融

我们在中介提交和直接提交下比较 gpt-5.4，使用同一批 120 项任务规格和已记录轨迹。智能体和客户模拟器没有重跑。在原始混合协议下，双通过从 20.83% 降到 0.83%（双侧精确 McNemar $p=1.19\times 10^{-7}$），而 false-pass 从 43.33% 升到 66.67%。结果通过从 64.17% 变为 67.50%（$p=0.4545$）。

原始协议包含专门惩罚直接提交的提交机制检查，包括 no_agent_direct_submit、confirmation_before_submit 和 submit_matches_confirmed_draft，以及对应的大语言模型评判子条件。因此我们报告第三种打分条件：直接提交（排除提交机制检查）。这一条件在从两个评分组件中排除这些检查、同时保留所有其他硬规则和语义发现之后，对同一批轨迹重新打分。它是一种打分条件，而不是额外的执行模式。

在对两种模式施加同一排除检查的打分下，中介提交仍为 25/120 次双通过（20.83%），直接提交达到 22/120（18.33%）。直接减去中介的差为 $-2.50$ 个百分点，双侧精确 McNemar $p=0.677639$，成对任务自助 95% 区间为 $[-10.00,5.00]$ 个百分点。对应的直接提交过程通过率和 false-pass 率分别为 20.00% 和 49.17%。

对排除检查的比较，12 项任务在两种模式下都通过，13 项只在中介提交下通过，10 项只在直接提交下通过，85 项在两种模式下都失败。作为中间诊断，只移除 no_agent_direct_submit 得到 9/120 次直接提交双通过；这一条件不用于主要比较，因为其他提交机制检查仍然有效。

表 11：gpt-5.4 的提交控制消融。所有行使用同一批 120 项任务规格和已记录轨迹。第三行从硬规则和大语言模型评判两个组件中排除提交机制检查；它是一种重新打分条件，而不是额外的执行模式。所有条目都是百分比。

G.4 带注释的 false-pass 轨迹

gpt-5.4-mini 对保险任务 INS-FLOW-010.us 的执行，说明正确结果可以伴随过程失败。清单 3 概括中介提交执行下的选定事件，保留其原始序列号。

清单 3：一份已确认的全损复核草稿被成功提交，尽管过程要求并未满足。

seq 10--11, agent/tool:
  Reads the policy summary.

seq 17--18, agent/tool:
  Checks total-loss or storage risk.

seq 20--22, agent/runtime/tool:
  Creates draft_001 for a total-loss review.

seq 24--28, agent/tool:
  Records acknowledgment and no-promise notices
  for draft_001.

seq 34--36, agent/runtime/tool:
  Creates corrected draft_002.

seq 39--41, simulator/customer/runtime:
  Confirms draft_002 and submits the matching draft.

译注：清单 3 的轨迹摘录按原文保留。其含义是：序列 10–11，智能体或工具阅读政策摘要；17–18，检查全损或仓储风险；20–22，为全损复核创建 draft_001；24–28，为 draft_001 记录确认和无承诺通知；34–36，创建更正后的 draft_002；39–41，模拟器、客户和运行时确认 draft_002 并提交匹配草稿。

所提交的复核与所要求的任务字段匹配，因此 $r_{\mathrm{outcome}}=1$。然而，确定性规则层识别出缺少报告人权限检查。大语言模型评判还标出：在业务检查之前缺少既有索赔上下文，以及草稿被更正之后，所要求通知的关联或结转不足。

因此两个评分器组件都失败：$r_{\mathrm{rule}}=0$ 且 $r_{\mathrm{judge}}=0$，使这次执行成为 false-pass。该示例说明，匹配的草稿确认和成功提交，可以与未满足的过程要求并存。

附录 H 评测敏感性与专家审阅

我们考察对评判配置和硬规则选择的敏感性，报告判定调和的影响，并概括对评判提示和轨迹级判断的专家审阅。

H.1 评判配置的比较

我们在来自六个模型、排除 deepseek-v4-flash 的同一批 720 条轨迹上，比较 gpt-5.6-sol 和 gpt-6-astra。结果检查和确定性规则结果保持固定。两种评判的输出词元上限都是 81,920；评测设置概括在附录 F。

表 12 报告所得到的混合双通过率。汇集的双通过率从 13.89% 变为 14.72%，增加 0.83 个百分点。混合过程判定在 92.22% 的评测上一致。模型排序大体不变，Kendall 的 $\tau_{b}=0.9661$。唯一的排序变化解消了 gpt-5.4-mini 与 qwen3.6-plus 的基线平局；此前严格的成对排序没有被反转。这些结果表明，在所测试的配置之间，汇总分数和模型排序相似，而一致性度量的是一致程度，不是正确性。 此处一致只说明两种评判配置接近，并不证明哪一种更正确。

表 12：两种评判配置下的双通过率。每个模型对两种评判使用同一批 120 条轨迹。比率是百分比；$\Delta$ 是从 gpt-5.6-sol 到 gpt-6-astra 的变化，单位为百分点。

H.2 对单条硬规则的敏感性

我们依次移除 35 条有观察失败的硬规则中的每一条，保持结果、所记录的评判判定和其余硬规则固定。在除 gpt-4o-mini 之外的六个模型中，只有三次规则移除增加了任一模型的双通过计数。

最大的增加发生在移除 policy_summary_before_authority_check 时：qwen3.6-plus 的双通过从 18 升到 24，增加 5.00 个百分点。移除 read_before_check 或 risk_check_before_step_up，使一个模型的比率至多改变 0.83 个百分点。

两次规则移除打破 gpt-5.4-mini 与 qwen3.6-plus 的基线平局，但没有一次反转此前严格的排序。这些分析度量对单条规则的敏感性；所报告的基准分数保留完整的混合评分器。

H.3 判定调和的影响

我们考察附录 D 所述的判定与发现一致性检查的影响。在 840 次基线评测中，这一检查改变两条原始评判判定，都来自 gpt-5.4-mini。两条记录在结果和硬规则评测上已经失败，因此双通过计数仍为 116，false-pass 计数仍为 466。

该检查在 720 次替代评判评测或 120 次直接提交评测中，没有改变任何评判判定。它解消评判的判定与发现之间的内部不一致；它并不独立核验对轨迹证据的解释。

H.4 专家审阅与人类参照比较

参与者与开发程序。行业合作者贡献了业务场景和访谈反馈，审阅了已编码的过程规则，并标注了执行轨迹。作者负责从监管来源抽取要求，并把它们翻译成规则卡和评分判据。五位资深软件工程专家参与评判开发。一位专家起草初始评判指令，另外三位专家审阅它们。这一审阅中的分歧通过讨论和投票解决。初始运行之后，第五位专家审阅 gpt-5.4-mini 智能体生成的 120 条轨迹，并把它们的轨迹级判断与 gpt-5.6-sol 的判定比较，以改进评判。这 120 条校准轨迹的轨迹级参照判断，由上述校准专家产生。

与专家标签的比较。表 13 在这 120 条轨迹上比较 gpt-5.6-sol 的判定与专家标签。以过程通过为正类，有 23 个真阳性、4 个假阴性、10 个假阳性和 83 个真阴性。精确率为 $23/33=69.70\%$，召回率为 $23/27=85.19\%$，F1 为 $46/60=76.67\%$，准确率为 $106/120=88.33\%$。

以过程失败为正类，精确率为 $83/87=95.40\%$，召回率为 $83/93=89.25\%$。因此，专家支持评判 87 个失败判定中的 83 个；4 个专家标为通过的被拒绝，10 个专家标为失败的被接受。

表 13：在 gpt-5.4-mini 生成的 120 条轨迹上，gpt-5.6-sol 判定与专家标签的比较。这些轨迹在评判校准期间使用。过程通过为正类。

证据的范围。这些轨迹在评判开发期间使用，因此不构成独立的留出验证集。该比较使用一位专家的轨迹级判断，并不度量评分者间可靠性。它在来自一个智能体模型的轨迹上评测基线 gpt-5.6-sol 评判，并不确立其在全部被评测模型上的准确率。行业参与为基准的场景、工作流、规则和轨迹标注提供实践输入。来源引用使作者的监管解释和规则映射可被检查。行业参与和来源可追溯性，都不确立这些解释的法律正确性或完整性，也不认证部署中的合规。720 条轨迹的评判比较集上 92.22% 的混合判定一致，度量的是配置之间的一致性，而不是相对人类标签的准确率。

[^1]: Regulation E，12 CFR § 1005.11(b)(2)（书面确认）。见 CFPB 发布的官方监管文本：https://www.consumerfinance.gov/rules-policy/regulations/1005/11/#b-2 。