Agent技能路由：检索与大模型协同，从多路召回到精排

Agent技能路由是Agent开发里绕不开的一个问题，面试被问到“该用检索还是大模型”时，如果直接回答“让模型自己选”，大概率会被追问到乏力。这个问题的核心不是二选一，而是如何设计一条“召回、过滤、精排、执行”的路由链路，让系统在技能数量增加时依然保持低延迟、低成本、高准确率。下面按我自己的实测经验拆一遍：什么时候该检索，什么时候该让模型推理，以及面试时怎么回答才不吃亏。

1. 为什么“让模型自己选”不总是最优解

1.1 “模型自选”的本质是隐式推理

很多Agent框架的默认做法，是把所有技能的描述、参数、示例全部塞进大模型的上下文，让模型从一堆工具里挑选要调用哪个。这种“让模型自己选”的方式不是错误，它的本质是让大模型在生成时做一次隐式推理：既要理解用户意图，又要对比全部技能描述，最后输出一个工具调用结果。

在技能数量少、任务单一的原型阶段，这条路非常好用。我最早做带工具调用的Agent时，只挂了五六个技能，模型选得很准，代码也简单。但随着技能增加，问题开始出现。

一个很直接的问题是上下文膨胀。每个技能如果写一行摘要，十几个技能还好；一旦技能变成上百个，每个技能还要带上JSON Schema、参数说明、调用示例，prompt会越来越长。模型处理上下文的时间变长，显存和内存占用升高，接口调用成本也跟着涨。更麻烦的是，技能描述越长、越相似，模型在长上下文里找到正确技能的概率反而可能下降。

另一个要命的问题是决策黑盒。模型选错了，你很难说清楚是技能描述不清楚、意图识别失败，还是多个技能太像导致排序混乱。只能靠反复改prompt，效率很低。

1.2 什么时候该用检索，什么时候该靠模型推理

不能无条件检索，也不能完全放弃模型推理。判断依据不是“哪个技术高级”，而是三个现实条件：技能数量、上下文预算、对错误成本的容忍度。

如果技能数量小于10，每个技能的描述也不长，那直接让模型在完整工具列表里选择，通常没问题。这个阶段不要强行加向量检索，因为检索本身有延迟，还要维护索引，收益很小。

如果技能数量超过20个，或者技能描述长度超过一定比例，就要考虑路由了。我一般会用“固定规则 + 检索召回到候选集 + 小范围模型选择”的结构，而不是只靠检索出top1。因为检索适合缩小范围，不适合完成带歧义和组合意图的最终判断。

判断标准可以看一组实际现象：

• 模型经常在多个相似技能之间选错，比如“视频搜索”和“视频推荐”容易混。
• Prompt已经很长，实测单次调用变慢了，成本也明显上涨。
• 你希望路由结果有日志可查、可回放、可定位，而不只是看模型输出字符串。

只要出现其中一两条，就说明“让模型自己选”的简单方案快到极限了，需要给Agent加一层路由机制。

2. 检索式路由：先召回，再绑定技能

2.1 先把每个技能变成一条可检索的记录

检索式路由的第一步，是把技能列表做成索引。不是把整个函数代码拿去embedding，而是抽取技能元信息，组合成一段适合检索的文本。

我会为每个技能维护一张表，至少包含这些字段：

embedding时，不能只对“触发描述”做向量化。最好把技能名、触发描述、参数摘要、调用示例拼成一段话，整体编码。原因是触发描述经常写得不够细，加上示例后能显著提升召回率。

这一步最容易踩的坑是描述写得太笼统。比如“视频搜索”写成“搜索视频”，召回时很容易和“视频推荐”“视频播放”撞在一起。更好的写法是写上边界条件：“当用户只是希望查看视频列表，但不确定具体标题时，优先走视频搜索；如果用户想根据观看历史推荐内容，不要走这个技能”。描述里带上“不要做什么”，对检索和后续模型精排都有帮助。

2.2 向量检索加关键词召回，别只用一路

很多教程只讲向量检索，但实际线上环境里，向量检索不是银弹。技能描述是短文本，用户的意图表达可能和技能描述用词差异很大，单纯向量语义匹配在部分场景下会漏召回。

我一般会做两路召回：

• 向量召回：对用户请求做embedding，在技能向量库里找语义相近的topN。
• 关键词召回：用BM25或简单的倒排索引，对请求里的业务词、技能名、参数名做匹配，召回到可能相关的技能。

两路结果合并去重，交给下一层。这样既能处理“用户没有说技能名”的语义化表达，也能处理“用户明确提到某个功能词”的精确匹配。这个思路在实际项目里稳很多，也正好能把“向量混合检索加BM25多路召回”这种经验落到Agent技能路由上。

关键词召回不一定非要上Elasticsearch。技能数量几百个以内，用内存里的Trie树或者正则规则都能实现。关键是“多路”而不是“一套方案走天下”。我用过的比较轻量的做法是，把技能名称和典型别名维护成一份映射，再配合BM25实现关键词匹配，效果已经够用。

2.3 阈值和候选集大小要按业务调

检索式路由不是简单取top1。取top1在Demo里看着没问题，一旦用户意图有点歧义，top1往往不是正确技能。正确的做法是召回一组候选集，比如3到5个，再让下游做选择。

这里有两个参数很关键：

• 相关性阈值：低于阈值的技能不进入候选集，避免无关技能干扰判断。
• 候选集上限：进入下一层的技能数量，通常限制在3到8个。

阈值不能照抄别人的数值，因为它取决于embedding模型、技能描述质量、用户请求风格。我在不同项目里用同一个向量模型，阈值从0.3到0.7都调过。更稳妥的做法是，先用小样本把每个技能的真实请求拉出来，算一下正确技能的相关性分数分布，再决定阈值，而不是拍脑袋定0.6。

还有一点要注意：如果候选集为空，不要硬让模型从空列表里猜。这时候应该先走兜底逻辑，比如把请求返回给用户澄清，或者调用一个通用的对话技能，而不是直接报错。

3. 大模型路由：推理决策适合放在哪个环节

3.1 模型自选的价值不在“选”，而在理解上下文

如果完全靠检索，Agent会很死板。比如用户说“把昨天那条视频找出来，顺便看看标题取得怎么样”，这个请求其实包含两个技能：视频搜索和标题分析。单靠检索召回，很可能招到两个技能，但不知道如何组合。这时候需要模型来推理，把用户意图拆解成连续技能调用。

所以我的结论是：不要试图用检索完全替代大模型路由。检索负责缩小候选范围，模型负责在候选集里做精排和决策。模型自选不是被淘汰了，而是从“面对全部技能”变成“面对一小撮技能”。

这种划分最直接的好处是，模型看到的工具列表更短，注意力更集中。实测中，候选集从3到5个技能时，模型的选择准确率远高于面对50个技能。而且即使模型选错，日志里可以看到它是在哪一组候选里错的，问题定位容易很多。

3.2 把大模型放在“精排”阶段

具体落地时，我会把路由拆成三个环节：

1. 离线阶段把技能注册成索引。
2. 在线请求进来后，先做检索召回候选集。
3. 把候选技能列表和用户原始请求一起交给大模型，让模型选择一个技能，或输出一个技能调用计划。

在精排阶段，prompt可以这样组织：

用户请求：{query} 以下是候选技能列表，请选择最合适的一个。如果多个技能组合才能完成任务，请按顺序输出。 技能列表： {json格式的候选技能} 输出格式： {"skill": "技能标识", "reason": "选择原因", "next_step": "待执行参数"}

这里会有几个工程细节。

第一，temperature要调低。路由任务大多数时候是确定性任务，temperature设成0或者0.1比较合适。温度太高，模型会在两个相似技能之间反复横跳。

第二，输出必须结构化。不要直接让模型输出一句话，而是要求返回JSON。也可以用函数调用机制，如果平台不支持，就要求模型只输出可解析的JSON片段。这样下游好处理。

第三，要考虑超时和重试。模型精排是一个外部调用，延迟可能从几百毫秒到几秒不定。如果路由这一步超时，要有备用方案。我在生产里会设置1.5到3秒的超时限制，超时后降级为直接选候选集第一个。

3.3 模型路由的参数要关注成本和稳定性

很多人只关注选得准不准，忽略了这个环节的模型大小选择。精排阶段不需要最强的模型，只需要能从3到5个候选里挑一个合适的。基础小模型往往已经够用，成本却低很多。

比如本地部署大模型时，可以用7B到14B的模型做精排，不需要上超大模型。我在一个技能路由项目里用过一个小参数模型做精排，准确率和大模型差不多，但单次推理成本差了好几倍。最重要的是，候选集如果只有5个，技能描述很短，小模型完全能胜任。

不过小模型对prompt格式更敏感，需要把候选技能格式尽量固定一致。输出解析失败时，最好做一次重试或重选择，保证路由成功率。不要忽略异常分支，失败重试、默认技能、人工兜底都要设计好。

4. 不同场景下的路由策略落地

4.1 技能数量少、核心技能固定：规则优先

面对10个以内技能，而且业务基本固定时，规则路由往往比检索和模型都稳。

比如客服机器人，只支持查订单、退换货、开发票、查物流等几个技能。可以根据用户请求里的关键词或意图识别接口，直接用规则映射到对应技能。规则的优势是零延迟、零成本、完全可解释。缺点是没有泛化能力，遇到新表达就失效。

我建议在这种场景下，先做一层“规则 + 关键词”路由，把能精确匹配的请求都消费掉；只有规则匹配不上，才把请求交给大模型或向量检索兜底。这样核心请求永远走最稳的路径，新表达也能被模型和检索接住。

4.2 技能数量多、功能重叠：检索辅助，模型兜底

当技能数量到几十甚至上百，技能之间还有重叠时，规则就不够用了。这个阶段需要用“检索召回 + 模型精排”的完整链路。

举一个实际场景：文档管理Agent里，有“文档搜索”“文档分类”“文档摘要”“文档翻译”“文档标签生成”等一批技能。用户说“帮我看看这份合同的核心条款”，可能同时触发“文档摘要”和“文档搜索”。这时检索会把两个都召回，模型看到候选后，根据“核心条款”这个词判断，应该优先走文档摘要，而不是先搜索再摘要。这就是模型推理的价值。

在这个阶段，最需要盯住的不是某个技能选得对不对，而是整体任务能不能一次跑通。因为Agent技能路由往往只是第一步，后面还跟着参数抽取、技能执行、结果返回。如果路由这层就选错了，后面全错了。

4.3 动态技能系统：要考虑上线、下线和权限

很多Agent平台正在做“技能插件化”，第三方可以动态注册新技能。这种动态系统里，路由不是一次次固定列表，而是每次请求来都要查询当前可用技能。

这时候需要在路由前加一层“可用技能过滤”。同一个租户下，可能某些技能不开放；同一个技能，不同用户有不同的调用权限。如果不过滤，检索会把不可用技能也召回来，模型可能选到一个用户没有权限使用的技能，最后执行阶段才报错。

动态技能还带来索引更新问题。新增技能、修改描述、调整参数，都要及时同步到向量库和关键词索引。我习惯在技能发布流程里加一个“重建索引”的钩子，不能手工维护。否则技能上线了，路由却找不到。

4.4 一套可复用的路由流水线

把上面的经验汇总成一条流水线，大概是这样：

用户请求 -> 基础过滤：黑名单、权限、可用状态 -> 意图前置：如果有明确规则，直接走规则 -> 多路召回：向量召回 + 关键词召回 + 规则命中 -> 合并去重 -> 相关性阈值过滤 -> LLM精排：从候选技能中选一个或生成调用顺序 -> 执行技能 -> 校验结果：成功则返回，失败则回退到候选技能或用户澄清

这条流水线不是唯一的正确答案，但它在我的项目里比较通用。面试时如果能把这样一条链路讲清楚，比直接说“用检索”或“用大模型”都有说服力。

实现时注意，不要把每条链路都做得太重。小场景可以砍掉LLM精排，直接选候选集第一个；大场景再逐步加模型。核心是先把路由的边界条件定义清楚。

5. 面试答法和工程落地要点

5.1 面试官到底在考察什么

面试题问“Agent技能路由该用检索还是大模型”，通常不是在考你有没有用过某个框架，而是在考察你的工程判断力。面试官希望看到你能意识到这几个层次：

• 技能路由不是一个单独模型调用，而是一条链路。
• 上下文窗口、延迟、成本都会影响方案设计。
• 检索和模型推理是可以叠加的，不是互斥的。
• 你有明确的判断标准和验证方式。

如果只是回答“让模型自己选”，说明你只看到了Agent最表层的运行方式。真正上线时你会遇到成本、稳定性、可排查性等一堆问题。

5.2 一个稳妥的回答框架

我如果被问到这个问题，会按下面这个顺序回答：

1. 先反问：技能数量大概是多少？变更频率高不高？对延迟和成本有什么要求？这些变量直接决定方案。
2. 再给边界：技能少、上下文短时，直接让模型选；技能多、上下文压力大时，不能全量塞给模型。
3. 给分层方案：离线把技能注册成索引，在线用多路召回缩小候选集，再用大模型做候选技能的精排和组合。
4. 讲执行细节：候选集大小、阈值、温度、超时、失败降级、权限过滤。
5. 讲验证指标：路由准确率、覆盖率、端到端成功率、p95延迟、单次成本、回退比例。

这个框架的好处是，哪怕你现场没有跑过真实数据，也能展示出你考虑过完整链路，而不是背概念。

5.3 落地时的验证指标和排查顺序

如果已经把路由系统搭出来，千万不要只看几个好看的平均数。我建议重点盯这几个指标：

排查时从前往后看，不要一开始就去调大模型参数。我一般按这个顺序：

1. 先看有没有召回到正确技能。如果候选集里没有正确技能，问题在召回或技能描述，不在精排。
2. 再看候选集里有多少个相关技能。如果太多相似技能，会把模型绕晕，考虑调整阈值或合并技能。
3. 再看模型选择结果。如果正确技能已经召回但还是选错，可能是prompt不够清晰，也可能是温度太高。
4. 最后看执行阶段。有些“路由错误”其实是执行结果不对，和路由没关系，要分开观察。

还有一个经验是，日志里一定要记录每一轮的候选技能和分数。否则出了问题只能靠猜。把“召回结果 + 精排结果 + 执行结果”三条日志对齐，排错速度会快很多。

回到最初的问题：Agent技能路由到底该用检索还是大模型？我的答案是，不要二选一。检索负责“看到全貌”，模型负责“理解意图”，规则负责“兜底和控成本”。把三者按场景组合起来，才是真正适合生产的Agent技能路由方案。