评估 AI Agent 技能的框架：如何量化技能对代理性能的真实影响
译注： 本文翻译自 Tessl 技术博客，原作者 Maksim Shaposhnikov。原文链接：A Proposed Framework For Evaluating Skills。译文在保留原文核心观点的基础上进行了意译润色，并保留了所有原始配图。
摘要
本文研究的是如何评估**技能（Skills）**的实际价值------技能是一种可复用的指令包，能为 AI 代理提供特定任务所需的知识和工作流程。尽管创建技能的门槛很低，但它们究竟能在多大程度上提升代理的表现，目前尚不明确。
我们提出了一套大规模评估框架，通过基于技能内容自动生成真实编码任务，分别在「有技能」和「无技能」两种条件下测量代理的性能差异。将这套框架应用于大规模技能语料库后，我们发现：使用相关技能能显著提升解决方案质量，准确率较无技能基线提高了约 20 个百分点 。更重要的是，小模型在获得合适的技能后，其表现可以媲美大模型，同时成本仅为后者的 三分之一。
此外，我们还发现代理在自由场景下经常无法正确激活已有技能，激活率仅约 40% 。最后，评估质量本身也至关重要：约 30% 的自动生成任务存在信息泄漏问题，如果不加以检测，会导致得出过于乐观的错误结论。这些发现既揭示了技能的巨大潜力，也凸显了精心设计评估方案的重要性。
基于这项研究，Tessl 已发布了一套评估框架，将评估设计的复杂性自动化封装，让从业者能够专注于构建高质量技能本身，而不必自建临时评估流水线。
如果你对评估（evals）、上下文管理和智能体开发等话题感兴趣，欢迎参加 6 月的 AI Dev Conference。
为什么要评估技能
技能本质上是一组打包在文件夹中的指令，用于教会 AI 代理如何处理特定任务、遵循特定工作流程，或做出有主见的选择。
技能是自定义 Claude Code 或任何其他 AI 代理最强大的方式之一。你不必在每次对话中反复解释自己的偏好、流程和领域知识，只需教会代理一次，之后每次都能受益。
创建技能本身很简单，成本也很低。然而，要可靠地回答「这个技能到底有没有用？」这个问题，难度就大得多了。实际上，这只是冰山一角。以下这些问题往往更加关键：
- 这个技能相比完全没有技能，真的能改善结果吗？
- 代理到底有没有激活这个技能？
- 它在
claude-haiku-4-5上能正常工作，还是只有更大、更贵的claude-sonnet-4-6才行？ - 技能中试图教授的某些行为，是否有任何模型真正学会了？
- 这个技能是否反而让某些方面变得更差了？
为了回答这些问题，我们对 Tessl Registry 中数百个真实世界的开源技能进行了大规模研究，量化了它们对编码质量的影响。
为此，我们设计了一套评估框架：自动生成真实的编码问题，然后分别在「有技能」和「无技能」条件下测量模型表现。两种条件之间的差距，就告诉我们这个技能是否真的在创造价值。
本文将介绍这套评估方法论，并量化技能这一概念在大量真实技能上的整体影响。
我们将这套评估方法作为 Tessl 评估平台的核心构建模块，使你能够可靠地评估任何技能。详情请参考这里。
实验设计：如何大规模评估代理技能
为了大规模评估技能的实用价值，我们构建了一个多样化的技能数据集。我们从 Tessl Registry 中下载了经过正式审查的公开技能，并从中采样了各种类型的技能。然后，我们自动审核了技能质量以过滤掉低质量的条目。接下来，我们根据每个技能的内容自动生成最多五个真实的任务，每个任务都配有评估标准。最后，我们在两种条件下（有技能 vs. 无技能）分别让代理完成任务。下面的流程图概括了整个流水线，后续各小节将逐一展开。
Tessl Registry 是什么？
Registry 目前包含约 5,000 个 经过正式审查的独特技能（你可以使用 Tessl 的审查功能在这里快速了解你的技能质量如何）。
利用这个大型数据集，我们通过为每个技能计算嵌入向量来进行主题聚类，从而对技能内容进行宏观刻画。
分析识别出了 88 个主题类别。最大的几组分别是：AI/ML（560 个技能）、Web 开发（562 个）、DevOps/基础设施（555 个），此外还有大量专门领域的长尾内容，如生物信息学和数学等。
最热门主题的分布如下：
总体来看，Registry 在软件开发的常见和冷门领域都有广泛的覆盖。我们利用这些聚类构建了一个包含 1,200 个技能的代表性样本，用于下一阶段的评估。
可行性检查：过滤无法评估的技能
我们引入了一种护栏机制，用于判断一个技能是否在原则上可以通过有意义的合成任务来评估。有些技能只能在特定仓库中使用，脱离了那些既有环境就毫无用处。比如 PyTorch GitHub 仓库中的技能集合------这些技能在 PyTorch 代码库内开发时很有用，但脱离该仓库环境就毫无意义。在本研究中，我们希望过滤掉这类技能，专注于可以独立评估的技能，比如描述框架 API 文档、工具、有主见的风格指南或其组合的技能。
具体来说，该机制会读取技能内容并给出三种标签之一：
- 不可行（INFEASIBLE）：该技能依赖于大量预置环境，无法在评估中合成为真实任务的条件。比如需要现有的代码库、运行中的数据库、Git 历史、多文件项目状态或已配置的基础设施等。在这些情况下，技能的核心目的就是操作这些既有上下文。
- 可行但需输入数据（FEASIBLE_BUT_NEEDS_INPUT_DATA）：该技能可以在合成环境中评估，但需要提供特定的输入制品（如某个文件）。这种依赖是有限的，不构成完整的环境。
- 完全可行（FEASIBLE）：该技能可以直接在全新环境中评估，通常是因为它专注于 API、文档或类似的独立任务。
该机制速度快，能可靠识别技能与全新环境评估设置之间的明显不匹配，并通过过滤不适合评估的技能来减少不必要的评估成本。
下表表明，这种区分在实践中很重要：约 40% 的技能要么需要某种形式的输入数据，要么根本无法在全新环境中评估。
| 类别 | 技能数量 | 占比 (%) |
|---|---|---|
| 完全可行 | 726 | 63.5 |
| 需输入数据 | 134 | 11.7 |
| 不可行 | 283 | 24.8 |
我们只保留了完全可行的技能，并将过滤后的集合带入下一阶段评估。值得一提的是，Tessl 产品允许你判断自己的技能是否可评估。Tessl 评估引擎支持 fixtures 和 artifacts，允许技能所有者上传任何内容，这使得在实践中评估大多数技能成为可能。
为 AI 代理技能生成评估任务
这是整个流水线中最有趣的环节，也是真正产生价值的地方。
对于每个技能，我们生成了一组评估任务（task evals），旨在测量技能的可用性是否会导致代理行为产生有意义的差异。
任务生成始于对技能内容的结构化分析。我们解析每个技能，提取其可操作的指令，包括推荐的库、规定的工作流程、要求的约定、禁止的模式，以及领域特定的实现细节。对于每条指令，我们还记录了它在何种场景下会变得相关，以及它编码的是提醒、新知识还是在多个有效选项中的特定偏好。
基于这种表示，我们生成了真实的编码任务，这些任务共同最大化了对技能指令的覆盖。每个任务都被构建为一个连贯的用户任务，而不是对指令的直接测试。具体来说，任务描述被写得让技能自然相关，但不会明确揭示正在评估的行为。
每个任务包含多个组件：描述待解决问题的任务规范，以及以评分标准集合形式表达的评分规范，每个标准都分配了分数。这些标准直接源自技能指令，设计得尽可能客观和二元化，以便最终产出可以被可靠评分。
重要的是，这些标准关注的是是否遵循了技能特定的指导，而不是通用的软件质量或整体任务成功与否。
我们将每个技能的最大任务数固定为五个，不过对于简单的技能可能会生成更少。五个任务能实现对技能指令的高覆盖，而一两个任务明显不够，如下表所示：
| 任务数量 | 平均覆盖率 (%) |
|---|---|
| 1 | 28 |
| 2 | 47 |
| 3 | 59 |
| 4 | 70 |
| 5 | 78 |
评估中的信息泄漏问题
我们发现，通过评估技能内容泄漏到任务中的程度来监控生成任务的质量极为重要。这对于保持评估设置的区分力是必要的。
为了检测这些"作弊"行为，每个生成的任务都经过三个维度的审查：
- 标准泄漏（Criteria Leakage）：检查评分标准有多少泄漏到了任务内容中。高泄漏意味着任务指令明确告诉代理该做什么才能获得高分。
- 技能泄漏（Skill Leakage）：检查技能的指令有多少泄漏到了任务内容中。高泄漏意味着任务指令明确描述了技能的工作方式，使技能的有无变得不那么有意义。
- 任务价值（Task Value）：检查任务在多大程度上测试的是真正的技能特定指令，而非任何称职的代理在没有技能时也会遵循的通用实践。换言之，它衡量的是任务对真正依赖技能的行为的捕捉程度。
这些过滤器使我们能够移除低质量任务，防止代理"作弊"。
我们发现，相当大比例（30%）的生成任务在任务描述中包含了相当程度的标准泄漏。完整分布如下：
这些观察表明，即使我们明确提示生成任务的代理避免泄漏，生成器在没有独立验证器的情况下仍然倾向于"作弊"。因此，需要额外的验证机制。
在这一阶段，我们应用以下过滤器从数据集中移除低质量任务：
- 过滤掉具有中等 或高标准泄漏的任务。
- 过滤掉具有中等 或高技能泄漏的任务。
- 只保留高价值的任务。
最终得到的是一套真实的、对技能敏感的评估任务，可用于比较有技能和无技能条件下的代理表现。
结果：技能将代理准确率提升 20%
我们进一步在多个领域中选取了约 500 个技能及其对应任务。然后在有技能和无技能两种条件下，在这些任务上评估编码代理。
在有技能的设置中，代理在提示中被明确告知该技能可用于解决任务。这使我们能够隔离技能本身的效果，而不是将结果与代理是否会选择激活技能的不确定性混为一谈。我们将在后文呈现不强制使用技能的消融实验结果。
这些实验使用了 Anthropic 系列的模型，具体是评估时可用的最新 Haiku 和 Sonnet 变体。
我们报告三个主要指标的结果：解决方案质量、成本和运行时间。
从中可以得出几个实用的发现：
- 第一，技能的可用性收益巨大。 在所有评估任务中，Sonnet 4.6 在有技能条件下的准确率较无技能基线提高了约 20 个百分点。
- 第二，更小更便宜的模型在获得专业上下文后能与大模型竞争。 在我们的实验中，当相关技能可用时，Haiku 相对于更大模型的表现相当出色。
- 第三，额外的上下文会增加成本和运行时间。 这在预期之内，因为代理需要消耗 token 来阅读技能内容并将其指导纳入解决方案过程。然而在实践中，成本增幅适中，还可以通过渐进式披露等技术进一步缓解。
Claude Code 经常无法判断何时该激活技能
如前所述，在有技能的设置中，代理在提示中被明确告知技能可用。这样做是为了隔离技能本身的效果。我们还进行了一个额外的消融实验：代理可以访问技能（已安装且对 Claude Code 可见），但必须根据自己对任务的理解来决定是否使用它。
换言之，我们从指令中移除了以下这段话：
text
确保有一个合适的技能来帮助你完成任务。如果技能未安装且不可用，立即中止运行。始终使用技能来解决任务，因为它是宝贵信息的来源。某些技能可能需要某个服务的 API 密钥才能真正使用，这不应成为实现任务的障碍。在不强制使用技能的情况下，技能仅在约一半的情况下被激活，而在强制使用时则几乎总是被激活。
| 技能已安装但不强制 | 技能已安装且强制 | |
|---|---|---|
| 评估任务数 | 2286 | 2286 |
| 技能被激活的任务数 | 929 | 2240 |
| 激活率 % | 41 | 98 |
这个实验表明，技能激活本身是一个额外的挑战------Claude Code 并不总能从可用上下文中判断出自己应该使用某个技能。最常见的原因是技能的 description 字段不清晰，让模型感到困惑。这推动了两方面的工作：
- 改进前沿模型的后训练方案，使其能更高效地识别和使用技能。这只能由模型提供商来做。
- 改进技能描述，使其更加独特、清晰和精确。
我们的人工分析表明，许多公开可用的技能描述质量堪忧，使用了大量与技能实际内容无关的泛泛之词。
Tessl 提供了一项功能，可以审查你的技能描述和 SKILL.md，并基于最佳实践提出改进建议。详情请参考这里。
低质量任务如何影响评估
如上所述，我们过滤掉了被标记为"差"的任务------要么因为它们包含高度的标准泄漏或技能泄漏，要么因为被判定为低价值。然后我们探讨了如果专门在这些"差"数据切片上测量分数会怎样。结果如下：
具体发现如下：
- 对于高质量任务（即标准泄漏低 或无的任务），有技能和无技能代理之间的差距是显著的。
- 具有中等 或高标准泄漏的任务导致两种设置之间的行为差异缩小。
- 仅在低价值任务上测量质量，不出所料地会导致有技能和无技能之间没有差异。
这些观察凸显了任务验证的重要性，表明任务质量对于得出可靠的性能结论至关重要。
结论：技能确实有效------但前提是你得能衡量它
我们的研究结果支持三个实践性的结论。
技能在质量和成本方面都是有意义的杠杆。 20% 的准确率提升并不微不足道。同样重要的是，小模型搭配正确的技能可以匹敌大模型，这意味着技能质量是推理预算的一个真实投入变量。
安装了技能不等于使用了技能。 在非强制场景下，代理仅在 41% 的情况下激活了相关技能。技能描述的质量和独特性会提高激活几率。运行评估可以让你明确测量激活率并在需要时进行调整。
评估质量决定了结论是否可信。 没有任务验证，大约 30% 的生成评估任务包含泄漏，这会虚高分数并掩盖技能的真实效果。在一个设计糟糕的基准测试上看起来不错的评估，并不能证明技能有效。设计严格的评估很难，而跳过验证的诱惑恰恰是误导性结论的来源。
这些发现驱动了 Tessl 评估平台的设计，它处理了完整的流水线：可行性检查、任务生成、泄漏检测和评分，让从业者能够专注于构建高质量技能本身，而不必考虑如何设计评估方法论和维护必要的基础设施。
想知道你的技能是否真的有效？试试看吧。