模型技术排行榜

Agentic Skill Routing 排行榜：最佳 Skill 分配方案

2026-06-06

阅读 0

热度 0

作者菜鸟AI编辑部

摘要

当AIAgent的Skill数量增多时，将全部Skill塞入上下文会导致预算超限、描述截断和语义干扰。

核心问题

Agent 的能力边界不断扩展：可读取文件、调用接口、编写代码、管理日程，还能根据团队积累的标准化流程自动执行。沉淀这些实操经验的常见方案就是 Skill。

关键在于：Skill 数量较少时，将所有名称和描述塞入上下文，模型基本能正确匹配。一旦 Skill 规模膨胀，这套方式开始失效——上下文预算被挤占，描述被截断，语义相似的 Skill 相互干扰。一个低频 Skill 每月只用一次，却每天都在消耗常驻 token。

更棘手的在于，许多团队在编写 Skill 时天然倾向“细粒度拆分”：一个 OpenAPI 对应一个 Skill，一个业务流程对应一个 Skill，一个文档模板也对应一个 Skill。短期看灵活，长期看，Agent 的路由入口逐渐被噪声淹没。

因此，我们关注的不是“再训练一个更精准的分类器”，而是另一个命题：Skill 能否像知识库一样被 Agent 主动检索？常用能力保留在手边，长尾能力存入冷存储；需要时，Agent 自行搜索、核查证据、确认选择，再将对应 Skill 拉回执行。

这实际上是 Agentic Search 在 Skill 管理中的一次变体实践。

Skill 常驻列表的真实成本：远不止 token 数字

图：高频 Skill 保留在工作台中，长尾能力进入可检索冷存储

Skill 的核心设计理念是渐进式加载。默认只将 metadata 放入上下文，真正的操作步骤、示例、脚本和参考资料在触发后才读取。这比将完整插件说明常驻上下文合理得多。

但 metadata 并非免费资源。

常见的 Skill 文件结构如下：

skills/
  lark-doc/
    SKILL.md        # metadata + body
    references/
    scripts/
  lark-mail/
    SKILL.md
  code-review/
    SKILL.md

SKILL.md 通常分为两个层次：

frontmatter / metadata：包含 name、description、tags、适用场景，默认参与路由判断。
body：完整流程、注意事项、命令示例、错误处理，命中后再读取。

这套架构在几十个 Skill 时运行良好。到了数百甚至数千个时，问题逐渐暴露。

第一，宿主通常为 Skill 列表分配固定上下文预算。超出预算怎么办？只能截断 description，甚至只保留 name。一个原本描述清晰的“飞书文档读取、更新、图片插入与权限处理”，被截成“飞书文档读…”，路由质量必然下降。

第二，Skill 数量越多，语义相似项越密集。lark-doc、lark-wiki、lark-drive、lark-sheets 都与“飞书文件”相关；stock-analysis、china-stock-analysis、us-stock-analysis 都与股票有关。模型面对一堆短描述时，容易被表面词汇误导。

第三，常驻列表让低频 Skill 持续占用预算。一个一年只用三次的 Skill，只要处于 enabled 状态，就和每日高频 Skill 站在同一个上下文入口。个人环境尚可忍受，团队级 Skill 目录则完全不现实。

因此，Skill 管理的核心矛盾并非“如何把所有 Skill 介绍得更短”，而是：哪些 Skill 应该常驻？哪些 Skill 应该退出上下文，但仍然能被有效召回？

被动 Top-K 路由为何不足

一个自然的思路是引入检索。将 Skill 的 name、description、body 建立索引；用户请求到来时，通过 embedding 召回 Top-K，再交由 reranker 或 LLM 选择。

这条路径可行，且在多数场景下有效。但它带来两个工程代价。

首先是模型依赖问题。embedding、reranker、向量库、索引刷新、版本兼容……这些对于平台团队不是难题，但对于本地 Agent 用户和小团队则是额外负担。Skill 本意是降低使用门槛，结果却引入一套检索基础设施，方向有些偏离。

其次是交互形态。传统 Top-K 本质上是一次性函数调用：用户 query 输入，候选列表输出，Agent 仅能被动消费结果。如果第一轮 query 抽取了错误词汇，或者候选中有两个 Skill 高度相似，Agent 很难像人类一样“换个词再搜一次”“打开两个候选查看证据”“不确定就不选”。

这正是被动检索的局限。它将 Agent 置于消费者位置，而非 搜索过程的主动操作者。

Agentic Search 的关键转变：让模型主导检索流程

Agentic Search 并不神秘。它只是将搜索从“一次性返回答案”改为“多步收集证据”。

一个更适配 Agent 的检索接口，至少应允许它完成四件事：

从当前任务中提取关键短语，而非直接拿用户原始句子去搜索。
查看候选被召回的原因，包括命中的字段、片段、评分以及是否被截断。
对少量候选进行深入检查，但避免一次性倒出全部内容。
在证据充分时做出选择，证据不足时主动停止或继续搜索。

这与近年 Agentic RAG、Direct Corpus Interaction、grep-style harness 的讨论一脉相承：检索器不再只是黑盒排序器，而是 Agent 可以操作的外部环境。

将其应用于 Skill 管理，思路演变为：

图：Agent 在 enabled Skill 与 metadata corpus 之间按证据路由

这里有一个边界至关重要：在 select 之前，只查看 metadata，不读取被禁用 Skill 的 body。

这并非洁癖，而是上下文控制。搜索阶段如果每个候选都打开完整说明，Skill router 很快会退化成一个新的上下文黑洞。metadata 足够时就选定；metadata 不足时，最多检查少量候选；仍然不足，则承认低置信度，而非勉强挑一个看起来顺眼的。

禁用不等于删除：低频 Skill 应进入冷存储

Skill 管理中最容易被误解的概念是 disable。

很多人听到禁用，会以为能力被移除。更合理的理解是：禁用只是让 Skill 退出常驻列表。文件仍在，metadata 仍在，路径仍在，使用记录也可以继续追踪。它只是从“每天站在上下文门口”变成“需要时可以被查找到”。

这类似于内存与磁盘的关系。高频、基础、系统级 Skill 留在内存中；长尾 Skill 放到磁盘上。Agent 不应每次启动都把整块磁盘读入上下文，它需要一套索引和读取协议。

一个可维护的 Skill 冷存储，至少需要以下组件：

组件	作用	需要避免的问题
metadata corpus	保存 disabled Skill 的可检索字段，如 name、description、aliases、tags、tools、domains、intents、examples	description 过短、字段缺失、同质 Skill 缺乏区分度
stable ref	用稳定引用指向候选，而非直接暴露本地路径给模型	路径泄露、路径变化、候选不可复现
inspect 接口	允许 Agent 对少量候选查看更多 metadata	一次性输出过多，重新制造上下文压力
select 记录	将“为何选择它”记录为可审计事件	路由不可追踪，后续无法优化
restore 机制	能将 disabled Skill 恢复为 enabled	禁用变成破坏性操作

这样处理后，Skill 数量增长带来的压力就不再线性加载到上下文中。上下文里常驻少量高频 Skill，外加一个 router 入口；长尾 Skill 通过 metadata corpus 按需找回。

三个核心原语：search、inspect、select

图：Agent 通过 search、inspect、select 逐步收集路由证据

更稳妥的做法，是将 Skill 路由拆分为三个小工具，而不是一次性封装一个 routeSkill(query) 函数。

corpus search：低成本召回

search 接收 Agent 提取的关键词，返回一组候选。最好区分 must terms 与 probe terms。

例如用户说“读取飞书 docx 并提取第一章”，must terms 可以是 lark、docx，probe terms 可以是 document、fetch、extract。search 返回的不是最终答案，而是候选证据：ref、score、matched terms、description snippets、totalMatches、returned、truncated。

truncated 这个字段非常有价值。它告诉 Agent：当前 query 过于宽泛，候选被截断了，需要更换词汇或增加约束条件。没有这个信号，模型会误以为返回列表就是全部可选项。

corpus inspect：仅检查少量候选

inspect 用于处理“几个候选看起来都像”的情况。它可以返回更完整的 metadata，如 aliases、tags、tools、domains、intents、examples，但仍然不读取 body。

这一步的关键是有界性。不要让 Agent 一次性 inspect 50 个候选。通常 2-5 个就足够了。Skill 路由不是信息检索比赛，它只是要为当前任务找到一个可执行的能力入口。

corpus select：将选择变为记录

select 是闭环动作。Agent 必须提供 ref/id、原始 query、confidence 和 reason。CLI 再将 ref 解析为真实的 disabled Skill，记录一次 routed use，最后返回 selected.skillMdPath。

这样做有两个好处。

第一，模型不能直接拿搜索结果中的路径随意读取。第二，所有选择都有审计记录。日后你想了解哪些 disabled Skill 实际上经常被召回，哪些从未被选中过，就会有数据可供分析。

一个典型的调用流程可以设计如下：

agentic-skill-router skills corpus search 
  --all "lark" 
  --any "docx" 
  --any "document" 
  --any "extract" 
  --limit 30 
  --jsonagentic-skill-router skills corpus inspect corpus-xxx corpus-yyy --jsonagentic-skill-router skills corpus select "corpus-xxx" 
  --query "读取飞书 docx 并输出第一章" 
  --confidence high 
  --reason "metadata covers Lark docx fetching and document content extraction" 
  --json

这个接口不花哨，但边界清晰。Agent 负责判断，CLI 负责索引、分页、ref、JSON schema、缓存和选择记录。

Bash 直接搜索文件，为何不适合作为默认产品边界

如果仅用于研究验证，让 Agent 直接使用 shell 搜索本地 Skill 目录确实很有吸引力。find、grep、sed、awk 功能足够强大，模型也能临场组合多种策略。中小规模目录中，这种 DCI 风格的做法甚至非常精准。

但它不适合作为默认产品形态。

原因不是 bash 不够强，而是过于自由。今天模型写 grep -R，明天写 find | xargs，后天又加 head -20。路径包含空格怎么办？文件过多触发 ARG_MAX 怎么办？候选被 head 截断怎么办？输出太长撑爆上下文怎么办？这些问题最终都会落入 prompt 中，prompt 越来越像一段脆弱的 shell 教程。

Tool-wrapped 的优势正在于此。将容易出错的部分收敛到 CLI：路径枚举、缓存、索引、分页、截断提示、候选引用、schema 校验。Agent 仍然进行主动搜索，但不必每次临场编排一段不稳定的 pipeline。

换言之，bash 适合调试 failure case，适合作为研究对照；默认路径最好还是稳定的原语。

Metadata-first 的边界：领域词汇可能误导路由

仅依赖 metadata 也有其上限。

最典型的失败来自“业务领域词”与“底层执行工具”之间的冲突。用户说“分析 supply shock 的经济影响并生成表格”，metadata-only router 可能被 economics、shock analysis、timeseries 这些领域词汇吸引。但真正完成任务需要的可能是 spreadsheet / Excel Skill，因为交付物是读取表格、编写公式、生成文件。

这类 query 不能简单按语义最接近来匹配。需要加入一条 tie-break 规则：当任务明确要求操作 xlsx、csv、单元格、公式、透视表或表格产物时，底层 substrate Skill 的优先级应高于领域分析 Skill。除非领域 Skill 明确声明自己也能完成文件读写和表格输出。

因此，metadata-first 更像第一层过滤，并非最终真理。当候选接近时，可以引入 body-on-tie：只读取少量候选的 body，确认谁真正具备执行能力。这个动作必须少量、低频、可记录，否则又会回到全文倒灌的问题。

从理论到可用实现：agentic-skill-router

以上是设计原则。依据这些原则寻找实现时，有一个项目比较贴合这套思路：agentic-skill-router。

它的定位不是再做一个推荐系统，而是将低频 Skill 从常驻列表中移出，同时保留可检索的 metadata。当 Agent 没有明显命中 enabled Skill 时，再通过 router Skill 进入 search / inspect / select 工作流。

项目地址：

GitHub：github.com/legendtkl/a…
Web 页面：legendtkl.github.io/agentic-ski…

有几个设计点值得单独关注。

第一，disable 的实现非常轻量。它通过重命名 SKILL.md 为 SKILL.md.agentic-skill-router-disabled 等方式让 Skill 退出宿主扫描，但文件本身仍然可以恢复。这符合“禁用不等于删除”的思路。

第二，检索阶段坚持 metadata-only。router 在 select 前不读取 disabled Skill body，只暴露可路由字段和候选证据。这个边界能避免路由过程本身成为上下文膨胀的源头。

第三，候选使用 stable corpus ref。Agent 看到的是 corpus-... 这类引用，而非本地绝对路径。最终必须通过 select 才能拿到 selected.skillMdPath。这大大减少了路径暴露、幻觉路径、绕过审计等问题。

第四，select 会记录 routed use。这个细节非常工程化：路由不是一次性行为，它会反过来影响后续管理。一个长期被找回的 disabled Skill，可能应该重新 enabled；一个从未被选中的 Skill，可能 metadata 写得不好，也可能确实该清理。

基本安装和初始化非常直接：

npm install -g agentic-skill-router
agentic-skill-router init

如果需要指定宿主和作用域，可以显式指定：

agentic-skill-router init codex project
agentic-skill-router init codex global
agentic-skill-router init claude-code project
agentic-skill-router init claude-code global

日常管理大致包含以下操作：

agentic-skill-router list
agentic-skill-router suggest --json
agentic-skill-router disable  --yes
agentic-skill-router enable 
agentic-skill-router status

如果在 Codex 或 Claude Code 中使用，也可以通过对应宿主的 Skill 触发方式调用。与其把它当作主角，不如说它是 Agentic Skill Routing 这套设计的一个可运行样本：低频能力冷存储、metadata corpus、Agent 主动检索、选择后再读取 body。

更长期的形态：本地 router 加服务化 registry

本地 Skill 管理能解决一部分问题，但不应承担全部治理职责。

Skill 一旦在团队内部扩散，新的问题就会出现：哪个版本最新？哪个版本已废弃？谁发布的？有没有签名？有没有组织推荐版本？当前宿主是否兼容？本地目录扫描很难回答这些问题。

更合理的分工可能是：

图：本地 Skill Router 与远端 Registry 的分工

本地继续负责低延迟、隐私、缓存和最终执行。服务端负责目录、版本、信任、策略和反馈闭环。

这个 registry 不需要把所有 Skill body 都服务化，也不应替 Agent 做最终选择。它更像一个控制平面：告诉本地 router 有哪些 Skill、哪个版本可信、哪些已 deprecated、哪些适合当前组织、包的 digest 是什么、发布者是谁。

一个完整流程可以是：开发者发布 Skill，registry 校验 schema、metadata、权限声明和签名；组织将其标记为 recommended、experimental、deprecated 或 blocked；本地 router 同步 metadata 和 lockfile；Agent 请求到来时先查本地 enabled Skill，未命中再查 cache / registry；选中后才按需拉取或 materialize 对应 Skill。

这比“每台机器各装各的 Skill，然后靠目录扫描自我管理”可靠得多。

收束

Skill 规模化之后，真正的难点不在于编写更多 Skill，而在于让 Agent 在正确的时间看见正确的 Skill。

将所有 Skill 常驻上下文，简单但难以扩展。将路由完全交给一次性 Top-K，省事但会削弱 Agent 的主动判断力。更稳妥的方向是 Agentic Skill Routing：高频 Skill 常驻，长尾 Skill 进入 metadata corpus；Agent 通过 search、inspect、select 多步找回能力，证据不足就继续查或停止，不强行命中。

这套方法的价值不在于某个 ranker 得分有多高，而在于边界清晰：metadata 先行、候选有界、选择可审计、body 按需读取、禁用可恢复。等到 Skill 向团队级、组织级扩展时，本地 router 还可以自然接入服务化 registry，将发现、版本和信任治理从个人机器中解放出来。

Agent 的上下文窗口不应沦为 Skill 目录的垃圾箱。它更像一个工作台，只放置当前要用的工具。其他工具可以存放在仓库里，但需要一套可靠的查找和取用机制。