Agent 的 Skill 过多？怎么提高命中率¶

我们团队在构建企业级 Agent 平台的过程中踩过一个典型的坑：从最初的十几个 Skill 快速迭代到上百个 Skill 后，原本准确率不错的 Skill 路由突然就"失灵"了。明明用户需求对应着明确的 Skill，模型却总是选错，要么挑了个看似相关实际不对的，要么干脆直接自己回答不调用任何 Skill。

刚开始我们以为是模型变笨了，或者 Prompt 写得不够好，反复优化 Skill 内部的提示词却收效甚微。后来才意识到：当 Skill 数量达到一定规模后，Skill 路由本身已经变成了一个检索问题，需要用检索系统的思路来解决。

核心思想：渐进式披露¶

Anthropic 在 Agent Skills 设计中提出的 progressive disclosure（渐进式披露） 给了我们很大启发：不需要把所有 Skill 的完整信息全部塞进上下文，只需要先把每个 Skill 的名称和描述展示给模型，让模型先判断要不要进一步加载完整内容。

这个思路点醒了我们：很多团队优化错了方向，天天死磕 Skill 内部的 Prompt，却不重视 Skill 的描述信息。实际上 Skill 的 name 和 description 本质上就是向量检索里的标题和摘要。如果这里写得模糊，比如"数据分析助手"、"通用办公工具"、"代码处理专家"，那几十个 Skill 放在一起，模型根本分不清谁是谁。

四个提高命中率的方法¶

1. 提高 Skill 描述的区分度¶

不要写这个 Skill 是什么，而要写什么时候用它。

比如： - ❌ 不要写：负责生成 PPT - ✅ 应该写：当用户要求制作汇报材料、融资路演、季度总结或演示文稿时使用

Anthropic 官方也特别强调，description 里应该包含触发场景，而不仅仅是功能介绍。因为模型路由的本质是在做语义匹配，场景描述越清晰，命中率越高。

2. Skill 分层¶

很多团队会把一百多个 Skill 全部平铺，结果模型每次都要在一百多个选项里做判断，负担太重。

更好的做法是建立一颗 Skill Tree： - 第一层先分大类，比如研发、运营、市场、财务 - 第二层再分子类，比如代码生成、代码评审、测试生成

这样模型先找到大类再定位具体 Skill，搜索空间一下就缩小了。很多大型 Agent 系统其实都在做这种分层路由，而不是一次性全量匹配。

3. 增加负样本描述¶

这是很多人忽略的一点：除了告诉模型什么时候用，还要告诉他什么时候不要用。

例如： - 仅用于生成 SQL，不适用于数据库设计和性能优化 - 仅用于前端代码生成，不负责后端接口开发

社区里很多高质量的 Skill 都开始加上 when not to use 这一部分，因为它能显著减少误触发。

4. 召回加重排¶

不要让大模型直接从几百个 Skill 里选，先用 embedding 或关键词检索召回 Top 10，再交给大模型做最终判断。这和 RAG 的思路完全一样。

实际上，当 Skill 数量达到几百上千以后，Skill Router 本身就已经变成了一个检索系统，很多研究工作甚至专门训练小模型来做 Skill Router 来解决这个问题。

总结¶

我们团队把这四件事做好后，Agent 的命中率重新稳定了下来：

写好场景化描述 —— 告诉模型什么时候用，而不仅仅是做什么
做好分层路由 —— 建立 Skill Tree，逐步缩小搜索空间
加上负样本边界 —— 明确说明什么时候不要用，减少误触发
引入召回重排机制 —— 先检索召回候选，再让模型做最终判断

这个问题其实是所有 Agent 系统规模扩大后的必经之路，早做规划就能避免后续很多麻烦。