如何准确的找到工具：万级 Skill 路由生产级方案

当 Skill 池膨胀到万级，模型上下文窗口装不下所有工具描述，"让 Agent 选对工具"就成了一个系统工程问题。本文梳理一套可落地的生产级方案——从 4 层漏斗架构、SkillRouter 论文实测数据、到置信度分流机制，完整走一遍。

一、核心矛盾：1 万个 Skill，模型看不过来

一个 MCP 工具的 schema 描述（名称 + 功能说明 + 参数定义）约 150 token。当 Skill 池达到 10,000 个，仅工具描述就需要约 150 万 token——远超当前主流模型的上下文窗口上限（128K–256K tokens）。

这不是"工具太多"的问题，而是"模型能看到的工具必须是经过筛选的子集"的问题。我们需要一个分层漏斗，把 10,000 个候选逐步收窄到模型能处理的 5 个以内。

二、系统全景：4 层漏斗 + 执行 + 反馈

用户输入
    ↓
┌─────────────────────────────────────────────┐
│  Layer 1: 意图分类（规则引擎 + LLM 兜底）    │
│  10,000 → ~2,000                             │
│  延迟 <100ms                                 │
└──────────────┬──────────────────────────────┘
               ↓
┌─────────────────────────────────────────────┐
│  Layer 2: 向量检索（SkillRouter Embedding）  │
│  2,000 → 20                                  │
│  延迟 <50ms                                  │
└──────────────┬──────────────────────────────┘
               ↓
┌─────────────────────────────────────────────┐
│  Layer 3: 精排（SkillRouter Reranker）       │
│  20 → 5                                      │
│  延迟 <200ms                                 │
└──────────────┬──────────────────────────────┘
               ↓
┌─────────────────────────────────────────────┐
│  Layer 4: LLM 最终选择                       │
│  5 → 1                                       │
│  延迟 <500ms                                 │
└──────────────┬──────────────────────────────┘
               ↓
┌─────────────────────────────────────────────┐
│  Layer 5: Skill 加载 + 执行                  │
│  OpenViking 三层加载 → CubeSandbox/本地执行   │
│  延迟 <1s                                    │
└──────────────┬──────────────────────────────┘
               ↓
┌─────────────────────────────────────────────┐
│  Layer 6: 反馈闭环                           │
│  用户确认/纠正 → 训练集 → 定期重训模型       │
└─────────────────────────────────────────────┘

设计思路借鉴了业界头部玩家的共识——阿里千问的 Nacos MCP Router 语义检索和字节豆包的 Coze 三层渐进加载（详见附录）。核心原则一致：模型永远不直接面对全量工具，路由层做筛选，执行层做隔离。

三、各层详解：从论文数据到工程选型

Layer 1：意图分类——先缩小战场

职责：把 10,000 个 Skill 按领域缩小到约 2,000 个候选。

分类体系：

实现：规则引擎优先（关键词 + 正则），置信度低于阈值时降级为 LLM 分类。延迟控制在 100ms 以内。

容错设计：分类错误不影响最终结果——Layer 2 的向量检索会跨领域召回，分类只是缩小范围的加速手段。

Layer 2：向量检索——用 SkillRouter Embedding 粗筛

职责：从约 2,000 个候选中检索 Top 20。

组件：SkillRouter Embedding 0.6B + FAISS 向量库。

关键设计决策：

1. 用 SKILL.md 全文做 embedding，不是只有 description。

这是最重要的工程决策。SkillRouter 论文（arXiv: 2608.11312）实测证明：去掉 SKILL.md 正文后，检索准确率暴跌 37–44 个百分点。正文中的工作步骤、约束条件、Few-shot 示例是决定性信号——Reranker 91.7% 的注意力集中在正文，而非 description。

2. 分类内优先检索，候选不足时全局补充。

先在 Layer 1 划定的领域内检索，如果 Top 20 不满再扩展到全量池，避免漏召回。

3. 索引完全放内存。

10K Skills × 768 维 × 4 字节 ≈ 35MB，FAISS 索引常驻内存，检索延迟 <50ms。

索引更新策略：Skill 注册/更新时增量更新索引，每周全量重建一次保证一致性。

Layer 3：Reranker 精排——Cross-encoder 二次排序

职责：从 Top 20 精排到 Top 5。

组件：SkillRouter Reranker 0.6B（Cross-encoder 架构）。

工作方式：Reranker 的输入是 query + 每个候选的完整 SKILL.md 正文。它不是简单的向量相似度，而是逐对交叉编码，关注正文中的实现细节、脚本说明、边缘情况处理。

实测效果：

Reranker 的价值在于它能"读懂"正文。当两个 Skill 的 description 高度相似时（比如"生成销售报表"vs"生成销售周报"），只有读了正文中的具体步骤和约束才能区分。

Layer 4：LLM 最终选择——从 Top 5 中决策

职责：从 Top 5 中选 1 个，返回选择理由和置信度。

输入：Top 5 的 name + description + L2/L3 分数。

输出：选中的 Skill ID + 置信度（0–1）+ 选择理由。

置信度是后续分流机制的依据（见第五章）。

Layer 5：Skill 加载与执行——三层渐进 + 沙箱隔离

组件：OpenViking（存储+加载） + CubeSandbox / 本地进程（执行）。

三层渐进式加载（借鉴 Coze 与 Anthropic Agent Skills 标准）：

OpenViking 实测效果：Token 节省 34–91%，延迟降低 58–66%。

执行环境按信任等级隔离：

Layer 6：反馈闭环——让路由越用越准

反馈信号：

更新节奏：每周重训 Reranker（近 30 天数据），每月重训 Embedding（全量数据），每次更新后用测试集验证——Hit@1 下降超过 2% 自动回滚。

四、Skill 数据模型

每个 Skill 注册时生成的元数据：

每次路由的完整日志（query、各层候选、最终选择、用户反馈、执行结果）是后续模型重训的数据基础。

五、置信度分流：不是所有请求都需要同样的精度

三级分流策略

LLM 选择返回置信度
        ↓
┌───────────────────────────────────┐
│  置信度 ≥ 0.8                     │
│  → 直接执行（无需确认）           │
│  预期占比：~60%                   │
└───────────────────────────────────┘

┌───────────────────────────────────┐
│  置信度 0.6 - 0.8                 │
│  → 返回 Top 3 让 LLM 自我确认     │
│  预期占比：~25%                   │
└───────────────────────────────────┘

┌───────────────────────────────────┐
│  置信度 < 0.6                     │
│  → 让用户从 Top 3 中选择          │
│  预期占比：~15%                   │
└───────────────────────────────────┘

用户感知准确率推算

关键洞察：用户感知准确率 ≠ 系统准确率。低置信度时让用户选择，看似"没选对"，但用户体验反而是最好的——因为给了他明确的候选，一秒就能纠正。

六、监控与告警

核心指标

• 准确率突降：最近 1 小时准确率比 30 天均值低 15% 以上 → 告警
• 某 Skill 被频繁纠正：7 天内纠正 >10 次 → 检查 description 质量
• 延迟突增：P99 >5s → 检查 Reranker 和 LLM API 状态

七、实测数据：SkillRouter 论文与推算

SkillRouter 论文基准（80K Skill 池）

原生 SkillRouter 组合最优——比 16B 大模型基线高 6 个百分点，参数量只有 1/13。

池规模对准确率的影响

池缩小 → 候选间区分度增大 → 检索和精排的准确率同步上升。

Reranker 的关键发现

去掉 SKILL.md 正文（只用 description），准确率暴跌 37–44 个百分点。 Reranker 91.7% 的注意力集中在正文，而非 description。这意味着：Skill 的 description 是给检索用的"名片"，正文才是给 Reranker 用的"灵魂"。写好正文比写好 description 更重要。

OpenViking 评测数据

八、延迟预算

路由层控制在 1 秒以内——用户感知是"几乎瞬间选对了工具"。

全部开源，无闭源依赖。

附录：参考项目与业界实践

业界共识：阿里千问（Nacos MCP Router + Higress 语义检索）和字节豆包（Coze 三层渐进加载 + 技能商店）均已实现万级工具管理。核心思路一致——模型永远不看全量工具，路由层筛选，执行层隔离。详见 Nacos MCP Router 文档 和 Coze 技能概述。