前两天群里一位兄弟分享了他面某大厂 Agent 应用岗的一道真实场景题非常考验候选人对「工具路由」的底层把控力「你们的内部 Agent 平台接入了上百个 Skill。某天运营急冲冲找来用户明明说『帮我生成季度汇报的 PPT』模型却调了『代码生成』工具命中率从 90% 掉到了 50%。作为架构师你接手后怎么定位、怎么解」看到这道题我先帮群里兄弟把它定性这不是模型能力退化是工具路由在规模面前失效了。下面把拆解逻辑完整还原一遍——既是这类面试题的标准解法也是一套可落地的工程思路。一、先定性路由退化成了检索问题很多候选人一上来就答「优化提示词、把功能描述写清楚」方向偏了。Skill 只有十几个时模型一次性把候选塞进上下文语义匹配很简单一旦上百个候选集合爆炸模型要在上百个高度相似的选项里做语义匹配难度是指数级上涨的。这和 RAG 里「从几篇文档里找答案」到「从百万文档里检索」是同一个问题——候选越多越不能靠「硬塞给模型」解决。一句话定性Skill 变多之后工具路由本身就转化成了检索问题。解题思路和 RAG 完全同构——先召回再排序而不是把所有工具一次性摊给模型盲选。二、为什么一多就乱规模与表现当时面试官追问了一句「你说不是模型的问题那根因到底是什么」。我给了这张表Skill 规模模型表现根因~10 个识别准命中率高候选少语义空间不拥挤一选一个准~100 个频繁误选、乱选候选爆炸、上下文拥挤、功能描述相似匹配难度指数级上涨所以「抽风」的本质是路由逻辑没跟上规模。下面四步从治标到治本按规模递进——这也是我当时给面试官的作答主线。三、四步解法按规模递进第一步优化 Skill 描述写明触发场景先说成本最低、见效最快的一招。很多团队死磕 Skill 内部的执行提示词却忽略了 Name 和 Description。但 Skill 的名称、描述本质就是检索引擎里的「标题 摘要」。写得模糊笼统向量检索也区分不开。对比一下反例和正例[反例] 只写功能太模糊name: ppt_tooldescription: 一个生成 PPT 的工具[正例] 写清触发场景name: ppt_generatordescription: 当用户需要制作汇报、融资路演、季度总结、产品演示文稿时调用输入自然语言大纲输出可编辑的 .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 模块把容易混淆的相邻工具显式隔开能大幅减少误触发。SkillWhen To UseWhen Not To UseSQL 工具生成查询语句数据库架构设计、SQL 性能调优前端生成工具产出页面代码后端接口开发、数据库迁移第四步召回 重排检索机制和 RAG 一致最后一招压轴当 Skill 到几百上千量级路由系统本质就是一台检索引擎。思路和 RAG 完全一致——用户提问后先通过向量语义召回 Top 10 候选 Skill再交给大模型精排选出最优工具。# 海量 Skill 场景路由即检索candidates vector_recall(user_msg, top_k10) # 向量语义召回best llm_rerank(user_msg, candidates) # 大模型精排选优return best现在不少专项路由模型底层都是靠这套「召回 重排」架构解决海量工具匹配难题。它把「从一百个里盲选」变成「先缩到十个、再精排」命中率立刻回来。四、回面试官完整作答模板讲完四步我给面试官收了个尾这道题的答题层次就是「先定性、再分层、补全边界、最后上召回重排」。再往上加分可以提两点——一是 Anthropic 的渐进加载Progressive Disclosure不一次性把全部 Skill 塞进上下文先读名称简介判断、需要才加载完整逻辑控制上下文拥挤二是上线后必须监控命中率指标、做 A/B 评估路由不是配完就完事得有数据闭环。工具越多越要把路由当检索引擎来设计——你不是在写提示词你是在搭一个检索系统。先定性、再分层、补全边界、最后上召回重排命中率自然会回来。你做 Agent 时是被工具路由坑过还是卡在别的地方评论区聊聊下期接着拆 Agent 落地里的坑。 面试官：Agent 的 Skill 上百个，模型频繁选错工具、命中率暴跌怎么破？
前两天群里一位兄弟分享了他面某大厂 Agent 应用岗的一道真实场景题非常考验候选人对「工具路由」的底层把控力「你们的内部 Agent 平台接入了上百个 Skill。某天运营急冲冲找来用户明明说『帮我生成季度汇报的 PPT』模型却调了『代码生成』工具命中率从 90% 掉到了 50%。作为架构师你接手后怎么定位、怎么解」看到这道题我先帮群里兄弟把它定性这不是模型能力退化是工具路由在规模面前失效了。下面把拆解逻辑完整还原一遍——既是这类面试题的标准解法也是一套可落地的工程思路。一、先定性路由退化成了检索问题很多候选人一上来就答「优化提示词、把功能描述写清楚」方向偏了。Skill 只有十几个时模型一次性把候选塞进上下文语义匹配很简单一旦上百个候选集合爆炸模型要在上百个高度相似的选项里做语义匹配难度是指数级上涨的。这和 RAG 里「从几篇文档里找答案」到「从百万文档里检索」是同一个问题——候选越多越不能靠「硬塞给模型」解决。一句话定性Skill 变多之后工具路由本身就转化成了检索问题。解题思路和 RAG 完全同构——先召回再排序而不是把所有工具一次性摊给模型盲选。二、为什么一多就乱规模与表现当时面试官追问了一句「你说不是模型的问题那根因到底是什么」。我给了这张表Skill 规模模型表现根因~10 个识别准命中率高候选少语义空间不拥挤一选一个准~100 个频繁误选、乱选候选爆炸、上下文拥挤、功能描述相似匹配难度指数级上涨所以「抽风」的本质是路由逻辑没跟上规模。下面四步从治标到治本按规模递进——这也是我当时给面试官的作答主线。三、四步解法按规模递进第一步优化 Skill 描述写明触发场景先说成本最低、见效最快的一招。很多团队死磕 Skill 内部的执行提示词却忽略了 Name 和 Description。但 Skill 的名称、描述本质就是检索引擎里的「标题 摘要」。写得模糊笼统向量检索也区分不开。对比一下反例和正例[反例] 只写功能太模糊name: ppt_tooldescription: 一个生成 PPT 的工具[正例] 写清触发场景name: ppt_generatordescription: 当用户需要制作汇报、融资路演、季度总结、产品演示文稿时调用输入自然语言大纲输出可编辑的 .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 模块把容易混淆的相邻工具显式隔开能大幅减少误触发。SkillWhen To UseWhen Not To UseSQL 工具生成查询语句数据库架构设计、SQL 性能调优前端生成工具产出页面代码后端接口开发、数据库迁移第四步召回 重排检索机制和 RAG 一致最后一招压轴当 Skill 到几百上千量级路由系统本质就是一台检索引擎。思路和 RAG 完全一致——用户提问后先通过向量语义召回 Top 10 候选 Skill再交给大模型精排选出最优工具。# 海量 Skill 场景路由即检索candidates vector_recall(user_msg, top_k10) # 向量语义召回best llm_rerank(user_msg, candidates) # 大模型精排选优return best现在不少专项路由模型底层都是靠这套「召回 重排」架构解决海量工具匹配难题。它把「从一百个里盲选」变成「先缩到十个、再精排」命中率立刻回来。四、回面试官完整作答模板讲完四步我给面试官收了个尾这道题的答题层次就是「先定性、再分层、补全边界、最后上召回重排」。再往上加分可以提两点——一是 Anthropic 的渐进加载Progressive Disclosure不一次性把全部 Skill 塞进上下文先读名称简介判断、需要才加载完整逻辑控制上下文拥挤二是上线后必须监控命中率指标、做 A/B 评估路由不是配完就完事得有数据闭环。工具越多越要把路由当检索引擎来设计——你不是在写提示词你是在搭一个检索系统。先定性、再分层、补全边界、最后上召回重排命中率自然会回来。你做 Agent 时是被工具路由坑过还是卡在别的地方评论区聊聊下期接着拆 Agent 落地里的坑。