安装完 OpenClaw 的那个晚上，我做的第一件事是这样的：
打开 ClawHub，看到几万个 Skill 整整齐齐排列在那里，于是我一个接一个地给我的小龙虾装...
但我用了几周之后，突然想到一个问题：
我装了这么多 Skill，好像真正每天用的也没几个。为什么装了几百个 Skill，我的龙虾没有变得更强呢？
然后我在社群里逛了一圈，发现有类似困惑的人不少：
有人觉得装得越多覆盖面越广，也有人反馈装多了之后，小龙虾反而经常调错 Skill，干了不该干的事。
为了搞清楚这件事，我把「小龙虾是否 Skill 技多不压身」问题拆成了三个子问题：
第一，Skill 到底是不是越多越好？
第二，如果不是越多越好，假如有一个相对合理的装 Skill 的数量区间，大概是多少？
第三，我们日常使用中，该怎么管理和使用 Skill？是否有什么最佳实践？
然后我上周花了五天的时间，翻了最近几篇跟 Agent Skill 直接相关的学术研究，也结合自己这段时间的使用经验，我试着把这三个问题理一理，然后给大家做个报告。
越多越好？不，装多了效果会变差
先说结论，根据两项最新的学术研究：
Skill 并非越多越好，在某些情况下，装多了反而会让效果变差。
第一项研究叫《SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks》，它是由俄亥俄州立大学、斯坦福、卡内基梅隆等二十多家机构联合发布。
https://arxiv.org/abs/2602.12670
这是目前第一个系统评估「智能体技能到底有没有用」的基准测试，覆盖了 86 项任务和超过 7000 条测试。
几个关键发现值得注意：
1、Skill 的效果不是越多越好，是一条倒 U 型曲线：三个最好。
只配 1 个 Skill 时，通过率提升了 17.8 个百分点。配 2 到 3 个的时候提升最多，达到 18.6 个百分点。但超过 4 个 Skill 之后，提升幅度骤降到 5.9 个百分点。
2、有接近 1/5 的任务用了 Skill 性能反倒下降了。
在全部 84 项测试任务中，有 16 项在使用 Skill 之后性能反而下降了，最大降幅达到 39.3 个百分点。
3、过于详细的 Skill 文档，对 Agent 非但没有帮助，反而让性能下降了 2.9 个百分点。
相比之下，中等长度、带有清晰步骤和实际示例的文档效果最好。写得太面面俱到，模型反而抓不住重点，大量文本占用了上下文窗口却无法提供精准指导。
让模型自己生成 Skill，效果平均下降了 1.3 个百分点，部分配置下甚至降了 5.6 个百分点。也就是说，有效的 Skill 必须依赖人类的专业设计，模型自己「悟」出来的程序性知识基本不靠谱。
5、经过人工精选的 Skill，平均能把任务通过率提升 16.2 个百分点。
人：AI，你这玩意儿可真行，学了我的知识，抢了我的岗位，还要我帮你做 Skill。
但这个提升很不均匀，在医疗领域提升了 51.9 个百分点，在软件工程领域只提升了 4.5 个百分点。这说明，在模型本身越不擅长的领域，外挂 Skill 的帮助越大，反之则边际收益很小。
第一项研究到这就讲完了，如果说 SkillsBench 这项研究，回答的是「Skill 有没有用」。
接下来分享第二项研究，它直接给出了一个结论：Skill 装多了会出问题。
这篇论文的标题是《When Single-Agent with Skills Replace Multi-Agent Systems and When They Fail》，来自加拿大和韩国的学术团队，研究者测试了不同规模 Skill 库下模型选对 Skill 的准确率。
https://arxiv.org/abs/2601.04748
这里研究的关键结论是：
当 Skill 数量在 20 个以下时，选择准确率保持在 90% 以上，几乎不会选错。超过 30 个之后，准确率开始快速下滑。到了 200 个 Skill 的时候，准确率已经跌到大约 20%。
这种下降不是线性的。研究者发现，在大约 20 到 30 个 Skill 的位置存在一个临界点，越过之后准确率呈陡峭式崩溃。
为什么数量变多会导致失败呢？
因为导致选择失败的根本原因，在于 Skill 之间的语义相似性。
当 Skill 库里有好几个功能相近、描述也类似的 Skill 时，模型就很容易选错。比如你面前摆了五把长得差不多的钥匙，大概率得试好几次才能找对，但如果每把钥匙形状完全不同，即使数量多一些，也不容易搞混。
研究还验证了一种应对策略：
通过把 Skill 分层组织，先做粗粒度的类别判断，再在小组内精选具体 Skill，可以把选择准确率从 45% 提升到 85%。
这个策略也很容易理解：如果我们把一个大决策拆成两步小决策，每一步面对的选项都足够少，判断就容易做对了。
至此，两项研究指向了共同的结论：Skill 有用，但前提是精而不是多，并且 Skill 的设计目前离不开人。
那装多少个 Skill 算合适呢？
那么，按照研究结论，Skill 只能装三个吗？
其实落到实际使用中，「给龙虾装多少个 Skill 的最优数量」这个问题没有统一答案：
因为每个人的工作场景、使用频率、业务复杂度都不一样。
不过结合研究结论和我自己的使用体感，可以给出一个比较实用的经验区间，仅供参考：
1、如果你是个人用户、小团队或者 OPC 做日常自动化的活，8 到 15 个 Skill 通常最舒服。
数量不多，你记得住每个 Skill 是干什么的，维护起来也轻松，调用命中率很高。
并且，这个范围完全落在研究显示的安全区间内。
2、如果需要覆盖多个部门或多条业务线，15 到 30 个也可以接受。
到了这个量级，就必须在命名规范、标签分类、触发条件设定和功能去重上下功夫了。
刚提到的两项研究都表明，30 个往上是准确率加速下滑的区域。
除非你已经建立了完善的分类体系和治理流程，否则增加更多 Skill 带来的好处，很可能抵不过它由于太多造成的混乱。
为什么到了一定数量就会变差？
从实际使用经验来看，主要集中在三类问题上：
1、Skill 的功能很容易重叠。
比如两个 Skill 都能处理类似的任务，描述也相近，模型在选择时就犹豫不定，调用结果变得不稳定。今天用这个明天用那个，输出质量忽高忽低，你还不太容易排查原因。
2、Skill 的职责边界比较模糊。
有些 Skill 写得太万能，什么都沾一点边，描述又很宽泛。结果就是它经常被误触发，本该调另一个 Skill 的场景被它抢了先。
3、还有就是装每一个 Skill 都有隐含的代价：维护成本。
依赖外部网站或第三方 API 的 Skill，装得越多，失效的概率越高。某个接口悄悄改了，某个 API 调整了权限，你装的 Skill 就默默失灵了，但往往要到实际使用时才发现。
面对这些问题，我们有一个思路值得大家参考：
与其把几十个 Skill 全部塞给一只小龙虾，不如按照职责把它们分组，编排成多只各有专长的小龙虾。
我们在测评飞书 Aily 里提过「给龙虾分配角色」的概念，思路就是这样的：
一只小龙虾专门管项目流程，另一只专门负责工程落地，再来几只当助理或者测试。每只小龙虾身上挂的 Skill 控制在十个以内，各司其职。
这样做的好处直接对应了前面的研究结论：
每个小龙虾面对的选择变少了，选择错 Skill 的可能性降低了，选对 Skill 的概率自然就上去了。
怎么把 Skill 用好的五个经验
那么如何才能让我们的龙虾真的用好 Skill 呢？
实操层面，我们有一些实际的工程经验给大家分享：
这话听起来像废话，但偏偏是最容易犯的错。CrawHub 上那些 Skill 的介绍都写得很吸引人，看着每个都觉得「说不定哪天用得上」。
但前面的研究已经讲得很清楚了，每多装一个不常用的 Skill，就是在给小龙虾的选择空间增加干扰。手机上装了一百个 App 的人都有体会，满屏的图标反而让你找到真正想用的那个更费劲。
安装之前问自己一个问题，这个 Skill 我这周会用到吗？如果答案不确定，先别装。等真正需要的时候再加进来，远比提前囤一堆要好。
第二条，建立一套简单的判断规则来决定什么时候该增、什么时候该合并、什么时候该拆。
当一个新需求出现时，先想想能不能在现有 Skill 上加一个参数或子命令来解决。
如果可以，就不要新增 Skill。你已经有一个「生成周报」的 Skill，现在又要「生成月报」，没必要再装一个，扩展一下参数就够了。
当你发现某个 Skill 的描述里出现了大量「以及」、「同时」、「还可以」，而且你经常要改它的描述来适配不同场景，就该考虑拆分了。因为一个试图包揽所有事情的 Skill，往往哪件事都做不够好。
另外，当两个 Skill 的输入和输出几乎一样，只是中间步骤有差异，就该考虑合并。用参数来区分不同的执行流程，比同时维护两个几乎一样的 Skill 高效得多。
第三条，优先使用用的人最多的 Skill。
https://skillhub.tencent.com/
第四条，也是最重要的一条，给 Skill 做分类。
我个人的做法是按「类型」和「用途」两个维度给 Skill 来分类。类型是指 Skill 所属的工作领域，比如数据处理、内容创作、项目管理。用途是指它在工作流中的具体角色，比如信息采集、格式转换、质量检查。
这样做有两个好处：
1、你自己对 Skill 库有了清晰的认知图谱，缺什么多什么一目了然。
2、同时，当你按照「给龙虾分配角色」的方式编排多只小龙虾时，分类本身就是分组的天然依据。
这也正是上面第二项研究提到的「把 Skill 分层组织」策略的实践应用。
说到这，还有一个容易忽略的细节：
前面第一项研究 SkillsBench 里提到，Skill 的命名和描述直接影响模型的选择准确率。那项关于语义相似性的研究也指出，描述越独特、越有区分度的 Skill，被正确调用的概率越高。所以这里还有一个策略：
第五条，在写 Skill 描述的时候，尽量突出它的独特功能和适用边界。
同时，要避免「处理数据」、「辅助写作」这种过于宽泛的表述：
比如「计算七日移动平均值并生成趋势图表」这种，可能就比过于抽象的「数据分析助手」好得多。
当然，也不能太细，太细就会导致 Skill 变多。
讲到这里，回到开头的那个问题，用「龙虾装 SKill 是否技多不压身」就很清楚了：
但在 Agent（比如小龙虾）的使用场景里，这个直觉会误导人。
因为 Skill 的价值，来源于它和你真实需求的匹配程度，和龙虾里有多少个技能关系不大：
2 到 3 个精心挑选的 Skill 模块，在严格测试中的表现好过一个塞满了几十个 Skill 的配置。简单的模型配上合适的 Skill，甚至可以打平比它能力更强的模型。
少装一点，多用一点，定期清理一下。
你的小龙虾会因此变得更聪明，你自己也会更轻松。
