SkillRouter: Skill Routing for LLM Agents at Scale

读前先抓住结论

SkillRouter 研究的是一个很贴近当前 Agent 产品的问题：当系统里有成千上万个 reusable skill 时，Agent 不可能在每次任务里看到全部 skill。于是系统必须先做一件上游工作：根据用户任务，从庞大的 skill 注册表中找出最相关的少量 skill，再交给后续规划和执行模块。

论文的核心结论非常直接：在大规模且高度重叠的 skill 池中，只看 skill name 和 description 远远不够，完整 skill body 是关键路由信号。 作者在约 8 万个候选 skill 的 SkillsBench-derived benchmark 上发现，隐藏 body 会让 BM25、embedding 检索和 retrieve-and-rerank pipeline 的准确率下降 31 到 44 个百分点。

这件事对 Agent 架构很重要。很多系统采用 progressive disclosure：先只暴露 skill 名称和描述，真正需要时再展开 body。这个设计对上下文预算友好，但如果路由器也只看元数据，它可能根本找不到正确 skill。找错之后，下游 Agent 再强也很难恢复，因为正确知识没有进入 shortlist。

基于这个发现，作者提出 SkillRouter：一个 1.2B 参数的全正文 retrieve-and-rerank pipeline。第一阶段是 0.6B bi-encoder，从约 8 万个 skill 中召回 top-20；第二阶段是 0.6B cross-encoder reranker，读取 query 和候选 skill 的完整正文并重新排序。

结果上，SkillRouter 达到 74.0% Hit@1 和 70.4% R@10，超过最强 16B base pipeline 的 68.0% Hit@1，同时参数少 13 倍、服务延迟低 5.8 倍。补充基准和下游 coding agent 实验也显示，路由收益会传导到真实任务成功率，尤其是更强的 Agent 更能吃到好 skill routing 的红利。

为什么 skill routing 是高杠杆瓶颈

skill 的价值在于复用。一个 skill 往往不只是几句描述，而是包含任务流程、工具调用方式、依赖安装、输入输出格式、边界条件和执行提示。对 Agent 来说，skill 类似可召回的过程性知识：一旦召回正确，它可以显著减少重新摸索；一旦召回错误，它会把 Agent 带向错误操作路径。

问题是 skill 生态会迅速膨胀。个人、团队、组织、社区都可能积累自己的 skill 注册表。一个成熟系统里，skill 数量很容易达到几千甚至几万条，而且大量 skill 会共享关键词。例如很多 skill 都提到 GitHub、CSV、PDF、workflow、dependency、report，但它们真正支持的功能可能完全不同。

因此，skill routing 和普通工具选择不太一样。普通 tool routing 往往面对几十个 API 或函数，名称和描述通常足以区分；skill routing 面对的是大量自然语言文档、执行说明和近似功能包。候选之间不仅数量大，而且语义重叠严重。

这也是论文强调的 hidden-body asymmetry。路由器理论上可以查看完整 skill 文本，但下游 Agent 为了节省上下文，通常只会看到被选中的少量 skill 的 name 和 description，或在需要时才展开 body。换句话说，上游路由器应该比下游 Agent 看得更多，否则 progressive disclosure 会在第一步就损失关键信息。

这篇论文最实用的地方，就是把这个直觉变成了实验问题：如果只看 name+description，性能到底掉多少？如果读 full body，能不能用紧凑模型把成本控制住？如果检索指标提升，下游 Agent 任务成功率会不会也提升？

基准怎么构造，指标怎么看

论文的核心 benchmark 来自 SkillsBench。SkillsBench 提供专家标注的任务-skill 映射，作者从 87 个任务中排除 12 个过于泛化的文件类型任务，保留 75 个核心查询。其中 24 个是单 skill 查询，51 个是多 skill 查询。这一点很重要，因为真实任务常常需要多个 skill 协同，而不是只有一个正确答案。

候选池约 8 万个 skill，由 SkillsBench skill 加上 Claude Skill Registry Core 等开放 skill 集合组成，覆盖 51 个类别。作者设置了两个难度层：Easy 有 78,361 个候选；Hard 在此基础上加入 780 个 LLM 生成的干扰 skill，总数 79,141。这些干扰项主题相近但功能不同，用来模拟“看起来很像但不能完成任务”的困难候选。

指标方面，Hit@1 是主指标，表示第一个结果是否命中任一所需 skill。多 skill 查询下，Hit@1 只要把任一 ground-truth skill 排第一就算命中，所以它更像 top-1 入口质量。MRR@10 衡量正确 skill 排名靠前程度，Recall@K 衡量 top-K 中找回了多少所需 skill，FC@10 则看完整 ground-truth skill set 是否都出现在 top-10。

这里要注意一个评价边界。Hit@1 高并不意味着完整任务一定能完成，尤其是多 skill 查询。它只说明入口候选足够好。真正的 Agent 成功还取决于后续规划、上下文展开、工具执行和错误恢复。因此论文同时报告 Recall、FC 和端到端任务成功率，避免只用单一检索指标过度解释。

Hard tier 的设计尤其值得借鉴。很多检索基准只加入随机负样本，这会让问题变得太容易；真实 skill 注册表里更常见的是功能相近的候选。比如一个任务需要“生成 GitHub Actions YAML”，错误候选可能是 generic task scheduler 或 cron manager。它们都和自动化有关，但功能边界不同。SkillRouter 的 benchmark 正是在测试这种功能级混淆。

full body 为什么是关键路由信号

论文最先证明的不是 SkillRouter 本身，而是 body access 的必要性。作者对三类代表基线做对比：BM25 稀疏检索、Qwen3-Emb-8B encoder-only 检索，以及 Qwen3-Emb-8B 加 Qwen3-Rank-8B 的强 base retrieve-and-rerank pipeline。每类都比较 name+description 和 full text 两种输入。

结论很强：隐藏 skill body 会导致 31 到 44 个百分点的准确率下降。这说明 full body 不是轻微补充，而是路由器判断 skill 功能的主要证据来源之一。尤其在大规模重叠池中，描述往往写得短、泛化、营销式或不完整，真正能区分功能的内容藏在 body 里。

body 里通常包含哪些信号？第一是依赖和环境，例如是否安装某个库、是否需要浏览器、是否调用特定 CLI。第二是支持格式，例如一个转换 skill 是否同时支持 XML、YAML、JSON、TOML、INI。第三是执行步骤，例如是否包含 vulnerability audit、CVSS 提取和 CSV 输出。第四是边界条件，例如只支持 docs 还是支持 slides，支持本地文件还是云端 API。

作者还做了两个反驳检查。第一，长度控制注意力分析说明 reranker 不是简单偏向更长字段；它在控制字段长度后仍然关注 body 中与功能相关的片段。第二，按 description quality 分层后，full body 的收益仍然存在，说明问题不是某些 skill 描述太差这么简单。

这个结论对实际系统有个直接含义：progressive disclosure 不能等同于 blind routing。下游 Agent 可以只看精简描述，但路由器最好有权限读取完整 body，或者至少读取 body 的结构化摘要、执行约束和能力索引。否则，系统会把最重要的功能信息藏在第一道门后面。

SkillRouter 的方法：标准 IR 组件，针对 skill 池做适配

SkillRouter 并没有发明新的模型架构。作者的选择很务实：用标准两阶段信息检索架构解决大规模 skill routing。第一阶段 bi-encoder 负责速度和召回，第二阶段 cross-encoder reranker 负责精排。创新点主要在于输入使用完整 skill text，以及训练时针对同质 skill 池做了几个关键适配。

第一阶段中，所有 skill 的完整文本会被离线编码进向量索引。在线来一个 query，只需要对 query 做一次 encoder 前向，然后近似最近邻检索 top-20 候选。这个阶段的任务是不能漏掉正确 skill，因为第二阶段只能重排 encoder 给出的候选。

第二阶段中，cross-encoder 同时读取 query 和每个候选 skill 的完整文本。与 bi-encoder 不同，cross-encoder 可以在 query 与 skill body 之间做 token 级交互，因此更适合判断依赖、格式、任务步骤和功能边界之间的细粒度对应关系。代价是慢，所以只用于 top-20。

1Require: query $q$, full-text skill pool $S$, trained encoder $E$, trained reranker $R$2Ensure: ranked skill shortlist $L$3Offline: embed every skill body $s \in S$ with $E$ and build ANN index4Online: $z_q \leftarrow E(q)$5$C \leftarrow ANN\_Search(z_q, topK = 20)$6for each skill $s$ in $C$:7  $score_s \leftarrow R(q, full\_text(s))$8$L \leftarrow sort(C)$ by $score_s$ descending9return $L$

这个架构的好处是边界清楚。encoder 的指标重点是 Recall@K 和 Hit@1，它需要把正确 skill 带进 top-20；reranker 的指标重点是把 top-20 里的正确 skill 推到最前。服务效率也容易估算：一次 query encoder 前向、一次 ANN 检索、20 次 reranker 打分。

论文把主配置控制在 1.2B 参数，是为了证明全正文路由不是只能靠大模型硬读全部候选。0.6B encoder 加 0.6B reranker 的组合，在这个任务上比 16B base pipeline 更准也更快，说明 task-specific training 和合理 pipeline 比盲目扩大 base model 更关键。

训练细节：困难负样本、假负例过滤和 listwise reranking

SkillRouter 的训练难点来自 skill 池同质性。随机负样本太容易，模型很快学会区分类别，却学不会区分“很像但不对”的候选。因此 encoder 训练为每个 query 构造 10 个负样本，混合四种来源：语义近邻、BM25 词面匹配、同 taxonomy 干扰和随机负样本。

语义近邻让模型处理意思相近但功能不同的 skill；词面匹配让模型处理关键词重叠；同 taxonomy 干扰让模型处理类别相同但能力边界不同；随机负样本保持基本区分能力。这个负样本配方对应了真实注册表里的几种混淆来源。

假负例过滤是另一个关键点。大规模 skill 池里可能有功能等价或近似等价条目。如果一个 query 的标注 ground truth 是 A，但候选池里有另一个 skill B 也能完成任务，把 B 当负样本就会污染训练。模型会被迫把可用 skill 推远，泛化反而变差。

论文使用 BM25 找相似候选，再用 LLM 判断是否功能等价，并移除等价项。附录提到，这个过程发现并移除了多组等价 pair，尤其在 github、docx、xlsx、pptx 等常见能力上最多。这很好理解：通用文件处理和仓库自动化最容易出现重复 skill。

reranker 的核心训练选择是 listwise loss。pointwise loss 把每个 query-skill pair 当成独立二分类，问“这个候选是否相关”；listwise loss 把一组候选一起看，问“这一组里谁应该排最前”。在高度相似的 top-20 候选中，后者更符合实际任务。

消融结果非常夸张：pointwise reranker 只有 43.3% Hit@1，而 listwise 版本达到 74.0%。这说明 skill reranking 不是判断单个候选有没有相关词，而是在一堆都看似相关的候选里做相对排序。孤立二分类会把很多候选都判成“还不错”，但无法稳定推出最正确的那个。

实验怎么读：主结果、消融与补充基准

主实验先看 encoder-only。SR-Emb-0.6B 达到 65.4% 平均 Hit@1，比同尺寸 Qwen3-Emb-0.6B 高 9.4 个百分点，也略高于 13 倍参数的 Qwen3-Emb-8B。这个结果说明，针对 skill routing 的训练能让小模型学到“任务描述到 skill body”的专门匹配模式。

完整 pipeline 更强。SR-Emb-0.6B 加 SR-Rank-0.6B 达到 74.0% Hit@1 和 70.4% R@10。相比同一 encoder 的 encoder-only，reranker 又带来 8.6 个百分点 Hit@1 提升；相比最强 16B base pipeline 的 68.0% Hit@1，它用更小参数取得更高准确率。

消融表把机制说得更清楚。假负例过滤给 encoder 带来 +4.0pp Hit@1 和 +3.1pp MRR@10；listwise reranking 则是 reranker 的决定性因素，pointwise 版本几乎崩掉。这两个结果分别对应训练数据质量和排序目标设计。

Supplementary benchmark SkillBench-Supp 用三个 skill 来源独立构造，包含 256 个单标签查询和约 77K 候选池。作者在这个基准上继续看到 SkillRouter 的收益，说明它没有只记住核心 75 个查询的分布。附录还拆分 Descriptive 和 Indirect 查询，进一步分析直接描述型和间接意图型任务的差异。

指标解释上要小心。Hit@1 适合衡量 top-1 skill 是否好用，Recall@10/20 更适合衡量 shortlist 是否覆盖所需技能，FC@10 则对多 skill 任务更严格。一个系统可能 Hit@1 不错，但多 skill 集合没有完整召回；真实 Agent 任务中，这会导致执行到中途缺少后续能力。

下游 Agent 和服务效率：检索分数是否变成任务成功

论文没有停在 retrieval benchmark，还做了下游端到端 coding agent 评估。设置是把不同路由器产出的 top-1 或 top-10 skill shortlist 交给四个 coding agent，看任务成功率是否提升。这个实验很重要，因为最终用户关心的不是 Hit@1 本身，而是 Agent 有没有更大概率完成任务。

结果显示，SkillRouter 相比最强 base router 提升平均任务成功率，而且更强的 Agent 获益更明显。这也符合直觉：弱 Agent 即使拿到正确 skill，也可能不会用；强 Agent 有能力消化 skill body、执行工具和修复错误，因此更好的 skill routing 会更直接转化为成功率。

这说明 skill routing 和 Agent 能力之间存在互补关系。路由器负责把正确过程知识放到桌面上，Agent 负责读懂并执行。两者缺一不可：路由器差，Agent 看不到正确 skill；Agent 差，正确 skill 也可能被误用。

服务效率部分回答另一个现实问题：读 full body 会不会太慢？作者只计算在线查询路径，包括 query encoder 前向、ANN 检索和 top-20 reranking。主 1.2B pipeline 达到亚秒级中位延迟，并且比最强 base pipeline 快 5.8 倍。

这里的工程启发是，full-text routing 不一定意味着每次都把 8 万个 skill 全部塞给大模型读。正确架构是离线编码全量 skill，在线只取小候选集，再用 reranker 在小集合上认真读正文。这样既保留 body 信号，又控制线上成本。

案例揭示了什么失败模式

附录案例很有价值，因为它解释了模型到底在学什么。第一个案例是 video-tutorial-indexer。base encoder 被表面关键词 video 误导，召回视频编辑工具；SR-Emb 学会了“video + timestamps”实际上对应 speech-to-text 或转写索引能力，把 ground truth 排到第一。

第二类案例是 reranker rescue。encoder 可能只把正确 skill 放到第 13 名，但 reranker 通过完整 body 看到依赖安装说明、支持格式或执行步骤，把它提升到第一。这个过程说明 reranker 的贡献不是重新做大池召回，而是在候选已经大致相关时读取细节做裁决。

workflow-automation 案例也很典型。query 需要 GitHub Actions YAML，base encoder 可能召回 generic automation 或 cron manager，因为关键词都接近；SR-Emb 能从 body 中学到 CI/CD、conditional workflow syntax 与 GitHub Actions 的对应关系。这里的关键不是词面相似，而是功能结构相似。

multi-format converter 案例则展示了 body 的独特价值。名称和描述可能只粗略说“convert files”，但 body 里列出 XML、YAML、JSON、TOML、INI 等支持格式。reranker 通过 cross-attention 读到这些支持范围，才能判断哪个 skill 真正覆盖用户需求。

这些案例共同说明，skill routing 的难点不是找“相关主题”，而是找“可执行能力”。相关主题可以靠关键词或通用 embedding 找到；可执行能力往往藏在 body 里的参数、格式、依赖和步骤中。

局限与复用启发

SkillRouter 的第一个边界是 benchmark 范围。核心 benchmark 只有 75 个专家验证查询，虽然候选池很大，也有 Hard distractors 和补充基准，但它仍代表特定 skill 生态和任务构造方式。其他组织的内部 skill 可能有不同命名规范、正文质量和等价 skill 密度。

第二个边界是正文可用性。论文的前提是 skill body 质量足够高，包含可区分的功能信息。如果组织里的 skill body 写得很随意、缺少执行步骤、没有清楚边界，full-text routing 的收益会下降。换句话说，SkillRouter 同时提醒我们：skill 文档质量本身就是召回质量的一部分。

第三个边界是权限与安全。路由器能读完整 body，不代表下游 Agent 应该无约束执行所有 skill。真实系统还需要权限过滤、环境限制、危险操作确认和审计日志。否则召回到强力 skill 可能提高效率，也可能扩大错误执行的风险。

第四个边界是动态更新。skill 注册表会不断变化，新增、删除、合并和版本升级都会影响向量索引、等价关系和 hard negative 分布。SkillRouter 的方法适合做定期重建或增量更新，但论文没有完整展开持续在线更新机制。

对工程复用来说，最应该带走四件事。第一，路由器应该能访问完整 body，至少应访问从 body 中抽取的结构化能力索引。第二，训练样本必须包含困难负样本，随机负样本无法教会模型区分相似 skill。第三，要处理假负例，因为真实 skill 池里常有功能重复项。第四，reranker 最好用 listwise 目标训练，因为 top-20 候选之间的相对排序才是关键。

这篇论文也和 skill 自进化关系很近。skill 自进化不仅是生成新 skill，更包括让系统知道何时召回、如何比较、如何淘汰或合并等价 skill。SkillRouter 提供的是“skill 生态的检索层”：没有可靠检索层，skill 越多，Agent 反而越容易迷路。

读完之后应带走的判断

SkillRouter 最值得记住的判断是：大规模 skill 生态里，召回不是辅助功能，而是 Agent 能否使用技能的前置条件。Agent 的能力上限不仅取决于模型会不会执行 skill，也取决于系统能不能先找到正确 skill。

full body 的作用也应该被重新理解。它不是为了让下游 Agent 每次都读完整文档，而是为了让上游路由器做更好的筛选。progressive disclosure 仍然可以保留，但披露策略不能把路由器也限制在贫乏元数据里。

方法上，SkillRouter 说明标准 IR pipeline 仍然很有生命力。面对 8 万候选，不必让一个大模型直接选择；更稳的方式是 encoder 负责召回，reranker 负责精排，并用任务专门训练解决同质候选和假负例问题。

结果上，论文展示了一个漂亮的效率-准确率折中：1.2B tuned pipeline 超过 16B base pipeline，说明在 Agent 基础设施问题上，数据构造、训练目标和系统分层常常比单纯扩大模型更有效。

对后续 Agent 产品来说，这篇论文可以成为设计 skill registry 的检查清单：skill body 是否足够可检索，是否存在大量等价项，是否有 hard negative 训练集，是否用 reranker 做细粒度排序，是否把检索指标和端到端任务成功率一起看。只有这些层都稳，skill 数量增长才会变成能力增长，而不是噪声增长。

从论文到产品系统的设计清单

如果把 SkillRouter 放进真实产品系统，可以把它拆成五个工程层。第一层是技能注册表，负责保存名称、描述、正文、版本、权限、依赖和适用范围。第二层是离线索引，负责把完整正文编码成可检索向量，并记录每个技能的结构化元数据。第三层是在线召回，负责用用户任务找到一批高覆盖候选。第四层是全文重排，负责在相近候选之间读细节、判功能、排序。第五层是执行前治理，负责权限检查、风险过滤、上下文展开和审计记录。

这五层里，最容易被低估的是注册表质量。许多团队会把技能写成给人看的说明，名称很漂亮，描述很简洁，但正文缺少输入输出格式、依赖安装、失败条件和边界说明。这样的技能即使被人类读懂，也不一定适合机器检索。SkillRouter 的结论反过来要求我们写技能时兼顾“可执行”和“可召回”：正文应该明确说明它能做什么、不能做什么、需要什么环境、输出什么产物。

第二个容易被低估的是等价技能管理。真实注册表里常常会有多个技能都能完成相似任务，例如多个文档转换器、多个仓库自动化脚本、多个表格处理流程。训练路由器时如果把这些等价技能互相当成负例，模型会学到错误边界；线上服务时如果完全不管理等价项，系统也可能给用户展示多个重复候选。论文的假负例过滤可以扩展成产品里的技能合并、去重和版本治理机制。

第三个设计点是多技能任务。很多真实请求不是一个技能就能解决，而是需要组合：先读取文件，再分析内容，再生成报告，再提交仓库。对于这类任务，只优化首位命中不够。系统还需要关注前十是否覆盖完整技能集合，或者让规划器能够基于初始技能继续召回后续技能。论文报告完整集合覆盖率，正是因为它意识到多技能任务的短名单质量不能只由第一名决定。

第四个设计点是路由器与智能体能力的匹配。弱智能体拿到正确技能也可能不会用，强智能体更能从好路由中获益。因此，在评估路由器时不能只看离线命中率，也要接入不同能力层级的智能体做端到端实验。SkillRouter 的下游实验给出一个重要信号：随着智能体执行能力增强，路由质量会成为更明显的瓶颈。

第五个设计点是成本边界。全正文重排听起来昂贵，但论文的架构把成本压在前二十候选上。对产品来说，这意味着可以用多级策略：高频简单任务走轻量路由，低置信或高风险任务启用全文重排，关键任务再加入人工确认或更强模型复核。这样既不会牺牲召回质量，也不会把所有请求都推向最高成本路径。

和 skill 自进化的关系

SkillRouter 讨论的是召回，但它实际上补上了技能自进化闭环里很关键的一环。一个技能系统要自进化，至少要能做四件事：生成新技能，判断新技能和旧技能是否重复，知道什么时候召回哪个技能，根据执行反馈修正技能或路由器。SkillRouter 主要解决第三件事，同时也触及第二件事，因为假负例过滤本质上就是在识别功能等价技能。

如果没有可靠召回，技能越多未必越好。新增技能会增加候选池噪声，让名称和描述相近的条目越来越多，反而降低选择正确技能的概率。这就是技能生态的规模悖论：积累本应带来能力增长，但没有路由层时，积累也会带来检索混乱。SkillRouter 的价值在于让规模增长继续可用。

执行反馈也可以反向训练路由器。每次任务成功，都可以记录用户查询、被召回技能、实际展开正文、执行路径和最终结果；每次失败，也可以记录错误候选、遗漏技能和人工修正。长期来看，这些日志可以形成新的 hard negative、等价技能判断和重排训练样本。这样一来，技能自进化不只是写新文档，也包括改进“如何找到文档”。

这篇论文还提醒我们，技能正文不是静态说明书，而是可学习信号。正文写得越结构化，路由器越容易学习；正文越含混，路由器越依赖表面词。未来的技能系统可以考虑把正文拆成能力、输入、输出、依赖、步骤、边界、失败处理和示例等字段，再让检索器同时读自然语言正文和结构化字段。这会比单一描述更适合大规模召回。

可能的扩展方向

第一个扩展方向是层级路由。八万个技能已经很大，但企业内部可能还有组织、项目、权限域和版本层级。可以先按组织或能力域做粗路由，再在局部池里做全文召回和重排。这样既能减少候选规模，也能更自然地接入权限控制。

第二个方向是多轮路由。用户任务可能一开始很模糊，单次查询无法确定技能集合。路由器可以先召回候选能力域，再让智能体询问澄清问题或读取部分技能摘要，随后进行第二次路由。这样可以避免在任务意图未清楚时过早锁定错误技能。

第三个方向是组合路由。论文主要关注把相关技能排前，但真实任务经常需要技能组合。未来系统可以让路由器直接预测技能序列或技能图，例如先解析仓库，再运行测试，再生成修复，再提交变更。这里可以结合规划器，让检索和任务分解互相影响。

第四个方向是安全感知路由。某些技能拥有写文件、执行命令、访问凭据或操作远端服务的能力。路由器不应只按相关性排序，还应考虑风险等级、用户权限、环境限制和审计要求。一个高相关但高风险的技能，可能需要被降级、要求确认，或替换成只读版本。

第五个方向是持续评估。技能池更新后，旧 benchmark 可能不再覆盖新混淆。系统需要持续生成 hard distractor、抽样人工审核、监控线上失败，并定期重训或校准路由器。SkillRouter 的方法提供了初始框架，但产品化还需要把评估变成常态化运维。

最后的判断

SkillRouter 的核心信息其实很朴素：技能是 Agent 的长期能力资产，而路由器是访问这些资产的索引。如果索引粗糙，资产越多越难用；如果索引能读懂正文、区分功能边界、处理重复项，并把正确候选交给执行器，技能生态才会随规模增长而变强。

因此，这篇论文不只是一个检索模型结果，也是在为 Agent 系统补基础设施。它告诉我们，技能的生成、存储、召回、重排、执行和反馈应该作为一个整体设计。只优化提示词或只堆技能数量都不够，真正稳定的系统需要把“找到正确技能”变成可训练、可评估、可维护的模块。

对正在构建技能库的人来说，最实际的行动是从今天开始保存完整正文、写清能力边界、记录执行反馈、标注相似与等价技能，并用真实任务构建困难负样本。等这些数据积累起来，SkillRouter 式的检索重排层就能把技能库从静态文档集合变成可用的过程知识系统。

更细的落地架构

如果把 SkillRouter 真正接进一个 Agent 平台，最前面应当是技能写入流程。每个新技能进入注册表时，不应该只保存一段自由文本，而应至少包含技能名称、短描述、完整正文、适用任务、输入输出、依赖工具、权限级别、失败条件、示例查询和版本信息。这样做的目的不是让页面看起来整齐，而是让后续检索器和重排器能获得稳定信号。正文越结构化，模型越容易学到功能边界；正文越随意，模型越容易退回到关键词匹配。

第二步是离线索引与质量检查。系统可以定期读取全部技能正文，生成向量索引，同时运行重复检测和等价技能检测。对于高度相似的技能，不一定要立刻删除，但应当建立等价组或替代关系。这样，训练路由器时不会把可替代技能误当负例；线上返回结果时，也可以避免给用户展示一堆重复选项。

第三步是在线路由策略。不是所有请求都需要完整重排。简单、高置信、低风险任务可以直接使用轻量检索；低置信、高风险、多技能或长尾请求则启用全文重排。如果重排后分数仍然接近，系统可以触发澄清问题或把多个候选交给规划器比较。这样的分层策略能把成本花在真正难的任务上。

第四步是上下文展开。路由器找到正确技能后，下游智能体不一定需要读取所有正文。系统可以先给智能体名称、描述和必要片段，再根据规划阶段需要展开依赖、步骤或错误处理。换句话说，路由器读全文是为了选择，智能体读片段是为了执行。选择和执行可以使用不同的信息粒度。

第五步是执行反馈闭环。每次任务完成后，系统都应该记录路由候选、最终使用技能、是否成功、失败原因、人工修正和实际产物。这些日志能转化为新的训练数据：成功样本可以加强正确匹配，失败样本可以生成困难负例，人工替换技能可以标注原路由器的混淆点。长期来看，路由器会随着真实使用逐步变得更懂组织内部技能。

评估时不要只看一个数字

论文使用多个指标是有原因的。首位命中很直观，但它对多技能任务不够完整；前十召回可以看短名单覆盖，但不说明第一名是否好；完整集合覆盖更接近多技能任务需求，但会更严格；下游成功率最接近用户价值，却受智能体能力、工具环境和任务难度影响。一个成熟系统应该同时看这些指标，而不是只挑最高的一个。

离线评估还应区分描述型任务和间接型任务。描述型任务会直接说出技能功能，例如“把表格转成报告”；间接型任务可能只说目标，例如“审计依赖漏洞并生成汇总”。后者更依赖模型理解任务意图和技能正文之间的隐含关系。SkillRouter 在案例中展示的“视频加时间戳对应转写索引”就是典型间接匹配。

困难负样本也要持续更新。随着新技能加入，旧的困难候选可能变容易，新的相似技能又会出现。评估集如果长期不变，会低估新混淆。真实产品可以从线上失败、人工纠正和高相似候选中自动采样，再定期让人工或强模型判断功能差异，形成新的测试集。

端到端评估尤其重要。一个路由器在离线指标上更高，但如果下游智能体不会使用返回的技能，用户仍然感受不到提升。因此要把路由器放进真实执行链路里测试：给同一组任务，固定智能体和环境，只替换路由器，看最终任务成功率、耗时、工具错误和人工干预次数是否改善。

成本指标也应该进入评估。全文重排可以提高准确率，但如果每次请求都明显变慢，产品体验会受影响。论文用亚秒级中位延迟证明主配置可用，但不同组织的硬件、技能正文长度和请求量不同，仍需要本地压测。更实用的做法是把准确率、延迟和风险等级放在同一个决策表里，决定哪些请求启用哪一级路由。

技能正文应该怎样写

SkillRouter 的结论反过来给技能作者提出要求。好的技能正文应该写给人，也写给机器。它需要明确任务入口，例如什么用户请求应该召回这个技能；需要明确输入条件，例如需要文件路径、仓库目录、网络权限还是账户凭据；需要明确输出产物，例如生成文档、提交代码、返回表格还是调用外部服务。

正文还应该写清不适用边界。很多路由错误来自过宽描述：一个技能说自己能处理文档，但其实只支持文字提取，不支持排版；一个技能说自己能做自动化，但其实只生成定时任务，不生成持续集成配置。把这些边界写进正文，路由器才有机会在相似候选中做正确区分。

依赖和工具信息也很关键。如果一个技能需要特定命令行工具、库、浏览器、云服务或认证方式，这些信息都应该出现在正文中。用户查询常常会隐含环境限制，例如“在本地仓库里”“不要联网”“生成某种格式”。路由器只有读到依赖说明，才能判断技能是否真正适用。

示例也很有用。技能正文中可以保留几条典型查询和反例查询。典型查询帮助路由器建立正向匹配，反例查询帮助它区分边界。例如某个技能适合生成工作流配置，但不适合运行工作流；适合转换表格，但不适合分析统计。这样的正反例会成为天然训练信号。

最后，正文应当保持版本可追踪。技能能力变化后，旧的向量索引、训练样本和评估标注可能失效。如果技能正文没有版本，路由器很难知道某次失败是因为模型选错，还是因为技能已经更新。把版本和变更说明纳入正文，有助于后续维护路由数据。

风险与治理

技能路由越强，越需要治理。一个高质量路由器会更容易找到能执行真实操作的技能，这当然提高效率，也提高误操作风险。对于写文件、执行命令、访问凭据、调用付费接口或操作生产资源的技能，路由器返回候选只是第一步，系统还必须检查用户权限和环境安全。

权限可以进入路由阶段。比如同样能操作仓库的两个技能，一个只读分析，一个会直接提交修改。对于未授权用户或高风险任务，路由器应该优先返回只读技能，或者在返回可写技能前要求确认。这样，路由不只是相关性排序，也包含安全策略。

审计日志同样重要。每次路由为什么选择某个技能、它读取了哪些正文片段、下游是否展开完整正文、执行了哪些工具，都应该可追踪。出现事故时，团队需要判断错误来自用户请求歧义、路由器误选、技能正文不清、智能体误用还是工具执行失败。没有日志，技能生态会变成难以维护的黑箱。

治理还包括技能淘汰。随着技能库增长，有些技能会过时、重复、低质量或长期从未被成功使用。路由日志可以帮助发现这些技能：如果某个技能经常被召回但执行失败，需要改正文或降权；如果某组技能总是等价，可以合并；如果某个技能长期无人使用，可以归档。这样，路由器不仅消费技能库，也帮助维护技能库。

从这个意义上说，SkillRouter 不只是检索组件，而是技能生态的观察窗口。它暴露了哪些技能容易混淆，哪些正文缺少判别信息，哪些任务需要新的技能，哪些旧技能应该被合并。把这些信号反馈给技能作者和平台维护者，技能系统才会真正自我改进。

还有一个常被忽略的点：技能路由会影响智能体的探索成本。没有可靠路由时，智能体可能需要在对话中反复试错，先尝试一个看似相关的技能，失败后再寻找替代方案。这个过程会消耗上下文、时间和工具调用次数，也会让用户更难判断系统为什么失败。可靠路由把试错提前到检索阶段，用训练好的模型和重排器过滤大部分错误候选，让智能体从一开始就站在更好的起点上。

这也解释了为什么更强的智能体从 SkillRouter 中获益更大。强智能体能够阅读更复杂的技能说明，能把多个技能组合起来，也能根据失败信息调整执行路径；当路由器给它更好的候选时，它有能力把这些候选转化为真实完成率。弱智能体即使拿到正确技能，也可能因为规划、工具调用或错误恢复能力不足而失败。因此，路由器和执行智能体应该一起评估，而不是孤立优化。

最后，技能路由还会影响用户体验。用户通常不会关心系统内部有多少技能，也不会知道某个技能正文写得多完整。他们只会感受到：任务是否很快进入正确方向，系统是否少问无关问题，失败时是否能解释原因。SkillRouter 这类基础设施的价值，往往体现在这些不显眼但持续影响体验的地方。它让技能库从“很多文档”变成“能在合适时机被找到的能力”。

因此，衡量技能库成熟度时，不能只数技能数量，还要看路由是否能稳定找到正确能力、是否能解释混淆、是否能随反馈持续改善。

这正是本文最有工程价值的提醒：技能系统的质量，最终取决于知识是否能在需要时被准确召回。

否则，沉淀越多，噪声也越多。

路由层就是把沉淀转成能力的入口。