Skill Eval 实践
市面上存在诸多用于评估 Skill 的工具，但它们大多仅停留在阅读结构与内容层面，依赖 LLM 进行主观评判。此类评估缺乏说服力，难以在模型替换或 Skill 变更时提供可靠依据。
此前我们已了解 Skill Eval 的基本流程：
系统化评估 Agent Skill (Skill Eval)
- 构造正反例，验证 Skill 是否被正确触发；
- 执行 Skill，观察流程与结果是否符合预期；
- 对比有无 Skill 时的执行结果，确认其实际效用。
原理虽易懂，但实践易陷入盲目。本文将解析 Anthropic 官方的 skill-creator，演示如何构造测试集，并采用更严谨的手段（LLM-as-a-judge + 人工判断）为 Skill 打分。
Skill 构成
skill-creator 地址：https://github.com/anthropics/skills/tree/main/skills/skill-creator[1]
安装命令如下：
npx skills add https://github.com/anthropics/skills --skill skill-creator
该 Skill 逻辑复杂，不仅能创建符合标准的 Skill，还能自动执行评估流程，确保创建过程严谨。
| 主要文件 | 作用 |
|---|---|
SKILL.md |
定义 Skill 名称、触发描述及完整工作方法。核心思想：明确目标→编写 Skill→测试验证→迭代优化。 |
agents/analyzer.md、agents/comparator.md、agents/grader.md |
专供评估角色使用：grader按断言检查输出，comparator盲评两个结果，analyzer分析 Benchmark 或对比结果背后的原因。 |
scripts/*.py |
提供可重复执行工具，包括校验、打包、聚合 Benchmark、运行 Description 触发评估、自动改进 Description 及生成报告等。 |
eval-viewer/generate_review.py、eval-viewer/viewer.html |
生成可浏览的评审页面，展示测试输出与 Benchmark 结果，便于用户逐条查看、反馈及版本比较。 |
assets/eval_review.html |
用于人工检查 Description 触发评估题集，支持用户在浏览器中调整应触发 Skill 的 Query。 |
references/schemas.md |
说明 evals.json、grading.json、timing.json、benchmark.json、comparison.json、analysis.json 等文件格式规范。 |
整体执行流程如下：
定义和编写 Skill：明确解决的问题、触发时机及输出格式，写入
SKILL.md。若逻辑复杂，可将脚本、参考资料或模板放入对应目录。运行测试和评估：准备真实用户测试提示词，并行运行「使用 Skill」与「不使用 Skill/旧版 Skill」两组结果。评估结合人工查看、断言检查、耗时、Token 消耗及 Benchmark 汇总。
反馈迭代 Description：用户通过评审页面查看输出并反馈，系统据此修改 Skill。待输出稳定后，进一步优化
description的触发效果，最终打包交付。
本文重点聚焦第 2、3 步：如何对 Skill 进行评估测试，以及如何对 Skill 的 Description 进行评估优化。
评估 Skill
评估 Skill 的核心流程总结为：
- 设计测试用例与 Rubric 标准（多维度打分准则）；
- 分别在使用与不使用 Skill 的情况下执行用例；
- 由 LLM 对结果打分，辅以人工查看与反馈。
以创建写作 Skill 为例，Skill 创建完成后，将同步生成测试用例文件 eval.json。
每组测试用例将派发 2 个 Subagent，分别在“使用 Skill"与“不使用 Skill"状态下执行创作任务。3 个用例共计产生 6 个执行结果。
每个执行结果包含两类评价：维度打分与 Token 消耗（注：部分模型如 GLM5.2 可能未捕捉到 Token 消耗数据）。
最终产出使用 Skill 后的测试通过率，以及 Token 与耗时的变化数据。
借此流程，可得出严谨结论：Skill 带来了多少提升，是否节省 Token 或提高时间效率。
相关思路参考：https://agentskills.io/skill-creation/evaluating-skills[2]
评估与优化 Description
Skill 采用按需加载与渐进式披露机制，其触发与否取决于 Name 与 Description 的编写质量。评估的关键在于：Description 是否足够精准，确保 Skill 在该触发时触发，不该触发时保持沉默。
skill-creator 提供了一套“测评 + 优化”Description 的思路：
首先生成 20 个 Prompt 用例，其中 10 个应触发 Skill，另 10 个不应触发。例如，“请写一篇关于 xxx 的博客”应触发写作 Skill，而“请修改这个页面的风格”则不应触发。Agent 生成用例供审查，确认无误后进入后续流程。
Agent 将这 20 个用例切分为训练集与测试集。执行训练集时，若出现非预期情形，Agent 将持续优化 Description；测试集则用于防止过拟合。经过最多 5 轮迭代，测试集评分最高的 Description 将被选为最终版本。
详细流程参考：https://agentskills.io/skill-creation/optimizing-descriptions[3]
总结
初期尝试用 Codex完成全流程未果，因其未能严格遵循工作流（如仅执行 with-skill 测试，缺失 without-skill 对比，且中途断开）。
切换至 Claude Code 后，成功跑通复杂的测评与优化流程。测试表明 Opus 4.7 与 GLM 5.2 均可顺利完成，可见 Skill 设计需充分考虑执行 Harness 的兼容性。
总体而言，skill-creator 的执行体验仍有局限：一是工作流过长，Agent 难以百分百遵循指令；二是 Token 消耗巨大。
仅靠 Skill 驱动复杂工作流并不可靠，指令遵循度亦不理想。此外，单一 Skill 完成的测评并非绝对严谨，结果复现性存疑。工业级 Eval 仍需功能完整、可复用的框架支撑。