Agent 早期没有 skills 这个概念，只有 rules，一条全局性的系统提示词，出现在 Cursor 里。从单文件规则到多文件匹配，形态一直在变。到底什么叫好？这是一个很自然的疑问。

笔者最近做产品 SEO 优化，涉及若干 SEO 相关 skills 的评估，遇到不少麻烦。description 重叠导致触发不稳定；模型把过程证据外推成最终结果；缺数据时猜测性补全；模型自评无法证明任务真的完成。大模型固有的幻觉问题推着你去想：怎么才算「评估到位了」。

Agent eval 学术界做得够多了，测试、归因、基准集，不缺综述。本文不打算搞成学术文章，更多从个人用 skills 的经验出发，聊聊怎么看待评估这件事。

Skills 为什么被造出来

回到原点：skills 为什么被造出来？从它要解决的问题出发，就能想清楚怎么评估它。

Skills 最早是一个系统级提示词。问题在于，系统提示词覆盖面太广，不是所有场景都适合反复注入。自然想到做分级和索引。这就是 skills 结构体的由来：title 和 description 做索引，描述它要做什么；下面是详细约束和要调用的工具。

它填补的是通用模型在垂直领域的缺失。除知识缺失外，还有风格缺失。模型知道怎么写代码，但不知道团队的编码、发布风格。

Cursor 做这件事最早。从单文件 .cursorrules 到多文件 .cursor/rules，再到现在的 Agent Skills 目录。长期规范和项目事实留在 Agent.md，条件性的工作流程放 skills。

系统提示词是公司文化，每时每刻都要参照的行为守则；skills 是处理特定工作时翻找的 wiki 目录。

组织 vs 个体对于 Skills 的需求

对于大公司

大公司需要 skills，因为内部有大量隐性的语言和约束。版本号怎么写、数据源口径用什么。过去这些统一约束在人与人协作时，叫文档。

对于个体

个体层面，skills 更像是重复工作的 SOP 包装。有些问题反复出现，就该做成流程。在 Agent 里，这就叫 skills。

从组织到个体

大公司内有动力把员工经验沉淀为 skills。资深人员把经验总结下来，交给新手执行。过去组织规范化的动作是梳理 SOP 文档，现在变成总结 skills。

对于资深人来说，过去写文档，文档上留我的名字，是增强影响力的方式。现在 skills 交出去，很少有人在意谁写的。工作交出去，HC 也就交出去了。其中的劳资关系很微妙。

文档的阅读对象也从 Junior 变成了 Agent，Junior 的职业发展更难，少有公司还愿意培养初级员工。

评估的实用主义

Skills 是给 Agent 读的 SOP。既然是 SOP，预期就是：重复相同步骤，达到一样的结果。换人或换 Agent，效果不变。

那怎么验证这一点？一搜 skills eval，出来的全是数据驱动、AB 测试、增益模型。没错，但太专业了。非工程背景的人做不到，对单个小 skill 做了也未必有意义。这些方法都在回答同一个问题：加上 skills，达到预期目的了吗？

大厂里做严密分析不奇怪。过去做产品也是这个思路：要评判效果，就做消融实验，分流开 AB。但 skills 和产品策略不太一样。产品策略的验证需要大量数据，得出来的仍然只是置信数据，不代表 A 一定优于 B（置信不代表对）。

工程角度可以讲很多，但普通人关心的就是效果。甚至不在乎能否稳定达到效果，体感上有效就行。学术界倒是做了系统对比，简单来说就是专有领域如医疗提升巨大、软件领域加 skill 基本无提升。

感觉有效，大概率就有效。有时候感觉比数据实验管用。不要高射炮打蚊子。对大部分人来说，用了某个 skills，目标达成了，工作量降低了，成本没有明显增加，它就合格了。

更进一步的评估

一次有效是体感，反复有效才算数。

笔者的标准是三条：可复现、不添乱、好维护。这也是给 Cursor 定的早期工程约束。

可复现，意思是同一个任务跑几遍，结果稳定。不是第一遍写出完整代码，第二遍给你半成品。如果结果忽好忽坏，大概率是 description 写得不够精确，模型在不同上下文里理解不一致，无法准确触发。

不添乱，意思是 skill 不引入额外问题。常见的添乱：token 消耗突然翻倍，说明指令太模糊，模型在反复试探；和其他 skill 或 rules 冲突，执行路径被带跑偏；skill 里调用的工具或脚本在特定环境下报错。

好维护，意思是换个项目或换个模型，skill 还能正常工作，好扩展。如果一个 skill 只在特定模型版本上有效，换了版本就废了，维护成本太高。

大部分人到这一步就够了。只有当 skill 反复不达预期，或者你想把它分发给团队或外部时，才需要往下走。

什么时候做系统评估

什么时候从「体感判断」切换到「认真排查」？几个典型的触发点。

效果不如意，这个最直接。用了 skill 反而更差，或者时好时坏，就该停下来看了。不同上下文下表现不一致。同一个 skill 在不同项目里效果差很远，说明触发条件或适用范围写得不够精确。

Skills 数量增多到触发率下降、错误触发。实操经验：同一类主题，3 到 5 个精简 skill 效果最佳，数量超了模型收益骤降。

切换模型。基础模型能力一升级，原来需要 skill 辅助的任务模型自己就能做了。这时候应该果断删掉过时的 skill，重新跑一遍对比。模型升级对于软件编程方面，影响更大。内部流程向的影响较小。

要分发给团队。自己用着好的 skill 迁移给别人，效果往往不如预期。别人的项目结构不同、模型配置不同、配合的 rules 不同，原来跑得好的 skill 可能不工作。分发前要评估依赖关系、明确预期交付物。

安全也是这个阶段需要认真对待的。skills 和 npm 包一样，来源不可控就有被注入恶意逻辑的风险。今年已经发生了不少来自 skill 注入的恶性事件。

触发了评估之后，排查思路也是顺着 skill 自身的结构走：触发条件对不对，执行路径有没有跑偏，终止条件是否合理，调用的资源和工具有没有冲突。拆成这几块，逐个排查。

系统评估怎么做

到这一步，说明你已经不满足于「感觉」了。系统评估要回答：这个 skill 到底改变了什么，改变了多少，值不值得它带来的成本。

设置对照

最基础的是有无对比。同一个任务，开着 skill 跑一遍，关掉跑一遍，对比结果和过程。不只看最终产出，还要看中间步骤：工具调用对不对、推理路径有没有偏、有没有多余的重试。如果关掉 skill 模型也能完成，这个 skill 的边际价值就存疑。

更细致的做法是把「效果」和「触发」分成两次实验。三个条件：不加 skill、强制加载 skill（明确告诉 Agent 这个 skill 可用）、自然触发（不提示，看 Agent 自己会不会激活）。第二和第三之间的差就是触发率。触发率低说明 description 没写好，或者 Agent 根本认不出来该用它。

Anthropic 自己也承认模型有欠触发倾向，建议 description 写得强势一点。测试需要测试集。8 到 12 个精确 case 起步，绑定真正重要的决策和失败模式。

判定方法

能用代码、正则的不用模型打分。模型有先天性的同类偏好，且成本不低。通过规则检查硬性条件：文件是否存在、JSON 是否合法、工具调用参数是否正确、某个不该发生的状态变更有没有发生。

难解的语义问题才交给模型打分，给评分标准、参考答案和弃权选项。

用模型互评时需注意：随机化呈现顺序；多次投票取多数；设最小差值阈值，排除噪声导致的伪排序。用 A 模型评 B 模型的输出，以避免同类偏好。

成本和时间

skill 是纯 context 开销。加了 skill 之后 token 消耗突然翻倍，往往说明指令写得太模糊，模型在反复试探和补全。时长也是：如果一个 skill 让任务慢了三倍，效果提升那点可能不值得。

轨迹分析

记录 Agent 的推理过程、工具调用、状态变更，定位失败发生在哪一步。有 skill 和没 skill 的轨迹放一起比，能看清 skill 具体改变了哪些行为。不过轨迹评判目前主要靠模型打分，主观性是绕不开的。

边际贡献

有无 skill 的差值接近零，说明模型本来就具备该行为，这个 skill 可以删掉；增量大的地方标记出 skill 里真正起作用的部分。增量接近零就删，这是评测最直接的产出。

评估频率

一般而言，评估是伴随着改动发生的。可以是 skill 本体变更、也可以是更换任务、更换模型。生产中出现的反面案例，很适合放到 case 库里作为边界进行判定。

整理一下方法和适用场景：

方法 看什么 适合什么阶段
有无对比（配对对照） 加 skill 前后的结果和过程差异 所有阶段的基础方法
三条件实验（无/强制/自然） 触发率，description 是否有效 skill 写好后的首次验证
代码判定 文件存在、参数正确、状态变更 有明确预期产出的任务
轨迹分析 推理路径、工具调用、失败步骤 排查失败原因
Token 和时长监控 成本波动、运行时长变化 日常监控，发现质量劣化
跨模型验证 skill 的通用性、模型特性干扰 换模型、分发给团队前
delta 审计 边际贡献是否存在 定期清理 skill 库

核心评估以外的问题

以上是针对单个 skill 的方法。跳出来看，skills 生命周期里，从开始写到一起用，还有几个结构性问题。

AI 自生成的 skills 可能不可靠。基准测试里模型自己写的 skill 平均效果为负。原因还是模型不能准确把握自身权重外的知识。核心 SOP 最好人来控制内容（或提供清晰方向参考）。措辞要明确，写清楚什么时候该触发、什么时候不该触发。当然还有前文提到的，触发指令写得激进一些这类。

Skill 之间会冲突。多个 skill 同时加载，指令互相矛盾，模型不知道听谁的。这是上下文腐败问题，skills 越多越明显。这部分内容，也可以算上面评估的一部分。将已有skills看作系统整体，剩下思路类似。

可观测性已经开始被量化。不少框架试图把「会不会被触发」正式变成了可测量的指标，也开始追踪 skill 调用率。但对个人来说，目前还没有好用的工具让你看清自己几十个 skill 里哪些在高频工作、哪些从没被触发过。Claude 目前据我所知，/doctor 指令可以实现部分目标。

版本管理的问题在缓解。今年 8 月多厂商联合发布 Agent Plugins 1.0，把 skills 和 MCP 打包成可分发的标准目录。过去跨 agent 维护多份副本的问题，会得到进一步改善。

最后，skills 解决不了编码风格、整体架构的问题。笔者刚开始觉得 Cursor 比 Codex 好用，是因为 rules 层面积累了半年多的约束。这些约束迁移到 Codex 后，编码体感舒服很多。

后续方向

Skill 后面会怎么变？这可能是专门做 skill 研究的人才需要考虑的事。不过从研究进展来看，这个方向正在快速成形：

时间 事件 评估关注点
2025-01 Cursor 推出多文件 .cursor/rules 规则描述、智能附加
2025-10 Anthropic 发布 Agent Skills 触发、意外轨迹、脚本安全
2025-12 Agent Skills 开放标准；OpenAI Codex 采纳 跨平台兼容、渐进加载
2026-02 SkillsBench v1.0；skills.sh 自动审计上线 有无 Skill A/B；平台侧安全基础设施
2026-03 SkillRouter（阿里）；三大市场累计约 49 万 skill description 路由在大池子下失效
2026-04 Tessl 评测框架；SkillsMP 单平台超百万 skill 三条件配对评测；规模问题
2026-06 SkillsBench 1.1 任务集扩容、追踪 skill 调用率
2026-08 Agent Plugins 1.0（五家联合）；NVIDIA SkillEvaluator 跨端打包同步；厂商持续评测

回头看这十个月：

研究主线变了。从「skill 能不能提高任务成功率」，转向「什么 skill 在什么模型、任务、环境下，产生了多少可归因且值得成本的增益」。

篇幅和受众限制，这篇文章点到为止。笔者整理了一份更完整的技术评估路径文档，包括具体的评估方法、实验设计和用于评估 skills 的 skills。想了解实操细节的朋友，可以关注或联系笔者获取。

参考资料

关于作者