前两天，群里一位兄弟分享了他面某大厂 Agent 应用岗的一道真实场景题，非常考验候选人对「工具路由」的底层把控力：

「你们的内部 Agent 平台接入了上百个 Skill。某天运营急冲冲找来：用户明明说『帮我生成季度汇报的 PPT』，模型却调了『代码生成』工具，命中率从 90% 掉到了 50%。作为架构师，你接手后怎么定位、怎么解？」

看到这道题，我先帮群里兄弟把它定性：这不是模型能力退化，是工具路由在规模面前失效了。下面把拆解逻辑完整还原一遍——既是这类面试题的标准解法，也是一套可落地的工程思路。

一、先定性：路由退化成了检索问题

很多候选人一上来就答「优化提示词、把功能描述写清楚」，方向偏了。Skill 只有十几个时，模型一次性把候选塞进上下文，语义匹配很简单；一旦上百个，候选集合爆炸，模型要在上百个高度相似的选项里做语义匹配，难度是指数级上涨的。这和 RAG 里「从几篇文档里找答案」到「从百万文档里检索」是同一个问题——候选越多，越不能靠「硬塞给模型」解决。

一句话定性：Skill 变多之后，工具路由本身就转化成了检索问题。解题思路和 RAG 完全同构——先召回，再排序，而不是把所有工具一次性摊给模型盲选。

二、为什么一多就乱：规模与表现

当时面试官追问了一句「你说不是模型的问题，那根因到底是什么」。我给了这张表：

所以「抽风」的本质，是路由逻辑没跟上规模。下面四步，从治标到治本，按规模递进——这也是我当时给面试官的作答主线。

三、四步解法，按规模递进

第一步：优化 Skill 描述，写明触发场景

先说成本最低、见效最快的一招。很多团队死磕 Skill 内部的执行提示词，却忽略了 Name 和 Description。但 Skill 的名称、描述，本质就是检索引擎里的「标题 + 摘要」。写得模糊笼统，向量检索也区分不开。对比一下反例和正例：

[反例] 只写功能，太模糊

name: ppt_tool

description: 一个生成 PPT 的工具

[正例] 写清触发场景

name: ppt_generator

description: 当用户需要制作汇报、融资路演、

季度总结、产品演示文稿时调用；输入自然语言

大纲，输出可编辑的 .pptx 文件。不支持图表

数据计算与后端接口开发。

Anthropic 在 Skill 设计规范里明确强调：description 必须写明触发条件。场景越具体，模型做语义匹配时命中越准。这一步治标，但几乎是零成本。

第二步：搭建 Skill Tree 分层路由

光改描述不够。上百个 Skill 平铺展示，让模型一次性在全部工具里筛选，搜索空间极大。更合理的方案是树形分层：第一层划大类（研发、运营、市场、财务），第二层再细分（代码生成、代码审核、自动化测试）。模型先匹配大类，再在大类内部缩小范围，筛选压力直接减半。

def route_skill(user_msg):

# 第一层：按大类粗筛

category = classify_category(user_msg) # 研发/运营/市场/财务

# 第二层：在大类内细匹配

skill = match_in_category(user_msg, category.skills)

return skill

这套分层路由，头部大厂的 Agent 系统基本都在用——它从结构上把「百选一」拆成「四选一 + 十选一」，复杂度断崖式下降。讲到这，面试官点了下头。

第三步：补充负样本，标注禁用场景

被追问「那相邻工具描述相似怎么办」时，我抛出第三招：光写「什么时候该用」不够，必须写明「什么时候绝对不能用」。现在很多高质量 Skill 都专门加了 When Not To Use 模块，把容易混淆的相邻工具显式隔开，能大幅减少误触发。

第四步：召回 + 重排检索机制（和 RAG 一致）

最后一招压轴：当 Skill 到几百上千量级，路由系统本质就是一台检索引擎。思路和 RAG 完全一致——用户提问后，先通过向量语义召回 Top 10 候选 Skill，再交给大模型精排，选出最优工具。

# 海量 Skill 场景：路由即检索

candidates = vector_recall(user_msg, top_k=10) # 向量语义召回

best = llm_rerank(user_msg, candidates) # 大模型精排选优

return best

现在不少专项路由模型，底层都是靠这套「召回 + 重排」架构解决海量工具匹配难题。它把「从一百个里盲选」变成「先缩到十个、再精排」，命中率立刻回来。

四、回面试官：完整作答模板

讲完四步，我给面试官收了个尾：这道题的答题层次就是「先定性、再分层、补全边界、最后上召回重排」。再往上加分，可以提两点——一是 Anthropic 的渐进加载（Progressive Disclosure），不一次性把全部 Skill 塞进上下文，先读名称+简介判断、需要才加载完整逻辑，控制上下文拥挤；二是上线后必须监控命中率指标、做 A/B 评估，路由不是配完就完事，得有数据闭环。

工具越多，越要把路由当检索引擎来设计——你不是在写提示词，你是在搭一个检索系统。先定性、再分层、补全边界、最后上召回重排，命中率自然会回来。

你做 Agent 时，是被工具路由坑过，还是卡在别的地方？评论区聊聊，下期接着拆 Agent 落地里的坑。