一个 Skill 最后返回了正确答案，能不能算通过？
不一定。
它可能没有调用预期 Skill，而是模型凭已有知识猜出了答案；也可能调用了错误工具，只是碰巧得到可接受结果。更危险的是，文字回复说“文件已保存”，实际文件并不存在，或者写到了错误位置。
测 Prompt 时，输入和输出往往是主要证据。测 Skill 时，还必须验证它是否在正确时机出现、是否正确执行、是否产生真实结果。
Skill Eval 测的是办事能力，不只是回答能力。
Skill 成功是一条乘法链
一个 Skill 从用户意图走到任务完成，大致要经过三段：
被正确发现和触发 × 按正确流程执行 × 产物与状态满足任务 = 真实任务成功。
假设三个环节分别有 90% 的成功率，端到端成功率并不是 90%，而是三段成功率的组合。
这意味着，只优化最后输出无法解决全部问题。Skill 的质量至少需要五道门：
- 触发是否正确；
- 工具和过程是否正确；
- 产物和状态是否正确；
- 异常情况下是否安全；
- 在目标模型上是否稳定且成本可接受。
第一道门：该出现时出现，不该出现时别乱动
Skill 首先需要被模型“看见”。
用户不会总按 Skill 描述中的标准用语表达需求。他们可能使用简称、口语或间接目标。一个飞书文档转换 Skill，用户可能说“把这个需求整理成开发能看的版本”，不一定会说“调用文档转换 Skill”。
触发评估至少需要四类案例。
正例
用户意图明确符合 Skill 能力，应该稳定触发。
正例不能只复用 Skill 描述中的措辞，还要覆盖真实用户的不同说法。
负例
任务明显不适用，不应该触发。
例如 Skill 负责“整理已有材料”，用户要求“搜索最新行业信息”时，不应在没有外部研究能力的情况下强行执行。
边界例
信息不足、授权不清或任务范围模糊。
正确行为可能不是立即触发，而是追问、提示缺少材料，或者让用户确认高风险动作。
混淆例
任务与另一个 Skill 很相似，用于验证路由边界。
例如“润色现有文章”和“从源材料写一篇新文章”可能需要不同 Skill。两者都与写作有关，但工作目标和证据边界不同。
触发质量通常会看两个方向：
- 需要时能不能找到，避免漏触发；
- 不需要时会不会乱调用，避免误触发。
高副作用 Skill 更应该减少误触发。一个只提供建议的 Skill 漏触发会影响体验；一个能删除文件或修改线上数据的 Skill 误触发，风险完全不同。
第二道门：工具、参数和关键步骤是否正确
Skill 被触发之后，不能只等着看最终文本。
需要检查执行轨迹中的关键节点：
- 是否先完成必要的只读检查；
- 是否选择了正确工具；
- 参数、路径和目标对象是否准确；
- 是否按正确顺序执行；
- 外部工具失败后是否重试、降级或停止；
- 是否重复执行已经完成的写入。
这里有一个边界：不要试图约束模型的每一步思考。
Agent 可以通过多条路径得到同样合法的结果。过程评估只应固定必须遵守的业务规则和安全约束，例如“写入前确认目标”“不能跳过权限检查”“只能修改指定文件”。
如果连无关步骤都写成唯一正确路径，测评会把合理的模型差异误判为失败。
第三道门：产物和真实状态是否正确
最终回复只是 Output，也就是用户看到的文字。
对于会执行任务的 Skill，还要检查至少三类证据：
- Trace：整个执行过程；
- Artifact：生成的文件、报告、代码或结构化数据；
- State：执行前后真实系统状态。
假设用户要求创建一份 Markdown 报告。
只检查回复中的“已完成”远远不够。还要验证：
- 文件是否真实存在；
- 是否保存在正确目录；
- 文件能否打开；
- 内容是否完整；
- 是否覆盖了不该覆盖的旧文件；
- 回复中提供的路径是否与真实路径一致。
如果 Skill 修改外部系统，还要比较执行前后的状态。例如创建草稿后，草稿是否真的存在；更新记录后，是否只改动了指定字段；失败后是否留下半完成状态。
声明完成和真实完成必须分别验证。
第四道门：失败时是否安全、可恢复
Agent 的价值在于代替用户执行动作，风险也来自这些动作。
异常场景中，下面几项通常要独立设为硬门：
权限
Skill 是否只使用完成任务所需的最小权限？没有授权时，是否停止而不是尝试绕过？
确认
删除、覆盖、发布、发送消息或改变线上状态之前，是否在需要时获取用户确认？
可恢复性
执行失败后，是否能回滚、重试或清楚说明当前状态？哪些结果不可恢复，是否提前告知？
清理
临时文件、测试数据、会话和中间状态是否被清理？失败是否会污染下一次运行？
幂等性
用户重复点击或系统自动重试时，是否会重复创建数据、重复发消息或多次扣费？
安全问题不能用“最终任务成功”抵消。一个成功生成报告但同时泄露敏感数据的 Skill，仍然是失败。
第五道门：目标模型上是否稳定
Skill 与模型之间存在真实的适配差异。
有的模型更容易理解 Skill 描述，有的模型工具参数更稳定，有的模型在长任务中容易漏步骤。只在一个模型上跑通，不能说明它适用于全部模型。
跨模型评估不需要追求支持越多越好，先明确产品范围：
- 哪些模型必须支持；
- 哪些模型只作为降级或候选；
- 是否允许为特定模型保留适配版本。
然后在相同任务上分别检查：
- 触发成功率；
- 工具与参数正确率；
- 任务成功率；
- 严重失败；
- 重复运行稳定性；
- 延迟、Token 和工具调用成本。
不要把多个模型平均成一个总分。一个核心模型出现严重退化，不能由另一个模型的高分补回来。
一张可直接使用的 Skill 验收表
| 验收层 | 核心问题 | 主要证据 | 典型硬门 |
|---|---|---|---|
| 触发 | 该用时能否找到，不该用时是否克制 | 触发结果、候选路由 | 高风险误触发 |
| 过程 | 是否选择正确工具、参数和关键步骤 | Trace、工具调用记录 | 越权、跳过确认 |
| 结果 | 输出、文件、数据和状态是否真实可用 | Output、Artifact、State | 虚假完成、错误写入 |
| 异常 | 失败后是否安全、可恢复、无污染 | 错误记录、回滚与清理结果 | 数据损坏、敏感泄露 |
| 适配 | 目标模型上是否稳定且成本合理 | 多次运行、模型分组 | 核心模型不可用 |
每个 Skill 都可以在这张表上增加自己的专业要求，但不应删掉触发、过程、结果和安全这四条主线。
完成 Skill 的完整评估之后，下一步才是比较修改前后：新版究竟真的改善了能力，还是只在几个案例上运气更好。
Agent 测评入门系列
- 【Eval】Agent测评不是简单给回答打分
- 【Eval】测试同学别焦虑，Eval也不是替代品
- 【Eval】第一次Eval，先干小事情
- 【Eval】测Skill，不只是盯结果（本文）
- 【Eval】分数变高，不代表版本真的变好
- 【Eval】规则、AI裁判和人工怎么成为铁三角
- 【Eval】离线全通过，上线仍会失败的原因到底是啥