Agent技能路由是Agent开发里绕不开的一个问题面试被问到“该用检索还是大模型”时如果直接回答“让模型自己选”大概率会被追问到乏力。这个问题的核心不是二选一而是如何设计一条“召回、过滤、精排、执行”的路由链路让系统在技能数量增加时依然保持低延迟、低成本、高准确率。下面按我自己的实测经验拆一遍什么时候该检索什么时候该让模型推理以及面试时怎么回答才不吃亏。1. 为什么“让模型自己选”不总是最优解1.1 “模型自选”的本质是隐式推理很多Agent框架的默认做法是把所有技能的描述、参数、示例全部塞进大模型的上下文让模型从一堆工具里挑选要调用哪个。这种“让模型自己选”的方式不是错误它的本质是让大模型在生成时做一次隐式推理既要理解用户意图又要对比全部技能描述最后输出一个工具调用结果。在技能数量少、任务单一的原型阶段这条路非常好用。我最早做带工具调用的Agent时只挂了五六个技能模型选得很准代码也简单。但随着技能增加问题开始出现。一个很直接的问题是上下文膨胀。每个技能如果写一行摘要十几个技能还好一旦技能变成上百个每个技能还要带上JSON Schema、参数说明、调用示例prompt会越来越长。模型处理上下文的时间变长显存和内存占用升高接口调用成本也跟着涨。更麻烦的是技能描述越长、越相似模型在长上下文里找到正确技能的概率反而可能下降。另一个要命的问题是决策黑盒。模型选错了你很难说清楚是技能描述不清楚、意图识别失败还是多个技能太像导致排序混乱。只能靠反复改prompt效率很低。1.2 什么时候该用检索什么时候该靠模型推理不能无条件检索也不能完全放弃模型推理。判断依据不是“哪个技术高级”而是三个现实条件技能数量、上下文预算、对错误成本的容忍度。如果技能数量小于10每个技能的描述也不长那直接让模型在完整工具列表里选择通常没问题。这个阶段不要强行加向量检索因为检索本身有延迟还要维护索引收益很小。如果技能数量超过20个或者技能描述长度超过一定比例就要考虑路由了。我一般会用“固定规则 检索召回到候选集 小范围模型选择”的结构而不是只靠检索出top1。因为检索适合缩小范围不适合完成带歧义和组合意图的最终判断。判断标准可以看一组实际现象模型经常在多个相似技能之间选错比如“视频搜索”和“视频推荐”容易混。Prompt已经很长实测单次调用变慢了成本也明显上涨。你希望路由结果有日志可查、可回放、可定位而不只是看模型输出字符串。只要出现其中一两条就说明“让模型自己选”的简单方案快到极限了需要给Agent加一层路由机制。2. 检索式路由先召回再绑定技能2.1 先把每个技能变成一条可检索的记录检索式路由的第一步是把技能列表做成索引。不是把整个函数代码拿去embedding而是抽取技能元信息组合成一段适合检索的文本。我会为每个技能维护一张表至少包含这些字段字段作用示例技能标识唯一调用名video_search技能名称给模型看的人类可读名视频搜索触发描述说明适合什么场景应该怎么写当用户想按关键词、标题、发布时间查找视频时调用参数摘要关键参数和格式不一定要完整Schemakeyword: string; upload_time: datetime调用示例让模型知道正确输入长什么样video_search(keyword会议记录)权限范围哪些租户或角色可用用于后续过滤admin, editorembedding时不能只对“触发描述”做向量化。最好把技能名、触发描述、参数摘要、调用示例拼成一段话整体编码。原因是触发描述经常写得不够细加上示例后能显著提升召回率。这一步最容易踩的坑是描述写得太笼统。比如“视频搜索”写成“搜索视频”召回时很容易和“视频推荐”“视频播放”撞在一起。更好的写法是写上边界条件“当用户只是希望查看视频列表但不确定具体标题时优先走视频搜索如果用户想根据观看历史推荐内容不要走这个技能”。描述里带上“不要做什么”对检索和后续模型精排都有帮助。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 把大模型放在“精排”阶段具体落地时我会把路由拆成三个环节离线阶段把技能注册成索引。在线请求进来后先做检索召回候选集。把候选技能列表和用户原始请求一起交给大模型让模型选择一个技能或输出一个技能调用计划。在精排阶段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 一个稳妥的回答框架我如果被问到这个问题会按下面这个顺序回答先反问技能数量大概是多少变更频率高不高对延迟和成本有什么要求这些变量直接决定方案。再给边界技能少、上下文短时直接让模型选技能多、上下文压力大时不能全量塞给模型。给分层方案离线把技能注册成索引在线用多路召回缩小候选集再用大模型做候选技能的精排和组合。讲执行细节候选集大小、阈值、温度、超时、失败降级、权限过滤。讲验证指标路由准确率、覆盖率、端到端成功率、p95延迟、单次成本、回退比例。这个框架的好处是哪怕你现场没有跑过真实数据也能展示出你考虑过完整链路而不是背概念。5.3 落地时的验证指标和排查顺序如果已经把路由系统搭出来千万不要只看几个好看的平均数。我建议重点盯这几个指标指标含义理想情况路由准确率选中的技能是否正确大于95%召回覆盖率正确技能是否在候选集里大于99%端到端成功率技能执行后用户是否满意看业务要求p95延迟路由决策耗时尽量低于500ms回退比例无匹配或执行失败降级低于5%成本每千次请求的模型调用成本随候选集和模型减小而降排查时从前往后看不要一开始就去调大模型参数。我一般按这个顺序先看有没有召回到正确技能。如果候选集里没有正确技能问题在召回或技能描述不在精排。再看候选集里有多少个相关技能。如果太多相似技能会把模型绕晕考虑调整阈值或合并技能。再看模型选择结果。如果正确技能已经召回但还是选错可能是prompt不够清晰也可能是温度太高。最后看执行阶段。有些“路由错误”其实是执行结果不对和路由没关系要分开观察。还有一个经验是日志里一定要记录每一轮的候选技能和分数。否则出了问题只能靠猜。把“召回结果 精排结果 执行结果”三条日志对齐排错速度会快很多。回到最初的问题Agent技能路由到底该用检索还是大模型我的答案是不要二选一。检索负责“看到全貌”模型负责“理解意图”规则负责“兜底和控成本”。把三者按场景组合起来才是真正适合生产的Agent技能路由方案。