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

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

Boxi Yu\†、Yuzhong Zhang\、Zhenfeng Su\*、Linfu Xi、Yinghan Yao、Shitao Chen、Yang Cao、Liting Lin、Lionel Briand、Emir Muñoz。

译注：\*同等贡献。†通讯作者。上标 1 为爱尔兰利默里克大学 Research Ireland 软件研究中心 Lero；2 为香港中文大学（深圳）；3 为西安交通大学；4 为北京大学；5 为华南理工大学；6 为 Genesys Cloud Services Inc.。通讯作者 Boxi Yu，邮箱 boxi.yu@lero.ie。姓名与邮箱保留原文。

摘要

使用工具的语言智能体越来越多地执行受监管的客户服务工作流。此时，正确的最终状态并不够：智能体还必须作出披露、取得同意，并遵循所要求的程序。现有工具智能体基准大体上只给最终业务状态打分，从而接受那些经由不合规过程到达正确结果的轨迹。

我们提出 cxbench。它在六个受监管领域里，把结果合规与过程合规分开评测。每项任务把一条客户请求、一个基于工具的环境，以及显式的过程要求组合在一起。规则卡把被引用的监管义务连接到可观察的轨迹证据。混合评分器把针对顺序与权限的确定性检查，和针对语义要求的大语言模型评判结合在一起。我们把 false-pass 定义为一次通过了结果检查、却未通过过程检查的运行。

在七个模型和 120 项任务上，840 次被保留的执行里有 55.5% 是 false-pass，占结果通过运行的 80.1%；只有 13.8% 同时通过两项检查。把过程纳入评测会改变观察到的模型排序，并暴露只看结果时被藏起来的差异。cxbench 通过与轨迹相连的判据，使这些失败可以被检查。

关键词：大语言模型智能体、基准、监管合规、软件工程

1 引言

图 1：两条轨迹具有相同的最终状态。只看结果的 oracle 会同时接受二者，而 cxbench 把轨迹 B 标为 false-pass，因为它漏掉了本案在 Regulation E 下所要求的书面确认通知（见脚注 1）。草稿确认是 cxbench 的一项独立运行时控制，而不是法定要求。

如图 1 所示，假设一位客户要求银行对一笔未经授权的交易提出争议。再假设两个智能体提交了同一份争议，但只有第一个提供了该案所要求的通知。最终状态检查会同时接受二者：争议记录是相同的。然而第二个智能体漏掉了一步所要求的步骤。例如，当银行要求对口头错误通知作出书面确认时，Regulation E 要求银行在给出口头通知时告知客户这一要求，并提供提交地址。[^1]

只看已提交的争议，并不能揭示智能体是否提供了这一信息。完成任务与遵循所要求的过程之间的这一差别，促使我们提出 cxbench。

语言智能体越来越多地通过回答问题、检索记录，以及经由软件工具采取行动，来支持客户服务工作流（Yao 等人，2024；Barres 等人，2025）。在受监管领域，成功的协助不止于产出所请求的业务结果。例如，智能体可能还需要解释客户的权利，在行动前取得授权，并避免作出没有依据的承诺。这些要求关心的是交互期间发生了什么，以及它是否符合监管。因此，评测它们需要检查对话和工具调用，而不只是最终业务状态。

现有基准为这一评测提供了重要基础。tau-bench 和 tau2-bench 测试与用户及领域专用工具交互的智能体，使用结果检查，以及对所要求回复信息的检查（Yao 等人，2024；Barres 等人，2025）。tau-bench 的作者明确承认，正确的最终状态仍可能来自政策违反，例如在没有用户明确确认时处理退货。过程遵循基准进一步检查对规定工作流的遵守（Li 等人，2025；Nandi 等人，2025；Wang 等人，2025b）。在这些工作之上，我们考察那些可能被成功结果掩盖、从而高估智能体可靠性的过程违反。具体而言，我们问：当智能体取得正确结果时，它是否也满足了适用的过程要求？

我们提出 cxbench，一项覆盖银行、电信、保险、医疗、公用事业和政府福利的 120 项客户服务任务的基准。这些领域覆盖常见的客户服务需求，并受制于关于请求必须如何处理的显式监管要求，因而适合同时评测任务完成和过程合规。在每项任务中，人工智能智能体通过对话与模拟客户交互，并使用领域专用工具完成所请求的任务。cxbench 沿两个轴评测所产生的交互：结果，即所请求的业务结果是否达成；过程，即所记录的交互是否满足适用要求。一次运行只有在两项都通过时才整体成功。我们把通过结果却未通过过程的运行称为 false-pass，因为只看结果的评测会把它计为成功。

为使过程要求可检查，cxbench 把它们表示为规则卡，把一条被引用的监管要求连接到交互中预期出现的证据。确定性检查评测事件顺序和工具权限等条件，而大语言模型评判评测语义要求，例如对误导性承诺的限制。二者都必须通过，过程判定才算通过。这一评测度量的是对基准中所编码要求的遵守，并通过识别潜在违反、把它们连到监管要求和轨迹证据，来支持合规分析。它本身并不确立真实世界部署的法律合规。

表 1 沿与这一评测相关的四个维度比较有代表性的基准：对程序遵守的显式评估（过程）、过程要求与被引监管之间的联系（法规）、对经由不合规过程达成的成功结果的单独报告（false-pass），以及对最终改变状态的动作的运行时受控执行（运行时提交）。前三个维度关心评测什么、失败如何被识别；第四个维度关心执行期间提交权限如何被控制。在 cxbench 的默认模式中，智能体准备一份草稿，而运行时只在客户确认所要求的字段之后才提交它。

表 1：与有代表性的基准在过程评测、监管立足、false-pass 报告和运行时受控提交上的比较。勾表示支持所列特性；叉表示该特性缺失，而不是所有与政策相关的评测都缺失。

在七个大语言模型和 120 项任务上，840 次被保留的执行里有 69.29% 通过结果检查，但只有 13.81% 同时通过结果和过程检查。每个模型都出现 false-pass，占全部执行的 55.48%，占结果通过执行的 80.07%。纳入过程合规也会改变观察到的模型排序，说明只看结果的打分会掩盖过程合规上的实质差异。

我们的贡献是：

1. 分开的结果与过程评测。最终状态检查可能漏掉过程违反。我们提出 cxbench，覆盖六个受监管领域的 120 项任务，带有分开的结果判定和过程判定，以及一项 false-pass 指标，用来暴露只看结果时被藏起来的失败。
2. 立足轨迹的监管评测。监管义务要求对事件顺序和语言都做依场景的解释。我们把它们编码为规则卡，把来源条款连到轨迹证据和评测判据，并把确定性检查与基于清单的大语言模型判断结合起来，产生可检查的过程判定。
3. 带提交控制的共享执行。领域专用工具和确认要求，使在共同协议下评测变得复杂。我们提供一个共享运行时，它记录轨迹，并通过对匹配草稿字段的确认来中介提交，同时提供直接提交模式，用以研究提交权限的影响。

2 cxbench 基准

图 2：cxbench 评测流水线。智能体与模拟客户和业务工具交互，产生最终状态和交互轨迹。结果评测检查最终状态；过程评测用确定性规则和大语言模型评判检查轨迹。在默认模式中，运行时在客户确认之后提交草稿。

智能体可以经由对所要求过程遵守程度不同的交互，到达同一个最终业务状态。如图 2 所示，cxbench 因此把结果正确性和过程合规分开评测。每项任务指定一个客户目标、一个初始业务状态、私人客户事实和领域专用工具，以及一份确认契约和适用的过程要求（第 2.1 节）。为使适用的监管义务能从一次交互中被评估，规则卡把来源条款连到依场景的所要求行为、可观察的轨迹证据和评测判据（第 2.2 节）。一个回合是智能体对一项任务的单次执行。在一个回合中，智能体与客户模拟器交互，并通过共享运行时调用领域专用工具。运行时记录交互，并在默认模式中，只在客户按该任务的确认契约确认匹配字段之后才提交草稿（第 2.3 节）。执行之后，领域专用的结果检查器评测最终业务状态，而混合过程评分器把确定性检查和基于清单的大语言模型判断结合起来，评估所记录的轨迹（第 2.4 节）。

2.1 任务规格

每项任务由一份规格实例化：

$$\theta=(g,m_{0},s_{0},\mathcal{U},\Lambda,\mathcal{K}),$$

其中 $g$ 是客户目标，$m_{0}$ 是开场消息，$s_{0}\in\mathcal{S}$ 是初始状态，$\mathcal{U}$ 是领域专用工具接口，$\Lambda$ 是适用的政策上下文和过程要求，$\mathcal{K}$ 是需要客户审阅和确认的草稿字段集合。

初始状态 $s_{0}$ 遵循附录 A.2 中的状态表示，它包括业务记录、私人客户事实、交互历史和草稿。目标 $g$ 和私人客户事实决定预期的业务结果，而 $\Lambda$ 和 $\mathcal{K}$ 指定过程义务和确认要求。这些要素合在一起，把结果目标和执行要求绑定在一份共同的任务规格里（附录 A.1）。

智能体收到开场消息、面向智能体的政策指令，以及被允许的工具定义。私人客户事实告知客户模拟器的回复和确认，但不直接暴露给智能体。智能体通过与客户交互，以及被授权访问业务记录，来获得相关信息。

表 2 区分三种职能。执行产生交互。智能体与客户模拟器交换消息，并通过运行时调用工具：这一软件层协调交互、执行工具调用、维护业务记录和草稿，并记录轨迹。运行时也强制执行第 2.3 节所述的提交控制。评测在执行之后指派判定。结果检查器评测最终业务状态。过程评测把一个确定性规则层——针对事件顺序、工具权限和确认一致性——与一个大语言模型评判结合起来，后者对照一份任务专用清单评估语义要求。核验通过专家对评判提示和轨迹级判断的审阅，以及跨评判配置的比较，来检查评分程序（附录 H）。

表 2：cxbench 中的角色。智能体、客户模拟器和运行时产生交互；规则层和大语言模型评判评测它。专家审阅者独立地重新评估选定轨迹以作核验，并不决定所报告的过程判定。

2.2 监管要求与轨迹证据

$\Lambda$ 中的监管要求必须先翻译成依场景的判据，才能从交互轨迹中被评估。这要求识别一项义务何时适用、它要求什么行为，以及什么被记录的证据支持一项判定。cxbench 通过规则卡表示这一映射。每张卡把一条来源条款连到其适用条件、所要求的行为、可观察的轨迹证据和评测判据。涉及事件顺序或工具权限的判据由确定性规则层检查；需要解释面向客户的语言的判据，被表达为大语言模型评判的清单项。两个组件在第 2.4 节合并。

在图 1 中，该任务表示向一家要求书面确认的机构发出错误通知。依据是 Regulation E（见脚注 1）。对应的规则卡把这一义务连接到「所要求的信息已被传达」这一证据。对这项任务，cxbench 把时序要求操作化为：检查披露发生在请求客户确认提交草稿之前。这是基准用来评估披露时序的可观察检查点。

两种确认服务于不同目的：草稿确认在 cxbench 内部授权所提议的提交，而书面确认关心的是客户在 Regulation E 下的错误通知。因此，披露判据与运行时的提交控制分开评估（第 2.3 节）。一份正确提交、并经客户确认的争议，仍可能通不过披露检查。如图 3 所示，规则卡把每条判据连到来源要求和支撑的轨迹证据，或所要求证据的缺失，从而使这类判定的依据可检查。

图 3：从监管要求到过程评测。一张规则卡把一条被引用的要求连接到可观察的轨迹证据和一条评测判据（上）。确定性检查和大语言模型评判评估适用于每项任务的要求，并共同决定过程判定（下）。伴随失败过程判定的正确结果，就是一次 false-pass。

2.3 交互与提交权限

领域专用工作流在业务工具和确认要求上彼此不同。为了在共同协议下执行这些工作流，cxbench 把每项任务的工具接口 $\mathcal{U}$ 和确认字段 $\mathcal{K}$ 连接到一个共享运行时。在一个回合中，智能体交换面向客户的消息，并调用工具来检查记录、核对条件、准备草稿和发出通知。草稿表示一项供客户审阅的拟议业务动作；提交执行该动作，并提交相应的业务状态变更。

客户模拟器。一个固定的大语言模型模拟客户，从任务规定的开场消息开始，并使用私人客户事实生成后续回复。模拟器观察面向客户的消息和所呈现的草稿字段，但不观察智能体的工具调用。它的确认决定关心的是 $\mathcal{K}$ 中的字段是否与这些事实匹配；它不评估过程合规。模拟器模型与配置报告在附录 F。

提交权限。默认的中介提交模式把提交权留给运行时。智能体可以准备草稿并请求客户确认，但提交工具被排除在其可用动作之外。确认之后，运行时仅当草稿在 $\mathcal{K}$ 中的字段与已确认的值匹配时才提交它。这强制执行如下顺序：

$$\mathrm{draft}\rightarrow\mathrm{customer\ confirmation}\rightarrow\mathrm{submission}.$$

每个箭头表示，对同一份草稿，前一步必须发生在后一步之前。同一机制通过 $\mathcal{K}$ 容纳领域专用的确认要求。直接提交模式把提交工具暴露给智能体，并禁用运行时中介的提交。智能体仍负责取得确认并提交匹配的草稿。比较这两种模式，使我们能够考察提交权限如何影响任务结果和过程合规。

运行时以共同的只追加轨迹格式记录交互，保留消息、工具调用与结果、确认和提交的顺序。中介提交强制对匹配草稿字段的确认；额外义务，包括所要求的披露、对结果承诺的限制，以及起草前适用的权限检查，在执行之后评测（第 2.4 节）。工具清单和形式化的运行时模式见附录 C.1 和 C.3。

2.4 结果与过程评测

一个回合在执行之后，使用其最终业务状态和所记录的交互轨迹来评测。奖励是一对二元指示：

$$r=\bigl(r_{\mathrm{outcome}},r_{\mathrm{process}}\bigr),$$

它们把客户目标的达成与对所要求过程的遵守区分开。

结果正确性。当领域专用检查确认最终业务状态满足任务的预期结果时，结果指示为 1。对一项提交争议的任务，这要求一份已提交的争议，其相关字段与指定的客户事实匹配。这一检查评测所产生的业务状态，而不判定此前的交互是否合规。

过程合规。过程指示由混合评分器计算，它把确定性检查与大语言模型评判结合：

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

规则层在轨迹上评测适用的确定性条件，包括事件顺序、工具权限，以及已确认字段与已提交字段的一致。大语言模型评判在固定解释量规和任务专用清单下评测语义要求。它返回结构化发现，标明被评估的要求、判断和支撑的轨迹证据。评判的总体判定按附录 D 中的协议与其发现调和；任何失败的发现，不论严重程度，都迫使评判组件失败。两个组件都必须通过，过程指示才为 1。仅规则和仅大语言模型的评测留给消融。

整体成功与 false-pass。整体成功要求两个判定都通过；false-pass 满足结果却未通过过程：

$$r_{\mathrm{success}}=r_{\mathrm{outcome}}\wedge r_{\mathrm{process}},$$

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

这一指示识别那些只看结果的评测会接受、却被检测到过程违反的运行。因此，false-pass 是基准定义的「结果通过 / 过程失败」事件：它表示一项已编码的监管或机构要求失败，但本身不是一项经裁决的法律不合规认定。

3 基准构建

构建结合人工抽取要求、大语言模型辅助的任务合成、结构检查和人类审阅，得到六个领域、每领域 20 项、共 120 项任务。

规则卡与行业参与。作者从可通过 Legal Information Institute 获得的监管材料中抽取 55 项义务，并去重为 53 张规则卡。每张记录标识符、来源引用、义务、所要求的证据，以及确定性检查或评判清单项（第 2.2 节）。行业合作者贡献了业务场景、访谈反馈、规则审阅和轨迹标注。作者把要求翻译成评分判据，并以机构程序作为工作流参照，并对监管解释负责。三位资深软件工程专家审阅每一映射的适用性、所要求的行为，以及时序或顺序约束，通过讨论和投票解决分歧。监管来源为所抽取的义务提供依据，而机构程序告知其操作工作流。规则卡作为场景生成和评测的共同参照，使来源、预期行为和评分判据可供检查。

任务合成与核验。一条大语言模型辅助的流水线，从规则卡和一份接口清单生成任务和评分规格。接口清单列出已注册的工具和受支持的规则。结构检查要求已注册的提交工具、受支持的规则标识符、非空的评判清单，以及出现在私人客户事实中的确认字段。这些检查确立规格一致性；语义审阅检查对来源义务的忠实度。例如，若一项任务的确认契约命名了一个私人事实中不存在的交易标识符，它就通不过结构核验。接口清单同样把生成约束到基准所支持的操作和规则标识符。附录 A.1 和 E 给出模式和程序。

评判开发。五位资深软件工程专家参与：一位起草指令，三位审阅并通过讨论和投票解决分歧，第五位标注 120 条 gpt-5.4-mini 轨迹，并把它们与 gpt-5.6-sol 的判定比较，以改进评判。附录 H.4 报告与人类参照的比较。这些是校准轨迹，不是独立的留出验证集。

领域适配。新领域需要业务状态定义、工具实现，以及从义务到既有或新轨迹谓词的映射。它们复用交互循环、轨迹格式、提交控制和评测协议。因此，领域接口和证据要求应在任务生成之前确立，随后做分开的结构和语义检查。

表 3：全部 120 项任务上的分模型结果。被评测记录包括任务失败。结果通过度量结果正确性；双通过要求同时通过结果和过程检查；false-pass 表示结果通过且过程失败。比率和 Wilson 95% 置信区间（CI）是百分比；置信区间适用于双通过比率。

4 实验

评测协议。我们在六个领域的 120 项任务上评测七个模型，得到 840 条记录。所有记录都计入比率，主要结果和提交控制消融使用混合评分器。客户模拟器是 gpt-5.4-mini；评判是 gpt-5.6-sol。我们报告 Wilson 95% 置信区间，以及经 Holm 校正的双侧精确 McNemar 检验；更多设置见附录 F。

4.1 结果与过程的差距

每个模型都会产生 false-pass。在 840 次评测中，582 次（69.29%）通过结果检查，但只有 116 次（13.81%）同时通过两项检查。466 次 false-pass 占全部评测的 55.48%，占结果通过的 80.07%。因此，纳入过程的打分暴露了只看结果时被藏起来的失败。

模型排序也会改变（表 3）。deepseek-v4-flash 与 glm-5.1 在结果率上打平（77.50%），但双通过分别达到 13.33% 和 21.67%。gpt-5.4 的结果率更低（64.17%），但双通过率（20.83%）高于 deepseek-v4-flash。经 Holm 校正后，21 项比较中有 6 项在 $p<0.05$ 上显著。

4.2 跨领域的失败模式

结果与过程的差距因领域而异：银行的结果通过为 94.29%，双通过仅为 5.71%；政府福利为 84.29% 与 4.29%；医疗为 13.57% 与 2.14%。详细结果见附录 G.1。

混合评分器识别出互补的失败：在 466 次 false-pass 中，329 次仅被大语言模型评判拒绝，38 次仅被硬规则拒绝，99 次被二者同时拒绝。53 条硬规则中有 35 条至少失败一次；一条反复出现的保险顺序规则在 47 条 false-pass 记录中失败。附录 G.2 给出规则级证据。

4.3 提交控制的影响

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

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

因为原始协议包含直接提交专用的检查，我们在去掉相应的硬规则和大语言模型评判检查、同时保留其余检查之后，对同一批轨迹重新打分。直接提交的双通过为 18.33%，中介提交为 20.83%（相差 $-2.50$ 个百分点；精确 McNemar $p=0.677639$；自助 95% 置信区间 $[-10.00,5.00]$ 个百分点），说明原始差距对打分敏感。

4.4 对评判配置的敏感性

在同一批 720 条轨迹上，把 gpt-5.6-sol 换成 gpt-6-astra，使汇集的双通过从 13.89% 变为 14.72%，并保持全部严格的成对排序（Kendall 的 $\tau_{b}=0.9661$）。混合判定在 92.22% 上一致；共同的硬规则失败可能掩盖语义评判的差异。

对照一位专家审阅的 120 条开发轨迹，gpt-5.6-sol 的准确率为 88.33%。以过程通过为正类，精确率、召回率和 F1 分别为 69.70%、85.19% 和 76.67%；以过程失败为正类，精确率和召回率分别为 95.40% 和 89.25%。这些结果关心的是 gpt-5.6-sol 在开发轨迹上的表现，并不确立基线评判的留出准确率。附录 H.4 给出细节。

5 相关工作

交互式工具智能体基准。SWE-bench 对照可执行测试来测试仓库级代码改动（Jimenez 等人，2024），而 tau-bench 和 tau2-bench 用领域专用工具评测对话智能体（Yao 等人，2024；Barres 等人，2025）。Tau-bench 指出，正确结果可能违反政策，例如在没有明确确认时处理退货；cxbench 把这一过程维度与结果分开评测。

过程遵循基准与行业参与。SOPBench 使用可执行验证器评测动作许可、数据库结果和程序完整性，并报告结果正确但程序不正确的情形（Li 等人，2025）。SOP-Bench 使用领域专家撰写的工业程序，以及对人工智能生成产物的人类核验（Nandi 等人，2025），而 SOP-Maze 从业务数据派生任务，并纳入业务用户和专业标注的反馈（Wang 等人，2025b）。这些基准展示了把程序知识和人类输入纳入基准构建的互补做法。AgentSpec 和 OWASP 处理运行时权限与政策强制（Wang 等人，2025a；OWASP Agentic Security Initiative，2025）。在这些工作之上，cxbench 纳入行业输入，并把来自被引监管来源的要求连接到客户服务交互中的证据。它把对已确认草稿的中介提交，与针对披露和对误导性承诺的限制等要求的事后检查结合起来，同时保留结果与过程的区分，以刻画这一设置中的失败。

监管评测与轨迹评判。LegalBench、LiCoEval 和法律关键测试研究法律推理、许可证合规和由法律派生的要求（Guha 等人，2023；Xu 等人，2025；Gogani-Khiabani 等人，2025）。遵循把大语言模型当作评判的方法（Liu 等人，2023；Zheng 等人，2023），cxbench 把与监管相连的要求应用到交互轨迹上，把语义判断与针对顺序和权限的确定性检查结合起来。

6 结论

cxbench 通过与监管相连的规则卡和混合评分器，在受监管的客户服务工作流中把结果正确性与过程遵守分开。在 840 次被保留的执行中，55.48% 通过结果检查却未通过过程检查，而只有 13.8% 同时通过二者。纳入过程的评测也会改变观察到的模型排序，暴露只看结果时被藏起来的差异。与轨迹相连的证据，使这些失败可以对照基准所编码的要求被检查，并支持分析哪些程序义务被遗漏。这些发现合在一起，促使我们在评测智能体是否达成所请求结果的同时，也评测它们如何完成任务。

局限

把结果评测和过程评测分开，会暴露只看结果的评分所遗漏的要求，而运行时控制只强制执行选定的动作约束。随着监管和程序演变，未来的发布应当对更新后的规则卡、任务和评分判据做版本管理。

伦理考量

所报告的评测使用合成的业务状态和大语言模型模拟的客户，而不是真实的客户服务记录。可复现性产物排除秘密、账户元数据和原始提供者载荷。行业合作者贡献了业务场景、访谈反馈、规则审阅和轨迹标注；软件工程专家审阅了规则映射和评判指令。这些贡献支持基准构建和核验，但不构成法律意见，也不构成对监管解释的独立认证。该基准只覆盖有限的领域和操作化，其材料在被用来评测新法域或高影响工作流中的系统之前，应当被更新并审阅。

致谢

本工作来自由 Taighde Éireann–Research Ireland 在资助号 13/RC/2094_2 下，以及由 Genesys Cloud Services, Inc. 共同资助的研究。本工作还得到广东省基础与应用基础研究基金（资助号 2024A1515010145）、国家自然科学基金（资助号 92582201），以及研究资助局一般研究基金（编号 16210725）和主题研究计划（编号 T41-517/25-N）的支持。

参考文献

• [1] Victor Barres、Honghua Dong、Soham Ray、Xujie Si 与 Karthik Narasimhan。2025。$\tau^{2}$-bench：在双控制环境中评测对话智能体。https://arxiv.org/abs/2506.07982 预印本，arXiv:2506.07982。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [2] Consumer Financial Protection Bureau。2026。12 CFR 1005.11：解决错误的程序。https://www.consumerfinance.gov/rules-policy/regulations/1005/11 《电子联邦法规》，Regulation E。见第 (b)(2) 段。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [3] Sina Gogani-Khiabani、Ashutosh Trivedi、Diptikalyan Saha 与 Saeed Tizpaz-Niari。2025。面向法律关键软件的大语言模型智能体方法：报税软件案例研究。https://arxiv.org/abs/2509.13471 预印本，arXiv:2509.13471。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [4] Neel Guha、Julian Nyarko、Daniel E. Ho、Christopher Re、Adam Chilton、Aditya Narayana、Alex Chohlas-Wood、Austin Peters、Brandon Waldon、Daniel N. Rockmore、Diego Zambrano、Dmitry Talisman、Enam Hoque、Faiz Surani、Frank Fagan、Galit Sarfaty、Gregory M. Dickinson、Haggai Porat、Jason Hegland 等 21 人。2023。LegalBench：一项协作构建的、用于度量大语言模型法律推理的基准。https://arxiv.org/abs/2308.11462 预印本，arXiv:2308.11462。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [5] Carlos E. Jimenez、John Yang、Alexander Wettig、Shunyu Yao、Kexin Pei、Ofir Press 与 Karthik Narasimhan。2024。SWE-bench：语言模型能否解决真实世界的 GitHub issue？https://arxiv.org/abs/2310.06770 预印本，arXiv:2310.06770。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [6] Zekun Li、Shinda Huang、Jiangtian Wang、Nathan Zhang、Antonis Antoniades、Wenyue Hua、Kaijie Zhu、Sirui Zeng、Chi Wang、William Yang Wang 与 Xifeng Yan。2025。SOPBench：评测语言智能体遵循标准操作程序与约束的能力。https://arxiv.org/abs/2503.08669 预印本，arXiv:2503.08669。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [7] Xiao Liu、Hao Yu、Hanchen Zhang、Yifan Xu、Xuanyu Lei、Hanyu Lai、Yu Gu、Hangliang Ding、Kaiwen Men、Kejuan Yang、Shudan Zhang、Xiang Deng、Aohan Zeng、Zhengxiao Du、Chenhui Zhang、Sheng Shen、Tianjun Zhang、Yu Su、Huan Sun 等 3 人。2024。AgentBench：把大语言模型当作智能体来评测。https://arxiv.org/abs/2308.03688 载于 Proceedings of the 12th International Conference on Learning Representations。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [8] Yang Liu、Dan Iter、Yichong Xu、Shuohang Wang、Ruochen Xu 与 Chenguang Zhu。2023。G-Eval：用与人类更对齐的 GPT-4 做自然语言生成评测。https://arxiv.org/abs/2303.16634 预印本，arXiv:2303.16634。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [9] Subhrangshu Nandi、Arghya Datta、Rohith Nama、Udita Patel、Nikhil Vichare 等。2025。SOP-Bench：用于评测大语言模型智能体的复杂工业标准操作程序。https://arxiv.org/abs/2506.08119 预印本，arXiv:2506.08119。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [10] OWASP Agentic Security Initiative。2025。智能体人工智能：威胁与缓解。https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/ OWASP GenAI Security Project。为智能体应用定义最小能动原则。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [11] Haoyu Wang、Christopher M. Poskitt 与 Jun Sun。2025a。AgentSpec：面向安全可靠大语言模型智能体的可定制运行时强制。https://arxiv.org/abs/2503.18666 预印本，arXiv:2503.18666。被 ICSE 2026 接收。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [12] Jiaming Wang、Zhe Tang、Zehao Jin、Hefei Chen、Yilin Jin、Peng Ding、Xiaoyu Li 与 Xuezhi Cao。2025b。SOP-Maze：在复杂的业务标准操作程序上评测大语言模型。https://arxiv.org/abs/2510.08942 预印本，arXiv:2510.08942。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [13] Tianbao Xie、Danyang Zhang、Jixuan Chen、Xiaochuan Li、Siheng Zhao、Ruisheng Cao、Toh Jing Hua、Zhoujun Cheng、Dongchan Shin、Fangyu Lei、Yitao Liu、Yiheng Xu、Shuyan Zhou、Silvio Savarese、Caiming Xiong、Victor Zhong 与 Tao Yu。2024。OSWorld：在真实计算机环境的开放式任务上给多模态智能体做基准。https://arxiv.org/abs/2404.07972 预印本，arXiv:2404.07972。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [14] Frank F. Xu、Yufan Song、Boxuan Li、Yuxuan Tang、Kritanjali Jain、Mengxue Bao、Zora Z. Wang、Xuhui Zhou 等与 Graham Neubig。2024。TheAgentCompany：在有后果的真实世界任务上给大语言模型智能体做基准。https://arxiv.org/abs/2412.14161 预印本，arXiv:2412.14161。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [15] Weiwei Xu、Kai Gao、Hao He 与 Minghui Zhou。2025。LiCoEval：在代码生成的许可证合规上评测大语言模型。https://doi.org/10.1109/ICSE55347.2025.00052 载于 Proceedings of the 47th IEEE/ACM International Conference on Software Engineering。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [16] Shunyu Yao、Noah Shinn、Pedram Razavi 与 Karthik Narasimhan。2024。$\tau$-bench：真实世界领域中工具、智能体与用户交互的基准。https://arxiv.org/abs/2406.12045 预印本，arXiv:2406.12045。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。
• [17] Lianmin Zheng、Wei-Lin Chiang、Ying Sheng、Siyuan Zhuang、Zhanghao Wu、Yonghao Zhuang、Zi Lin、Zhuohan Li、Dacheng Li、Eric P. Xing、Hao Zhang、Joseph E. Gonzalez 与 Ion Stoica。2023。用 MT-Bench 和 Chatbot Arena 评判「以大语言模型为评判」。https://arxiv.org/abs/2306.05685 预印本，arXiv:2306.05685。 本条按原文出现顺序完整著录，作者姓名、会议名、页码与网址保留不译。

附录 A 任务规格与形式化

本附录展开第 2.1 节引入的任务规格。我们先把它的数学表示连接到任务模式，再形式化回合执行，并描述每个组件可获得的信息。

A.1 任务表示与模式

每项任务由下式指定：

$$\theta=(g,m_{0},s_{0},\mathcal{U},\Lambda,\mathcal{K}),$$

其中 $g$ 表示客户目标，$m_{0}$ 表示规定的开场消息，$s_{0}$ 表示初始状态，$\mathcal{U}$ 表示领域专用工具接口，$\Lambda$ 表示适用的政策上下文和过程要求，$\mathcal{K}$ 表示需要客户确认的草稿字段。目标和私人客户事实指定可接受的业务结果必须满足的条件。政策要求和确认字段约束智能体应当如何取得该结果。

表 5 把这些要素与序列化的任务规格联系起来。形式化的初始状态 $s_{0}$ 既包括存放在 initial_state 下的业务记录，也包括存放在 hidden_facts 下的私人客户事实，以及由运行时维护的初始历史和草稿存储。因此，YAML 字段 initial_state 表示的是业务状态组件，而不是整个 POMDP 状态。

表 5：任务表示与任务模式之间的对应。已注册的领域实现提供与这些字段一起使用的工具行为和状态初始化。

图 4 展示一项关于未经授权的 ACH 借记的银行任务的选定组件。该任务把客户请求和初始记录连接到领域工具、与法规相连的要求，以及评分判据。评分配置指定要求如何被评估；确认契约另行标明哪些草稿字段需要客户审阅。

图 4：一项未经授权 ACH 借记的银行任务规格的选定组件：（a）客户目标、开场消息和初始业务状态；（b）领域专用工具接口；（c）与法规相连的政策要求；（d）相关联的评分配置。私人客户事实、确认字段和其他细节为简洁而省略。

下面的清单用一项 ATM 争议任务 BK-RAW-008.us 提供互补的模式示例。它说明私人事实、工具权限级别、确认字段和过程检查如何在任务文件中表示。这是与图 4 不同的银行场景。清单经过缩写；注释标明被省略的内容，完整任务包含与每个确认字段对应的私人事实。

清单 1：Regulation E 下一项 ATM 争议的缩写任务规格。

id: BK-RAW-008.us
domain: banking
scenario: eft_error_resolution
business_system: banking_customer_ops_v0
customer_goal: ATM incorrect amount error
seed_message: >-
  The ATM only gave me USD 60, but my account
  was debited USD 100 on 2026-06-12.

notice_channel: oral
institution_policy:
  requires_written_confirmation: true
  written_confirmation_address: example_address

hidden_facts:
  customer_id: cus_raw_008
  transaction_id: txn_raw_008
  amount: 100.0
  dispensed_amount: 60.0
  disputed_difference: 40.0
  # Additional private facts omitted.

initial_state:
  session_context:
    authenticated: true
    # Additional session fields omitted.
  disputes: []
  # Customer, account, and transaction records omitted.

tools:
  read: [get_session_context]
  check: [classify_eft_error]
  draft: [create_eft_dispute_draft]
  notice: [record_reg_e_timeline_disclosure]
  submit: [submit_eft_dispute_case]
  # Additional tools omitted.

confirmation_contract:
  - transaction_id
  - merchant
  - amount
  - reason

policy:
  source_refs:
    - reg-e-error-resolution-1005-11-r001
  process_requirements:
    - >-
      If written confirmation is required after an
      oral error notice, inform the consumer of
      the requirement and submission address
      under 12 CFR 1005.11(b)(2).
    - Submit only the confirmed draft.
  grading_notes:
    - No exact disclosure text is required.
  llm_judge:
    checklist:
      - id: confirm_exact_business_object_before_submit
        severity: critical
        pass_condition: >-
          Agent obtains explicit confirmation for
          transaction txn_raw_008 before submitting
          the draft.
      # Additional checklist items omitted.
  grading_policy:
    deterministic_hard_rules:
      - draft_before_confirmation
      - confirmation_before_submit
      - submit_matches_confirmed_draft
      - no_agent_direct_submit
      # Additional hard rules omitted.

rules:
  - draft_before_confirmation
  - confirmation_before_submit
  - submit_matches_confirmed_draft
  - no_agent_direct_submit
  # Additional rule references omitted.

译注：清单 1 的 YAML 按原文保留，不翻译键名与示例值。注释中的省略说明亦保留英文。

该规格通过显式字段连接共享的基准组件。运行时使用工具清单和确认契约来控制提交。结果检查器使用客户目标、参照事实和最终业务状态。过程评分器使用适用规则和语义清单来评测所记录的交互。智能体只收到指定给智能体使用的信息，详见第 A.3 节。

A.2 POMDP 形式化

对固定的任务规格和运行时模式，一个回合被建模为部分可观察马尔可夫决策过程

$$\left\langle\mathcal{S},\mathcal{A},\mathcal{O},T,\Omega,R,B_{0},\gamma\right\rangle,$$

其中 $\mathcal{S}$ 是状态空间，$\mathcal{A}$ 是智能体的动作空间，$\mathcal{O}$ 是观察空间，$T$ 是转移核，$\Omega$ 是观察核，$R$ 是终端奖励机制，$B_{0}$ 是智能体的初始信念，$\gamma$ 是折扣因子。

状态。每个状态 $s\in\mathcal{S}$ 具有如下表示：

$$s=(\mathit{business\_state},\,\mathit{private\_facts},\,\mathit{history},\,\mathit{drafts}).$$

业务状态包含账户、交易、争议或保险保单等领域记录。私人事实编码客户与任务相关的意图和参照信息。历史是交互的只追加记录，草稿存储包含可提交给客户确认的拟议业务动作。业务记录、历史和草稿在执行期间演化；私人事实提供该任务固定的客户上下文。

动作与观察。智能体动作要么是面向客户的消息，要么是一次被允许的工具调用。工具接口 $\mathcal{U}$ 指定可用的领域操作，而运行时模式决定哪些操作属于 $\mathcal{A}$。在中介提交模式中，由运行时发起的提交是环境操作，而不是智能体动作。两种模式的形式化动作集见附录 C.3。

智能体观察由开场客户消息、后续客户回复，以及其工具调用返回的结果组成。观察核 $\Omega$ 描述一次动作之后暴露给智能体的信息。智能体不直接观察完整的业务状态或私人事实组件。

转移。转移核 $T$ 捕捉工具效果、客户回复、草稿更新、运行时中介的操作，以及对历史的相应追加。对固定的输入和业务记录，领域工具施加确定性的状态更新。客户回复由大语言模型模拟器生成，因此确定性的工具行为并不使整体交互成为确定性的。运行时记录已实现的事件及其顺序，保留随后评测所用的证据。

初始条件。任务指定初始状态 $s_{0}$，而 $B_{0}$ 表示智能体在与其初始信息一致的状态上的信念。该信息包括 $m_{0}$、面向智能体的政策上下文、被允许的工具定义，以及任何提供的会话上下文。智能体通过客户回复和被授权的工具访问来细化其信息；它并未被给予完整的任务状态。

终端奖励。回合结束后，评分器评测所记录的最终业务状态和交互轨迹，并返回

$$r=\bigl(r_{\mathrm{outcome}},r_{\mathrm{process}}\bigr)\in\{0,1\}^{2}.$$

结果组件检查业务结果，过程组件检查对适用要求的遵守。这些判定在执行之后计算，而不是用来控制中间动作。我们设 $\gamma=1$，因为评测使用终端奖励。评分器的组成在附录 D 中描述；评测记录和汇总比率的处理遵循第 4 节的协议。

A.3 信息访问与组件角色

任务规格把基准所用的参照信息，与被评测智能体可获得的观察分开。特别是，向智能体提供政策指令，并不意味着暴露私人客户事实或完整的评分规格。表 6 概括执行组件和评测组件所用的信息。

表 6：执行组件和评测组件所用的信息。访问按职能描述；这并不意味着每个组件都收到完整的任务文件。

客户模拟器的确认关心所呈现的 $\mathcal{K}$ 字段是否与私人客户事实匹配。它并不认证监管合规。运行时强制执行与所选模式相关联的提交控制，而结果检查器和过程评分器在执行之后指派判定。专家审阅分析检查评测程序；其范围和发现报告在附录 H.4。

附录 B 监管要求与规则卡

本附录展开 $\Lambda$ 中监管要求的表示（第 2.2 节）。它描述规则卡的内容、银行披露示例，以及过程评测所用的规则类别。

B.1 规则卡表示

我们从可通过 Legal Information Institute 获得的监管材料中人工抽取 55 项义务，并去重为 53 张规则卡。这些卡覆盖银行、电信、保险、医疗、公用事业和政府福利。

每张规则卡是一条带稳定标识符和来源引用的结构化文本记录。它把义务及其适用条件连接到所要求的行为、可观察的轨迹证据，以及一项确定性检查或大语言模型评判清单项。任务规格决定哪些要求适用于该场景。

规则卡指导任务及其评分规格的生成。在任务模式中，policy.source_refs 记录来源引用，而过程要求和相关联的评分指令出现在 policy 块中。任务还指定确定性规则和一份大语言模型评判清单。附录 A.1 提供一个任务示例，附录 E 描述构建程序。

B.2 监管要求与轨迹证据

第 2.2 节中的银行示例，关心的是向一家要求书面确认的机构发出的口头错误通知。依据 Regulation E，机构必须在消费者给出口头通知时告知这一要求，并提供提交地址（Consumer Financial Protection Bureau，2026，12 CFR § 1005.11(b)(2)）。对应的要求关心的是交互期间被传达的信息，而不只是最终业务状态中的争议记录。

表 7 组织这一示例的要素。它概括来源要求及其在基准中的表示，而不是复现一份序列化的规则卡文件。

表 7：Regulation E 披露示例：来源义务、适用的任务条件、所要求的信息，以及基准评测判据。

来源条款要求机构在消费者给出口头通知时，传达书面确认要求和提交地址。对这项任务，cxbench 把请求草稿确认用作评估披露时序的可观察检查点。这一检查点是基准的评测选择，不是 Regulation E 另行规定的截止期限。客户对草稿的确认，不同于 Regulation E 所述的书面确认：前者在基准内部授权所提议的提交，后者关心对客户口头错误通知的书面确认。因此，披露要求与运行时的「草稿—确认—提交」控制分开评测。一份正确提交、并经客户确认的争议，若漏掉所要求的通知，仍可能通不过过程评测。

过程检查同时使用结构和语义证据。确定性规则层检查事件顺序、工具权限，以及已确认字段与已提交字段的一致等条件。大语言模型评判在固定解释量规和任务专用清单下评估语义要求。其发现标明被评估的要求、判定和支撑的轨迹证据。输出格式和判定组成程序在附录 D 中描述。

B.3 规则目录与评分规格

在检查报告人权限之前阅读政策摘要这一要求，遵循保险任务所用的机构工作流。我们把它编码为 policy_summary_before_authority_check。这一顺序并未被所引用的监管条款显式规定。因此，一次失败表示未遵守已编码的机构工作流，而不是对这些条款的一项独立违反。

表 8：过程规则目录中的类别。定义在此给出；观察到的规则失败报告在附录 G.2。

任务的评分规格标明适用的检查。确定性硬规则记录在评分政策配置的 deterministic_hard_rules 下。语义要求表示在 policy.llm_judge.checklist 中。每条评判发现记录规则标识符、通过或失败决定、严重程度、轨迹序列引用和证据。确定性组件和大语言模型评判组件都必须通过，混合过程判定才算通过。

监管披露义务和基准提交控制有不同的依据。银行示例中披露书面确认信息的要求来自被引用的条款。草稿确认机制和对智能体发起提交的限制，是 cxbench 的运行时控制（第 2.3 节）。过程判定评估的是对基准所编码要求的遵守；它本身并不确立真实世界部署的法律合规。

附录 C 交互与运行时实现

本附录展开第 2.3 节所述的执行框架。共享运行时把任务的领域专用工具接口 $\mathcal{U}$ 连接到共同的交互循环，用确认字段 $\mathcal{K}$ 控制中介提交，并记录交互以供随后评测。

C.1 领域系统与工具接口

每个领域提供其业务状态表示和已注册的工具实现。工具分为五类：read、check、draft、notice 和 submit。这些类别出现在任务的 tools 清单中，该清单指定领域接口 $\mathcal{U}$。运行时模式决定哪些工具动作对智能体可用。

读取工具检索业务记录，检查工具评估领域专用条件。草稿工具准备供客户审阅的拟议业务动作，通知工具支持所要求的披露。提交工具执行所提议的动作，并提交相应的业务状态变更。表 9 报告跨领域的已注册工具计数。

表 9：按领域和工具类别统计的已注册工具。计数包括别名。

工具实现领域专用操作，同时使用共享的执行和记录机制。例如，公用事业工具 submit_arrangement_or_hold 按草稿的 draft_type 分派，写入付款安排、监管暂停或账单争议。确认匹配检查把已提交字段与已确认草稿比较，与哪条业务记录接收结果无关。

C.2 客户模拟

一个回合从规定的客户消息 $m_{0}$ 开始。一个固定的大语言模型使用任务的私人客户事实生成后续客户回复。基线实验用 gpt-5.4-mini 作为客户模拟器；其配置报告在附录 F。

模拟器观察面向客户的消息和所呈现的草稿字段，但不观察智能体的工具调用。它的回复基于私人事实提供信息，这些事实不直接暴露给智能体。因此，智能体通过与客户交互以及被允许访问业务记录，来获得与任务相关的信息。

确认契约指定需要客户审阅的字段 $\mathcal{K}$。模拟器的确认决定关心这些字段的呈现值是否与私人客户事实匹配。这一决定不评估过程合规。所要求的披露、对承诺的限制和其他适用义务，在执行之后分开评测。

C.3 提交模式与确认匹配

记

$$\mathcal{A}_{\mathrm{read}},\;\mathcal{A}_{\mathrm{check}},\;\mathcal{A}_{\mathrm{draft}},\;\mathcal{A}_{\mathrm{notice}},\;\mathcal{A}_{\mathrm{submit}}$$

为与 $\mathcal{U}$ 中五类相关联的工具调用动作，并记 $\mathcal{A}_{\mathrm{msg}}$ 为面向客户的智能体消息。两种运行时模式的差别在于提交动作是否对智能体可用。

中介提交模式。默认的、面向智能体的动作集是

$$\mathcal{A}_{\mathrm{LP}}=\mathcal{A}_{\mathrm{read}}\cup\mathcal{A}_{\mathrm{check}}\cup\mathcal{A}_{\mathrm{draft}}\cup\mathcal{A}_{\mathrm{notice}}\cup\mathcal{A}_{\mathrm{msg}}.$$

提交工具被排除在这一集合之外。智能体试图调用提交工具会被拒绝并返回错误，并被记录为一次被阻断的提交尝试。这类尝试由确定性规则 no_agent_direct_submit 检查。

智能体准备草稿并请求客户确认。运行时只在确认之后，且仅当 $\mathcal{K}$ 中的字段与已确认的值匹配时，才提交草稿。所记录的确认通过内容哈希与草稿内容相关联。运行时在提交前，把任务指定的字段与已确认草稿核对。

这一控制强制执行

$$\mathrm{draft}\rightarrow\mathrm{customer\ confirmation}\rightarrow\mathrm{submission}.$$

每个箭头表示同一份草稿上的一项所要求的先后关系。确认字段是任务专用的，而运行时应用共享的提交机制。

直接提交模式。面向智能体的动作集变为

$$\mathcal{A}_{\mathrm{direct}}=\mathcal{A}_{\mathrm{LP}}\cup\mathcal{A}_{\mathrm{submit}}.$$

提交工具暴露给智能体，运行时中介的提交被禁用。智能体仍负责取得所要求的客户确认，并提交匹配的草稿。

提交控制实验在原始混合评分协议下评测两种模式（第 4.3 节）。暴露提交工具改变的是执行权限；它并不自动从该打分协议中移除直接提交禁令。移除这一禁令的诊断，在同一节中另行报告。

控制的范围。中介提交强制在提交前确认匹配的草稿字段。它并不强制全部过程要求。智能体仍必须提供适用的披露，遵守对结果承诺的限制，并在起草前执行所要求的权限检查。这些义务由过程评分器使用所记录的执行来评估（附录 D）。

C.4 轨迹表示

运行时维护一份只追加的交互历史。它按执行顺序记录客户和智能体消息、工具调用与结果、确认和提交。这些记录保留把已达成的业务结果与取得它所使用的过程区分开所需的证据。

轨迹事件由序列下标引用。过程评分器用事件顺序检查先后要求，大语言模型评判的 seq 字段把一条发现连到相关轨迹事件。消息和操作也按其来源区分：客户消息来自模拟器，智能体消息和所请求的工具调用来自智能体，中介提交由运行时发起。虽然运行时执行工具调用，但智能体请求的调用和运行时发起的提交，在权限检查中角色不同。

所记录的证据支持若干种过程评测。面向客户的消息支持对披露和结果承诺的评估。工具调用和结果支持对所要求操作及其顺序的检查。确认和提交记录支持检查已提交字段是否与客户确认的字段匹配。被阻断的提交尝试为直接提交禁令提供证据。

最终业务状态和所记录的交互在执行之后传给评测组件。结果检查器检查业务结果，确定性规则层和大语言模型评判评估过程证据。它们的实现和判定组成在附录 D 中描述。

译注：全文超过单篇容量。本篇为上篇，收到附录 C。下篇从附录 D 续到文末。