NVIDIA提出ACES：文档及格不等于可用，成对实测带来21%能力净增
Evaluating Skills, Not Just Agents: Agentic Continuous Evaluation of Skills
在过去一年里，大语言模型（LLM）驱动的智能体（Agent）正在经历从单体提示词工程向“模块化扩展”的范式转移。无论是在 Claude Code、Codex 还是各类代码助手与自动化工作流中，以 SKILL.md 规范为代表的 Agent Skill（智能体技能）已经迅速成为事实上的应用层标准。这种设计通过渐进式披露机制，让 Agent 仅在需要时按需加载特定领域的指令规范、确定性执行脚本与参考样例，避免了上下文窗口的无谓膨胀。然而，当大量企业试图将这些封装好的技能推向生产环境时，工程团队却撞上了一堵无形的墙：我们该如何验证一个技能包是真正有效的？
ArXiv URL：https://arxiv.org/abs/2608.20614v1
目前业界的常规做法几乎完全依赖静态的“文档审查”——通过规则检查 frontmatter 格式是否合规、调用大模型评审说明文档是否通顺、静态扫描 Python 脚本的语法与安全风险。这种门禁就像给程序代码开启 -Wall -Werror 编译参数：没有警告，绝不代表程序在运行时能得到正确结果。一个在文档打分中拿到满分的技能，在真实运行时可能从未被 Agent 成功唤起，可能在解析参数时频繁报错，也可能与工作区中的其他既有技能发生冲突，导致灾难性的流程偏移。
针对这一脱节现象，NVIDIA 团队提出了名为 ACES（Agentic Continuous Evaluation of Skills）的持续评估框架，并在开源工具 NVIDIA SkillEvaluator 中实现了该方法。ACES 的核心理念在于将技能视为“可执行的智能体产物”，跳出脱离执行过程的文档扫描，引入带对比基准的真实交互测试，并通过统一的轨迹交换规范来量化技能带来的边际贡献。在大规模跨 Harness 的 947 组对比实验中，该框架展示了技能在真实环境中带来的能力增量，同时也揭示了过往静态评估机制中普遍存在的巨大盲区。
文档打分与运行实效的断裂
要理解动态评估的必要性，首先需要看清当前静态门禁的局限。业界现有的技能评估工具主要集中在四个方向：确定性的结构检查、基于大模型作为裁判（LLM-as-Judge）的文本质量评分、脚本代码静态检查（Linter）以及针对 Prompt 注入与敏感凭据的安全扫描。这些机制的共同属性是“只读不跑”。
为了量化这种静态评估手段的有效性，研究团队收集了来自企业内部仓库与公开目录的 145 个真实技能，并同时运行了结构规则检查与基于大模型的说明文档主观打分。结果令人意外：高达 94.5% 的技能轻松通过了默认的 C 级静态结构检查，86.2% 的技能通过了大模型对其文档清晰度与样例质量的审核。然而，当比对这两组静态得分时，它们之间的斯皮尔曼等级相关系数（Spearman $\rho$）仅有 0.14。这意味着，即便同为静态扫描，规则检查与大模型裁判也呈现出极低的一致性，各说各话。更严重的是，两者的良好评分都无法保证 Agent 在真实任务里能够合理调用工具并解决问题。
在真实的 Agent 运行环境中，失效往往发生在静态文本无法观测的缝隙之中。第一种典型失败是路由失效：用户提出的需求与技能完全契合，但 Agent 在前置决策时直接忽略了该技能，完全没有触发它。第二种是参数与接口失调：Agent 尝试调用技能附带的脚本，却在填入实参时发生了逻辑错误。第三种是工作区冲突：当工作区中并存多个技能时，相似的功能描述引发了工具争用，Agent 陷入反复试错的震荡。第四种则是基础模型迭代带来的隐式退化：当底层模型升级或微调后，它对某段指令的意图理解发生偏移，原先稳定的技能可能瞬间失效。这些问题，依靠阅读静态文档永远无法发现。
成对测试与技能净增益的度量
为了填补静态扫描与实际部署之间的断层，ACES 引入了一种类似软件工程 A/B 测试的成对测试机制（Paired Live Trials），并由此提出了量化技能核心价值的指标——Skill Lift（技能净增益）。
评测 Agent 与评测传统软件不同，不能简单地跑一遍技能看最终任务是否完成。如果一个任务最终成功了，究竟是因为底层的大模型本身逻辑强大，还是因为该技能提供了不可替代的程序性知识？同样，如果直接拿“提供技能”与“完全不提供任何技能的空白工作区”进行对比，评测结果也会被严重高估。因为在空白工作区中，Agent 根本不需要进行技能筛选，这相当于把“具备工具检索能力”和“技能本身的指令价值”混为一谈。
ACES 的做法是：对每一个待评测的具体任务，在同一底层模型、同一执行沙盒、同一 Harness 与统一评分标准的前提下，并行启动两组测试。一组是包含目标技能的条件（with-skill），另一组是不包含目标技能的基准条件（baseline）。极其关键的一点是，在 baseline 条件下，工作区并非空无一物，而是保留了预置的先决技能、辅助技能以及参考干扰项（Reference Decoys，例如通用的日志排查或配置检查工具）。这意味着 Agent 在 baseline 条件下依然必须执行工具发现与路由判断。
通过计算两组试验在评估指标上的差异，研究者得出了严格受控的 Skill Lift 公式：
\[\mathrm{Lift}_{s,a} = \frac{1}{\lvert M \rvert}\sum_{m\in M}\Bigl(\overline{S}^{\,\mathrm{with}}_{s,a,m} - \overline{S}^{\,\mathrm{base}}_{s,a,m}\Bigr)\]其中 $s$ 表示技能，$a$ 表示 Agent Harness，$M$ 为生效的评估指标集合。这个指标剥离了大模型自身的基础智力红利，也剔除了环境中其他工具带来的通用支持，精准反映了引入该技能后为系统带来的纯粹“边际增量”。
这一设计的工程意义在于，当团队升级底层基座模型（例如从 Claude 3.5 升级到 Claude 3.7，或引入更大参数的开源模型）时，任务的绝对成功率可能会普遍上升，但 Skill Lift 可能会收缩。如果一个技能在更聪明的模型面前带来的边际增量趋近于零，团队就可以确信，该技能所包裹的逻辑已经内化为模型的通用常识，这一资产便不再具备维护的必要性。
统一轨迹标准与可观测指标体系
让评估系统在多个不同的 Agent 框架之间保持一致，是持续集成中的另一道难题。业界现存的 Agent 架构五花八门，Claude Code、Codex 拥有高度结构化的工具调用输出，而如 cursor-cli 等工具在默认情况下仅打印非结构化的文本日志。如果每个工具都要定制一套评估标准，跨系统横向对比便无从谈起。
ACES 选取了开源的智能体轨迹交换规范 ATIF（Agent Trajectory Interchange Format）作为系统的中枢枢纽。ATIF 是一种版本化的 JSON 规范，它将智能体的运行过程抽象为按时序排列的步骤列表，每一个步骤明确记录交互来源、消息内容、包含函数名与实参的结构化工具调用，以及沙盒环境返回的观察结果（Observation）。对于原生支持结构化调用的 Harness，ACES 直接记录其轨迹；对于只输出终端文本的工具，则通过启发式适配层将其重构为标准 ATIF 轨迹。
依托标准化的运行轨迹，ACES 设立了由六项默认指标构成的评测管道，兼顾确定性事实与语义级裁决：
-
轨迹级安全（Trace-Level Security）：动态监控执行过程中是否存在恶意的系统破坏行为或异常调用。
-
技能执行判定（Skill Execution）：通过确定性规则核实目标技能对应的工具或脚本是否被真实调用，参数传递是否合规。
-
技能效率（Skill Efficiency）：量化技能在解决问题过程中是否精简了步骤，或是带来了不必要的上下文膨胀与无效工具交互。
-
目标达成度（Goal Accuracy）：结合 RAGAS 等框架，通过大模型判定 Agent 是否完整实现了任务提示词中的最终诉求。
-
回答准确率（Accuracy）：针对任务的具体答案与输出结果，核验其客观事实的准确性。
-
行为合规检查（Behavior Check）：根据技能作者预先声明的预期行为规范，检查 Agent 是否遵循了特定的调用时序与处理逻辑。
为了让非技术背景的管理者与产品团队能够理解评估结果，ACES 进一步将上述底层指标映射为五类业务侧维度，涵盖能力发现与调用、工作流遵循度、最终成效达成度、操作安全性以及资源调用效率。此外，框架还开放了 BYOT（自带任务资产）与 BYOG（自带评判逻辑）接口，允许企业将内部系统的专有业务状态与自定义代码核验逻辑无缝接入，而不需要破坏统一的成对评估流程。
隔离测试与群组测试：拆解“路由溢价”
一个技能的实际表现，往往由两个阶段决定：第一是 Agent 在众多候选项中能否精准“认出并选择”它，第二是选择之后能否按照文档“正确执行”它。以往的测试环境往往把单个技能单独丢给 Agent 跑用例，这掩盖了绝大部分线上故障。
ACES 通过“隔离测试（Isolation）”与“群组测试（Group）”的双重模式，巧妙地解耦了这两类贡献。在隔离模式下，整个沙盒工作区只挂载待测试的目标技能。Agent 面对特定任务时别无选择，只要需要用外部能力就只能调用该技能。此时测算出的 Skill Lift，纯粹衡量的是技能的“内容贡献”——即提示词写得好不好、脚本功能是否完备、边界处理是否稳妥。
而在群组模式下，待测技能被放置在一个包含若干个干扰技能的环境中。Agent 不仅要解题，还必须先在一揽子看似相关的工具中完成甄别与路由。通过群组模式测得的 Skill Lift，综合了内容与路由两个维度的表现。
研究团队将这两个数值之间的差异定义为“路由溢价（Routing Premium）”。如果一个技能在隔离模式下得分极高，但在群组模式下表现骤降，这就给作者发出了明确的工程改进信号：技能脚本本身没问题，但 SKILL.md 的描述过于模糊、触发词（Trigger）设置不够鲜明，导致它在面对同侪竞争时被其他技能分流掩盖。这种细粒度的定位，为持续优化技能资产提供了精确的抓手。
947 组对比实验揭示的核心规律
为了验证这套评估体系在真实生产环境中的表现，研究团队在 64 个高频使用的生产技能中选取了 58 个，跨越四种主流 Agent Harness，构建了 947 组配对测试用例。这批数据也是目前智能体领域针对动态技能扩展进行的最为详尽的实证评估之一。
统计数据显示，跨越所有测试用例的复合平均 Skill Lift 达到了 0.2134（95% 置信区间为 [0.1967, 0.2301]）。在纯结果维度（准确率与目标达成度的均值）上，平均边际增量达到了 0.1799。在这 947 个配对案例中，有 72.8% 的案例录得了正向的综合增益。
更具洞见的是增益分布的来源。在六项默认指标中，技能带来的最大提升并未单纯落在“答案文本写得更优美”这类泛化质量上，而是集中在技能执行（Skill Execution）、行为合规（Behavior Check）和技能效率（Skill Efficiency）这三个过程型指标上。这表明，技能的核心生产力价值主要体现在引导 Agent 按照确定性的工程路径发现工具、路由意图、遵循既定工作流以及执行代码，而这恰恰是传统的文档扫描所完全无法触及的信号盲区。
另一个值得业界警醒的发现是“负增益（Negative Lift）”现象的存在。在接近四分之一的测试中，引入一个表面上符合规范的技能反而拖累了 Agent 的最终表现。究其原因，劣质的技能描述不仅占用了有限的上下文预算，而且其模糊的指令还可能破坏大模型原本的推理链路，诱使 Agent 发起多次错误的工具调用，陷入无休止的重试循环，最终导致任务超时或崩溃。若无成对测试的度量，这类隐蔽但致命的“负资产”将长久潜伏在企业的技能库中，持续侵蚀系统的推理成本与响应效率。
走向工程化的“评测原生”技能演进
随着智能体工程化程度的加深，静态的技能说明书正在经历其“单元测试时刻”。过去，开发者往往凭借主观感受编写提示词，只要在大模型交互界面中单次验证通过，便将技能合入主干代码。
ACES 倡导的“评估原生（Evaluation-Native）”开发流程，试图把软件工程中成熟的 CI/CD 理念完整平移至技能资产管理中。在这一框架下，技能的仓库不仅仅包含指令说明与代码脚本，必须同步包含一份作为头等公民资产的 evals.json。每当开发者提交 Pull Request 修改技能的逻辑或说明时，持续集成系统便自动触发沙盒化环境，在数分钟内并行拉起成对运行的动态实例，并将最终生成的 Skill Lift 报告与详细的 ATIF 轨迹附在代码审查界面中。
更有价值的是基于轨迹反哺的数据集自演进机制。很多时候，人工设想的测试标准可能脱离 Agent 的真实行为模式。ACES 允许系统读取前次成功运行所保存的标准 ATIF 轨迹，将 Agent 实际探索出的有效工具调用时序提炼为后续的预设期望行为（expected_behavior），从而以极低的人工干预成本实现测试用例集的持续迭代与泛化。
从只看文档的“代码审查”，到置于真实动态沙盒中的“成对实测”，智能体系统的质量工程正在走出早期手工作坊式的试错阶段。NVIDIA 通过开源 SkillEvaluator 与确立 ACES 方法论，向行业展示了一个清晰的方向：在模型本身日新月异、工具环境极其复杂的 Agent 时代，唯有用严谨的边际增量度量取代泛泛的打分，才能让真正具备生产力价值的智能体资产沉淀下来。