SkillRouter：面向大规模 LLM Agent 技能池的检索-重排路由方案
当 Agent 需要从 8 万个技能中选出正确的那个时，技能的名称和描述几乎没用——真正起作用的是技能的完整实现代码。SkillRouter 利用这一发现，用仅 1.2B 参数的检索+重排流水线达到 74% 的 top-1 准确率，可在笔记本 CPU 上本地运行。
问题：Agent 生态的技能选择困境
Claude Code、Codex CLI 等编程助手的技能（tool/plugin）生态已增长到数万规模。将所有技能塞进上下文窗口既不可能也不经济。更棘手的是，社区技能仓库存在大量功能重叠——许多技能名称和描述相似，只在实现细节上有差异，形成高度同质化的候选池。
当前 Agent 框架普遍采用「渐进披露」设计：只向 Agent 暴露技能的名称和描述，隐藏完整的实现代码。这隐含地假设名称和描述足以做出正确选择。这篇论文正是要系统性地检验这一假设——结论是它完全站不住脚。
论文围绕三个问题展开：RQ1 大规模技能路由是否真的困难？RQ2 技能文本的哪个部分（名称、描述、body）对选择起决定作用？RQ3 紧凑的检索-重排流水线能否有效利用这些信号？
核心发现：Body 是唯一重要的信号
| 方法 | 类型 | 仅名称+描述 | 完整文本 | 差值 |
|---|---|---|---|---|
| BM25 | 稀疏检索 | 0.0% | 34.7% | +34.7pp |
| Qwen3-Emb-0.6B | 密集编码器 | 22.7% | 58.7% | +36.0pp |
| Qwen3-Emb-8B | 密集编码器 | 30.7% | 65.3% | +34.6pp |
| Qwen3-Emb-8B × Qwen3-Rank-8B | 交叉编码器 | 24.0% | 68.0% | +44.0pp |
| Qwen3-Emb-8B × GPT-5.4-mini | LLM 裁判 | 30.7% | 59.4% | +28.7pp |
方法：SkillRouter 两阶段流水线
基于 body 是决定性信号这一发现，SkillRouter 在两个阶段都使用完整技能文本。整个流水线仅 1.2B 参数（0.6B 编码器 + 0.6B 重排器），可在消费级硬件上运行。
第一阶段：双编码器(查询和文档分别编码为向量)检索。 基于 Qwen3-Emb-0.6B 微调的 SR-Emb-0.6B 将查询和所有技能编码到共享嵌入空间，通过余弦相似度检索 top-20 候选——将 ~80K 缩减到 20 个。技能离线预编码，推理时只需编码查询 + ANN(近似最近邻)搜索。
第二阶段：交叉编码器重排。 基于 Qwen3-Reranker-0.6B 微调的 SR-Rank-0.6B 对每个（查询，候选技能）对做联合注意力计算，产生精细的相关性打分，将 20 个候选重新排序。
训练策略的关键设计
假阴性过滤： 社区技能仓库中大量技能功能近乎相同但名称不同。在对比学习(通过正负样本对比训练嵌入)中，这些功能重复的技能会成为假阴性，破坏训练信号。论文设计了三层过滤管道：① 名称去重——移除与正例同名的负例（24,879 对）；② Body 重叠——移除 body 文本 trigram Jaccard 相似度 > 0.6 的负例（13,860 对）；③ 嵌入相似度——移除余弦相似度 > 0.92 的负例（326 对）。总计移除约 10% 的负样本对，贡献 +4.0pp Hit@1。
Listwise vs. Pointwise 损失： 对重排器而言，listwise 交叉熵戏剧性地碾压了 pointwise 二元交叉熵（+30.7pp）。原因在于技能池的高度同质性——top-20 候选中常充满功能相似的技能，pointwise 独立打分产生的分数收敛到窄带，排序近乎随机；而 listwise 通过 softmax 在整个候选列表上做比较，迫使模型学习相对排序。
实验结果
| 流水线 | 参数量 | Hit@1 | MRR@10 | R@10 |
|---|---|---|---|---|
| BM25（仅 body） | – | 31.4% | 36.5% | 32.1% |
| Qwen3-Emb-8B | 8B | 64.0% | 69.8% | 65.9% |
| text-emb-3-large | – | 62.0% | 65.8% | 60.9% |
| SR-Emb-0.6B（微调） | 0.6B | 65.4% | 72.3% | 68.5% |
| Qwen3-Emb-8B × Qwen3-Rank-8B | 16B | 68.0% | 74.5% | 69.2% |
| SR-Emb-0.6B × SR-Rank-0.6B ★ | 1.2B | 74.0% | 79.1% | 70.4% |
| SR-Emb-8B × SR-Rank-8B | 16B | 76.0% | 80.8% | 71.9% |
微调闭合了规模差距。 SR-Emb-0.6B（0.6B 参数，微调）在编码器阶段就超越了 Qwen3-Emb-8B（8B 参数，零样本），证明任务适配比简单堆参数更有效。完整流水线进一步放大了这一优势。
重排器贡献分析： 在 150 条查询中，重排器修正了 19 条（12.7%）编码器排错的查询，仅降级 6 条（4.0%），净贡献 +8.7pp Hit@1。22% 的查询两阶段都未能解决——这些通常需要多跳推理（如「发票欺诈检测」→ PDF 表格提取）。
案例说明： 查询要求「从教程视频提取章节时间戳」，正确技能是 speech-to-text。基础编码器被「video」关键词误导到视频编辑工具，而 SR-Emb-0.6B 学会了「video + timestamps → speech-to-text」的间接映射，直接检索到正确技能。
实践建议
对 Agent 框架开发者： - 技能路由层必须访问完整 body 文本，仅暴露名称和描述的设计会导致 30-44pp 的准确率损失 - 即使 Agent 本身受上下文窗口限制只能看到名称+描述，路由组件也必须能访问全文——这是一个真实的设计约束（hidden-body asymmetry） - 重排器如果不能访问 body，不如不用——它会把排序搞得更差
对技能路由模型训练者： - 在社区技能仓库上训练时必须做假阴性过滤，否则功能重复的技能会破坏对比学习信号 - 重排器务必使用 listwise 损失（而非 pointwise），候选池高同质性下 pointwise 近乎无效 - 0.6B 级别模型经过微调即可匹敌甚至超越 8B 零样本基线，无需大规模计算资源
对技能作者： - 技能的 body（实现代码/详细规格）是路由系统选中它的关键，写好 body 比打磨名称和描述重要得多
适用边界
时效性
SkillRouter 于 2026 年 3 月发表，属于该领域的较新工作。截至 2026 年 5 月：
- 代码已开源，GitHub 仓库提供了基准数据、评估脚本和 0.6B 模型权重 - 同期出现了 LiveMCPBench（2025 年底至 2026 年初），专门评估 MCP 协议下 527 个工具的大规模路由，发现近半数失败源于工具检索错误——印证了 SkillRouter 指出的「路由是瓶颈」这一判断 - ITR（Instruction-Tool Retrieval） 从另一个角度验证了类似结论：按需检索工具子集可减少 95% 的上下文 token 并提升 32% 的正确路由率 - SkillRouter 的核心发现（body 是决定性信号）尚未被后续工作推翻，其实验方法论（注意力分析、假阴性过滤）正在被同领域研究采纳 - 论文的 8B 版本达 76.0% Hit@1，但随着更大规模预训练嵌入模型的出现，这一数字的绝对领先幅度可能缩小
