你可能没想过这个问题：当一个AI助手面前摆着23万个可以调用的"技能包"，它该怎么选？
这不是夸张的数字。Anthropic 去年推出了一种叫 Agent Skills 的机制，简单说就是把一些可复用的操作知识打包成一个个文件夹，每个文件夹里有一份说明书，告诉AI这个技能是干什么用的、怎么用。这个想法很快被开源社区盯上了，大家疯狂地把各种技能包传到网上汇总。结果呢，短短时间内，这些技能库从几万个暴涨到超过23万个。
这就带来一个新麻烦。以前大家担心的是"技能不够用"，现在要担心的是"技能太多不知道选哪个"。
**选择，而不是创造，成了新的瓶颈。**
这篇来自 Stevens Institute of Technology 等机构的论文，就是奔着这个问题去的。他们做的东西叫 SkillSeek，一个开源的技能检索工具。但这篇论文真正有意思的地方，不是它造了个新轮子，而是它质疑了一件大家已经默认接受的事情：面对海量技能库，是不是必须得让大模型亲自上阵去挑选？
### 当前的主流做法，有点"杀鸡用牛刀"
先说说现在业界是怎么解决这个问题的。
一篇 2026 年的论文（Liu et al.）给出了一个很有代表性的方案：把 BM25（一种经典的关键词匹配检索算法，主要靠计算词语重合度来判断文档相关性）和一个深度学习的向量嵌入模型结合起来，在一个3.4万个技能的市场库里做检索，然后让AI智能体自己去反复琢磨，改写查询词、浏览候选结果、最后把几个相关技能揉合成一个专门为这个任务定制的新技能。
听起来挺聪明对吧？确实，论文里举了个很漂亮的例子：有个任务是关于张量并行计算的，智能体先找到了两个部分相关的技能，一个讲权重分片，一个讲自定义的反向传播函数，然后AI把这两者的精华合并，造出了一个任何单一技能库里都没有的新技能。这种"创造性合成"的能力，确实是静态检索系统做不到的。
但问题是，这套流程每次运行都要调用大模型，而且不止一次。实验数据显示，这种精细化的"refined"版本平均每次任务要付出约51.3美元的开销，其中一大部分是花在检索阶段本身的思考上。
**也就是说，为了找一个工具，先要雇一个更贵的大脑去想该用哪个工具。**
这就好比你家里需要拧一颗螺丝，正常拿起螺丝刀就行了，但现在的做法相当于先打电话请一个工程顾问，花一个小时帮你分析应该用十字螺丝刀还是一字螺丝刀，分析完了才让你去拧。如果不这样做会怎样？你可能会说，万一真遇到需要定制螺丝刀的罕见情况呢？这种担心不是没有道理，但代价是，哪怕99%的情况下一把普通螺丝刀就够用，你每次都要支付那个顾问费。
### 两阶段检索：经典IR的老配方还顶用吗
SkillSeek 的设计思路其实非常朴素，甚至可以说是"复古"。它没有引入任何复杂的智能体循环，而是用了信息检索领域（Information Retrieval，简称IR，就是研究怎么从海量文档里快速找到你想要的那几条的学科）里几十年来的标准配方：两阶段检索。
> 双编码器（Bi-encoder）：一种把查询和文档分别转换成向量（一串数字）的模型，通过计算向量之间的相似度来快速筛选候选项，速度快但精度相对粗糙。
>
> 交叉编码器（Cross-encoder）：把查询和文档放在一起同时输入模型，让模型直接判断两者的匹配程度，精度更高但计算量更大，所以通常只用来处理少量候选项。
具体流程是这样的：第一阶段，用一个叫 BGE-base 的双编码器（1.1亿参数）对查询和技能库里所有技能做初步打分，挑出得分最高的20个候选项。第二阶段，再用一个稍大一点的交叉编码器（5.68亿参数，叫 bge-reranker-v2-m3）对这20个候选项逐一精细打分，最终把前5个最靠谱的技能交给智能体。
整个过程完全跑在CPU上，没有任何一次调用大语言模型。
这就像图书馆找书。第一阶段相当于先用书名和分类号快速筛出20本看起来相关的书，第二阶段则是你亲自翻开这20本书的目录，逐一对比看哪几本真正切题。你完全不需要雇一个博士生陪你逛图书馆分析每本书的学术价值，书名和目录提供的信息已经足够做出靠谱的判断了。如果反过来，每次找书都要先咨询专家，那找书本身的成本可能比看书还高。
> MCP（Model Context Protocol，模型上下文协议）：一种让AI智能体和外部工具、数据源进行标准化通信的协议，任何支持这个协议的工具都能被不同的AI助手直接调用，不需要专门适配。
SkillSeek 把自己包装成一个 MCP 服务器，暴露出三个工具接口：一个用来查询候选技能，一个用来加载某个技能的完整说明文档，一个用来列出所有技能。这样设计的好处是，不管是 Claude Code、Codex CLI 还是研究里用的 OpenHands，只要支持 MCP，就能直接接入 SkillSeek，不用改代码。
### 索引该塞什么内容，决定了检索的上限
这篇论文有个细节特别值得展开讲，就是关于"该把什么文字喂给检索模型"这件事。
直觉上你可能觉得，信息越多越好，把技能的完整说明文档（SKILL.md 正文）整个塞进索引里，检索模型总能找到更多线索吧？
**实验结果恰恰相反。**
研究团队试了三种索引方式：只用技能的名字和简短描述；在此基础上加上正文的前800字；或者用一种叫 Tool-REX v3 的结构化标签方法，给每个技能打上四个标签（文件类型、主要操作、两个次要特征）。
结果显示，加上原始正文反而让效果下降了3.2%，比只用名字加描述还差。原因是正文里塞满了实现细节，这些细节对于"判断这个技能是不是我需要的"这件事其实是噪音，反而稀释了名字和描述里原本清晰的信号。
这就好比你去相亲，对方给你发了一份详细的个人简历，里面写了十年前小学三年级获得的朗诵比赛三等奖，这种细节不仅没用，还会让你抓不住重点，比如对方到底是做什么工作的、性格合不合适。简洁的介绍反而比事无巨细的流水账更有效。
Tool-REX v3 这个标签方案本身也经历了两次失败的迭代，论文里诚实地写了出来。第一版让大模型自由生成3到5个描述性标签，结果一个叫 pdf-excel-diff（对比PDF和Excel文件差异）的技能被打上了"文件对比"、"表格数据"这类标签，却漏掉了最关键的字面词"excel"和"xlsx"。这直接导致检索排名下滑，因为交叉编码器非常依赖查询词和文档之间的字面重合度。第二版加上了具体的软件库名字，结果又矫枉过正，库名字反而主导了打分，导致一些名字相似但实际不对的技能被误排到前面。第三版才稳定下来，固定用四个标签：文件类型、主要操作、两个次要操作，不许出现软件库名。
这个反复试错的过程说明一件事：**给机器喂什么样的"摘要"，本身就是个需要精心设计的技术活，不是随便截取一段文字就能应付的。**
### 实测结果：简单方法在三分之四的场景里打平甚至赢了
现在到了最关键的部分，到底谁强谁弱。
研究团队在 SkillsBench 这个基准测试集上做了全面对比，这个基准包含89个任务，每个任务都配有确定性的 pytest 验证脚本（也就是跑完代码，自动判断对错，不需要人工评分）。他们测试了两个技能库规模：一个是192个技能的精选小库，一个是3.4万个技能的市场级大库；搭配两个不同的大模型作为执行智能体：Qwen3.5-397B-A17B 和 MiniMax-M2.7。
数据说话:
| 方法 | 192库/Qwen3.5 | 192库/MiniMax | 3.4万库/Qwen3.5 | 3.4万库/MiniMax |
|---|---|---|---|---|
| 不加任何技能 | 0.352 | 0.267 | 0.352 | 0.267 |
| 纯BM25 | 0.430 | **0.387** | 0.420 | 0.346 |
| bge-reranker-v2-m3（SkillSeek默认） | **0.480** | 0.371 | 0.409 | 0.346 |
| Qwen3-Reranker-0.6B（SkillSeek变体） | 0.430 | 0.353 | **0.442** | 0.341 |
| Liu等人的方案（无精炼） | 0.470 | 0.378 | 0.417 | 0.335 |
| Liu等人的方案（完整LLM精炼） | 0.397 | 0.344 | **0.442** | 0.329 |
在四个组合里的三个，连最简单的 BM25 都能打平或超过 Liu 等人那个烧钱的"完整精炼"方案。只有在"3.4万技能库+Qwen3.5"这个最苛刻的场景里，Liu 的方案才略胜一筹，但 SkillSeek 用一个小号的 Qwen3-Reranker-0.6B 重排模型，也刚好打平了这个分数。
更有意思的是成本对比。表格里写得很清楚：
| 方法 | 通过率 | 检索成本 | 智能体运行成本 | 总成本 |
|---|---|---|---|---|
| 不加技能 | 0.352 | 无 | $27.41 | $27.41 |
| SkillSeek | 0.409 | $0（纯CPU运算） | $27.54 | **$27.54** |
| Liu方案（无精炼） | 0.417 | $0 | $39.43 | $39.43 |
| Liu方案（完整精炼） | 0.442 | $25.63 | $25.67 | $51.30 |
SkillSeek 几乎没有额外花费，比起什么都不加的基线只多花了一毛三美分。而 Liu 等人的完整方案，总花费接近翻倍，达到51.3美元。
这个对比有点像选交通工具去机场。如果目的地就在隔壁区，骑共享单车十分钟就到，花费几乎为零；如果非要叫一辆配备私人导航顾问的豪华车，顾问全程帮你规划最优路线，确实能多节省几分钟，但代价是车费贵了快一倍。大多数情况下，共享单车已经够用了，豪华车的价值只在少数特殊路况下才能体现。
### 为什么是这样：第一阶段的"天花板"效应
这篇论文没有止步于"我们测出来这样"，而是试图解释背后的机制，这是我觉得全篇最值得细品的部分。
> 召回率（Recall）：在信息检索里，指的是真正相关的内容有多大比例被成功找到并排进候选列表里。比如 R@5 就是指正确答案出现在前5个结果里的比例。
研究团队测了两个库在"第一阶段"（也就是还没用交叉编码器重排之前）的召回率。在192个技能的精选库里，光靠BM25就已经达到了0.546的R@5，交叉编码器重排后只多了3.5个百分点。但在3.4万技能的大库里，BM25的R@5只有0.391，远没到天花板，交叉编码器重排后直接涨了5.4个百分点，加上Tool-REX标签优化后更是涨了9.9个百分点。
这揭示的规律是：**当第一阶段检索已经把正确答案捞得差不多了，再加一个更强的模型去精修排序，收益就很有限；只有当第一阶段漏掉的还很多，精修模型才有发挥空间。**
这就跟渔网捕鱼的道理一样。如果你用的渔网网眼已经足够密，鱼基本上都被兜住了，这时候再派一个更厉害的渔夫去网里"二次确认"哪条鱼最值钱，意义不大，因为该抓的鱼已经都在网里了。但如果渔网本身漏洞百出，很多鱼压根没进网，那无论派多厉害的渔夫去挑选，能挑的范围也就那么大，巧妇难为无米之炊。192个技能的精选库就像密网，3.4万个技能的大库则漏洞更多，这解释了为什么重排模型在大库上更有用武之地。
这个发现同时也说明了为什么在小库上简单方法够用，大库上才需要更强的工具，这不是偶然，而是检索召回率的数学规律决定的。
有意思的是，研究团队还发现，把重排模型继续放大（从0.6B参数放大到8B参数，整整13倍），效果提升却微乎其微，只多了0.7个百分点。这进一步印证了瓶颈不在"重排模型够不够聪明"，而在"第一阶段到底漏了多少本该找到的东西"。
### 一个反直觉的发现：召回率高不等于真的有用
论文里还有一个让人意外的实验，他们拿商业API服务 Voyage 的重排模型（rerank-2.5）来对比。这个商业模型的 R@5（前5个结果里命中正确答案的比例）达到了72.2%，是所有测试模型里最高的。
但它的实际任务通过率表现却是所有模型里最差的，甚至出现了"负帮助"，就是说如果智能体采纳了这个模型推荐的技能，反而比完全没检索到任何技能时表现更差。
研究团队为此专门设计了一个指标，叫"有用性差值"，具体算法是：把任务分成两组，一组是检索系统成功把正确技能排进前5名的，一组是没排进去的，然后比较这两组任务的平均通过率。
> 有用性差值（Helpfulness Gap）：衡量检索到的"标准答案"技能，是否真的对智能体完成任务有帮助。正值说明检索到确实有帮助，负值说明检索到的东西反而在误导智能体。
Voyage rerank-2.5 的有用性差值是负的，而 Qwen3-Reranker-8B 的有用性差值是正的0.149，远远领先。研究团队解释说，这是因为智能体大约65%的情况下只会采纳排名第一的候选项，所以真正重要的不是"正确答案有没有出现在前5名里"，而是"排名第一的那个到底是不是真的有用"。Voyage 这个商业模型是为通用的查询文档相关性训练的，它倾向于把语义上相似但实际不对的"近义技能"排到第一位，表面上看起来相关，用起来却帮倒忙。
这个发现其实在提醒一件更普遍的事：**衡量一个检索系统好不好，光看它能不能"找到"标准答案是不够的，还要看它推荐的东西是不是真的被用上了，而且用上之后真的解决了问题。**这两者听起来差不多，实际上可能完全脱节。
### 任务难度和具体案例：哪里赢哪里输
论文还做了细致的任务级分析。在难度分层上，重排检索给困难任务带来的提升最大，达到8.0%，中等难度任务提升5.4%，简单任务提升5.2%。这符合直觉，困难任务原本没有技能辅助时表现最差（基线通过率只有0.194），能提升的空间自然也最大。
具体到单个任务，论文列出了赢得最多和输得最惨的例子。像洪水风险分析、引力波探测这类任务，因为技能名字和描述跟查询词高度吻合，重排直接把通过率从0拉到接近满分。而像并行TF-IDF搜索、自适应巡航控制这些任务，库里存在描述相似的"孪生技能"，交叉编码器挑错了那个，反而把通过率拉低了0.5到0.8。
这说明失败的原因不是"技能库里没有对的答案"，而是"排序时把两个长得很像的选项搞混了"，这是个纯粹的排序精度问题，而不是覆盖率问题。
### 研究团队留下的诚实边界
这篇论文一个让人印象深刻的地方是，它非常坦诚地列出了自己结论的局限。
每个实验设置只跑了一次完整的89任务测试，没有做多次重复取平均。研究团队专门挑了一组重跑三次来估算波动范围，发现标准差大约1%，所以他们把2%以内的差异都算作噪音范围内，不敢声称哪个方法"确实更好"，只说"观察到的表现相当"。
另外，运行失败的任务被直接记作0分而不是丢弃，这个记分规则对所有方法一视同仁，但确实会压低绝对分数。MiniMax-M2.7 这个模型因为经常遇到网络超时等问题，大约一半的任务都会失败，所以论文把它定位为"辅助证据"，主要结论以 Qwen3.5 的结果为准。
还有一点很关键，192个技能的精选库本身是人工挑选的，确保每个任务都有对应的技能存在，所以在这个库上的绝对分数不能直接拿来说明检索系统本身有多强，真正有说服力的是跨库对比显露出的规律。
研究者甚至承认，自己对 Liu 等人方案的复现并不完全忠实，由于预算和实现细节的限制（比如把智能体的自由探索步数限制在10步以内，而不是原论文的不设限），他们测出来的"精炼版方案"效果可能被低估了，真实情况下精炼方案的表现或许会更好一些。这种每一处都坦白交代可能存在的偏差的做法，在学术论文里其实并不常见，值得点个赞。
### 写在后面
读完这篇论文，我脑子里一直转着一个问题：为什么大家一开始会默认"选技能"这件事必须交给大模型自己去做？
我猜测的答案是，当技能检索这个场景第一次出现的时候，大家下意识地把它当成了一个需要"理解"和"推理"的任务，既然大模型擅长理解语言，那就该让它去理解技能描述、推理哪个最合适。这个直觉本身没有错，问题在于忽略了一件事：信息检索这个领域已经被研究了几十年，双编码器加交叉编码器这套组合拳早就被各种搜索引擎、推荐系统验证过无数遍了，很多时候这类"经典工具"比想象中更顶用，只是因为新鲜感不够，容易被绕过去。
论文里那个商业重排模型召回率最高却表现最差的实验，是我觉得最值得单独拎出来说的一个细节。它提醒我们，评估一个系统的时候，选错指标比选错方法更危险。如果当初研究团队只看召回率这一个数字，大概率会得出"Voyage模型最强"的错误结论，恰恰是因为他们多走了一步，去看真实任务里这个检索结果到底有没有发挥作用，才发现了这个隐藏的坑。这种"指标和真实效果脱节"的现象，其实在很多AI应用评测里都存在，只是很少有人愿意多花这一步去验证。
这篇论文没有否定大模型参与检索这条路的价值，它甚至专门举了那个张量并行计算的例子，说明在确实需要"创造性合成"的场景下，LLM介入仍然有不可替代的作用。它想说的是更朴素的一件事：**在动用昂贵工具之前，先问问便宜的工具够不够用。**
如果技能市场继续涨到百万级别，这套简单的两阶段检索还能不能撑住，这是个留给未来的问题。
Q&A
Q1：SkillSeek是什么？
A：SkillSeek是一个开源的两阶段AI技能检索工具，用双编码器加交叉编码器的经典信息检索方法，从海量技能库中为AI智能体挑选合适的技能，整个过程不需要调用大语言模型，运行在CPU上就能完成。
Q2：SkillSeek和让大模型自己检索技能相比，效果差多少？
A：在89个任务的测试里，SkillSeek在四分之三的场景中表现持平甚至超过大模型自己检索的方案，成本却只要27.54美元，远低于大模型方案的51.3美元，几乎和不加任何技能的基础花费一样。
Q3：为什么技能库越大，简单检索方法反而效果变差？
A：因为技能库变大后，第一阶段粗筛的召回率跟不上，很多正确答案根本没被捞进候选名单里，这时候才需要更强的重排模型或大模型介入去弥补召回不足的问题，这是召回率天花板导致的规律。
