评估技能，而非仅关注智能体：智能体技能的连续评估

# 技能持续性代理评估  
来源：https://arxiv.org/html/2608.20614 \\@ACM@balancefalse  
## 评估技能，而不仅是代理：技能持续性代理评估  
CCS:计算方法 人工智能  
CCS:软件及其工程 软件验证与确认  
CCS:计算方法 自然语言处理  
Christopher Kevin*，Narendran Raghavan，Jean-Francois Puget，Roshni Malani，Meghana Puvvadi  
Moshe Abramovitch，Mohit Gupta，Rama Akkiraju，Subodh Prabhu，Yogesh Dangi，Wei Luo，Seong Hee Lee  
NVIDIA  
[[email protected]](mailto:[email protected]) © none  

###### 摘要  
企业代理程序正从原型走向生产环境，其中可复用的技能、工具和工作流包需要基于证据而非文字描述进行评审。当前的验收环节通常检查这些制品的结构、风格和安全性，但并未回答部署问题：能力包能否在相同的模型、沙箱和评分策略下，帮助实时代理完成企业任务？  

我们提出 **ACES**（技能持续性代理评估），一个仓库原生的框架，用于将技能和产品能力包作为可执行代理制品进行评估。ACES 在目标技能存在与否的两种条件下运行配对实时测试，将轨迹标准化为 **ATIF**（代理轨迹交换格式），评估六个默认运行时指标，并报告 **技能提升度**：在固定任务、测试工具集、工作区和评分器下，目标技能的附加价值。该协议同样支持由产品方提供的任务集，用于比较基线技能、技能包、团队技能和插件目标。  

在来自内部企业仓库和公共目录的 145 个真实技能中，仅扫描的验收环节能发现有用的编写问题，但衡量的是互补维度（结构性与 LLM 评分者斯皮尔曼相关系数 ρ=0.14）。在来自 58 个生产技能（共 64 个）和四个主要测试工具集的 947 个已评分配对案例中，平均综合技能提升度为 0.2134（95% 配对案例置信区间 [0.1967，0.2301]）；平均结果提升度（准确性和目标准确性的均值）为 0.1799。综合提升度在 72.8% 的配对案例中为正。过程指标的最大增益出现在技能执行、行为检查和技能效率方面——这些关于发现、路由、工作流遵循和工具使用的信号，是文档扫描无法观测到的。  

该方法的开源实现可在 **NVIDIA SkillEvaluator** 中获取。  

###### 关键词  
代理技能、LLM 代理、评估、LLM-as-评测者、技能提升度、多代理评估、持续性评估、CI/CD、过程知识  

## 1\. 引言  
技能是代理的应用层。过去一年，基于 LLM 的代理获得了可重复的扩展机制：**代理技能**。技能是一种过程知识的自然语言包——包含 SKILL.md 描述、可选的确定性脚本（用于代理不应即兴发挥的步骤）、以及参考资料和示例——代理在推理时加载。其决定性的设计选择是渐进式公开：代理最初仅读取简短描述，只有在判定该技能适用时才拉取指令、脚本或示例，因此数十个技能可以在工作区中共存而不会使上下文膨胀。该格式已被 Claude Code、Codex、Cursor 及其他代理工具集采用，社区注册表已托管数千个用户贡献的技能。相关技能的捆绑包越来越被称为插件；本文的方法论适用于单个技能、插件或代理可加载的任何技能组合。  

**当前实践状态**。如今，技能评估的工业工具主要分为四类互补类别。  

1. **结构检查**强制执行技能规范——前置元数据字段、章节布局、脚本存在性、命名约定——并产生确定性评分。  
2. **LLM-as-评测者评分标准**评估文档的主观质量，这些质量是静态规则无法判断的：指令的清晰度、范围定义、示例质量、触发短语。  
3. **检查器**对脚本本身的语法、风格和危险模式进行检查。  
4. **安全扫描器**检测提示注入标记、泄露的秘密、破坏性 shell 模式以及技能内容中的可疑 URL 引用。  

所有四类共享一个结构性特征：它们 **扫描技能文档**。没有一类是运行它。  

**扫描是必要的，但非充分的**。仅通过扫描来评估一个技能，类似于用 `-Wall -Werror` 编译程序：没有警告并不意味着程序做了它应该做的事。一个技能可能扫描完全通过，但在运行时仍然失败，因为：  
（a）当用户提出相关问题时，代理从未发现它；  
（b）代理阅读了文档但调用了错误的脚本或错误的参数；  
（c）代理产生了正确的输出但误解并错误报告；  
（d）该技能与工作区中已有的另一个技能冲突；  
或（e）技能被模型更新静默回归，该更新改变了代理对其文档的推理方式。这些故障模式仅从技能本身是无法观测到的。  

**衡量差距**。我们使用结构和 LLM 评测者两个层级评估了来自内部企业仓库和公共目录的 145 个真实技能。94.5% 的技能通过了默认的 C 级结构检查门槛，86.2% 通过了 LLM 评测者评分标准。然而，这两个分数的相关性仅为斯皮尔曼 ρ=0.14。换句话说，即使在扫描方法中，**两者彼此也不一致**。这是一个强烈的量化提示，表明文档扫描并未收敛到一个单一的、一致的技能质量概念——而且两种方法都没有告诉我们代理在运行时实际如何处理该技能。  

**ACES：在静态技能扫描基础上扩展实时代理评估**。我们提出 ACES（技能持续性代理评估），一种将技能作为可执行代理制品而非仅静态文档进行评估的方法论和系统。ACES 围绕三个可移植接口组织：一个随技能编写的评估资产契约、一个将这些资产实例化为配对运行时任务的适配器、以及一个基于 ATIF 的轨迹契约，允许相同的评分层比较跨代理工具集的行为。  

对于每个作者提供的任务，ACES 运行配对条件：一个 **带技能条件**，其中目标技能可用；一个 **基线条件**，其中目标技能被屏蔽，同时保留配置的前置技能、辅助技能、参考技能或干扰技能。配对差异产生 **技能提升度**：在固定代理、模型、任务、工作区和评分策略下，目标技能带来的边际价值。  

ACES 的实时评估方法在 **NVIDIA SkillEvaluator** 中可用，这是一个开源的多层次框架，其第 3 层实现了本文描述的配对评估协议。  

**我们的贡献**：  
1. (1) 一种将文档扫描扩展到作者自有任务上的实时代理评估的技能作为制品的评估方法论，包括带技能/基线的配对测量和技能提升度（§2，§4）。  
2. (2) 一个评估资产编写工作流，作者可以直接编写数据集，使用 LLM 辅助和真实轨迹来播种或完善案例，使用自由形式的 `expected_behavior` 断言进行 LLM 评测的工作流检查，并在通用指标不足时附加 BYOT/BYOG 资产（§4.1，§4.2）。  
3. (3) 一个基于 ATIF 的共享评分层，对跨代理工具集的轨迹应用确定性、安全、LLM 评测和可选的领域特定指标，并提供供作者评审的面向利益相关者的维度（§4.3–§4.5）。  
4. (4) 一个动态的 ACES 适配器，为跨代理、任务源、工作区模式、评分模式和沙箱后端（包括用于技能选择和前置技能场景的隔离和群组工作区）准备新鲜的配对任务环境（§4.6–§4.8）。  
5. (5) 一个评估原生的技能开发工作流，其中结构检查、LLM 评测评分、安全扫描、可选的实时代理评估和技能提升度报告成为跨产品仓库、技能中心仓库和注册表的技能变更评审证据（§5）。  
6. (6) 一项针对 145 个真实技能的实证研究，表明仅扫描信号是不完整的：94.5% 通过默认结构门槛，确定性评分和 LLM 评测评分在斯皮尔曼 ρ=0.14 下相关性很弱。在来自 58 个生产技能（共 64 个）和四个主要工具集的 947 个已评分配对案例中，平均综合技能提升度为 0.2134（95% 配对案例置信区间 [0.1967，0.2301]），平均结果提升度为 0.1799。相同的代理模型切片展示了为什么配对测量很重要：随着基线模型改进，绝对分数可能上升，而边际技能提升度却缩小（§6）。  

我们将相关工作推迟到 §8，以便优先呈现方法和测量结果。  

## 2\. 评估技能制品  
本节涵盖当今存在的四类仅扫描评估，描述每类相对于其他类别的附加价值，并衡量它们在我们 145 个技能语料库上留下的可观测性差距（§2.4）。  

### 2.1. 静态结构质量  
针对技能规范进行的确定性检查是最便宜且最可重复的第一步：无需 API 密钥，毫秒级运行，适合门控。我们的实现运行大约五十条规则检查，跨四个加权维度，每个维度从 100 分开始，每次发现扣分。检查家族在表 1 中总结；每个家族中的规则独立贡献严重性加权的扣分。总分是四个维度的加权和；默认门槛接受 70 分及以上的分数。这些规则与供应商关于技能应如何编写的指导紧密对齐。  

**表 1. 静态检查家族（每个维度，≈50 条规则总计）**  
每个家族包含多条独立触发的规则；每条规则从其维度分数中扣分。  

### 2.2. LLM-as-评测者  
**清晰度：静态扫描无法看到的**  
结构规则无法判断一个指令是否 **表述清晰**，一个示例是否 **具有代表性**，或者一个描述是否真的能在现实用户查询中 **触发** 该技能。因此，我们添加了第二个基于 G-Eval 表单填写方法的主观层。  

评测模型读取 SKILL.md、可选脚本内容和结构结果（作为上下文），然后返回一个 JSON 对象，包含每个标准的通过/失败和 0-10 分。温度固定为零。我们使用九个基础标准，加上第十个（*结构连贯性*，在代码中实现为 `tier1_coherence`），当提供了辅助脚本或参考内容时激活（表 2）。  

**表 2. LLM-as-评测者评分标准（9 个基础 + 1 个条件性）**  
每个标准按 0-10 分评分，并附有自由形式的推理。  

LLM 评测者捕获了结构检查遗漏的错误。像“适当处理错误”这样的指令通过了结构规则（词汇存在），但未通过错误处理质量（未描述具体行为）。长度合适的描述在触发模拟测试中仍然失败，如果现实的用户查询无法匹配。相反，评测者可以对一个前置元数据不完整但内容出色的技能给出高分——这对 §2.4 中的转折很重要。  

**跨评测模型敏感性**。绝对的 LLM 评测值取决于评测模型。我们轮换了三个评测者——Claude 3.7 Sonnet、Claude 3.5 Haiku 和一个 90 亿参数的内部评测模型——用于我们的 145 个技能语料库。最严格和最宽松评测者之间的分差在 0-10 分制上大约为 1.5 分；语料库内的相对排名基本保持不变，但我们对任何绝对主张都标注了评测者归属。  

### 2.3. 检查与安全扫描  
另外两类扫描读取脚本和完整内容，而不仅仅是 SKILL.md。**脚本检查**将 Python 检查器应用于 `scripts/*.py`，具有建议性但对作者反馈有价值。**安全扫描**检测提示注入标记（破坏系统提示的指令）、泄露的秘密（符合常见模式的 API 密钥和令牌）、破坏性 shell 调用（`rm -rf`、`DROP TABLE`、`curl | sh`）、可疑 URL 引用以及供应链红旗。一个技能可能具有完美的结构和评分标准分数，但仍在参考文件中包含提示注入向量。安全扫描在我们的流程中是外部集成，而非本文的贡献。  

### 2.4. 文档扫描告诉我们什么——以及它遗漏了什么  
在同一个包含 145 个真实技能的混合来源语料库上，四类文档扫描发现了具体问题。结构分数范围从 61 到 98（均值 79.2，中位数 79.8，σ=4.9）。94.5% 的技能在首次提交时通过了默认的 70 分门槛，但只有 48.9% 达到 80 分——这是一个可见的从 C 到 B 的壁垒（图 1，左）。每个来源的平均分紧密聚集在 78.5–80.2 范围内，表明跨来源边界的结构化技能质量非常一致。  

图 1 的要点并非大多数技能已准备好运行；而是宽容的结构门槛适合发现编写问题，但太弱，无法替代实时技能行为。  

**图 1. 文档扫描证据为实时评估提供动机，但不能替代实时评估。**  
(a) 结构分数为 0-100 分，对 n=145 个真实技能在正确性、可发现性、可靠性和效率维度上聚合了大约 50 条确定性规则检查。默认的 70 分门槛是宽容的：94.5% 的技能通过，但只有 48.9% 达到 80 分线。(b) 结构分数与 LLM 评测分数在同一语料库上不一致（斯皮尔曼 ρ=0.14，皮尔逊 r=0.08）。两图共同表明，文档扫描发现了真实的编写问题，但仅扫描的两个轴均未观测到发现、工具使用、工作流顺序或任务成功。  

**双面板图表。** 左图是来自内部企业仓库和公共目录的 145 个真实技能的结构分数直方图，垂直标记在 70 分门槛和 80 分线处。大多数技能在 75 到 85 之间，注释指出 94.5% 通过了门槛，而 48.9% 达到 80 分。右图是结构分数与 LLM 评测分数的散点图。