装 100+ 技能，Agent 越用越聪明？错！（附SKILL技能调度官安装地址）

摘要：技能装得越多，Agent 反而越容易选错、漏召、重复踩坑——「该用哪个」本身就是一项被忽略的开销。本文介绍 tool-router：一个零依赖、基于 BM25 的确定性技能路由工具，用 3 毫秒替代 LLM 逐条权衡，帮你在一瞬间精准唤起该用的技能。文章从用户痛点、适用场景、三步跑通的使用说明、快准省可审计的优点，到局限性与未来展望，完整拆解了「选工具」这件事如何从人工判断变成 Agent 的神经反射。

装 100+ 技能，Agent 越用越错

你以为技能装得越多，Agent 越聪明？真实情况恰恰相反：技能一旦过 100 个，「该用哪个」这件事本身就开始拖后腿——选错、漏召、重复踩坑，效率和 token 一起悄悄流失。本文讲一个被 99% Agent 用户忽略的事实：「选工具」本身就是一项开销。

一图看懂 tool-router：痛点 → 场景 → 说明 → 优点 → 局限与展望。

技能库不是越大越好，而是「该用谁时，能在一瞬间精准唤起谁」才越好。tool-router 干的就是这件事。

一、用户痛点：你不是缺技能，是缺「选择器」

我们都经历过这个循环：兴致勃勃装了一堆 skill，前两周真香，然后——

• 清单焦虑。技能越多，开场越懵。任务来了，脑子里闪过三五个可能相关的名字，却拿不准哪个真正对，最后凭直觉挑一个，重复踩坑。
• 两难：塞还是不塞。把候选全塞进上下文，token 像漏水一样掉；不塞，该查资料时在瞎猜、该调试时在乱改、某个明明存在的技能根本没被想起——这是隐形的「能力盲区」。
• 误路由无人发现。选错了也没人报警，下次还错。没有反馈闭环，错误被安静地累积成习惯。
• 多技能任务识别不了。一个任务其实要 3 个技能协作，Agent 却只唤了一个，结果半成品交付。
• 相似技能打架。artifacts-builder 和 web-artifacts-builder 你都装了，每次随机撞一个，输出质量看运气。

核心矛盾：你有「工具箱」，却没有「神经系统」。工具箱管「我有什么」，神经系统管「这一秒该动哪块肌肉」。少的就是后者。

二、使用场景：哪些时刻该先「路由」一下

它不是什么都能管的开关，但在这几类时刻几乎必用：

• 任何非平凡任务开始前——判据是：涉及专业领域、需要 ≥2 步、或你自己都不确定从哪下手。
• 跨领域任务——「写一章女频小说并去 AI 味」同时撞上写作、去味、质检多个技能，先路由分清主次。
• 上一轮明显选错工具了——该查资料在瞎猜、该调试在乱改，立刻重路由。
• 多步骤任务——把子步骤写进一个文件，–batch 一次性路由，拿到完整候选人名单。
• 每周健康度盘点——用 report.py 看谁被路由最多、谁从没被路由过（死技能候选）。
• 调试误路由——加 –explain，看清它到底命中了哪几个词，为什么判错。

一秒自查：该 route 还是该 orchestrate？

三、使用说明：三步跑通，零依赖

解压即装，仅依赖 Python 标准库，无需 pip 任何第三方包，跨机器直接拷走就能用。

# 1. 装了解压到 skills 目录后，先建索引（约 5 秒，784 个技能）
python scripts/build_index.py
2. 路由一句话任务 —— 只返回 0-3 个候选 + 一行描述
python scripts/route.py "帮我看看 C 盘为什么满了，哪些能删"
3. 看它为什么这么判（误路由调试神器）
python scripts/route.py "算一下这个八字，排个盘" –explain –top 5
批量：把多步任务写进文件，一次性路由
python scripts/route.py –batch tasks.txt
用完回填：记录你最终用了谁，写进日志供以后调参
python scripts/route.py "任务" –chosen cdisk-health-scan

常用选项：–top N 返回几条（默认 3）｜–threshold X 临时改阈值｜–deny A B 本轮禁用某技能｜–json 结构化输出｜–selftest 跑 12 条回归用例。

一次典型输出长这样——注意它主动标注了「分数接近，需人工判断」：

query: 帮我看看 C 盘为什么满了，哪些能删
[1] 23.91 cdisk-health-scan
按需 C 盘诊断助手
[2] 8.10 cloud-server-health-scan <- 分数接近，需人工判断
Linux 云服务器按需诊断
(候选 7 个 -> 输出 2 个，约 40 tokens)

四、优点在哪：快、准、省、可审计

• 快到无感。784 个技能上单次路由 3.3 ms，用倒排表累加，只触碰含查询词的文档，上下文零负担。
• 双字段 + 双阈值，专治「看起来相关其实无关」。索引拆成 core（名字+描述+触发词）和 body（正文），body 乘 0.25 衰减；再叠加「硬阈值 2.0 + 相对阈值 top1×0.30」。查询「C 盘满了」从输出 6 个（含 5 个噪声）收敛到 1 个。
• 填过 6 个真实坑。中文口语填充词虚高 IDF（一下 把真信号压死）、BOM/CRLF 坑掉 frontmatter 解析、通用疑问词白送 4.0 分霸榜……每个都有现象、根因、对策，写在 SKILL.md 里，不是纸面方案。
• 渐进式披露。阶段 1 只给一行描述，确定后才读完整 SKILL.md——永远不一次性把多个技能读进上下文，这正是它要消灭的行为。
• 反馈闭环可审计。每次路由写日志，report.py 周报能发现「从没被路由过的死技能」，路由质量持续可优化。
• 专业护城河。附 references/tuning-knowledge.md——把张俊林《这就是搜索引擎》与 Turnbull & Berryman《Relevant Search》两本书的方法论，逐条映射到实现决策与参数共识。这不是调参玄学，是信息检索工程。
• MIT 开源，可改可分发。免费、可二次创作，转载注明出处即可。

为什么不用 LLM 自己选？因为「让模型逐条权衡 785 个技能」本身就是一次昂贵的推理。tool-router 用 3 ms 的确定性打分替代它，把模型的判断力留给真正需要推理的部分。

五、局限性：先说清楚，再谈好不好用

• 本机的 token 收益是「省判断开销」，不是「省系统清单」。WorkBuddy 会把技能列表注入系统提示，tool-router 改不了这点。所以「省 94% token」这种话不适用于本机——它的真实价值是提高选对率 + 发现多技能任务 + 用 3 ms 替代 LLM 逐条权衡。诚实比漂亮数字重要。
• BM25 不懂语义。「清理磁盘」能匹配「C 盘满了」是因为共享字面词；纯近义改写会漏。要补语义需上 embedding，属 Roadmap，不是当前能力。
• 装了新技能要重建索引。否则新技能永远路由不到——一行命令的事，但容易忘。
• 消歧表是人工资产。相似度是机器算的（可信），但「该选哪个」的判据是归纳建议，遇到反例直接改表，别反过来怀疑数据。

六、未来展望：让「选工具」成为 Agent 的反射

• Phase 4 混合检索。在 BM25 字面匹配之上叠加 embedding 语义召回，专治近义改写漏召——但前提是先积累真实的误路由案例，不为优化而优化。
• deny 清单自动收敛。相似技能对（如 tencent-docs ↔ tencent-saas-docs）从「待你拍板」逐步变成自动消歧规则。
• 路由前置成为标准纪律。就像 WorkBuddy 已把「判断用哪个 skill 前先跑 route」写进 SOUL.md——未来每个多技能 Agent 都该在动手前先路由一次。
• 从「器官调度官」到「神经反射」。工具箱回答「我有什么」，神经系统回答「这一秒该动哪块肌肉」；tool-router 想做的，就是 Agent 的那根神经。

装 785 个技能不稀奇，稀奇的是每次都能用对那一个。
把「选工具」交给 3 毫秒，把判断力留给真正难的事。

如果这篇写中了你的处境，也欢迎在 SkillHub 搜 qizai-tool-router 免费试用——装完跑一次 build_index.py，你也能拥有自己的「技能神经系统」。觉得有用就收藏起来，下次装新技能前翻出来对照。

— 七仔的AI工具箱 出品 · SkillHub 搜索 qizai-tool-router · 免费 MIT 开源
转载请注明出处。本文数据均来自作者环境实测（785 个技能），你装完用自己的技能库跑 build_index.py 即可重建专属基准。