Skill 的调用机制：Agent 怎么决定调谁
先说一下 Agent 到底怎么挑 Skill 的。这个机制很多人其实不清楚。
一个 Agent 身上可能装了几十个 Skill，但 Agent 不会在每次任务里把所有 Skill 都加载进来------上下文窗口塞不下，Token 也耗不起。
实际的流程是这样的：
markdown
用户发任务
↓
Agent 扫描所有已装 Skill 的 name + description（只看这两个字段）
↓
Agent 根据 description 判断哪几个 Skill 跟当前任务相关
↓
只有被选中的 Skill 才会被完整加载（读取 SKILL.md、参考资料等）
↓
Agent 按加载进来的 Skill 指令执行任务关键在第三步：Agent 选 Skill 的唯一依据就是 Description。
不是看代码质量，不是看用户评价，不是看跑通率。就看 Description。
Description 膨胀：一个比 SEO 还离谱的军备竞赛
理解了上面的机制，你就能理解为什么 Skill 开发者会把 Description 往大了写。
逻辑很简单：Description 写得越宽泛，被 Agent 选中的概率就越高。如果你的 Skill 只写了「合同审查」，那 Agent 只有在用户明确提到「合同」的时候才可能调你。但如果你写成「法律全能助手，解决一切法律相关问题」，那只要用户的任务里沾了个「法」字，你就有可能被选中。
这跟当年 SEO 疯狂堆关键词是一模一样的逻辑。
结果就是 Skill 的 Description 普遍注水：
- 只能跑 React 的，写「支持所有主流前端框架」
- 只接了一个免费 API 的，写「全网数据覆盖」
- 本质上就是个 checklist 模板的，写「智能 XX 分析助手」
我们做过一次抽样，73% 的 Skill 存在不同程度的 Description 夸大。
这带来的直接后果就是：当你的 Agent 装了一堆 Description 互相重叠的 Skill 时，Agent 在选择调用哪个 Skill 的时候会犯迷糊。该调的没调，不该调的调了，甚至同时调了好几个互相冲突的。
你觉得是 Agent 变笨了，其实是 Description 把它搞晕了。
案例：Anthropic 官方 Skill 都翻车
你可能觉得大厂出品的 Skill 不会有这个问题。但事实是，Anthropic 自己官方开源的 Claude for Legal Skill 套件里就有一个经典反面教材。
这个 Skill 叫 is-this-a-problem，Description 写的是「当用户问某件事是不是一个问题时触发」。
三个坑一起踩：
1. 触发范围完全失控。 你在做代码 Review 的时候说一句「这个写法会不会有问题」，它都可能被触发------因为 Description 里没有限定场景，只要句子里出现「问题」两个字就可能中招。
2. 能力跟描述对不上。 它不会去查法律法规，不会检索判例。它的实际逻辑是：让你自己预先配一份风险检查清单，然后它逐项比对。本质上就是个 for item in checklist: check(item) 的循环。你不配清单？它告诉你「没有发现问题」。
3. 完全没有中国法律适配。 没接中国法律数据库，没有大陆法条和判例，对中国用户来说基本不可用。
这还是 Anthropic 出品的。
在更广泛的范围里，我们遇到过更离谱的------有个金融 Skill 号称能查实时股价，实际上它返回的是 Math.random() * 100，用随机数冒充股票价格。
传统搜索能解决这个问题吗？
不能。
现在的 Skill 市场给你的筛选维度就三个：名字、Description、下载量。
名字没区分度。Description 73% 注水。下载量只反映热度不反映质量------下载量 2 万的 Skill，可能作者半年没更新了，接口早就挂了，照样排在首页。
传统搜索做的是关键词文本匹配。你搜「法律」，它把 Description 含「法律」的全捞出来排个序。至于哪个是做合同的、哪个是做劳动仲裁的、哪个接了真数据源、哪个只是个 checklist------它不管也管不了。
你拿这三个维度做选型，跟闭着眼选没区别。
Deep Skill Finder：看战绩，不看简历
这就是我们做 Deep Skill Finder 的原因。
核心思路一句话：不信 Skill 自己怎么说，只看它在真实任务里跑得怎么样。
数据从哪来
不是我们自己造的测评数据。社区里大量用户在真实任务中使用各种 Skill，产生了海量的执行记录------哪个 Skill 跑了什么任务、花了多久、有没有报错、结果能不能用。这些信息本来散落在各种帖子和讨论里，我们做的是把它们收集起来，结构化，让它变得可搜索。
匹配怎么做
不是关键词匹配，是 「任务 × Skill」的组合评估。
同一个 Skill 在不同任务场景下表现可能天差地别。一个 Skill 在 Claude Code 里稳如老狗，换到 Cursor 里可能直接报错。在代码生成任务上表现 90 分，换到文案任务上可能只有 30 分。
所以我们不给 Skill 打统一分数，而是评估 「这个 Skill 在你这个具体任务里好不好用」。
markdown
用户用自然语言描述任务
↓
语义理解，提取任务类型、约束条件
↓
检索在相似任务中有真实执行记录的 Skill
↓
按「任务匹配度 + 执行成功率 + 结果质量」排序
↓
返回推荐（附带真实场景下的表现数据）使用姿势
别当搜索引擎用。 不要只输「法律」「股票」这种宽泛词。同样是法律任务，合同审查、劳动纠纷、知识产权检索需要的 Skill 完全不一样。
直接描述完整任务：
text
帮我审查这份采购合同，重点看付款条款、违约责任和知识产权归属。
找一个合适的 Skill 辅助你。Deep Skill Finder 会根据整个任务语义去匹配，而不是只抓「合同」这一个关键词。
架构速览
三层：
┌──────────────────────────────────────────────┐
│ 接入层：自然语言任务描述 → 语义解析 → 意图提取 │
├──────────────────────────────────────────────┤
│ 数据层：50,000+ Skill 候选库 │
│ 百万级社区真实执行记录 │
│ Skill 能力边界分析 │
├──────────────────────────────────────────────┤
│ 匹配层：任务-Skill 组合评估 │
│ 多源交叉验证（描述 × 实测 × 产出） │
│ 场景化成功率排序 │
└──────────────────────────────────────────────┘关键设计：交叉验证。
单看 Description------开发者写的，可能注水。单看下载量------可以刷。单看某一条反馈------存在个体差异。
三个渠道放在一起交叉比对，才能给出一个相对靠谱的判断。一个 Skill 声称「支持所有主流数据库」，但社区记录里只有 MySQL 场景的成功案例------推荐结果里会如实反映这个差异。
总结
Skill 不是装得越多越好。 Description 膨胀导致的调用混乱，是一个结构性问题，不是靠你「仔细挑选」就能解决的------因为你根本拿不到有效的筛选信息。
Deep Skill Finder 做的事情，就是在你和 Skill 之间补上一层基于真实执行数据的信任层。让你在装一个 Skill 之前，就知道它在你的任务场景下到底行不行。
工具地址：meyo.life/skill
踩过 Skill 的坑的，评论区聊聊。特别想听听大家遇到过哪些 Description 写得天花乱坠但实际拉胯的 Skill。