Agent Skill 评测实战：别再写完就算，先把对照实验跑起来
如果只看标题，这像是一篇教你“怎么写 Skill”的文章。真正读完会发现，它更像一篇给 Skill 建软件工程观的文章。作者先讲 Skill 是怎么来的，再讲 Description 和 Body 怎么写，最后把重点落在评测和迭代上。对我来说，最值得留下的恰恰是最后这一段。
因为 Skill 一旦开始进真实工作流，它就不再只是一个 Markdown 文件，而是概率系统上的一层执行接口。
原文前半段先把 Skill 放回到 Agent 能力扩展的上下文里。MCP 解决的是连接问题，让 Agent 能摸到工具和数据；AGENTS.md 是社区用自然语言补项目上下文的尝试；Skill 则把这件事标准化成一个文件夹结构，把指令、脚本、参考资料和资源组织到一起。
这一段很重要，因为它解释了 Skill 的定位。Skill 不是再造一个模型能力，而是把你团队的规范、流程、经验和工作手册外置出来，让 Agent 不必每次都从零学。
作者还专门讲了渐进式披露。description 常驻系统提示词，负责告诉 Agent 这个 Skill 什么时候该用；SKILL.md 在匹配后再加载；references/ 和 scripts/ 只在真正需要时进一步读取。这套机制既解决 token 问题，也决定了 Skill 的设计要分层。
这篇文章有一个很强的工程味道，就是它不把 Skill 当成一坨说明文，而是明确拆成两部分来看。
Description 解决的是“什么时候触发”。写得太模糊会过度触发，写得太窄又会漏触发。原文把它总结成三件事：能做什么、核心能力是什么、用户在什么场景下应该触发它。这个视角很实用，因为很多 Skill 之所以效果差，不是 Body 写坏了，而是根本没有在该出现的时候出现。
Body 解决的是“触发之后怎么执行”。作者给了两种常见形态：知识文档型和工作流型。前者适合规则、标准、审查清单这类任务，后者适合需要分步骤推进、要调用脚本或工具的场景。看到这里其实已经能明白一件事：Skill 写作不是文学创作，它更像在设计接口说明和执行约束。
我认为原文最有价值的部分，是第四节“基于评测迭代”。作者没有把评测当附属建议，而是直接把它视为 Skill 开发不可省略的一环。这个判断完全正确。
原因很简单。Skill 面向的是概率系统，你没法凭直觉判断一段 Description 或 Body 到底是更好了，还是只是更长了。没有评测，团队最终只能靠几条主观反馈和零散体感做决策，这种方式迟早失真。
原文给出的几条原则都很实用：
Description和Body要分层评测- 评测必须有对照组
- 评测里必须保留人类判断
这里的对照组尤其关键。新建 Skill 时，对照组可以是“无 Skill 裸跑”；改进已有 Skill 时，对照组可以是旧版本。如果没有比较基线，你永远说不清这次修改到底是优化还是噪声。
原文后面把 Description 评测和 Body 评测拆开了，我觉得这个拆法比很多泛泛而谈的“多测几轮”有用得多。
对 Description 来说，重点不是输出质量，而是触发精度。评测集要同时包含应触发的 query 和不应触发的 query，而且反例不能太傻。真正有价值的，是那些共享关键词、但语境不该触发的边界 case。
对 Body 来说，重点则回到结果质量和执行质量两层。结果有没有达标，执行过程中是不是绕了很多无效步骤，token 和时延有没有失控，这些都该一起看。只看最后结果，很容易把“一次侥幸成功”误判成稳定表现。
原文甚至把后续迭代路径也讲得很清楚：失败之后不要立刻往 Skill 里继续塞 MUST 和 NEVER，而是先看问题到底属于哪一层。是描述不准、指令冗余、任务拆分不对，还是有些确定性动作该沉到脚本里。这个判断力，才是 Skill 工程化真正难的地方。
这篇文章给我的一个直接启发是，Skill 评测不一定要从很重的体系开始。一个最小闭环就已经够用了：
- 给核心 Skill 准备一组稳定的小型评测集
- 每次修改都同时跑实验组和对照组
- 分开记录触发效果、输出质量和执行成本
- 根据失败样本决定是删指令、改拆分，还是沉脚本
- 用完整评测集重跑，不靠印象拍板
原文后面还举了官方 Skill-Creator 演进和代码审查 Skill 迭代的例子，意思其实很明确：Skill 的质量不是一次写出来的，而是靠评测驱动不断逼近。
我读完后的结论很简单：Skill 写作当然重要，但真正决定它能不能进入生产环境的，不是“会不会写格式正确的 SKILL.md”，而是“有没有把它当成一个需要持续回归验证的系统部件”。
这也是为什么我同意作者最后的判断。Skill 的价值，不在于让 Agent 看起来更聪明，而在于把那些本来每次都要重新交代的经验和流程，变成可触发、可执行、可评测、可迭代的资产。没有评测，这些资产迟早会老化；有了评测，它才有资格进入团队的长期能力栈。