AEVAL：把智能体技能测试从凭印象改成可重复

AEVAL：把智能体技能工作流的测试从凭印象改成可重复

Tejas Singh Anand（NVIDIA；滑铁卢大学），Yuet Ying Christina Wang（NVIDIA），Wanting Jiang（NVIDIA），Steve Masson（NVIDIA），Tian Zheng（NVIDIA），Bingjie Zhou（NVIDIA）

预印本，2026-07-16

Tejas Singh Anand 在 NVIDIA 实习期间参与了这项工作。

摘要

现在的智能体系统越来越依赖技能（skill）：可以安装的自然语言和代码包，用来教大语言模型智能体完成一项领域任务。技能仓库变大以后，开发者需要在每一次修改上都拿到自动、可信的质量信号。但今天的评测大多凭印象：开发者让智能体「试一下这个技能」，看一轮演示，再主观判断它能不能用。这样既不能在多次运行之间复现，也不能在版本之间比较，更撑不住多技能市场：一次回归可以悄悄弄坏几十条下游工作流。

我们提出 AEVAL（Agentic Evaluation，智能体评测）。它是接进持续集成（CI，代码一变就自动跑测试的流水线）的框架，用一条确定、可复现的测试流水线取代凭印象的做法。每一次技能变更都当作一次被触发的测试。流水线按开发者声明的评测契约 eval.config，在自动执行器里跑这个技能，并交出一份有证据的结构化质量信号，供下游 CI 决定怎么走。

关键设计是把执行器和评分器在结构上分开。这是为了挡住一种隐蔽但常见的失败：智能体在执行中悄悄改好自己的输出，再把改过的结果判成通过。我们称这种失败为自校正偏差（self-correction bias）。

贡献有四项。（i）一套由变更触发的确定性技能评测协议，包含每个技能的评测契约和每次运行的产物模式。（ii）把自校正偏差形式化，说明它是幼稚智能体评测器的一种独立失败模式。（iii）执行器与评分器的结构分离，加上首次尝试评分规则和显式的自校正记录。（iv）分层、必须有证据的修复建议：LV1 是因果修复，LV2 是质量改进，以行内合并请求（MR，把改动合进主干前的审查请求）评论发出。

我们在与具体运行时无关的接口上验证了这套框架，并接到多个常用智能体 SDK。在一套生产智能体栈里的真实技能上，协议把虚假的 100% 通过率变成可复现的首次尝试 FAIL，并留下执行器每一次修补的可审计记录，从而让下游工作流能可靠地决定继续还是停止。

关键词：智能体人工智能，评测，不确定性，自校正偏差，共形式保证，大语言模型智能体

1 引言

智能体编程系统越来越把领域能力放到技能外面：小型、有版本的包，里面通常有一份自然语言说明（一般是 SKILL.md）、配套脚本和配置（Anthropic，2025）。智能体运行时从库里发现一个技能，按它的说明去做任务。在生产栈里，技能失败就是产品失败：一个技能文件的回归，会悄悄弄坏所有依赖它的下游工作流。

尽管如此，今天对技能的评测几乎全凭印象。常见做法是开发者打开一次交互会话，贴一条有代表性的提示，看一轮演示，再主观判断这个技能「还能不能用」。这个信号不正式、不能复现、也不能跨版本比较：连续两次运行可能走不同代码路径、给出不同输出、引出不同判断。技能市场长到几十或几百个产物时，这种做法扩不了，静默回归会在两次发布之间堆积。我们需要的，是软件工程几十年前已经走过的那一步：从凭印象的手工测试，变成由变更触发、输出是可复现产物而不是人的印象的确定测试流水线。

本文介绍的 AEVAL 就是把这一步用到智能体技能上。AEVAL 把每一次技能变更当成一次 CI 触发的测试。技能带一份明确的评测契约 eval.config，写明测试提示、期望结果和所需凭据。框架把改过的技能装进干净会话，用自动智能体运行时按契约执行，再交出机器可读的质量信号：每条断言的通过或失败及所引证据、首次尝试通过率、对基准统计的分析，以及分层修复建议。这个信号可以跨运行复现，可以跨 MR 比较，下游 CI 不用人来解释就能用。

实际上，eval.config 变成一份持久的声明式测试套件。开发者在创建技能时把测试工作流写一次，之后每一次推送都自动重放完整的安装、执行、评分、建议修复循环，中间没有人。不必再打开交互式编程智能体、重新加载项目上下文、或每次重新提供凭据。套件是签进仓库的产物，任何推送或手工 CI 触发都会从头到尾重放。评分失败时，AEVAL 还充当开发者的自动审查者：它把修复建议提交到正好导致失败的源码行上，原作者点一下就能应用，并重新触发流水线。

在随机的智能体上面建确定流水线，会继承一个可靠性问题，这也是本文的核心技术贡献。如果同一个智能体既执行又评分，信号会系统性地偏乐观。大语言模型智能体被训练成从错误里恢复（Saunders 等，2022；Bai 等，2022），会悄悄重试、改配置、或就地修补技能，直到有东西成功，然后如实报告它自己造出来的世界状态。这样测到的是智能体的调试能力，不是技能质量。这和 LLM-as-judge（用大语言模型给输出打分）里观察到的自我偏好相近（Panickssery 等，2024；Zheng 等，2023）。我们在第 3 节形式化自校正偏差，并用执行器与评分器的结构分离来防止它（第 4.3 节）。没有这层分离，确定流水线给出的是可复现的噪声；有了它，下游的不确定性量化方法（Kadavath 等，2022；Lin 等，2022；Angelopoulos 等，2023）才有可靠信号可用。

贡献

我们有四项贡献。

1. 确定性技能测试（第 4 节和第 6 节）：一套由变更触发的智能体技能评测协议，包含每个技能的评测契约、每次运行的产物模式，以及与具体智能体运行时无关的执行器接口。它用可复现的 CI 流水线取代凭印象的手工评测。

2. 自校正偏差（第 3 节）：我们把智能体评测器的一种独立失败模式形式化，并说明它来自结构，而不是来自某一个模型。

3. 结构分离与首次尝试评分（第 4.3 节）：协议把评分器限制在一组受约束的信息上（输出加上执行记录），使它不能参与纠正动作。再加上首次尝试评分规则和显式的自校正跟踪，质量信号针对的是发出去的技能，而不是被修补之后的技能。

4. 有依据、分层、可一键应用到 MR 的建议（第 5 节）：每一条建议修复都必须引用一条失败断言，或一条被跟踪的自校正记录。LV1 是对失败有因果作用的修复，LV2 是评分器标出的改进，用来挡住投机性的「最好再加一点」。每条建议以 GitLab MR 行内评论发出，并带「应用建议」的差异。AEVAL 发现缺陷时，也给出一份经过实证检验的补丁，原开发者点一下就能用，在同一个合并请求里关上测试、失败、修复的循环，使框架成为技能作者的自动审查者。

2 背景与相关工作

智能体评测框架

现有平台落在三层之一。提示与回答平台（LangSmith（LangChain，2025）、Braintrust（Braintrust，2025）、Promptfoo（promptfoo，2025））按断言给模型输出打分；它们不安装、也不执行可部署的技能产物。能力基准（OpenAI Evals（OpenAI，2024）、AgentBench（Liu 等，2024）、SWE-bench（Jimenez 等，2023））在固定数据集上评测模型的一般解题能力；不能对准开发者在某个 MR 里改过的技能。沙箱智能体评测（Harbor Framework（Harbor，2025））在容器里让智能体做预定义任务；它测的是智能体，不是技能产物，也不会再拉起一个结构上独立的评测器。

用大语言模型当裁判与自我评测

LLM-as-judge 协议（Zheng 等，2023）和自我评测流水线（Saunders 等，2022；Ren 等，2023）已知会有自我偏好（Panickssery 等，2024）和校准问题（Kadavath 等，2022；Lin 等，2022）。这些工作研究的是对模型输出的判断。我们的设定不同：我们研究的是，在一个评测过程中会主动改世界的执行器之下，如何判断一个技能产物的行为。

智能体的不确定性量化

共形预测（conformal prediction，在可交换性下给出无分布覆盖保证的方法；Vovk 等，2005；Angelopoulos 与 Bates，2023）和预测驱动推断（Angelopoulos 等，2023）在可交换性下提供严格覆盖。我们的协议是互补的：我们不和共形保证竞争，而是准备一份可靠的地面真值信号，供这类方法使用。如果评测没有去掉自校正偏差，下游的共形或序贯程序吃到的是被污染的标签，名义上的保证就会塌掉。

3 自校正偏差问题

设 $s$ 为一个技能，$x$ 为开发者在 eval.config 里提供的评测提示，$A$ 为一个自主智能体。幼稚评测器在 $(s,x)$ 上运行 $A$，得到终态 $y$，再给出 $\hat{q}(s)\in\{0,1\}$，表示 $s$ 是否可用。我们观察到，$A$ 的执行轨迹

$$\tau=(a_{1},o_{1},a_{2},o_{2},\dots,a_{T},o_{T})$$

通常不是对 $s$ 的只读探测。因为 $A$ 有工具（编辑、bash、写入），动作 $a_{t}$ 可能修改技能本身或旁边的配置。令 $\Delta(\tau)$ 表示 $\tau$ 期间对技能文件执行的编辑集合。定义

$$q^{\star}(s)=\mathbb{I}[s\text{ 在未修改的首次尝试中可用}]$$

$$\hat{q}_{\text{naive}}(s)=\mathbb{I}[y\text{ 满足 }x]$$

失败模式是：只要 $A$ 能靠任意 $\Delta(\tau)\neq\emptyset$ 恢复过来，就有 $\hat{q}_{\text{naive}}(s)=1$，即便 $q^{\star}(s)=0$。这是结构性的：一个擅长调试的智能体，会把任何「还能修」而不是「已经坏死」的技能 $s$ 里的缺陷藏起来。

我们在自己的部署里看到了这一点。那是一个智能体优先的产品：技能由开发者编写，到达终端用户之前没有中间打包步骤。在这个设定里，开发者每一次推送技能本身就是生产事件，所以被自校正评测器掩盖的回归会直接发出去。有一次这样的推送，首次运行因缺少配置项而失败；智能体就地悄悄补上技能，再跑一次，并对着它在看到改正后的输出之后自己写下的断言，给出 100% 通过。这正是上面的形式模型所预言的偏差。

有两股设计力量造成这一点。第一，身份相同：同一个智能体既跑又评，它没有动机标出自己的补丁。第二，事后断言：看过输出之后再写的断言，会暗中贴合智能体已经生成的输出。要去掉偏差，两头都得处理。

4 方法

图 1：AEVAL 流水线。一次 MR 触发 CI，CI 发现变更过的技能并调用评测器。执行器跑四阶段工作流；评分器是单独的子智能体，只能看到输出和记录；建议被发回 MR。

AEVAL 是由技能目录上的合并请求触发的五阶段流水线（图 1）。核心流水线是：（1）检查（Examine），（2）安装（Install），（3）使用（Use），（4）评测（Evaluate），（5）建议（Suggest）。有特色的设计在第 3 到第 5 阶段。

4.1 由技能定义的评测契约

每个技能可以带一份与 SKILL.md 放在一起的 eval.config。契约按测试用例写明：一条自然语言提示、一个期望结果、一份所需凭据列表。evals 数组支持多个相互独立的用例，每个用例在隔离的 SDK 会话里执行。三层回退（按技能、按名称、通用）保证即使没有显式配置，每个技能也能测。把测试说明和技能放在一起，让每个产物声明自己的质量标准，评测契约进入 MR 的差异，而不是留在集中的基准登记处。

4.2 禁止模拟输出

执行器提示的第 3 阶段有一条硬规则：不许模拟输出。如果命令失败、服务不可达、或工作流出错，这次失败要作为真实测试结果记进该用例的记录 $\tau$。智能体可以自校正，但不能编造日志、合成结果、或给缺失输出占位。这条规则靠指令而不是沙箱执行，但我们发现它必不可少：没有它，GPU 集群不可达时，智能体经常造出合成的训练日志，再把这些日志判成通过。

4.3 把执行和评分分开

第 4 阶段给技能评分。核心约束是：评分器是单独的子智能体，按固定协议（agents/grader.md）拉起，信息集限制为

$$\mathcal{I}_{\text{grader}}=\{x,\tau,\mathcal{O},\mathcal{A}\},$$

其中 $x$ 是测试提示，$\tau$ 是只读的执行记录，$\mathcal{O}$ 是输出文件集合，$\mathcal{A}$ 是执行前写好的断言集合。关键是，评分器不参与执行，也没有能改 $\mathcal{O}$ 或 $s$ 的工具。

#### 断言先于输出

$\mathcal{A}$ 在执行器看到任何输出之前写好，只依据技能的 SKILL.md 和声明的期望结果。这防止「看过结果再写断言」的贴合。

#### 首次尝试评分规则

评分器按首次尝试轨迹评判每条 $a\in\mathcal{A}$。如果 $\tau$ 里有任何自校正编辑 $\Delta(\tau)\neq\emptyset$，而且某条断言的成功在因果上依赖这次编辑，那么无论后来是否成功，该断言都标 FAIL。评分器写一份结构化的 grading.json，包含：

• 每条断言的通过或失败，并引用 $\tau$ 或 $\mathcal{O}$ 里的证据；
• self_correction 一节，列出首次尝试错误、已应用的改动、以及受影响的断言；
• claims 一节，抽出过程和质量方面的主张，并逐条对照 $\mathcal{O}$ 核验。

这套拆分让「技能本身可用」和「智能体先修好技能然后才可用」的区别变得可审计、机器可读。下游 CI 只用首次尝试通过率作为门禁信号。

4.4 独立分析轮

第二个子智能体（analyzer）接收汇总后的基准，把自由形式的观察写进 analysis_notes.json：没有区分力的断言、方差很高的不稳定断言、词元或延迟的离群点。它看不到技能源码；它的角色只是描述这一次运行分布。

5 有依据的分层修复建议

当 $\hat{q}^{\star}(s)=0$ 时，AEVAL 发出给人在原 MR 上审查的修复建议。两条设计规则让这个通道的信号保持密。

#### 必须有证据

每条建议必须带 grounded_in 字段，引用（a）grading.json 里一条失败断言的原文，或（b）self_correction.changes_made 里的一条具体记录。没有依据引用的建议在提示层就被拒绝。智能体被要求：如果没有失败、也不需要校正，就必须给出空的建议集。这排除了我们在更早版本里看到的投机性「可以考虑再加……」：同一次 MR 上的两次运行，建议集几乎不重叠。

#### 分层

• LV1（严重）：对首次尝试失败有因果作用的修复。必须追溯到一条 FAILED 断言，或一条 self_correction 记录。
• LV2（改进）：评分器在 eval_feedback.suggestions 里标成能提高质量或稳健性、但没有造成硬失败的修复。

分层决定路由：LV1 建议挡住合并，LV2 建议只是参考。这和选择性预测式的校准一致，报告的是「我们有多确信必须采取行动」（Ren 等，2023）。

#### 以 MR 建议提交的方式交付

每条 LV1 或 LV2 对应技能目录里的一行源码，通过 GitLab Discussions API 发成行内建议评论。开发者看到一份差异和一个「应用建议」按钮。落在 MR 差异范围之外的修复，收进一条合并的后备评论，并附上可复制的提示。循环因此关上：AEVAL 不只发现失败，还给出经过实证检验、开发者点一下就能用的补丁。

6 系统与部署

框架分成三部分发布。（i）一个 Python 套件，通过通用的流式执行接口驱动自动智能体运行时（初始提示、结构化工具使用事件、逐事件的记录捕获）。（ii）一份捆绑的评测技能（含评分器、分析器和比较器子智能体定义），注入执行器的工作目录集合。（iii）一份可复用的 GitLab CI 模板，带一条可直接 include 的指令。CI 模板用 git diff 发现变更过的技能，按技能运行评测器，把每个用例的摘要发成 MR 备注，并调用建议发布器。

#### 与智能体运行时无关

套件故意把智能体 SDK 抽象掉。执行器接口只规定技能执行所需要的东西：提示输入、工作目录注入、结构化工具使用事件、记录流。任何常用智能体 SDK 都可以接上。我们在内部对多种广泛使用的智能体编程运行时验证过，包括 Claude 风格、Codex 风格和 OpenCode 风格的智能体。按运行时分别出报告，能露出单一运行时评测看不到的兼容问题，例如工具如何调用、工作目录如何挂载、多轮状态如何保存。同一份技能和同一份 eval.config 产生可比较的、按运行时分开的产物树，从而可以做跨运行时的回归跟踪。框架不绑定某一个 SDK，公开部署把运行时当成可配置后端，而不是固定依赖。

#### 产物模式

每次运行产生一棵 JSON 和 Markdown 产物树：transcript.md、eval_metadata.json、grading.json、benchmark.json、analysis_notes.json、fix_suggestions.json。多用例运行另外产生合并的 multi_eval_report.json 和给人读的摘要。模式是稳定的，支持下游回归跟踪：每次推送都可以和最近一次已知良好的基线比较，标出通过率差值和新增的失败断言。

#### 从单个技能到整条工作流

eval.config 接受 evals 数组，里面是相互独立的测试用例（例如模型开发工作流里的训练、推理和评测阶段）。每个用例在自己的隔离会话里执行，并独立评分。因此框架不只适合单提示技能，也适合开发者否则只能手工重新编排的多步工作流。再加上上面的持久套件：开发者不必每次重新打开交互式智能体、粘贴项目上下文、提供凭据并描述工作流，而是在 eval.config 里把工作流编码一次，得到一个自动的质量保证与实验底座，在每次推送或手工 CI 触发时重放同一条安装、执行、评分、建议修复循环。描述实验的投入在创建技能时付一次，之后每一次变更都收回来；第 4.3 节的结构分离则让每一次重放的质量信号保持诚实。

7 实证评测

我们在一个生产技能市场上评测，技能覆盖模型训练、数据生成、推理和文档生成。这里报告用来说明偏差和协议行为的定性发现；完整的定量研究留到扩展版本。

#### 案例：故意降级的分割技能

我们评测一个分割技能。它的 SKILL.md 写的动作名是 segment_train、segment_evaluate、segment_inference，和目标容器的真实动作名 train、evaluate、inference 对不上。在幼稚的智能体评测器下，第一次调用返回 KeyError；智能体在它生成的运行脚本里改了动作名，然后成功。幼稚评分是 100% 通过。

按第 4 节的协议，同一次运行在改正后的输出上得到 10/10 的断言通过率，但记录了 self_correction.was_needed = true，以及 3 个首次尝试错误和 2 处已应用的改动。「技能配置的动作名不经修改就能用」和「所有配置文件彼此一致」这类断言被标成 FAIL，并附有引用的证据。报给 CI 的首次尝试通过率因此严格低于终态通过率。对着 MR 发出的 LV1 建议精确指出动作名不匹配，并带「应用建议」的差异。

#### 有依据建议的稳定性

在要求 grounded_in 之前，同一次 MR 的重复运行会给出互不重叠的建议集。一次运行生成 5 条「为了一致」的建议，第二次运行生成 7 条大体不同的建议。加上这条规则之后，重复运行收敛到同一组有因果依据的 LV1；LV2 仍略有波动，但它只是参考。这正是下游共形或序贯程序要消费一个信号时所需要的稳定性。

#### 禁止模拟输出

有一个技能的下游 GPU 集群间歇不可达。更早的提示版本会生成一整套合成日志文件，并把它们判成通过。加上模拟禁令之后，智能体改为记录连通性失败，以 status = error 结束该用例，并留下明确的记录条目。下游 CI 于是能把技能缺陷和环境失败分开：前者挡住合并，后者触发重试。

7.1 跨运行时校准：每个智能体评分器的行为

因为执行器接口与运行时无关（第 6 节），同一份技能和同一份 eval.config 可以跑过不同的智能体编程后端，产物可以直接比较。我们在一个生产技能上做一组匹配运行。这个技能编排多个子技能，完成智能微调工作流。两个后端来自不同家族：后端 A 是 Claude 家族智能体，后端 B 是 GPT 家族智能体。每个后端对同一提示和同一配置调用多次，以便取出每次运行的量，而不是单次印象。表 1 报告每次运行的五个具体指标。

表 1：同一技能、同一 eval.config 上两个智能体后端的匹配运行。因果占比（causal share）= $\text{LV1}/(\text{LV1}+\text{LV2})$，即评分器标成阻断合并、而不是仅供参考的修复建议所占比例。它是每次运行的一个标量，落在 $[0,1]$，用来在评分器按声明的 expected_outcome 写出的、长度不一的断言列表之间做归一。记录的自校正次数，是执行器在首次尝试轨迹中就地打上的技能补丁条数（后端 A 显式记录；后端 B 不记录，标为「—」）。协议忠实度是这次运行是否遵守锁定的输出模板契约；后端 A 有一次运行悄悄偏离了它。通过率以通过/总数报告，不在后端之间直接比较，因为每个评分器写自己的断言列表。平均输入词元约为后端 A 的 8.5M（97% 命中缓存）和后端 B 的 12.4M（95% 命中缓存）。有缓存时，每发现一条阻断合并的问题，边际成本大约是几十万未缓存词元。

#### 通过率不是能分开两者的信号

两个后端都把工作流从头做到尾，裁决都是 PASS。原始通过率两边都落在 70–89%，区间重叠。单看通过率分不开两个评分器。部分原因是每个实例都按声明的期望结果写自己的断言列表（分母从 10 到 18），所以 M/N 不是严格的同一把尺子。

#### 因果占比把它们干净地分开

有区分力的量是因果占比：修复建议里被标成阻断合并（LV1）而不是参考（LV2）的比例。后端 A 的平均因果占比是 0.41；后端 B 是 0.82。在 $[0,1]$ 刻度上，分界差距是 0.41。看底层建议，两个后端指出的根因相同（命令行旗标不匹配、root 拥有的输出、配置模式缺口）；它们不同意其中哪些算阻断合并。后端 B 把配置一致性发现提升为 LV1，后端 A 把它们留在 LV2。两者都不是错的，因为 LV1 的定义（「对首次尝试失败有因果作用」）在发现与断言失败因果相邻、但不是直接原因时，两种读法都允许。分歧仍然大，在每个后端的多次运行里可复现，而且有后果，因为 LV1 是合并门禁那一层。

#### 直接测量自校正活动

后端 A 显式记录执行器打上的每一次就地补丁。在它的短工作流运行里，我们分别看到 5 次和 6 次自校正。这是第 3 节所形式化的偏差模式的直接实证。如果没有第 4 节的结构分离，这些自校正都会被悄悄吸收进一份干净的 PASS。

#### 协议忠实度本身就是可测的失败模式

框架要求执行器发出锁定的输出模板（提示块、结构化裁决、$\langle\text{details}\rangle$ 平衡、分层建议的拆分）。在这组匹配运行里，后端 A 有一次运行在同一条提示上悄悄换成了自己的格式，而它的姊妹运行输出是干净的；另外五次运行格式合规。这是「智能体当评测器」的失败模式，框架刚性的产物模式让我们用简单的结构检查就能发现。它有后果：下游不确定性量化程序如果吃到非规范产物，会悄悄丢掉或解析错。因此表 1 的忠实度列不是排版细节，而是每次运行的可靠性指标。

#### 成本主要由缓存决定

提示缓存命中率约为 95–97% 时，每次推送重放协议的边际词元成本，大约比总数字所暗示的低一个数量级。因此框架便宜到可以在技能的每一次变更上重跑，这是第 6 节持久套件所需要的前提。

合在一起，这就是智能体系统的统计框架必须容纳的评测器不确定性：同样的输入、同样的协议、两个评分器、对严重程度的系统性分歧，以及偶尔一次框架自己能发现的协议忠实度违反。这些都可以写成机器可读的、每次运行的标量（因果占比、自校正次数、忠实度布尔值）。我们认为这就是框架在结构上的验证：它的信号定义得足够清楚，让独立评分器跑过之后露出的是干净、可复现的校准缺口，而不是无法比较的噪声。这正是下游共形或序贯程序需要的输入。

8 讨论

#### 保证的范围

我们的协议不提供共形意义上的概率覆盖保证。它提供的是结构保证：评分器报告的信号是首次尝试执行的函数，而不是校正之后状态的函数。再加上观察前写好的断言、以及不参与执行的评分器，就得到可复现的质量信号，可以作为统计方法的地面真值输入。

#### LV1 与 LV2 的校准

LV1 和 LV2 的边界，目前由评分器判断一条发现是追溯到断言失败，还是追溯到 eval_feedback.suggestions 中的一条。我们用第 7.1 节引入的、每次运行的因果占比概括这条边界。它把划分收成 $[0,1]$ 上的一个标量，可以在分母不同的运行之间比较。一个自然的扩展，是在历史 MR 结局上做共形校准：学一个因果占比阈值，使得仅供参考的 MR 里，只有有界比例会在后续补丁上变成阻断合并。跨运行时研究表明，划分也取决于运行时：不同家族的后端把相同根因分到相反的层，平均因果占比相差 0.41。因此单一的全局阈值会欠拟合；需要按运行时的阈值，或在运行时上边际化的严重度分布。两者都留给以后的工作。

#### 限制

禁止模拟输出是靠指令执行的；足够强的智能体原则上可以违反它。我们目前的缓解是记录审计和评分器的独立核验。更干净的结构防御，是把执行器的文件系统写范围沙箱化，排除原始技能目录。首次尝试规则也依赖评分器能否在 $\tau$ 里正确认出因果上的自校正；复杂的多步校正可能被归错。最后，按智能体分别评测能露出兼容问题，但计算成本随运行时个数线性增加。

#### 与共形预测的关系

我们的协议与无分布不确定性量化正交，但相容。结构分离产生可靠的二值标签；共形预测和预测驱动推断（Angelopoulos 等，2023）消费这类标签，在可交换性假设下提供覆盖。我们把 AEVAL 看成可靠智能体工作流里、上游负责生成标签的部件。

9 结论

对智能体技能的评测仍由凭印象的做法主导：开发者跑一次演示，看一个智能体，再主观判断技能能不能用。这既不能复现，也不能比较，也撑不住多技能市场。我们提出 AEVAL，一个接进 CI 的框架，用由变更触发的确定测试流水线取代这种做法：技能声明评测契约，每一次变更触发一次自动执行器运行，运行交出有证据的结构化质量信号。流水线靠执行器与评分器的结构分离来挡住自校正偏差，靠带显式自校正跟踪的首次尝试评分规则，以及以 MR 行内评论交付的、有证据的分层修复建议。它部署在一个生产技能市场里，并在多个常用智能体运行时上验证。协议把自我兑现的 100% 通过信号变成可审计的首次尝试质量信号，并给出开发者点一下就能用的修复。我们把确定性技能测试，以及作为其核心可靠性成分的结构分离，看成对智能体工作流做统计上严格的监测和停止的基础部件。

参考文献

• Angelopoulos 与 Bates（2023）. Angelopoulos, A. N. and Bates, S. A gentle introduction to conformal prediction and distribution-free uncertainty quantification. Foundations and Trends in Machine Learning, 16(4):494–591, 2023.

• Angelopoulos 等（2023）. Angelopoulos, A. N., Bates, S., Fannjiang, C., Jordan, M. I., and Zrnic, T. Prediction-powered inference. Science, 382(6671):669–674, 2023.

• Anthropic（2025）. Anthropic. Agent skills: Progressive disclosure for claude agents. Anthropic Documentation, 2025. Accessed 2026-04-23.

• Bai 等（2022）. Bai, Y., Kadavath, S., Kundu, S., Askell, A., Kernion, J., Jones, A., et al. Constitutional AI: Harmlessness from AI feedback. In arXiv preprint arXiv:2212.08073, 2022.

• Braintrust（2025）. Braintrust. Braintrust: The enterprise-grade stack for building AI products. https://www.braintrust.dev/, 2025.

• Harbor（2025）. Harbor. Harbor framework: Containerized evaluation for AI agents. https://www.harborframework.com/, 2025.

• Jimenez 等（2023）. Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., and Narasimhan, K. SWE-bench: Can language models resolve real-world GitHub issues? arXiv preprint arXiv:2310.06770, 2023.

• Kadavath 等（2022）. Kadavath, S., Conerly, T., Askell, A., Henighan, T., Drain, D., Perez, E., Schiefer, N., Hatfield-Dodds, Z., DasSarma, N., Tran-Johnson, E., Johnston, S., El-Showk, S., Jones, A., Elhage, N., Hume, T., Chen, A., Bai, Y., Bowman, S., Fort, S., Ganguli, D., Hernandez, D., Jacobson, J., Kernion, J., Kravec, S., Lovitt, L., Ndousse, K., Olsson, C., Ringer, S., Amodei, D., Brown, T., Clark, J., Joseph, N., Mann, B., McCandlish, S., Olah, C., and Kaplan, J. Language models (mostly) know what they know. In arXiv preprint arXiv:2207.05221, 2022.

• LangChain（2025）. LangChain. LangSmith evaluation. https://www.langchain.com/langsmith, 2025.

• Lin 等（2022）. Lin, S., Hilton, J., and Evans, O. Teaching models to express their uncertainty in words. In Transactions on Machine Learning Research, 2022.

• Liu 等（2024）. Liu, X., Yu, H., Zhang, H., Xu, Y., Lei, X., Lai, H., Gu, Y., Ding, H., Men, K., Yang, K., Zhang, S., Deng, X., Zeng, A., Du, Z., Zhang, C., Shen, S., Zhang, T., Su, Y., Sun, H., Huang, M., Dong, Y., and Tang, J. AgentBench: Evaluating LLMs as agents. In International Conference on Learning Representations, 2024.

• OpenAI（2024）. OpenAI. OpenAI evals: A framework for evaluating LLMs. 2024. Open-source registry of model-capability benchmarks.

• Panickssery 等（2024）. Panickssery, A., Bowman, S. R., and Feng, S. LLM evaluators recognize and favor their own generations. In arXiv preprint arXiv:2404.13076, 2024.

• promptfoo（2025）. promptfoo. Promptfoo: Test your LLM app like software. https://www.promptfoo.dev/, 2025.

• Ren 等（2023）. Ren, J., Zhao, Y., Vu, T., Liu, P. J., and Lakshminarayanan, B. Self-evaluation improves selective generation in large language models. In arXiv preprint arXiv:2312.09300, 2023.

• Saunders 等（2022）. Saunders, W., Yeh, C., Wu, J., Bills, S., Ouyang, L., Ward, J., and Leike, J. Self-critiquing models for assisting human evaluators. In arXiv preprint arXiv:2206.05802, 2022.

• Vovk 等（2005）. Vovk, V., Gammerman, A., and Shafer, G. Algorithmic learning in a random world. 2005.

• Zheng 等（2023）. Zheng, L., Chiang, W.-L., Sheng, Y., Zhuang, S., Wu, Z., Zhuang, Y., Lin, Z., Li, Z., Xing, D., Gonzalez, J. E., Stoica, I., and Zhang, H. Judging LLM-as-a-judge with MT-bench and chatbot arena. In Advances in Neural Information Processing Systems, 2023.

Tejas Singh Anand, Yuet Ying Christina Wang, Wanting Jiang, Steve Masson, Tian Zheng, Bingjie Zhou，AEVAL: From Anecdotal to Deterministic Testing for Agentic Skill Workflows，2026-07-16，https://arxiv.org/abs/2607.16345，CC BY 4.0