技能一直在改：过程级评测才能拦住看起来正确的回归

技能一直在改：过程级评测才能拦住看起来正确的回归

Ngoc Phuoc An Vo（IBM），Aarya Doshi（佐治亚理工学院），Vadim Sheinin（IBM）

预印本，2026-10-01

摘要

企业里的智能体技能不是写完就不动的产物。工具接口会变，大语言模型版本会更新，技能说明也会按线上反馈改。现在每次改完，常见做法只核对最终输出对不对。这种做法会系统性地漏掉演化过程中引入的过程级行为漂移。过程是智能体为了得到结果所调用的工具、参数、顺序和落库方式。

我们给出一套面向企业智能体技能的持续评测框架，同时做结果层和过程层检查。它用在一套企业价值感知韧性系统 VAR（Value Aware Resiliency）里的两种业务价值测定技能 BVD（Business Value Determination）上。框架每次运行都独立计算参照值，把模板测试用例实例化成持久的回归测试，并用程序检查工具选择、参数是否正确、执行顺序和数据库是否完整。只有精确匹配会太脆的地方，才加一个范围很窄的大语言模型裁判。

我们报告一次全自动评测：240 次试验，覆盖两种相关但结构不同的技能（收入分摊和生产力分摊），两种说明变体（SKILL.md 和 Skill.txt），两种智能体运行框架（Claude Code 和 Codex），三个模型（GPT-5.6-Sol、Claude Opus 4.8、Claude Sonnet 4.6）。运行框架（harness）是包在模型外面、负责执行工具和记下轨迹的程序。240 次自动试验里，175 次通过了全部适用的最终数值检查；其中 162 次（92.6%；Wilson 95% 置信区间 87.7–95.6%）仍至少有一处评测器发现的额外偏离。Wilson 区间是由通过次数和试验次数算出的二项比例置信区间。把最终状态放宽到每项技能 7 项检查后，164 次通过运行里仍有 151 次（92.1%；95% 置信区间 86.9–95.3%）违反了轨迹检查。依赖归因把每次运行平均 6.34 条失败检查，描述性地压到 2.65 个根。说明变体的敏感度也随模型和运行框架变化：未校正的自助交互区间，在三项收入比较和 GPT 的生产力比较上都不含 0，另外两项生产力比较则含 0。带运行时解析占位符的模板测试用例，在已评测的说明、模型和运行框架之间提供可复用的回归覆盖。在真实接口演化下做纵向验证，仍是以后的工作。

1 引言

企业智能体技能是持续演化的系统。今天负责把信息技术基础设施成本分摊出去的技能，明天可观测性接口版本一变就要改，下个月和财务团队谈妥新公式还要改，底层大语言模型升级到下一版时再改一次。每一次改动都可能引入行为回归：偏离技能本来该走的过程。

现有评测对付这个问题的办法很差。标准评测看最终输出——一份报告、一行数据库、一个金额——是否等于期望值。但技能可以走出错误步骤，却交出一份看起来正确的最终输出：用错误范围调用接口、跳过规定的数据库回读、把中间结果写到错误的表。这些过程偏离对只看结果的检查是看不见的，却是真实的行为漂移。它会弄脏下游步骤，违反数据完整性约束，或交出碰巧正确、输入稍变就会失败的输出。在持续适应的设定里，技能按线上反馈反复修改，这些失败会跨版本叠加。因此，过程级评测是负责任部署循环里必要的一环。

本文研究的是，要让智能体持续演化仍然安全，评测层需要什么。我们不提出一种持续学习算法。我们论证：对企业技能在演化过程中设质量门，持续的过程级评测是合适的。我们在 VAR 系统的 BVD 技能上演示这一点。即使 BVD 交出了期望的最终分摊，它的轨迹仍可能违反规定的范围、持久化或顺序约束。只核对本组合计的结果检查发现不了这些偏离，更细的结果检查和过程检查可以。

我们的贡献如下。

1. 一套落在环境上的评测框架。它对照一条独立于被评轨迹算出的参照，检查工具选择、参数、顺序和数据库完整性；对语义上可以有多种写法的参数，再用一个范围很窄的大语言模型裁判补充。

2. 一份带参数的回归契约。运行时解析的占位符填上期望的范围、次数和数值，而不是把它们写死。一套登记过的测试在全部被测配置上复用：收入 104 条，生产力 80 条。

3. 实证。240 次自动试验，覆盖两种说明变体、两种运行框架和三个模型。175 次通过全部适用最终数值检查的试验里，162 次仍至少有一处评测器发现的额外偏离。把基线放宽到每项技能 7 项最终状态检查后，164 次通过运行里仍有 151 次违反轨迹检查。

4. 敏感度分析和根家族分解。去掉外部错误运行之后，结果与过程之间的缺口仍然在，并且跨过数据一致性、缺失阶段、允许名单、调用次数和范围检查。

2 企业智能体技能是演化中的系统

企业智能体技能和研究基准有一个关键差别：它们不是评一次就退役。它们按接口变化、说明修订、新工具能力和模型升级持续修改（Bogavelli 等，2025）。我们把企业技能的演化分成四条轴。

#### 工具接口演化

可观测性平台、数据库和业务系统在持续更新接口。技能今天用对了参数模式，下一版平台改了参数名或范围语义，调用可能静默失败。

#### 技能说明修订

运维团队从线上行为里学到东西之后，会改技能说明，把学到的行为写进去、堵住含糊之处，或改业务逻辑。每一次修订都可能改变智能体的规划策略，而结果指标抓不住这种改变。

#### 大语言模型版本变化

底层模型一更新，哪怕还在同一家族里，含糊步骤上的默认规划也可能变。上一版保守处理的步骤，下一版可能处理得更激进，于是调用哪些工具、按什么顺序调用都会变。

#### 运行框架变化

企业部署可能因成本、延迟或集成，在运行框架之间迁移，例如从 Claude Code 换到 Codex，或反过来。我们会表明：结果准确率相近的框架，过程偏离的模式可以不同，并且和不同的执行特征连在一起。同一份说明变体，在一个框架下可以很稳，换一个框架就会让准确率明显下降。

每一条演化轴带来的风险，只看结果的评测都发现不了。只查最终输出的质量门，会放行过程上已经退步的修订。我们提出：对着持久的模板测试用例做过程级评测，才是这个设定里该用的质量门。

3 相关工作

#### 智能体系统里的行为漂移与稳定性

同样的输入重复跑，智能体的输出不稳定。汇总的任务完成指标会掩盖工具使用、策略、核验和记忆召回上的失败（Bogavelli 等，2025；Akshathala 等，2026）。Cemri 等（2026）分析的多智能体轨迹里，系统设计类和任务核验类占标注失败的 63.1%（分别是 41.8% 和 21.3%）。这个分布说明系统层有大量可改进之处，但并没有排除底层模型本身的限制。

#### 智能体的评测方法

Flynt（2026）提出 GroundEval，用确定性方法替代有状态任务上的大语言模型裁判。GroundEval 按一份人审过、机器可查的状态契约给观察到的轨迹和最终答案打分，契约覆盖证据、时间、访问和必须做的搜索，而不是对照一条标准参考轨迹。不同评测方法给出互补信号：确定性检查可复现，大语言模型裁判能容纳语义变化，人工复核用来校准和监督。因此 Gritta 等（2026）主张把结果评测和过程评测合在一起，Zheng 等（2023）则主张把能力基准和偏好基准合在一起。

#### 用大语言模型当裁判的限制

已有研究表明，基于大语言模型的评测会对与回答质量无关的因素敏感，包括候选回答的顺序、啰嗦程度和模型身份（Wang 等，2024；Zheng 等，2023）。确定性规则又会漏掉用语义表达出来的失败。例如，AgentEval 报告，47 条手工规则相对人工标注的失败检测召回率是 0.58（Guo 等，2026）。我们的框架把基于规则的结构检查，和针对选定的、语义上灵活的参数所做的大语言模型核验合在一起，并可选地只对失败做补救审计。两位作者手工看了 60 条随机抽取的、由大语言模型判定的案例，57 条裁决与他们的判断一致（95%）。这种有针对性的审计降低了裁判有效性风险，但没有消除它。

#### 参照的完整性

在给 HumanEval 生成的测试里，Huang 等（2025）研究的错误测试用例中，88.89% 来自生成错了的输出参照，而不是无效的测试输入。在他们的七个基准上，这个参照错误占比从 79.71% 到 100%。我们的框架调用技能所用的同一批真实接口来计算参照值，路径独立于智能体执行轨迹，从而不依赖大语言模型生成的参照。与此同时，仍保留另一项风险：执行和评测之间，线上状态可能已经变了。

#### 过程评测与结果评测

只给最终输出打分，会奖励一条不合规或没有依据、但看起来正确的结果。因此有人主张对关键智能体应用做过程评测；在数学推理里，过程监督也优于只看结果的监督（Gritta 等，2026；Lightman 等，2024）。Barke 等（2026）演示了从执行轨迹做轨迹级的智能体失败诊断。

#### 持续集成式的回归评测

自动化回归测试，以及生产机器学习里的持续监测，为技能的持续质量保证提供了软件工程上的先例（Breck 等，2017）。Guo 等（2026）用 AgentEval 把这个想法用到智能体任务上：用依赖关系建成的有向无环图把步骤级检查串起来，并提高根因准确率，因此和我们的框架很近。我们在 AgentEval 没有的两个方向上延伸。（i）运行时解析的模板测试用例，设计成在技能说明、工具接口和输入组合演化时仍可复用。（ii）独立于智能体执行、靠实时接口算出的参照值，用来避开自生参照。自动测试生成里很高的生成参照错误占比，说明了这种失败（Huang 等，2025）。AgentEval 的评测图是围着某一次具体工作流执行建的。我们的回归产物则在评测时从当前企业环境解析期望值。实验建立的是跨配置复用，还不是接口变化下的纵向持久。

4 系统：VAR 与 BVD

#### 价值感知韧性（VAR）

VAR 是一套企业韧性智能体系统，按业务定义的服务等级目标衡量应用的韧性。它是一条由大语言模型驱动的技能流水线：业务价值测定（BVD）、归因评估、应用优化器、诊断、建议生成、建议影响估计器、建议优化器。技能实现为 Claude Code 或 Codex 会话，由一份技能说明文档指导，并配备两台 MCP 服务器上的工具。MCP 是让智能体调用外部工具的协议。VAR MCP 服务器有 23 个工具，无状态，从 Instana、Kubecost 和 ServiceNow 取利用率数据。VAR 数据访问 MCP 服务器有 18 个工具，管理持久会话状态、结果存储，以及 SQLite 里的分摊表。

#### 业务价值测定

BVD 是 VAR 的第 0 步。给定一组应用、一个日期范围和一笔年收入，BVD 查询可观测性接口，取出每个应用的 CPU、内存和调用次数，再按比例分摊业务价值。默认权重是 CPU 40%、内存 40%、调用 20%。输出写入持久数据库，后面的技能都读它。因此 BVD 的错误会弄脏整条剩余流水线。

我们研究两种相关但操作上不同的技能。收入分摊按 CPU、内存和调用量，把按比例分出的组合收入分到九个应用上。它先暂存完整的监控响应，再读回来，计算分摊，并分别写入主机级和应用级收入表。它的测试套件有 104 项检查。生产力分摊另外从 Kubecost 取 Kubernetes 成本，从 Cloudability 取 EC2 未混合成本，要求有 EC2 资源标识，在应用之间拆分主机成本，用显式的 NULL 语义计算收入对成本的生产力，并写入另一张应用表。它的套件有 80 项检查。两种技能共享基于资源的收入分摊，但工具集合、持久化契约和工作流深度并不相同。

#### 说明变体

MD 和 TXT 是成对的说明产物，不是一次受控的文件格式操纵。对收入技能，TXT 是一次大幅压缩（904 词对 1,379 词）：它去掉工具参考表和许多精确的输出与警告要求，但保留暂存、回读、分摊和持久化。对生产力技能，TXT 只略短（1,318 词对 1,405 词），并且加入了 MD 里没有的操作内容，包括显式的时长公式、$[0.01,1]$ 归一化区间、排除组合之外的应用、合并的 EC2 成本查询，以及 CSV 导出。因此 MD 与 TXT 的差异估计的是整次修订的敏感度，语法、长度和指令内容合在一起，而不是格式单独的因果效应。两种变体都把确定性算术交给工具。

5 持续评测框架

评测框架是一条五阶段流水线，独立于被评测的智能体会话（图 1）。

图 1：持续评测流水线。第 1 阶段和第 5 阶段每次运行都新做；第 2 到第 4 阶段在同一项技能内，跨已评测的说明、模型和运行框架复用一套模板。

5.1 阶段 1：捕获输入并解析工具调用轨迹

在技能说明第一步末尾追加一行，指示智能体把解析后的全部输入参数（组合、日期范围、收入）记到结构化日志。智能体的完整工具调用轨迹——工具名、参数、返回值和对话轮次——从运行框架的执行日志里捕获。

5.2 阶段 2：计算参照值

一段独立的 Python 脚本走另一条执行路径，调用技能所用的同一批真实接口，算出每个应用的期望分摊值。这种独立是关键的：在 HumanEval 上，Huang 等（2025）分析的错误大语言模型测试用例里，88.89% 是输出参照错了，而不是测试输入无效。实时调用让参照能跟上当前接口状态，但执行和评测可能看到不同快照。我们把这当成有效性威胁，而不是接口演化下正确性的证据。

5.3 阶段 3：实例化模板测试用例

模板测试用例用运行时解析的占位符描述技能应有的行为，而不是写死数值。例如占位符 $k8s\_host\_date\_calls$ 在评测时从阶段 2 的参照值解析出来。这样模板是按输入参数化的：只要工具语义没变，同一份模板文件可以用于不同日期范围、组合和收入数字。测试用例之间的依赖链接定义哪些失败是根因、哪些是下游效应，从而在阶段 5 做级联根因归因。下面这段摘录声明一项有条件的工具调用检查。期望调用从这次运行的参照填入，而不是抄进套件：

{"id": "k8s_cpu_mem",
 "condition": "$has_k8s",
 "check": {"type": "tool_call"},
 "tool": "...calculate_k8s_cpu_memory_usage",
 "scope_arg": "cluster_name",
 "expected_calls": "$k8s_host_date_calls"}
{"id": "compute_apps_match_stored_data",
 "depends_on": "resource_util_store_args_match",
 "check": {"type": "bash", "...": "..."}}

实例化把这句紧凑声明展开成存在性、参数、范围、执行、冗余和调用次数检查。下游检查可以通过 depends_on 引用展开后的标识。

5.4 阶段 4：评测

#### 结果与最终状态检查

我们区分三层。第 1 层是预先指定的最终数值结果：收入技能是应用收入；生产力技能是应用收入、总成本和生产效率。第 2 层放宽到每项技能 7 项最终状态检查：第 1 层的值，加上其他存储值和归一化合计，以及规定的响应结构。第 3 层是下面要说的其余轨迹检查。这样拆开，是为了检验：即使最终状态更丰富，轨迹评测是否仍然多发现一些问题，而不是只在一条故意很窄的数值基线上才多发现。

#### 过程检查

覆盖四个维度。

• 工具选择：该调的工具调了；没有调用无关工具。
• 工具参数：日期范围、过滤器和数值参数用带类型的约束检查。候选调用的选择和结构检查基于规则。大语言模型裁判（claude-sonnet-4-6）只在指定的、精确匹配太脆的检查上调用，例如语义等价的 SQL，或其他参数写法。它要求的数值比较通过计算器工具执行。选定的、失败了的程序检查也可以接受一次只针对失败的裁判补救审计。因此裁判是补充程序套件，不是替换，也不负责发现候选调用。两位作者手工看了 60 条随机抽取的裁判案例，57 条裁决与作者判断一致（95%）。
• 工具顺序：用对话轮次比较来强制规定的阶段顺序（取数 $\to$ 暂存 $\to$ 回读 $\to$ 分摊 $\to$ 写入）。
• 参数范围：按集群、按主机的工具调用要检查覆盖不足（缺调用）和覆盖过度（范围值错误的调用）。

#### 为什么演化时过程检查重要

技能说明被压缩，或工具接口变了，模型在含糊步骤上的行为就会移动。只要最终数字还对，结果检查就会批准新行为。过程检查抓住的是行为移动本身，不管它是否碰巧交出正确的最终输出，并在部署前把它作为回归交给人看。

5.5 阶段 5：用级联归因报告根失败

一项检查失败时，框架沿着作者写好的依赖图走，把指定的根失败和级联失败分开。级联失败归到它的根因上，避免开发者把每个下游症状当成独立问题来花时间。报告列出根以及级联下来的后代，以缩小最初要看的集合。这些由图得出的根是描述性的，不是经过验证的因果解释。

6 实验设置

#### 技能与测试套件

我们评测两种相关的 BVD 家族技能，参照值各自独立计算：收入分摊（104 条模板测试用例）和生产力分摊（80 条）。它们共享利用率检索和收入分摊，但生产力加上成本检索、成本分摊、NULL 处理和另一份持久化契约（第 4 节）。

#### 数据

一个真实企业组合：九个应用，跨三个基础设施平台（两个 Kubernetes 集群、一台 EC2 主机），年收入 1,200,000 美元。收入试验用 2026-05-01 到 2026-05-15；生产力试验用 2026-07-01 到 2026-07-15。利用率从 Instana 实时取；生产力另外查询 Kubecost 和 Cloudability。因此比较是在同一技能之内做的。本研究不把跨技能差异解释成同一数据快照下的效应。

#### 说明变体

按第 4 节，我们在启用计算工具的情况下测试 MD（SKILL.md）和 TXT（Skill.txt）。因为每一对在呈现和指令上都不同，实验因子是「变体」。

#### 运行框架与模型

两个运行框架：Claude Code（Anthropic 的命令行）和 Codex（OpenAI 的命令行）。每个框架驱动三个模型：GPT-5.6-Sol（Azure）、Claude Opus 4.8（AWS）、Claude Sonnet 4.6。于是得到技能、说明变体、运行框架、模型的 $2\times 2\times 2\times 3$ 矩阵。

#### 试验

每个格子跑 10 次，全部由评测框架对照相应的模板测试套件打分。报告的套件分数是全部已实例化检查里通过的比例。它把结果检查和过程检查合在一起，不应理解成整次运行正确的概率。一份存档的生产力 Codex–Sonnet TXT 结果里，有 6 条旧的 Cloudability 检查，不在登记的 80 项套件里。聚合前去掉这 6 条，使该技能内的套件一致。自动试验总数：$2\times 2\times 2\times 3\times 10=240$。

#### 统计分析

我们报告试验级的均值和标准差。为了看说明变体的效应是否随运行框架改变，另外计算双重差分 $\bigl(\mathrm{MD}-\mathrm{TXT}\bigr)_{\mathrm{CC}}-\bigl(\mathrm{MD}-\mathrm{TXT}\bigr)_{\mathrm{Codex}}$，并用每个格子 10 次运行的 20,000 次重抽样，给出 95% 非参数自助区间。这些区间没有对六次比较做校正，而且每格样本小，所以是探索性的。看轨迹之前，我们先定义窄的最终数值结果：收入技能是应用收入；生产力技能是应用收入、总成本和生产效率。因此「适用」指这项技能自己的那 1 项或 3 项结果检查；不因为执行错误而丢掉检查。其他检查用来测量额外的工作流偏离。这种分组不表示操作上的严重程度相同。作为第二层分解，更宽的最终状态层每项技能有 7 项检查。收入是：应用收入和平台收入、应用和分组的调用次数、两个归一化合计，以及响应结构。生产力是：收入、成本、生产效率、EC2 和 Kubernetes 的资源份额、归一化合计，以及响应结构。其余检查构成轨迹层。成本是每个运行框架记下的、每次运行的美元估计。我们只做描述性汇总，因为供应商定价、缓存记账和模型合同都不是受控实验因子。

7 结果

7.1 跨模型、跨运行框架的结果

表 1 报告全部 240 次自动试验的平均套件通过率。收入组合的偏差最多一分钱，但没有任何配置的平均套件分数达到 100%。因为分数把结果检查和过程检查合在一起，我们用轨迹级诊断、而不是只看汇总通过率，来找出过程偏离。

表 1：自动评测。每个格子 10 次试验的平均通过率（%）$\pm$ 标准差。两种技能（收入 104 条测试；生产力 80 条），两种运行框架，三个模型，两种说明变体。差距 = MD $-$ TXT（百分点）；正数表示 MD 更高。稳健性：R（差距绝对值 $<2$ 个百分点），M（$2$–$8$），S（$>8$）。

#### 过程检查在最终数值之外多发现偏离

把第 6 节定义的窄最终数值结果和所有附加检查分开：240 次里 175 次通过每一项适用的最终数值检查；这 175 次里 162 次（92.6%；Wilson 95% 置信区间 87.7–95.6%）至少有一处评测器发现的额外偏离。全部 120 次收入试验都通过最终收入检查，而且全部 120 次都至少有一处额外偏离。因此只看最终数值，会漏掉全部试验中 67.5% 的偏离。

这个结论对两种错误过滤都稳。33 次有外部错误的运行里，31 次通过全部适用的最终数值检查，而且这 31 次都还留着一处额外偏离。去掉这些运行后是 131/144（91.0%；Wilson 95% 置信区间 85.2–94.6%）。另外，去掉每一次含未恢复错误的运行后是 136/147（92.5%；Wilson 95% 置信区间 87.1–95.8%）。在完整套件上，240 次里 227 次（94.6%；Wilson 95% 置信区间 91.0–96.8%）至少失败一项检查。

在 162 次结果正确但仍被标出的试验里，不互斥的根家族是：数据或数值一致性（106）、缺失阶段或必需工具（66）、允许名单违反（55）、冗余或调用次数违反（43）、范围或过滤器违反（13）、响应格式（2）、工具执行（1）。这些计数说明观察到的缺口不是单一评测器假象，但不分配严重程度，加起来也可以超过 162。因为许多允许名单命中是运行框架的实用工具或模式操作，我们又做了一次敏感度测试，把 no_irrelevant_tools 这项检查整个去掉。162 次结果正确且被标出的运行，仍然各自留着另一项失败检查。

#### 轨迹检查在更宽的最终状态之外仍然多发现偏离

240 次里，164 次通过第 6 节定义的全部 7 项技能特定最终状态检查。其中 151 次（92.1%；Wilson 95% 置信区间 86.9–95.3%）仍至少违反一项轨迹检查；去掉 no_irrelevant_tools 后这个计数不变。按技能看，收入是 109/109，生产力是 42/55（76.4%）。这层分解说明，增量并不只是「大套件对一两项数值」比较出来的假象。它仍是按作者写下的不变量做的分析：被标出的轨迹不一定是已确认的操作缺陷。

#### 依赖归因在描述上压缩失败

一次运行的失败检查中位数是 4（均值 6.34），根失败只有 2 个（均值 2.65），最初要诊断的条目减少 58%。这是基于图的描述性压缩。根标签没有被独立验证成因果解释。收入技能上，领先的根是：暂存利用率的参数不正确（75/120）、使用了评测器允许名单之外的工具（42/120）、缺少数据库回读（24/120）。生产力技能上是：计算工具的应用输入不正确（73/120）、总成本不正确（40/120）、按应用过滤的 Kubernetes 查询（38/120）、按应用过滤的 EC2 查询（31/120）。这些是试验出现次数，不是互斥事件。

#### 说明敏感度取决于运行框架

收入分摊的 MD 与 TXT 分歧最明显。在 Claude Code 上，GPT-5.6-Sol 对变体稳健（$-1.2$ 个百分点），Opus 4.8 和 Sonnet 4.6 敏感或中等敏感（分别 $+9.7$ 和 $+6.3$ 个百分点）。在 Codex 上格局反过来：Sonnet 4.6 变成最稳的模型（$-0.4$ 个百分点），GPT-5.6-Sol 和 Opus 4.8 出现本研究里最大的 TXT 下降（$+12.9$ 和 $+11.8$ 个百分点）。生产力分摊的 MD–TXT 差距更小：Claude Code 上所有模型都是中等敏感（2.1–4.6 个百分点），Codex 上 Sonnet 4.6 和 GPT-5.6-Sol 稳健（$<2$ 个百分点）。自助双重差分区间支持一种随运行框架变化的变体效应：收入 GPT（$-14.0$ 个百分点，95% 置信区间 $[-18.5,-8.9]$），收入 Opus（$-2.1$，$[-4.2,-0.2]$），收入 Sonnet（$+6.6$，$[2.0,11.2]$），生产力 GPT（$+5.6$，$[1.3,10.0]$）。生产力 Opus（$-0.6$，$[-3.1,1.8]$）和 Sonnet（$+2.0$，$[-4.3,6.9]$）的区间含 0，不能下结论。这些结果说明的是配置级敏感度，成对文件并没有把格式和内容分开。因此团队迁移运行框架时，应该把每一份完整的技能说明重新评一遍，不要假设 MD 或 TXT 的效应可以照搬。

#### 运行框架之间的分歧

除了说明敏感度，在收入分摊的 TXT 变体上，Claude Code 在所有模型上都比 Codex 准确率更高（Claude Code 的 TXT：86.8–95.7%；Codex 的 TXT：82.1–92.6%）。生产力分摊在 MD 上两个框架更接近，但 Codex 上 GPT-5.6-Sol 的绝对准确率更低（90.9% 对 99.6%），说明框架行为与技能复杂度有交互。不过，未恢复错误集中在 Codex 运行里（全研究 38 次对 Claude Code 的 5 次；收入技能内 11 次对 4 次），而且全部 20 次生产力 Codex–Sonnet 运行都含有一次。这些对比因此可能部分反映执行可靠性，而不只是听从指令。按格子的干净运行计数见附录 A。因为生产力 Codex–Sonnet 没有剩下干净运行，这个配置的干净执行效应无法从这些数据估计。

#### 记下的执行成本

运行框架遥测报告 240 次运行共 859.34 美元（均值 3.58 美元，中位数 1.23 美元）。这些由记录器估计的观察成本，不是运行框架之间的因果比较。附录 B 报告运行时间、缓存记账和全部 24 个格子。

8 讨论

8.1 模板测试用例是可复用的回归产物

带运行时解析占位符的模板测试用例，对企业智能体技能起着可复用回归产物的作用，类似软件持续集成里的单元测试。每次修订技能说明、部署新模型，或工具接口变化，同一批模板测试用例就对着新版本再跑，并立刻在过程层露出行为回归。能复用，正因为占位符在评测时从实时接口状态解析，而不是写测试时写死。检查「分摊之前调用了数据库回读」的那条测试，对说明 v1.0 和 v1.7 同样有意义，对 Sonnet 4.6、Opus 4.8 和 GPT-5.6-Sol 也一样。去掉一份存档结果里留下的 6 条旧检查之后，全部 24 个模型–框架–变体–技能条件，都在每项技能上使用一套登记过的套件。在存档的实例化里，同一批检查标识覆盖 4 种不同的收入期望值状态和 16 种不同的生产力期望值状态，说明在观察到的参照变化下，运行时解析是成立的。这并没有检验受控的输入或接口演化，也没有证明语义变了以后仍然免维护。附录 A 报告一次事后的过时分析。往前看，报告可以当作合并门：标出新的根，或一个可配置的根数量阈值。但我们没有评测生产上的合并决定，也没有评测修复是否有效。

8.2 评测把说明里的缺口露出来

评测器的标记露出了几处隐含的策略选择：EC2 内存和成本怎么分、数据库回读的顺序、EC2 调用的范围。因此持续评测既可以当回归检测器，也可以当说明完整性工具。我们把 violation 留给打破作者所写不变量的轨迹。领域复核必须把已确认的缺陷、无害的替代做法和说明含糊分开。这些案例的细节在附录 A。

8.3 说明修订的敏感度随运行框架变化

240 次自动评测的一个关键发现是：对成对 MD/TXT 修订的敏感度，可以同时取决于模型、运行框架和技能类型。GPT-5.6-Sol 在 Claude Code 上做收入分摊时对变体稳健（差距 $-1.2$ 个百分点），到了 Codex 上却变成最敏感的模型（$+12.9$ 个百分点）。反过来，Sonnet 4.6 在 Claude Code 上中等敏感（$+6.3$ 个百分点），在 Codex 上对变体稳健（$-0.4$ 个百分点）。自助交互区间在三项收入比较和生产力上的 GPT 比较都不含 0；生产力的 Opus 和 Sonnet 比较仍然不能下结论。这些得到支持的反转表明，一次完整说明修订的效应可以随运行框架改变。因为 MD 和 TXT 在内容上也不一样，本研究不能把这些效应归到格式本身。在一个框架上验证过的说明，迁移之后应该重新评测。

8.4 结果准确并不等于过程符合

计算工具是每一个被报告条件里的操作基线。因此实验既没有估计「把计算封装进工具」的效应，也没有估计不用工具时的算术不稳定。它支持的主张是观察性的：175 次最终数值结果正确的运行里，162 次还有另一处评测器发现的偏离。更保守地说，164 次通过全部 7 项更宽最终状态检查的运行里，151 次仍违反一项轨迹检查。这些偏离跨多个根家族，而且去掉允许名单检查之后仍然在。因此过程级回归测试在选定的最终状态之外增加了覆盖，而每一处偏离在操作上有多严重，仍要看具体领域。

9 结论

240 次试验里，175 次最终数值结果正确的运行中有 162 次还含有另一处评测器发现的偏离。在更宽的最终状态基线下，164 次通过运行里仍有 151 次违反轨迹检查。依赖归因把每次运行平均 6.34 条失败检查减到 2.65 个根。这些结果说明，过程级回归测试补充了最终状态评测；模板复用和随运行框架变化的敏感度，则说明企业技能在演化时需要重新评测。

参考文献

• Akshathala 等（2026）. Sreemaee Akshathala, Bassam Adnan, Mahisha Ramesh, Karthik Vaidhyanathan, Basil Muhammed, and Kannan Parthasarathy. Beyond task completion: An assessment framework for evaluating agentic ai systems. In Proceedings of the 2026 International Workshop on Agentic Engineering, pages 9–17, 2026.

• Barke 等（2026）. Shraddha Barke, Arnav Goyal, Alind Khare, Avaljot Singh, Suman Nath, and Chetan Bansal. Agentrx: Diagnosing ai agent failures from execution trajectories. arXiv preprint arXiv:2602.02475, 2026.

• Bogavelli 等（2025）. Tara Bogavelli, Roshnee Sharma, and Hari Subramani. Agentarch: A comprehensive benchmark to evaluate agent architectures in enterprise. arXiv preprint arXiv:2509.10769, 2025.

• Breck 等（2017）. Eric Breck, Shanqing Cai, Eric Nielsen, Michael Salib, and D Sculley. The ml test score: A rubric for ml production readiness and technical debt reduction. In 2017 IEEE international conference on big data (big data), pages 1123–1132. IEEE, 2017.

• Cemri 等（2026）. Mert Cemri, Melissa Z Pan, Shuyi Yang, Lakshya A Agrawal, Bhavya Chopra, Rishabh Tiwari, Kurt Keutzer, Aditya Parameswaran, Dan Klein, Kannan Ramchandran, et al. Why do multi-agent llm systems fail? Advances in Neural Information Processing Systems, 38, 2026.

• Flynt（2026）. Jeffrey Flynt. Groundeval: A deterministic replacement for llm-as-judge in stateful agent evaluation. arXiv preprint arXiv:2606.22737, 2026.

• Gritta 等（2026）. Milan Gritta, Debjit Paul, Xiaoguang Li, Lifeng Shang, Jun Wang, and Gerasimos Lampouras. Process evaluation for agentic systems. In Findings of the Association for Computational Linguistics: EACL 2026, pages 2678–2692, 2026.

• Guo 等（2026）. Dongxin Guo, Jikun Wu, and Siu Ming Yiu. Agenteval: Dag-structured step-level evaluation for agentic workflows with error propagation tracking. arXiv preprint arXiv:2604.23581, 2026.

• Huang 等（2025）. Dong Huang, Mingzhe Du, Jie M Zhang, Zheng Lin, Meng Luo, Qianru Zhang, and See-Kiong Ng. Nexus: Execution-grounded multi-agent test oracle synthesis. arXiv preprint arXiv:2510.26423, 2025.

• Lightman 等（2024）. Hunter Lightman, Vineet Kosaraju, Yuri Burda, Harrison Edwards, Bowen Baker, Teddy Lee, Jan Leike, John Schulman, Ilya Sutskever, and Karl Cobbe. Let’s verify step by step. In International Conference on Learning Representations, 2024.

• Wang 等（2024）. Peiyi Wang, Lei Li, Liang Chen, Zefan Cai, Dawei Zhu, Binghuai Lin, Yunbo Cao, Lingpeng Kong, Qi Liu, Tianyu Liu, et al. Large language models are not fair evaluators. In Proceedings of the 62nd annual meeting of the association for computational linguistics (volume 1: Long papers), pages 9440–9450, 2024.

• Zheng 等（2023）. Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric Xing, et al. Judging llm-as-a-judge with mt-bench and chatbot arena. Advances in neural information processing systems, 36:46595–46623, 2023.

附录 A 限制

本研究评测一个企业系统和两种相关技能。生产力在收入之上加了外部成本来源、成本分摊、NULL 处理和另一条持久化路径。推广到其他技能类型、工具套件或非定量输出，仍然是开放的。

每个格子 10 次试验，足以谈论集中趋势和相对排序，但对小效应的统计功效有限。自助区间是探索性的。六项生产力模型比较里有两项，没有确立说明与运行框架的交互。

MD 和 TXT 是捆在一起的说明变体，不是一次受控的格式干预。它们在语法、长度、细节上不同，有时语义也不同。最明显的是，生产力的 TXT 增加了排除、归一化、合并成本查询和 CSV 导出要求。因此观察到的差距不能在因果上单独归到文件格式或压缩。

汇总的套件分数把不同质的结果检查和过程检查加在一起。它不编码失败的严重程度，依赖相连的检查在统计上也不独立。因此在把小的分数差解释成操作含义之前，需要按类别的根失败率。

轨迹里有执行噪声：240 次里 83 次至少记下一次工具或运行框架错误。外部错误和未恢复错误是重叠的，不是嵌套的：175 次两者都没有，32 次有未恢复错误但没有外部错误，22 次有外部错误但没有未恢复错误，11 次两者都有。因此 33 次有外部错误，43 次有未恢复错误。外部错误按框架几乎平衡（Claude Code 16；Codex 17），但格子之间不均匀。未恢复错误集中在 Codex（Claude Code 5；Codex 38）。框架和变体的对比因此可能部分反映基础设施和执行可靠性。我们保留全部运行，作为意向评测分析。以后的工作应预先登记重试和排除规则，并报告格子级的干净运行对比。汇总的未恢复错误敏感度不能代替这种格子级分析：去掉这些运行会移除全部 20 次生产力 Codex–Sonnet 观察，因此不能验证这个配置或它的交互估计。

表 2：每个 10 次试验格子里的干净运行数。一次运行在既没有外部错误、也没有未恢复错误时算干净。干净运行为 0 的格子，在干净执行分析下无法估计。

频繁的 EC2 内存不一致不是说明修订引入的。工具可以在无法做站得住的按应用拆分时，返回主机或 JVM 内存，而作者写下的不变量期望是 0。把这条测试写出来，露出了一个隐含的策略选择：按应用拆分不可能时，该存什么？原始结果因此指出说明缺口，但本身不能证明 0 是唯一正确的值。生产力参照期望 EC2 成本为 0、有些执行却分出非零 Cloudability 成本时，也是同一问题。数据库回读顺序和 EC2 调用范围上也反复出现这个模式。每一种情形里，把期望行为写明确，都把技能说明没有写明的假设露了出来。这个区分允许多条有效轨迹，而不是把一条标准轨迹等同于操作上的正确。

评测器是规范性的：240 次里有 71 次，它的「无关工具」检查是根失败，有时打到的是运行框架实用工具、模式初始化，或危害尚未确立的命名空间别名。顺序检查，以及把 EC2 内存或成本的零值写进检查，也编码了工作流策略。去掉允许名单检查后 162/175 不变，说明这个问题解释不了标题上的缺口。但仍然需要领域复核、等价轨迹测试和严重程度标签，才能把有害行为和无害行为分开。

实时接口参照可能在执行和推迟的评测之间漂移，所以不可变的响应快照会加强参照完整性。我们这次有针对性的、两位作者的审计，在 60 条随机抽取的裁判案例里有 57 条一致（95%）。这不应理解成裁判的一般准确率：样本是按裁决抽的，不是按运行抽的；检查类型上的覆盖没有分层；复核者是作者而不是外部标注者；审计也没有单独刻画只针对失败的补救路径。计算器支持的算术降低了语义判断风险，但没有去掉它。而且裁判模型（Claude Sonnet 4.6）本身是被评测的模型之一，所以相关偏差或自我偏好可能影响它对自己轨迹的判断。手工写的不变量和依赖图，会随着工具语义演化而需要维护。实验比较的是固定配置，不是一次纵向的接口或模型升级，所以在真实演化下能否持久，还没有测。两种技能也都只用一个组合、一个收入值和各自一个日期窗口。重复的随机试验并不提供环境输入的多样性。在一次事后的过时模拟里，若把生产力期望值冻在众数上，120 次生产力运行里有 80 次至少有一个值落在登记容差之外；观察到的收入变化则仍在容差内。这个反事实和实例化分析支持的是：在观察到的参照变化下做运行时解析，而不是受控演化。最后，框架诊断失败，但不修复失败。

成本分析用的是运行框架记下的美元估计，不是对过账的供应商发票。定价规则、缓存记账和供应商合同可以在框架和模型之间不同，异常贵的重试会造成重尾。因此成本结果刻画的是这 240 次执行，不应理解成某个运行框架固有的价格优势。

附录 B 成本与运行时间

全部 240 次运行上，运行框架遥测报告总成本 859.34 美元：均值 3.58 美元（标准差 4.50），中位数 1.23 美元，范围是每次运行 0.45–30.23 美元。在平衡设计下，Claude Code 平均 1.04 美元，Codex 平均 6.12 美元。在每项技能内合并变体后，Codex 相对 Claude Code 的平均成本比，Opus 是 5.9–6.0 倍，Sonnet 是 8.8–10.2 倍，GPT 是 1.0–1.4 倍。对 Claude 模型，缓存读取词元占 Claude Code 所记词元的 90.7–92.9%，在 Codex 上是 0%。这与「缓存是主要记账差异」一致。这些是记录器估计的观察成本，不是发票核过的因果效应。Claude Code / Codex 的平均运行时间（秒）是：GPT 416/238，Opus 254/450，Sonnet 284/344。Codex–Opus 的均值被一次 7,152 秒的运行拉高（中位数 241 秒）。

表 3 把平衡设计在两种技能和两种说明变体上汇总（每个框架–模型格子 $n=40$）。运行时间和成本一起报告，因为重试和长时间失败会影响两个量。

表 3：记下的成本、运行时间和缓存读取占比，在两种技能和两种变体上汇总（每行 $n=40$）。运行时间是均值/中位数秒数。

表 4 报告当前 240 次运行设计里的每一个格子。每一项是 10 次试验上记下的、每次运行美元成本的均值 $\pm$ 样本标准差。没有任何一次运行缺少成本遥测，也没有零成本。

表 4：运行框架记下的每次运行成本，单位美元（均值 $\pm$ 标准差；每格 $n=10$）。

Ngoc Phuoc An Vo, Aarya Doshi, Vadim Sheinin，Continuous Process-Level Evaluation for Evolving Enterprise AI Agent Skills，2026-10-01，https://arxiv.org/abs/2610.01833，CC BY 4.0