前言

之前写的基本都是大模型或者 Agent 的一些评测内容， 今天科普一下 SKILL 的测试，毕竟星球中很多同学都对 skill 评测有需求。

skill 评测的特点

做过大模型评测的同学应该明白， 大模型本身的评测模式仍然是 “输入 - 输出”，而测试测试人员只针对输出内容进行评测。 这还算是一种在流程上比较简单的一种模式（当然流程简单，但评测工作并不简单）。 而 skill 的使用场景是让 Agent 进行调用， 所以 Skill 往往不能只通过模型输出的 “最终答案” 来评估。 它仍然需要一些其他方向的验证。 比如，我们一般把 skill 的评测分为控制面和数据面两种方向：

• 控制面：主要评估调用 Skill 的模型，是否能按 Skill 的规定，正常唤起 skill，并严格按照 skill 的步骤执行，不会出现意图混乱， 跳步，漏步， 或者调用错误的工具等等。有些时候 skill 如果写的不清晰，或者工作流混乱， 可能会造成一些效果一般的模型无法按预期完成 skill 的调用， 可能跳步，漏步等。 这就是我们常说的控制面。与大模型的只评估最终交付物不一样， skill 评测其实是 Agent 评测的一个方向，在这个方向中， 最终交付物虽然是正确的，但其中的 token 消耗，是否遗漏步骤，是否有工具重复调用， 是否有不期望的工具调用等，都是评测指标之一。
• 数据面：主要测试 skill 本身， 通常一些 skill 中需要调用一些工具，脚本，mcp 等，也会产出不同的交付物，比如 csv 文件，md 文件。 交付给用户的结果往往是多方面的，除了文字结果，可能有文件，图片， 报告。 甚至也会把一些数据写入外部的系统，或者数据库。 所以数据面的评估，就是验证 skill 再各种场景下，是否能如期的调用这些工具并产出正确的交付物。

skill 的评测指标

这里列一些常用指标：

• 步骤正确性：控制面评估，防止出现漏步跳步，通常需要分析 agent 调用链路， 看是否按 skill 的步骤，一步一步执行。
• 工具调用链路：skill 中往往描述了要调用多个工具，那么是否如期调用了工具。比如如果做数据分析， skill 希望的使用某个 mcp 或者直接用 pandas 来针对数据进行处理。 而不是大模型自己读取文件然后进行总结计算（虽然最后的结果可能都是正确的）。 这里面又包含：
  • 工具是否被预期调用，是否工具调用报错。
  • 工具是否被重复调用，一般来说可能我们期望调用一次工具就可以完成任务， 但如果模型效果一般，或者 skill 描述的不够准确，可能会触发让 agent 调用错误，导致拿到错误的结果，从而进行重试。 这也是效果不好的表现， 所以会统计工具被重复调用的数据。
  • 是否额外调用了不期望的工具：比如有些时候我们希望按 skill 描述的查询某个知识库， 但可能它没查询到， 就额外跑去网络检索去查询了。 这就多了一个不期望的调用链路。
• 交付物正确性：与大模型的单一内容输出不同， Agent 和 skill 可能会交付多种不同形式的东西给用户，比如图片，文件，写入到第三方系统中的数据等。 所以除了回复给用户的答案外，也要验证这些交付物的准确性
• token 成本：通常也会统计记录 token 的成本，每次问答需要花费多少 token， 能否用较少的 token 来完成任务，而不是依靠模型暴力检索，花费海量 token 才能完成。
• 模型效果类：使用不同的模型去测试 skill， 验证不同模型执行 skill 的各项指标。

skill 的一般评测操作方法

其实操作起来说简单也简单， 我们需要在调用 Agent 来唤起 skill 后， 拿到整个 Agent 的调用轨迹以及所有的产出物，一般来说 Agent 的返回中都会有轨迹信息和思考过程信息。 然后按格式进行解析。 把其中工具调用的信息， 产出的交付物信息， token 等信息都提取出来。 然后进行验证。 而一般验证会有几种形式：

• 脚本：主要验证容易自动化的部分，比如工具调用正确率，重复调用率，错误调用率，产出物正确率这些可以从调用轨迹中提取出来的信息。 而产出物一般都会编写一些脚本来进行验证。主要是验证产出的例如 csv 文件是否正确产出，如果有明确预期答案，会验证其中的内容是否正确。 或者去第三方系统中查询数据是否正确被填写。
• 人工：主要针对最后结果进行评估，毕竟模型给的答案是通过文字 + 交付物来完成的。而且调用轨迹有些时候是通过模型的思考过程才能判断的。这就跟大模型评测的形式差不多。 你需要人工主观的去判断。
• 裁判模型：还是引入一个 LLM， 我们每个 case 写一个对应的规则来让大模型来判断。 比如对于控制面的跳步漏步的验证。 我们可以让 LLM 分析被测模型返回的思考过程和最终答案等信息。 让他拆解其中的步骤，然后与要求的步骤对比， 看是否严格按照步骤来。 比如我们之前不是分享过一个 UI 自动化测试的 skill 么，这个 skill 最终是一个多 Agent 形态的，最后一个 Agent 是专门用来测试的 Agent。 而我早期的单 Agent 版本中，经常会出现测试过程被跳过的情况， 虽然最终产出物是正确的，都生成了自动化测试脚本，但它跳过了测试过程也是不对的（单 agent 由于上下文腐化，经常会出这种问题）。 所以我才说 skill 评测，或者说 Agent 评测，不能只针对最终交付物进行评估，还要针对其中的执行步骤，工具调用等进行评估。 而裁判模型，就是在人力紧张的情况下，让大模型来分析运行轨迹，看看是否遗漏了步骤。

skill 的测试工具

一般在我们这样专门做 AI 的团队，都会有自研的评测工具， 尤其是现在 AI 编程很普遍，只要知道方法论，开发一个其实不困难。 但没有经验的同学总归还是希望有个思路。 那这里我也推荐一个开源的工具（针对 skill 评测的）， 阿里最近开源了一个名叫 skill-up 的工具，虽然现在能力还偏弱（毕竟刚开源），但其中的一些思路，大家还是可以借鉴的。 比如我给一个 case 的样例， 它使用 yaml 来管理 case 的：

id: pipeline-summary-quality
title: 总结内容质量（agent_judge 语义评审）
description: |
  LLM 评审 summary.md：是否点名需关注的门店、数字是否与 CSV 一致、建议是否可操作。

input:
  prompt: |
    使用 data-pipeline-analyst skill 完成以下任务：
    拉取 2026-10-07 到 2026-10-10 的门店日销售数据（通过 sales-datasource 工具），
    用 pandas 做聚合分析，产出 analysis_result.csv，并基于 CSV 数据撰写 summary.md 总结。

expect:
  files_exist:
    - "summary.md"

judge:
  type: agent_judge
  model: sonnet
  criteria:
    - "总结点名了所有需要关注的门店，并给出其退款率与退款订单数"
    - "总结中的数字与 analysis_result.csv 中的数据一致，没有出现 CSV 中不存在的数据"
    - "给出了至少 2 条可操作建议，针对具体门店给出具体动作，而不是空泛表述"
    - "结论明确（哪家店最差、差在哪），而不只是罗列数字"
  pass_threshold: 0.7
  timeout_seconds: 120

上面是 skill-up 的一条测试用例， 它是用 yaml 来进行管理的。 可以看到 input 是我们的测试数据， expect 字段是一种断言，断言 summary.md 文件必须要存在，这是在断言 skill 的交付物。 而 judge 字段是另一个断言， 这里我们使用了 agent_judge，也就是裁判模型， 可以在 criteria 规定让裁判模型来验证的规则。 这与大模型评测是一样的。 当然也可以用脚本进行断言，比如另一个 case：

id: pipeline-trajectory
title: 执行轨迹健康度（工具调用次数、顺序、过程精简度）
description: |
  skill-up 采集轨迹但不做聚合计算，本用例用 script judge 自行统计：
  MCP 恰好调用 1 次、先拉数据后写文件、确实执行 pandas、无冗余写入、过程不过度冗长。

input:
  prompt: |
    使用 data-pipeline-analyst skill 完成以下任务：
    拉取 2026-10-07 到 2026-10-10 的门店日销售数据（通过 sales-datasource 工具），
    用 pandas 做聚合分析，产出 analysis_result.csv，并基于 CSV 数据撰写 summary.md 总结。

expect:
  files_exist:
    - "analysis_result.csv"

judge:
  type: script
  script_path: evals/fixtures/scripts/verify_trajectory.py
  timeout_seconds: 60

上面用的断言就是一个脚本。 同时也可以有工具调用断言，如下：

id: pipeline-mcp-and-csv
title: 必须调用 MCP 拉数据并产出带正确表头的 CSV
description: |
  规则校验：确实调用了 sales-datasource 的 fetch_store_sales 工具（含正确参数），
  且产出了 analysis_result.csv 与 summary.md，CSV 表头符合 schema。

input:
  prompt: |
    使用 data-pipeline-analyst skill 完成以下任务：
    拉取 2026-10-07 到 2026-10-10 的门店日销售数据（通过 sales-datasource 工具），
    用 pandas 做聚合分析，产出 analysis_result.csv，并基于 CSV 数据撰写 summary.md 总结。

expect:
  files_exist:
    - "analysis_result.csv"
    - "summary.md"
  file_contains:
    - path: "analysis_result.csv"
      content: "store,orders,refunded,refund_rate,avg_order_value,total_sales,conversion_rate,status"

judge:
  type: rule_based
  success:
    - tool_called:
        name: "mcp__sales-datasource__fetch_store_sales"
        args:
          dataset: "store_daily_sales"

Skill-up 目前的功能还比较简单，不过很适合新手或者新团队进行使用。 当其实最好的方式仍然是根据自己的需要用 AI 定制一个工具出来。 大家可以借鉴 skill-up 的这种设计哲学。

结尾

最后再宣传下我得星球吧，更多教程可以加星球获取。也有专门的微信群。