SkillRouter：大规模 LLM 代理的技能选择检索 - 重排序管道

作者： Baohua Dong, Hangcheng Zhu
机构： 阿里巴巴集团，中国杭州
通讯作者

摘要

随着 LLM 代理生态系统的增长，可用技能（工具、插件）的数量已达到数万个，使得将所有技能注入代理的上下文变得不可行。这产生了对技能路由（skill routing）的需求——给定用户任务，从大型技能池中检索最相关的技能。社区技能仓库中普遍存在的功能重叠问题加剧了这一挑战，许多技能名称和用途相似，但实现细节不同。尽管具有实际重要性，技能路由仍未得到充分探索。当前的代理架构采用渐进式披露设计——仅向代理暴露技能名称和描述，同时隐藏完整的实现正文——隐含地将元数据视为足以进行选择。我们通过一项系统性实证研究挑战了这一假设，该研究基于包含约 80K 技能和 75 个专家验证查询的基准测试。我们的关键发现是：技能正文（完整实现文本）是决定性信号：移除它会导致所有检索方法的性能下降 29-44 个百分点，交叉编码器注意力分析显示 91.7% 的注意力集中在正文字段上。基于这一发现，我们提出了 SkillRouter，一个两阶段的检索 - 重排序管道，总参数量仅 1.2B（0.6B 编码器 + 0.6B 重排序器）。SkillRouter 实现了 74.0% 的 Top-1 路由准确率，在我们评估的紧凑型和零样本基线中提供了最强的平均结果，同时仍可部署在消费级硬件上。

1 引言

基于 LLM 的编码和个人助手——如 Claude Code（Anthropic, 2025）、Codex CLI（OpenAI, 2025）和开源替代品——已成为现代软件开发工作流的组成部分。其有效性的一个关键因素是技能（也称为工具或插件）生态系统：社区贡献的技能包，通过专门功能扩展代理的能力，从数据库迁移到代码检查再到 API 集成。随着这些生态系统的成熟，可用技能数量快速增长，在流行的注册表中达到数万个。然而，这种增长带来了一个关键挑战：社区贡献的技能仓库表现出普遍的功能重叠——许多技能名称和用途相似，仅在实现细节上有所不同，创建了一个高度同质化、难以导航的技能池。

将所有可用技能注入代理的上下文窗口是不可行的。上下文长度限制、推理成本以及技能质量和相关性的巨大差异，使得为每个任务向代理展示每个技能变得不切实际。这产生了对技能路由的根本需求：给定用户的任务描述，从大型技能池中自动选择最相关的技能。路由组件在一个独特的”隐藏正文不对称性”（hidden-body asymmetry）下运行——最终使用技能的代理只能看到其名称和描述（由于上下文限制），但路由系统可以访问完整的技能文本，包括其完整实现正文。

尽管这个问题具有实际重要性，技能路由仍未得到充分探索。当前的代理架构采用渐进式披露设计：在展示可用技能时，它们仅向代理暴露名称和描述，同时从上下文窗口中隐藏完整的实现正文。这种设计隐含地将元数据视为足以进行选择——据我们所知，这一假设从未得到系统性验证。现有的基准测试如 SkillBench（Huang 等人，2025）、ToolBench（Qin 等人，2023）和 MetaTool（Huang 等人，2024）评估代理如何使用已提供给它们的工具，但不研究首先从大型池中检索正确工具的上游问题。在检索方面，ToolRerank（Zheng 等人，2024）和 CRAFT（Yuan 等人，2024a）探索了带有重排序的检索和上下文感知检索，但仅在数百到数千的池中操作工具级元数据（名称和描述），没有研究工具的哪些文本组件实际上驱动准确选择。

在这项工作中，我们对大规模技能路由（约 80K 技能）进行了系统性研究，围绕三个研究问题组织：

• RQ1： 大规模技能池中的技能路由是否是一个真正具有挑战性的检索问题？
• RQ2： 技能文本的哪些组件（名称、描述、正文）对准确选择是决定性的？
• RQ3： 一个紧凑的、微调的检索 - 重排序管道能否有效利用这些信号？

我们的调查产生了几个发现。首先，我们证明技能路由确实具有挑战性：即使是最好的 8B 基础编码器也只实现 64.0% 的 Top-1 路由准确率，当排除技能正文时，BM25 降至接近零（RQ1）。其次，我们揭示技能正文——完整实现文本——是选择的决定性信号，而不是传统假设的名称或描述。移除正文会导致所有方法的性能下降 29-44 个百分点，交叉编码器注意力分析显示 91.7% 的注意力集中在正文字段上（RQ2）。第三，基于这些发现，我们提出了 SkillRouter，一个在两阶段都使用完整技能文本的两阶段检索 - 重排序管道。SkillRouter 总参数量仅 1.2B（0.6B 编码器 + 0.6B 重排序器），实现了 74.0% 的 Top-1 路由准确率，与更大的零样本替代方案相比表现优异（RQ3）。紧凑设计是有意为之：随着 OpenClaw 等个人代理产品的普及，技能路由必须在消费级硬件上运行，无需云 API 或大型 GPU 集群。SkillRouter 的 0.6B 模型可以部署在笔记本电脑 CPU 上，使设备端技能路由在我们目标的紧凑设置中变得实用。相同的方案可扩展到 8B，达到 76.0% 的 Hit@1，证实该方法可推广到紧凑设置之外。

我们的贡献：

1. 我们进行了首次大规模技能池中技能路由的系统性实证研究，揭示了技能正文的决定性作用——这一发现推翻了当前代理框架中普遍存在的”名称 + 描述就足够”的假设。

2. 我们构建了一个标准化评估基准，包含约 80K 技能和 75 个专家验证查询，分为两个难度级别，包括 24 个单技能查询和 51 个多技能查询，基于 SkillBench（Huang 等人，2025）的高质量任务 - 技能映射。

3. 我们提出了 SkillRouter，一个 1.2B 参数的检索 - 重排序管道，其紧凑的 0.6B+0.6B 配置达到 74.0% 的 Hit@1，与更大的零样本基线相比表现优异。紧凑设计使个人代理产品的设备端部署成为可能，并突出了任务特定适配对技能路由的价值。

4. 我们提供了详细的消融分析，表明在同质化技能池中训练时，假阴性过滤和列表排序损失至关重要，为未来工作提供实用指导。

2 问题定义与基准测试

2.1 问题形式化

我们考虑技能路由问题：给定用户任务查询 q 和大型技能池 S={s1,…,sN}，选择与完成任务最相关的技能。每个技能 si 是一个结构化文本单元，包含三个字段：

• 名称（Name）： 简短标识符（例如 pdf-merger）。
• 描述（Description）： 技能目的的一句话总结。
• 正文（Body）： 完整实现或详细规范，通常数百到数千个 token。

池大小 N 在现实世界的代理生态系统中可以从数万到数十万不等，使得暴力评估不可行。目标是检索候选技能的排序列表，使真实技能 Gq⊆S 尽可能排名靠前。

隐藏正文不对称性（Hidden-body asymmetry）

技能路由设置的一个独特特征是我们所称的隐藏正文不对称性：最终使用所选技能的代理通常在上下文窗口限制下运行，只能看到技能的名称和描述。然而，路由组件（检索器和重排序器）可以访问完整的技能文本，包括正文。这在选择器（具有完全访问权限）和消费者（仅看到元数据）之间创建了信息不对称。正如我们在第 3 节中展示的那样，这种不对称性不仅仅是设计便利，而是必要的——正文访问对准确选择至关重要。

评估指标

我们使用标准检索指标进行评估：Hit@1（Top-1 路由准确率，我们的主要指标）、MRR@10（Top-10 中的平均倒数排名）、nDCG@10（归一化折损累积增益）、Recall@K（K∈{10,20,50}，检索到的真实技能比例）和 FC@10（所有真实技能出现在 Top-10 中的查询比例）。对于多技能查询，当任何所需技能排名第一时，Hit@1 计为成功。因此，我们将 Recall@K 和 FC@10 报告为互补的覆盖率指标。在整篇论文中，我们的标题结果应被解读为路由质量结果，而不是直接的端到端任务完成测量。

2.2 基准测试构建

评估技能路由需要一个具有两个属性的基准测试：(1) 高任务 - 技能亲和力——每个查询必须有明确定义的真实技能，这些技能对于任务是必要且充分的；(2) 现实的池规模——技能池必须足够大，使检索变得不平凡。

来自 SkillBench 的任务 - 技能对

我们在 SkillBench（Huang 等人，2025）的基础上构建评估查询，这是一个旨在评估 LLM 代理在需要特定技能的复杂任务上表现的基准测试。SkillBench 提供专家策划的任务 - 技能映射，其中每个任务与完成它所需的特定技能配对。这种强大的任务 - 技能亲和力——经领域专家验证——使 SkillBench 成为高质量真实注释的理想来源。我们提取了 87 个任务查询及其真实技能映射，然后应用一致性过滤器移除具有模糊或注释者不同意技能分配的查询，得到 75 个核心查询。其中包括 24 个单技能查询和 51 个多技能查询。

技能池构建

为了创建现实的检索挑战，我们通过将 SkillBench 技能与来自开源仓库的大量社区贡献技能相结合，构建了一个约 80K 技能的技能池。 resulting 池跨越 51 个功能类别，并表现出现实世界技能生态系统的自然特征：高技能间同质性（许多技能名称相似且功能重叠）、多样化的正文长度（平均 952 词，中位数 703）和长尾类别分布。

难度级别

我们定义了两个难度级别来探究检索鲁棒性的不同方面：

• Easy（78,361 个技能）： 基础池 augmented with 真实技能。所有技能元数据（名称、描述、正文）完全完整。此级别测试标准条件下的检索。
• Hard（79,141 个技能）： Easy 池 augmented with 780 个 LLM 生成的干扰技能——与真实技能主题相关但功能不同的合成技能。这些干扰技能增加了技能间混淆，测试模型是否能区分真正相关的技能和看似合理的替代方案。

所有评估结果报告两个级别的性能，以平均值（Easy + Hard）作为主要汇总。

3 什么信号驱动技能选择？

在展示我们的管道之前，我们调查一个基本问题：技能文本的哪些组件实际上对准确选择很重要？每个技能由三个字段组成——名称、描述和正文——当前代理框架中的普遍假设是名称和描述提供足够的信息进行技能匹配。我们通过受控实验和注意力分析挑战这一假设，揭示技能正文是准确选择的决定性信号。

3.1 名称 + 描述 vs 完整技能文本

我们在检索方法中比较两种输入配置：nd（仅名称 + 描述）和 full（名称 + 描述 + 正文）。表 1 展示了结果。

关键发现：

• 移除正文导致灾难性失败。 使用 nd 输入的 BM25 在所有指标上恰好达到零：真实技能的名称和描述与用户查询几乎没有词汇重叠，使得关键词匹配完全无效。添加技能正文将 BM25 恢复到 34.7% 的 Hit@1。
• 这种效应在所有模型家族中是普遍的。 密集编码器显示出相同的模式：Qwen3-Emb-0.6B 从 58.7%（full）下降到 22.7%（nd），下降了 36.0 个百分点。即使是 8B 模型也无法补偿——Qwen3-Emb-8B nd（30.7%）远低于 0.6B full 模型（58.7%）。
• 没有正文的重排序器实际上有害。 在 nd 输入上操作的重排序器会将性能降低到仅编码器基线以下。最好的 nd 交叉编码器组合仅实现 30.7% 的平均 Hit@1——相比之下，相同编码器没有重排序为 56.0%，下降了 25.3 个百分点。

3.2 注意力分析：模型看哪里？

为了理解为什么正文很重要，我们分析了交叉编码器重排序器（SR-Rank-0.6B）的注意力模式。我们将注意力权重按字段（名称、描述、正文）划分并归一化为总和为 1。

结果：

• 正文接收 91.7% 的总注意力
• 名称接收 7.3%
• 描述仅接收 1.0%

分层模式：正文→名称→正文

注意力分布在各层中演变。早期层（0-6）几乎完全集中在正文内容上（97.3%）。中间层（7-20）分配越来越多的注意力给名称，在第 19 层达到峰值 26.3%。后期层（21-27）返回正文主导（91.7%）。描述注意力在所有层中保持可忽略不计（≤1.4%）。

3.3 启示

这些发现推翻了技能名称和描述足以进行选择的常见假设：

1. 检索和重排序必须访问完整正文。 任何仅操作名称和描述的技能路由系统从根本上受到限制。
2. 隐藏正文不对称性是真正的设计约束。 检索/重排序层必须具有正文访问权限，在代理和其路由组件之间创建固有的信息不对称。
3. 这些发现直接推动了我们的管道设计。 SkillRouter 在编码器和重排序器阶段都使用完整技能文本。

4 SkillRouter：首个实用管道

基于第 3 节的发现，我们设计了 SkillRouter，一个紧凑的两阶段检索 - 重排序管道，总参数量仅 1.2B（0.6B 编码器 + 0.6B 重排序器）。

4.1 概述

给定用户查询 q 和技能池 S（其中 N≈80K），SkillRouter 分两个阶段操作：

1. 双编码器检索： SR-Emb-0.6B 使用完整技能文本将查询和所有技能编码到共享嵌入空间。通过余弦相似度检索 Top-K 候选（K=20）。
2. 交叉编码器重排序： SR-Rank-0.6B 通过交叉注意力联合处理每个（查询，候选）对，对完整技能文本进行处理，产生细化的相关性分数。

两个阶段都使用完整技能文本作为输入。技能离线预编码；在推理时，只需要查询编码、ANN 搜索和 20 个候选的重排序。

4.2 双编码器检索

基础模型： 我们微调 Qwen3-Emb-0.6B，这是一个支持可变长度输入和指令前缀编码的基于解码器的嵌入模型。

训练数据： 我们构建了 37,979 个（查询，技能）对的训练集。对于每个采样的技能，我们使用 LLM（GPT-4o-mini）生成合成用户查询，提示技能的元数据和正文内容。

硬负例挖掘： 我们采用多源挖掘策略，从四个互补来源为每个查询生成 10 个负例：

• 语义负例（每个查询 4 个）
• 词汇负例（每个查询 3 个）
• 分类负例（每个查询 2 个）
• 随机负例（每个查询 1 个）

假阴性过滤： 我们应用三层过滤管道：

1. 名称去重
2. 正文重叠（三元组 Jaccard 相似度 >0.6）
3. 嵌入相似度（余弦相似度 >0.92）

总共，约 10% 的挖掘负例对被移除。

损失函数： 我们使用批次内 InfoNCE 损失进行训练。

训练配置： 我们在单个 GPU 上训练，批次大小 8，梯度累积 4（有效批次大小 32），学习率 2×10^-5，采用余弦调度和 5% 预热，使用 BF16 混合精度和梯度检查点。训练运行 1 个 epoch。

4.3 交叉编码器重排序

基础模型： 我们微调 Qwen3-Reranker-0.6B，这是一个基于解码器的交叉编码器，处理连接的（查询，文档）对并输出相关性分数。

输入格式： 每个候选技能以扁平连接的方式呈现给重排序器，包括其名称、描述和正文（记为 flat-full）。

训练数据： 对于 32,283 个训练查询中的每一个，我们使用训练好的 SR-Emb-0.6B 编码器检索 Top-20 候选。

损失函数： 我们比较两种损失公式：

• 列表交叉熵（LW）： 对列表中所有 K 个候选的相关性分数应用 softmax
• 逐点二元交叉熵（PW）： 通过 sigmoid 独立评分每个（查询，技能）对

我们的消融研究表明，列表 CE 显著优于逐点 BCE（+30.7pp Hit@1）。

训练配置： 我们在单个 GPU 上训练，批次大小 1（每次前向传播一个包含 20 个技能的候选列表），梯度累积 16 步。

5 评估

5.1 实验设置

评估协议： 所有实验都在我们的基准测试上进行，该基准测试包含 75 个专家验证查询（24 个单技能，51 个多技能），跨越两个难度级别：Easy（78,361 个候选技能）和 Hard（79,141 个候选技能）。

编码器基线： 我们与 BM25、传统编码器（E5-Large-v2、GTE-Large-v1.5、BGE-Large-v1.5）、基于解码器的编码器（Qwen3-Emb 0.6B 和 8B、NV-Embed-v2）以及专有模型（OpenAI text-embedding-3-large、Google gemini-embedding-001）进行比较。

重排序器基线： 对于重排序阶段，我们评估交叉编码器重排序器（Qwen3-Reranker-0.6B 和 8B）和 LLM 作为法官重排序器（GPT-4o-mini 和 GPT-5.4-mini）。

我们的模型：

• SR-Emb-0.6B：在 37,979 个技能路由查询上微调的 Qwen3-Emb-0.6B
• SR-Emb-8B：应用于 Qwen3-Emb-8B 的相同微调方案
• SR-Rank-0.6B：使用列表交叉熵损失微调的 Qwen3-Reranker-0.6B
• SR-Rank-8B：应用于 Qwen3-Reranker-8B 的相同重排序方案

5.2 编码器检索结果

关键发现：

• 微调缩小了规模差距。 SR-Emb-0.6B 实现 65.4% 的平均 Hit@1，略高于 Qwen3-Emb-8B（64.0%），后者是一个参数量多 13 倍的基础模型。
• 微调的 0.6B 与更大的基线具有竞争力。 SR-Emb-0.6B 在平均 Hit@1 上领先评估的编码器基线。
• 该方案可扩展到 8B。 SR-Emb-8B 达到 68.0% 的平均 Hit@1。

5.3 端到端管道结果

关键发现：

• 移除正文导致重排序崩溃。 仅使用名称和描述进行重排序会将性能降低到仅编码器检索以下。
• SkillRouter-0.6B 实现 74.0% Hit@1。 我们的主要管道（SR-Emb-0.6B × SR-Rank-0.6B，总共 1.2B）实现 74.0% 的平均 Hit@1，比最强的零样本 8B 管道高出 6.0 个百分点。
• 该方案可扩展到 8B。 SR-Emb-8B × SR-Rank-8B 达到 76.0% 的平均 Hit@1。
• 紧凑重排序器保持竞争力。 SR-Rank-0.6B（0.6B，微调）达到 74.0%，相比之下 Qwen3-Rank-8B base（8B，零样本）为 71.4%。

5.4 消融研究

5.4.1 训练数据质量：假阴性过滤

发现： 过滤贡献 +4.0pp Hit@1。移除假阴性过滤器会将平均 Hit@1 从 65.4% 降低到 61.3%。在 Hard 级别上的影响几乎是 Easy 级别的两倍（-5.3pp vs -2.7pp）。

5.4.2 损失函数：列表 vs 逐点

发现： 列表损失至关重要：比逐点高出 +30.7pp。使用列表 CE 的 SR-Rank-0.6B（74.0%）超过逐点变体（43.3%）30.7 个百分点。逐点微调会将性能降低到仅编码器检索以下。

5.5 分析

5.5.1 编码器 vs 重排序器贡献分解

发现： 重排序器挽救 12.7%，仅降级 4.0%。在 150 个查询中，重排序器纠正了 19 个案例（12.7%），其中编码器将正确技能放在排名 1 之外但在 Top-20 检索窗口内。相反，只有 6 个查询（4.0%）被降级。净贡献是 +8.7pp Hit@1（从 65.3% 到 74.0%）。

5.5.2 效率

SkillRouter 的一个关键动机是在个人代理产品（如 OpenClaw）中进行设备端部署，其中基于云或大模型推理不切实际。完整管道总共仅 1.2B 参数，可以部署在笔记本电脑 CPU 上。

6 结论

我们提出了首次大规模技能路由的系统性研究，揭示技能正文是准确选择的决定性信号——推翻了”名称 + 描述就足够”的假设。基于这一发现，我们提出了 SkillRouter，一个紧凑的 1.2B 参数检索 - 重排序管道，实现 74.0% 的 Hit@1，并使个人代理产品的设备端部署成为可能。我们的消融分析为未来工作提供实用指导，表明在同质化技能池中训练时，假阴性过滤和列表排序损失至关重要。