论文

  • 标题：Evaluating Skills, Not Just Agents: Agentic Continuous Evaluation of Skills
  • 论文链接：https://arxiv.org/abs/2608.20614
  • 发表时间：2026 年 8 月 20 日（arXiv v1）
  • 机构：NVIDIA（Christopher Kevin 等 13 人，内部多团队协作，涵盖企业级技能目录运营与评测基础设施）
  • 开源实现：NVIDIA SkillEvaluator（GitHub，Apache-2.0，Tier 3 实现本文的配对评测协议）
  • 领域标签：cs.AI / Agent 技能评测 / CI/CD

一句话概括：技能评审不能再只「读说明书」了——ACES 让技能像新药一样进临床试验，用安慰剂对照的差值说话。

一、论文背景：技能生态爆发，评审却还在「读文档」

1.1 什么是 Agent 技能

过去一年，LLM Agent 获得了一种可复用的扩展机制——技能（skill）。一个技能就是一个自然语言打包的「程序性知识包」：一份 SKILL.md 描述、若干可选的确定性脚本（覆盖那些不该让智能体即兴发挥的步骤）、加上参考资料和示例。智能体在推理时按需加载。

它的核心设计是渐进披露（progressive disclosure）：智能体一开始只读简短描述，只有当它判断该技能适用时，才拉取完整指令、脚本和示例。这样几十个技能可以共存于一个工作区而不撑爆上下文。可以把技能理解为一个 U 盘式的即插即用操作手册：插入（放入工作区）即被发现，需要时翻开详细页，用完即走。

这个格式已被 Claude Code、Codex、Cursor 等主流 Agent harness 采纳，社区注册表里已有数千个用户贡献的技能。相关技能的捆绑集合正在被称为 plugin——本文方法论对单个技能、plugin 或任意技能组合都适用。

1.2 企业评审现状：四类「扫描」，没有一类「运行」

企业里 Agent 走向生产，技能包必须「凭证据评审」而非「凭文字评审」。当前的工具链聚成四类：

  1. 结构检查：校验 frontmatter 字段、章节布局、脚本存在性、命名规范，输出确定性分数；
  2. LLM 评分：用评判模型给文档的主观质量打分——指令清晰度、范围定义、示例质量、触发措辞；
  3. Lint：检查脚本本身的语法、风格和危险模式；
  4. 安全扫描：检测提示注入标记、泄露密钥、破坏性 shell 模式、可疑 URL。

论文点破了四类方法的共同结构性质：它们都在扫描技能文档，没有一个在运行技能。 这就像用 -Wall -Werror 编译一个程序——没有警告不等于程序做对了它该做的事。

一个技能可以扫描全绿，但在运行时死于五种文档看不见的失败模式： 用户问了相关问题，智能体从未发现它； 智能体读了文档但调用了错误的脚本或参数； 智能体产出正确输出却误解并误报了它； 技能与工作区里另一个技能冲突； 模型更新改变智能体对文档的推理方式，技能被静默回归。这五种失败，从技能文件本身一个都观测不到。

二、论文定位和关联工作：五维能力矩阵里的空位

论文用五个能力维度审视现有工具：Artifact（直接给技能工件打分）、Value（用差值测边际价值）、Multi（跨多个 harness 评测）、CI（CI 原生部署）、HITL（人机协同的数据集精炼）。

  • SkillsBench：在固定 84 任务集上比较无技能/精选技能/自生成技能三种配置的通过率差，证明了「技能有用」，但不把单个技能当一等公民评分、不进开发者 CI、不用作者自己的任务评测；
  • In-the-Wild 研究：测试智能体能否从 34k 技能库中检索出正确技能，发现真实检索条件下收益会退化，但不评单技能质量与边际价值；
  • SkillTester：在隔离状态下评技能工件的效用与安全，不运行活体智能体；
  • Anthropic skill-creator：只做工件评分；
  • Terminal-Bench：跨 harness 评测智能体，但技能不是一等公民。

没有一种方法同时覆盖五维——ACES 是第一个五维全覆盖的：工件扫描 + 配对差值 + ATIF 跨 harness 轨迹契约 + CI 集成 + 作者主导的数据集精炼。

三、问题定义：技能的「边际价值」如何测量

论文把问题从「文档扫描的盲区」抽象为一个测量问题：在固定的任务、智能体、模型、沙箱和评分策略下，这个技能包为活体智能体完成企业任务增加了多少价值？

五种运行时失败模式（发现、路由、执行、冲突、回归）本质上都指向同一个缺口的度量——技能的边际贡献。绝对分数无法回答这个问题：「技能好」会和「智能体本身强」、「评分器恰好宽松」混在一起。你需要的是一个差分定义：

Skill Lift = 同一任务、同一智能体、同一模型、同一评分器下，六指标在「有技能」与「无技能（基线）」两种条件下的平均差值。

这就像药物临床试验：疗效不是「吃药后体温 37 度」，而是「服药组与安慰剂组的体温差」。配对设计固定了一切变量，唯一翻动的开关是目标技能是否可用——差值因此只能归因于技能本身。

四、问题解法：ACES 的配对活体评测流水线

4.1 评估资产契约：evals.json 是技能的测试套件

ACES 的第一原则是「写一次，处处评测」。核心契约是 evals/evals.json 数据集：每条包含唯一 id、用户问题、期望技能（负例为 null）、可选的期望脚本、ground_truth 参考答案，以及一列自由文本的 expected_behavior（如「执行前先读 git-skill/SKILL.md」「执行破坏性操作前与用户确认」）。作者主张像维护 tests/ 一样在写技能的同时维护 evals/——没有评估资产的技能可以扫描，但尚未声明它应保持的运行时行为。

数据生成有四桶分类法（源自 OpenAI Codex 团队的提示分类学）：Explicit（用户直接点名技能，测直接调用）、Implicit（用户描述场景不点名，测技能名称与描述能否让智能体自发选中）、Contextual（加领域噪声上下文，测真实触发）、Negative control（相邻或无关请求，抓技能过度触发的假阳性）。

第三原则是开发者引导：作者可写 EVAL.md 声明意图——其中的问题、期望行为和注释优先级高于任何 LLM 生成内容。当技能依赖产品状态或领域正确性标准时，可挂 BYOT（自带任务）与 BYOG（自带评分器）；ACES 不替换它们，只把同一配对协议套上去。

4.2 配对运行与 ATIF 归一化

ACES adapter 把评估资产物化为配对任务矩阵：每个用例发出一个「有技能」任务和一个「基线」任务。基线不是空工作区——配置的先决、辅助、参考技能和**诱饵技能（decoy）**在两个条件里都固定存在，只扣留目标技能。这迫使智能体在两侧都做技能发现与路由，差值才测的是目标技能的净增量，而不是「有技能可找 vs 无技能可找」。

执行层基于 Harbor 容器化框架：每个任务目录含 instruction.md、task.toml、Dockerfile、注入技能的 environment/skills/、可选的 mock MCP 服务 Compose 文件，以及统一注入的 verifier 脚本。所有 harness 的轨迹归一化为 ATIF（Agent Trajectory Interchange Format，版本化 JSON schema：有序步骤，每步带 source、message、tool calls、observation）——Claude Code 和 Codex 原生输出 ATIF，纯文本日志的 harness（如 cursor-cli）经启发式适配器转换。ATIF 是可移植性枢纽：任何能产出 ATIF 的 harness 都能被同一评分层打分。

4.3 六指标评分与两种工作区模式

六指标默认套件（各 1/6 权重，归一到 [0,1]）：

  • security（轨迹级确定性检查）：破坏性操作、泄露密钥、越界访问；
  • skill_execution（四个子查）：是否激活（读了 SKILL.md）、是否调用期望脚本、是否先读后执行、失败后是否合理恢复；
  • skill_efficiency：路由（只读允许的工作区技能）+ 工具效率（有效调用占比，含浪费指标如 --help 摸索、错误路径的探索性 ls）；
  • accuracy（LLM 评判，五问二值：技能识别对吗、动作对吗、事实与参考一致吗、任务被解决吗、回答可执行吗）；
  • goal_accuracy（RAGAS 的 AgentGoalAccuracyWithReference，LLM 兜底）；
  • behavior_check（逐条 expected_behavior 的 YES/NO 评判，通过率）。

工作区有两种模式：隔离模式只放目标技能，智能体别无选择，Lift_iso 测的是内容贡献（技能被选中后带来什么）；群组模式把目标技能放进固定的一组支撑/诱饵技能中，智能体必须先做选择，Lift_grp = 内容 + 路由。两者之差 routing premium 直接量化技能的名称和描述能否让智能体在邻居中把它认出来——近似零或为负，就是改写 name/description 的行动信号。

此外还有轨迹接地的精炼：首轮评测后 --refine 重读录制的 ATIF 轨迹，把智能体实际答案和工具调用序列回填进数据集（EVAL.md 永不覆盖），让假设行为对齐观测行为，后续运行的评判方差更低。整个流程按成本渐进：结构检查每次变更都跑（无 API 调用），活体评测留给发布候选、高风险技能或评审者触发——技能变更的 PR 从此带着 Skill Lift 证据进门。

五、评估指标与实验证据

5.1 扫描侧：两个扫描器自己就打架

145 个真实技能（内部企业仓库 + 公共目录，覆盖 System Access 49 个、Deployment 41 个、Platform 29 个、Data Infra 21 个等七类）上：结构分均值 79.2（σ=4.9），94.5% 通过默认 70 分门槛，但只有 48.9% 上到 80 分；LLM 评分侧 86.2% 通过。而两种分数在语料上的相关性只有 Spearman ρ=0.14（Pearson r=0.08）。分歧聚成两种模式：过结构、挂评分的技能「字段齐全但指令含糊」；挂结构、过评分的技能「内容扎实但丢了声明的元数据」。违规则榜首被 frontmatter 契约统治：99.3% 的技能没声明 tools、97.9% 缺 Limitations、97.2% 缺 author、91.7% 缺 tags——声明的契约是「理想化」的，默认门槛照样放行。

结论很锋利：还没到运行这一步，扫描方法之间就没收敛。换三个评判模型（旗舰、小模型、9B 内部）还会带来约 1.5 分的严格度差。

5.2 活体侧：947 个配对案例的主结果

排除 25 个扩展研究变体后，64 个生产技能中 58 个有评分配对案例，横跨四个主 harness（Claude Code 56 单元格/251 案例、Codex 50/259、OpenCode 34/211、Terminus-2 37/226），共 947 个评分配对案例（背后是 578 次条件运行、2,022 条 ATIF 轨迹、11,642 次工具调用、9,091 条行为观察）。

  • 平均复合 Skill Lift = 0.2134（95% CI [0.1967, 0.2301]），绝对条件均值 0.7460（有技能）vs 0.5326（基线）；按技能 bootstrap 的区间 [0.1898, 0.2350] 同样为正；
  • 只看结果指标（accuracy +0.1431、goal_accuracy +0.2167）的 outcome-only lift = 0.1799；
  • 复合 Lift 为正的案例占 72.8%（689 正 / 171 零 / 87 负，中位数 0.1717）——均值不是被小正尾巴拖出来的；
  • 过程指标增益最大：skill_execution +0.3263（64% 案例为正）、behavior_check +0.2983（56% 为正）、skill_efficiency +0.2758（但仅 41.7% 案例为正——高方差的「用效率换正确性」交易）；security 基本持平（+0.020），符合预期。

5.3 四 harness 对比与「模型变强、Lift 缩水」

四个 harness 的平均 lift：OpenCode 0.3611 > Claude Code 0.2904 > Codex 0.1264 > Terminus-2 0.0896。注意这是各 harness 对自己基线的匹配差值，不是模型排行榜。

更耐人寻味的是同一 harness 换模型的切片：Codex 从 5.2 → 5.4 → 5.5，绝对分一路上涨（基线 0.63→0.67→0.71），但 Skill Lift 从 +0.09 → +0.11 → +0.05——基线智能体不再那么需要技能帮忙了。这解释了为什么论文主张模型更新后要定期重评技能：技能的边际价值不是技能的固有属性，它随基线模型漂移。

5.4 负 Lift 与路由压力测试

87 个负 Lift 案例是论文最想暴露的回归信号，轨迹显示两类失败：一类是执行不稳定（如某次有技能运行没有产出可评分试验而基线完成了）；更干净的一类是技能把智能体带偏了——找到并尝试读了技能，但产出截断的元层回答、跳过验证、多花工具调用却没改善答案。一个匿名技术配置案例中，激活与部分行为检查都改善了，但目标准确率和效率跌到让总 Lift 转负。配对评测因此能区分「从未发现」与「发现但误用」——文档扫描对两者都失明。

路由压力测试（5 个目标技能 × 1/5/10/20/50 可见技能 × 2 harness）：1–20 个可见技能时平均 lift 稳在 0.133–0.149，但平均耗时从 258 秒（1 个）涨到 451 秒（20 个）；50 个可见技能时通过率跌到 0.55（1 个时为 0.725）、耗时 1290 秒——拥挤工作区是发布前的定向压力测试，不是每次编辑的默认项。

5.5 最关键的一张表：扫描分与活体 Lift 近零相关

64 个生产技能中 62 个有匹配的扫描元数据：Tier 1 结构分与活体 Lift 的 Spearman ρ = -0.0181，Tier 2 LLM 评分 ρ = -0.0266——统计上与零不可区分。一个公开的 OpenClaw 脱敏技能案例更戏剧化：静态评审 11/11 全过、89/100 分，安全扫描被跳过、代码检查漏掉了它的渲染器；活体配对运行（n=1）中渲染器成功执行，却在中间工件里保留了一个合成的 nvapi- 密钥罐头——智能体只修复了最终文件，且两臂的 accuracy/goal_accuracy 都是 1.0，只有工件级评分在「有技能」的中间产物里抓住了金丝雀。扫描分不是运行时证据，这就是全部证据。

六、效果优势的根源解释：为什么配对差值能「挤掉」混杂因素

ACES 有效的因果链可以拆成四环：

  1. 扫描测的是一个与运行效果统计独立的维度。 ρ=0.14（扫描器之间）与 -0.018（扫描 vs 活体）不是偶然噪声，而是结构性证据：文档质量与运行边际贡献本来就是两个随机变量。结构分测「格式契约符合度」，LLM 评分测「可读性」，而技能在运行时贡献的是发现率、路由正确性、执行保真度——三者没有理由单调相关。
  2. 配对设计通过控制变量把技能边际贡献从混杂中分离。 固定问题/智能体/模型/评分器/支撑技能，只翻动目标技能的可用性开关——「智能体强」和「评分器松」被两侧同值相减抵消。诱饵技能进一步保证基线侧也有发现压力，避免把「工作区里有技能可找」错记为技能内容的价值。
  3. 过程指标比结果指标更能暴露技能价值。 accuracy 只 +0.14 而 skill_execution +0.33、behavior_check +0.30：最终答案的正确性会被基线智能体的通用能力「兜底」，而发现、路由、流程遵循、工具使用这些行为层信号是技能真正作用的地方，也是四类文档扫描完全观测不到的地方。
  4. 负值携带诊断信息而非仅仅是失败。 因为有配对轨迹，负 Lift 可以回溯到「从未发现」（routing premium 为负，改 name/description）或「发现但误用」（执行层截断/跳步，改 Instructions 与示例）——它把一个回归变成了两次运行之间可追溯的对比。

七、必要知识反推：做出这项工作需要哪些前置知识

领域层：Agent 技能的生命周期与渐进披露机制——SKILL.md 契约、frontmatter 规范、触发词与发现机制、技能间的路由竞争；还要理解企业技能目录的真实评审流（PR/MR 门控、扫描分层、发布节奏）。

方法论层：配对实验设计（A/B 同体对照、控制变量、差分统计量与 bootstrap 簇敏感性分析）；G-Eval 式表单评判（温度为零、逐准则 0-10 打分、JSON 输出）；RAGAS 的 AgentGoalAccuracyWithReference；以及「绝对分依赖评判模型、需标注 judge attribution」的评判校准意识。

工程层：Harbor 容器化沙箱执行与 BaseAgent 接口；ATIF 轨迹契约设计（原生发射 + 启发式日志转换的双通道）；CI/CD 门控工程（渐进深度：扫描每次跑、活体按需跑、变更感知、报告原生于 PR 评论）；容器规模换算（N×K×C×A×2 次运行的线性成本模型）。

融合节点：这篇文章的独创性不在任何单项技术——配对差分、LLM 评判、容器化都是现成的——而在「差异化测量原理 × CI/CD 工程」的交叉：把临床试验的对照设计装进代码仓库的评审流水线，让「技能有没有用」变成每个 PR 自动回答的问题。

八、通用性灵感：超越技能评测的四个可迁移原理

  1. 边际价值测量。任何「这个工具/组件/文档/提示词片段到底有没有用」的问题，都可以用配对差值设计回答：固定一切、只翻一个开关、报差值不报绝对分。适用于 RAG 检索器选型、工具注册表治理、系统提示词组件化——绝对分会骗你，差值不会。
  2. 绝对分与增量分要分开报告。「模型变强 → 基线抬升 → 增量缩水」是强模型时代的普遍规律（Codex 5.5 切片：绝对分新高、Lift 腰斩）。任何依赖外部能力的系统都应定期重测增量，而非依赖一次性的价值认证。
  3. 过程指标优于结果指标。发现/路由/执行/恢复等行为信号比最终答案更有诊断力（+0.33 vs +0.14），因为结果会被通用能力兜底而过程不会。评测任何多步系统时，先问「中间行为可观测吗」，再问「答案对吗」。
  4. 作者意图优先的评估资产化。evals.json 如同 tests/、EVAL.md 如同代码注释里的设计意图、四桶生成如同测试分类学——把评估意图变成与工件同仓库、同版本、同评审的资产，是所有「AI 工件 + CI」场景的通用工程惯例。

附录：一句话总结

ACES 给技能生态补上了从「编译通过」到「程序正确」之间缺失的那一环：扫描回答「这个技能写得像不像样」，Skill Lift 回答「这个技能装上之后，智能体真的变强了吗」——后者才是企业部署时唯一重要的问题。947 个配对案例、0.2134 的平均 Lift、72.8% 的正例率和 87 个可追溯的负例，共同构成了这份答案的第一份大样本证据。