智能体技能选多了，反而找不到对的？这篇论文给出了优雅的解法

“

论文链接：https://arxiv.org/pdf/2603.22455

研究背景

随着 LLM 智能体生态的快速发展，可用的技能（skill）数量已经突破数万量级。无论是 Claude Code、Codex CLI 这样的编程助手，还是各类个人 AI 助理，背后都依赖一个庞大的社区贡献技能库来扩展自身能力。但问题来了：你不可能把几万个技能全塞进模型的上下文窗口，所以如何从一个巨大的技能池里，准确找到当前任务需要的那几个技能，就成了一个真实且棘手的工程问题，这就是本文定义的"技能路由"（Skill Routing）任务。

形式化来说，给定用户的任务描述  和技能池 ，每个技能  包含三个字段：名称（name）、描述（description）、实现体（body），目标是从  的候选池中检索出最相关的技能排在最前面。

这个任务之所以难，有一个绕不开的现实：社区贡献的技能库里充斥着大量"功能重叠"的技能，比如几十个名字略有差异的 git 管理工具、docker 配置工具，名字和描述都极其相近，但实现细节各有不同。在这种高度同质化的候选池里，传统的检索方法极容易"张冠李戴"。

现有大多数系统的做法是：把技能的名称和描述暴露给智能体，但隐藏完整实现体——本文将其称为"渐进式披露设计"（progressive disclosure）。这背后有个潜在假设：名称+描述已经足够判断技能是否相关。但这个假设从来没有被系统性验证过。本文的核心贡献，就是用实验打破了这个假设。

论文的贡献可以归结为三点：第一，在 ~80K 技能规模的基准上首次系统研究了技能路由问题，并揭示了"实现体才是关键信号"这一反直觉发现；第二，构建了包含 75 个专家验证查询、两个难度层级的评测基准；第三，提出了 SkillRouter 这个仅 1.2B 参数的两阶段检索-重排流水线，在消费级硬件上即可部署，且性能优于多个更大的零样本基线。

相关工作

技能/工具选择这个方向并不是全新的，之前已经有不少工作在做相关探索。Toolformer 和 HuggingGPT 是比较早期的代表，证明了 LLM 调用外部工具的可行性，但它们都假设工具集合是小而固定的。ToolLLM 把规模扩展到了 16K+ 真实 API，引入了检索增强的选工具方式；Gorilla 则通过检索 API 文档让模型与外部接口对接。AnyTool 和 CRAFT 分别探索了层次化工具发现和上下文感知工具检索，EASYTOOL 则发现对工具文档做结构化精简有助于提升选择准确率。ToolRerank 也尝试过自适应截断和层次化多样化作为检索后处理手段。

但这些工作有一个共同的局限：它们要么在规模上远小于 80K（多数在几百到几千量级），要么没有深入研究"技能文本的哪个部分"才真正对检索有用。本文填补的正是这个空白。

在检索架构上，本文遵循业界成熟的"检索-重排"（retrieve-and-rerank）范式：先用双编码器（bi-encoder）做快速粗筛，再用交叉编码器（cross-encoder）精排。DPR、Contriever、E5、GTE、BGE 这些工作奠定了双编码器检索的基础；BERT 段落重排和 RankGPT 则是交叉编码器精排的代表。本文的 SkillRouter 在架构上继承了这条主线，但针对技能路由的特殊性——结构化多字段文档、高度同质化候选池、关键信号在 body 而非 metadata——做了专门的训练设计。

评测基准方面，ToolBench、API-Bank、MetaTool、T-Eval 都从不同角度评估了工具增强智能体，但它们关注的是"会不会用工具"，而非"能不能从 80K 里找对工具"。本文基准建立在 SkillBench 的专家标注任务-技能对应关系之上，专注解决这个"找对"的上游问题。

核心方法

最重要的发现：body 才是关键

在介绍方法之前，有必要先说清楚论文最核心的实验发现，因为整个方法设计都以此为出发点。

论文系统比较了两种输入配置：nd（只用 name+description）和 full（name+description+body），在所有检索方法上测了一遍，结果让人震惊：

去掉 body 会导致灾难性崩溃。BM25 在 nd 配置下 Hit@1 直接跌到 0（关键词都对不上），加回 body 后恢复到 34.7%。稠密编码器 Qwen3-Emb-0.6B 从 58.7% 跌到 22.7%，足足少了 36 个百分点。更反直觉的是：把参数量扩大 13 倍换成 8B 模型，nd 配置下也只有 30.7%，还不如 0.6B 带 body 的效果——也就是说，模型规模无法弥补缺少 body 带来的信息损失。

不止如此，当重排器在 nd 输入下运行时，性能甚至会低于不做重排的基线，因为重排器会基于名称/描述的表面相似性对候选重新排序，反而把编码器更优的排序给破坏了。

为了理解"为什么 body 这么重要"，论文还做了注意力分析，检查交叉编码器重排器对输入各字段的注意力分布：body 获得了 91.7% 的总注意力，name 占 7.3%，description 仅 1.0%。层间分布也很有规律：早期层（0-6）几乎全在看 body（97.3%，进行 token 级别内容理解），中间层（7-20）name 的注意力逐渐升高，在第 19 层达到峰值 26.3%（做语义名称匹配），末尾层（21-27）再次回归 body 主导，做最终相关性判断。

这一发现直接推翻了"名称+描述已够用"的流行假设，并为 SkillRouter 的设计确立了根本原则：两个阶段都必须用完整 body。

SkillRouter 流水线

SkillRouter 是一个两阶段流水线，总参数量 1.2B（0.6B 编码器 + 0.6B 重排器）。

第一阶段：双编码器检索（SR-Emb-0.6B）

以 Qwen3-Emb-0.6B 为基座，对查询和所有技能用完整文本（name+description+body）分别编码到共享嵌入空间，通过余弦相似度检索 top-20 候选，将候选规模从 ~80K 压缩到 20。

训练数据构造上，论文生成了 37,979 个（query, skill）对。对每个技能，用 GPT-4o-mini 根据技能内容生成一段"如果你需要这个技能，你会怎么描述这个任务"的合成查询，要求不能直接提及技能名称，确保查询反映的是功能需求而非表面匹配。

负样本挖掘采用四路来源：语义负样本（基于嵌入相似度的 top-50 中非正例，最难）、词汇负样本（BM25 检索的 top-50，捕捉词汇混淆）、同类负样本（同类别不同名称的随机采样）、随机负样本（跨类别随机）。

一个重要细节是假负样本过滤：社区技能库里功能几乎完全相同的技能大量存在，这些在对比学习中会成为"错误的负样本"，污染训练信号。论文设计了三层过滤：名称去重、body 文本 Jaccard 相似度过滤（阈值 0.6）、嵌入余弦相似度过滤（阈值 0.92），共过滤掉约 10% 的负样本对。不过滤的话 Hit@1 要掉 4 个点。

训练目标使用 in-batch InfoNCE 损失：

其中  是温度超参数，较小的温度促使模型在相似度分布上做更细粒度的区分。

第二阶段：交叉编码器重排（SR-Rank-0.6B）

以 Qwen3-Reranker-0.6B 为基座，对每个（query, 候选技能）对做 token 级别交叉注意力，输出精细相关性分数，将 top-20 重新排序。输入格式同样是完整的 name+description+body 拼接。

训练时对比了两种损失函数：listwise 交叉熵（LW）和 pointwise 二元交叉熵（PW）。结果差异巨大：

Listwise CE（LW） 在整个候选列表上做 softmax，直接对候选间的相对排序建模：

Pointwise BCE（PW） 对每个候选独立打分，不感知候选间关系：

在高度同质化的技能候选池里，PW 的问题在于：所有候选的 sigmoid 输出会集中在一个窄带里，排序基本等于随机。LW 强迫模型在候选之间做比较，正是这种相对排序能力，让重排器在从一堆"长得很像"的候选里挑出正确答案时发挥作用。实验结果印证了这一点——两者相差 30.7 个百分点，PW 微调后的效果甚至不如不重排。

实验效果

编码器检索结果

在编码器阶段，SR-Emb-0.6B 以 65.4% 的平均 Hit@1 领跑所有基线编码器，包括参数量达 13 倍的 Qwen3-Emb-8B（64.0%），也超过了 text-embedding-3-large（62.0%）和 gemini-embedding-001（58.7%）。把同样的微调方法应用到 8B 基座得到 SR-Emb-8B，进一步达到 68.0%，说明这套方法是可扩展的——但微调带来的增益（+4.0pp over 8B base）远大于单纯扩大规模的增益（+2.6pp from 0.6B to 8B FT）。

端到端流水线结果

SkillRouter 主流水线（SR-Emb-0.6B × SR-Rank-0.6B，1.2B 参数）达到 74.0% Hit@1，比最强零样本 8B 基线（Qwen3-Emb-8B × Qwen3-Rank-8B）高出 6 个百分点，比编码器单独使用高出 8.6 个点。应用到 8B 规模得到 76.0%，进一步验证了方法的通用性。

对重排器贡献的逐查询分解显示：重排器在 150 个查询里修复了 19 个（12.7%）编码器没排到第一的 case，仅破坏了 6 个（4.0%）原本正确的 case，净贡献 +8.7pp。还有 33 个查询（22.0%）两个阶段都没答对，这些基本上属于需要多跳推理才能建立查询-技能连接的情况，是当前检索方法的能力上限。

在效率方面，技能嵌入可以离线预计算存入向量索引，推理时只需对查询做一次 0.6B 编码、ANN 检索，再对 20 个候选做一次 0.6B 交叉编码，完全可以在笔记本 CPU 上运行，满足 OpenClaw 等个人智能体产品的本地化部署需求。

论文总结

大家一直以为技能的名称和描述就够用来做路由决策，但这篇论文用硬数据证明：完整的实现体（body）才是判断技能是否匹配的决定性信号，去掉它性能直接崩溃 30~44 个百分点。基于这一发现，论文提出了 SkillRouter——一个只需 1.2B 参数、可在消费级硬件部署的两阶段检索-重排流水线，在 80K 技能池上达到 74% 的路由准确率，还顺手揭示了假负样本过滤和 listwise 排序损失这两个在同质化技能池里至关重要的训练技巧。

RAGraph" data-pm-slice="0 0 []">

添加微信，备注”LLM“进入大模型技术交流群

如果你觉得这篇文章对你有帮助，别忘了点个赞、送个喜欢