Skill 有评测与无评测对比：复杂业务中经验如何回归

在 Agent 能力建设的过程中，Skill 正在成为承载业务经验的重要载体。但一个常被忽略的问题是：写完 SKILL.md 就算完成了吗？还是说，Skill 必须配套评测体系才算真正成立？本文围绕“无评测的 Skill”与“带评测的 Skill”展开对比，帮助开发者和技术负责人理解两者的本质差异，并给出可落地的评测设计思路。

一、对比背景：为什么需要讨论这个问题

很多团队第一次建设 Skill 时，习惯把它当成一份“更懂业务的说明书”：把流程、术语、注意事项写进 SKILL.md，再补充一些 references/ 文件，似乎 Agent 就能稳定变强。

但实际落地后常见的情况是：

• 某些场景下 Skill 表现很好，换一个输入就误用规则；
• 该触发的时候没触发，不该触发的时候强行介入；
• 修改了一处逻辑，旧场景的能力悄悄退化；
• 团队无法回答“这个 Skill 到底比不用更好吗”。

这些问题的共同点是：它们不能靠感觉回答，只能靠评测回答。因此，本文对比的两个对象是：

• 对象 A：无评测的 Skill——只有 SKILL.md 和若干参考文件，没有测试集、没有回归机制；
• 对象 B：带评测的 Skill——SKILL.md + evals/，既有经验承载，也有经验验证。

二、对象定义：两者分别是什么

无评测的 Skill，本质上是“Markdown + 期待”。它把专家经验写成文档，期望模型按文档执行。它的价值上限取决于文档质量和模型理解力，但没有任何机制证明它在真实任务中可靠。

带评测的 Skill，把 Skill 建设看作一个循环：先写 Skill，再设计真实测试提示，分别跑“使用 Skill”和“不使用 Skill”两组，对比输出与基准表现，然后继续迭代。它的核心判断是：Skill 不是写完就成立，而是要证明它让 Agent 变得更可靠。

从结构上看，两者差异可以这样理解：

层级	无评测的 Skill	带评测的 Skill
入口层	SKILL.md	SKILL.md
知识层	references/	references/
执行层	scripts/	scripts/
模板层	assets/	assets/
验证层	无	evals/（测试提示、期望行为、回归基线）

三、相同点：两者共享的基础逻辑

在展开差异之前，需要先明确两者的共同点，避免把对比简单化为“好与坏”：

1. 目标一致：都是为了让 Agent 在复杂业务中更准确地行动，降低错误率。
2. 结构相似：都以 SKILL.md 为入口，都可能包含参考知识、可执行脚本和模板资源。
3. 依赖模型能力：两者最终都依赖模型对上下文的理解与调用能力，不能脱离模型单独存在。
4. 需要业务输入：两者都要求专家把判断、路径、禁忌和工具使用方式显式化。

真正的差异不在“有没有写文档”，而在“能不能验证文档是否有效”。

四、核心差异分析

1. 技术架构：静态说明 vs 闭环系统

无评测的 Skill 是单向的：人写文档 → 模型读取 → 输出结果。它没有反馈回路，出了问题只能靠人工观察。

带评测的 Skill 是闭环的：写 Skill → 设计测试提示 → 跑对照实验 → 分析差异 → 迭代 Skill。evals/ 目录承担了“验证层”的角色，使 Skill 从静态说明变成可迭代系统。

2. 功能能力：能否回答关键问题

无评测的 Skill 无法系统回答以下问题：

• 它能否在真实业务场景里稳定降低错误率？
• 它是否真的比不用 Skill 更好？
• 它修改以后，旧能力有没有退化？

带评测的 Skill 通过对照实验和回归测试，可以逐项回答这些问题。它不仅能证明“有效”，还能定位“哪里无效”。

3. 触发与边界控制

Skill 的一个典型风险是误触发：在不该介入的时候强行介入，或在关键场景漏用规则。

无评测的 Skill 很难发现这类问题，因为触发逻辑往往写在自然语言描述里，缺乏可验证的边界条件。

带评测的 Skill 会针对触发条件设计测试用例，例如：

测试提示：用户询问与业务无关的通用问题
期望行为：不触发该 Skill，直接回答
测试提示：用户询问涉及特定业务流程的问题
期望行为：触发该 Skill，并读取对应 references 文件

通过这类用例，触发边界从“描述”变成“可验证行为”。

4. 经验压缩的损耗可见性

Skill 本质上是“被压缩过的业务经验”：专家的判断、路径、禁忌和工具使用方式被压缩成 Agent 可按需调用的能力。但压缩会带来损耗：

• 哪些信息被省略了？
• 哪些规则写得太硬？
• 哪些场景被误触发？
• 哪些判断被模型过度泛化？

无评测的 Skill 对这些损耗几乎不可见，只能等线上出问题才发现。

带评测的 Skill 通过测试集覆盖这些维度，让损耗在迭代阶段暴露，而不是在生产环境暴露。

5. 运维与迭代成本

维度	无评测的 Skill	带评测的 Skill
初始建设成本	低	中高（需设计测试集）
问题发现时机	生产环境	迭代阶段
回归风险	高，修改后无基线	低，有回归基线
团队协作	靠口头共识	靠可复现结果
长期维护成本	隐性上升	前期投入换取可控性

需要强调的是：无评测的 Skill 初始成本低，但长期风险高；带评测的 Skill 前期投入大，但换来了可迭代性和可证明性。

6. 团队协作与决策依据

无评测的 Skill 在团队中容易变成“某个人写的文档”，修改和评审缺乏客观依据。

带评测的 Skill 提供可复现的对照结果，使评审从“我觉得这样写更好”变成“测试结果显示这样更稳”。这对技术负责人和架构师尤其重要，因为它把经验判断转化为可讨论的证据。

五、对比表格总结

对比维度	无评测的 Skill	带评测的 Skill
核心组成	SKILL.md + 参考文件	SKILL.md + evals/ + 参考文件
本质	静态说明书	可复用业务能力包
验证方式	人工观察	对照实验 + 回归测试
触发边界	描述性，难验证	用例化，可验证
回归能力	无	有基线可对比
错误发现	生产环境	迭代阶段
迭代效率	低，靠感觉	高，靠数据
团队协作	口头共识	可复现证据
适用阶段	早期探索	复杂业务、生产系统

六、典型场景选择

适合先采用无评测方式的场景：

• 业务逻辑非常简单，Skill 只做格式转换或固定模板填充；
• 仍处于概念验证阶段，目标是快速验证可行性；
• 使用频率低，错误代价可控。

更需要带评测方式的场景：

• 业务规则复杂，涉及多条件判断和边界处理；
• Skill 会被多个 Agent 或团队复用；
• 错误会带来明显业务影响；
• Skill 需要持续迭代，且必须防止旧能力退化。

七、选型建议

1. 如果 Skill 只是临时草稿：可以先不建评测，但应明确这是临时状态，不能直接上生产。
2. 如果 Skill 进入生产环境：建议至少建立最小评测集，覆盖核心场景、边界场景和误触发场景。
3. 如果 Skill 需要长期维护：建议把 evals/ 作为 Skill 的必备组成部分，与 SKILL.md 同步演进。
4. 如果团队多人协作：评测结果应作为评审依据，减少主观分歧。

判断标准可以简化为一句：当“它是否可靠”这个问题必须被回答时，评测就不再是可选项。

八、迁移与使用注意事项

从无评测迁移到带评测，需要注意：

• 不要一次性追求大而全：先从核心场景和高风险场景开始建立测试集；
• 对照实验要固定条件：同一模型、同一提示、同一环境，分别跑使用与不使用 Skill；
• 保留基线结果：每次修改后重新跑，观察是否退化；
• 关注触发行为：不仅要看输出内容，还要看是否正确触发、是否读取了合适的上下文；
• 避免过度拟合测试集：评测集要覆盖真实分布的输入，而不是只覆盖容易通过的用例；
• 权限与数据隔离：评测涉及真实业务数据时，需注意脱敏和访问控制。

九、总结

Skill 的终点不是 SKILL.md，而是 SKILL.md + evals/。前者承载经验，后者验证经验；前者告诉 Agent 怎么做，后者告诉团队它做得是否可靠。

无评测的 Skill 像一份未经验证的说明书，可能偶尔有效，也可能在关键场景中误用规则。带评测的 Skill 则把经验压缩的损耗显性化，让触发边界、规则强度和回归风险都变成可验证的对象。

在复杂业务里，经验必须能回归。评测不是额外负担，而是让 Skill 从“Markdown 和期待”变成“可复用业务能力”的关键一步。选型时不必一刀切，但只要 Skill 要进入生产、要被复用、要持续迭代，评测体系就应当同步建立。