Agent 总是选错 Skill？我是怎么把路由准确率从 65% 优化到 92% 的

上周有同事跑来找我吐槽他对着 Agent 说了句帮我查下 xx 服务的日志结果 Agent 触发了一个资讯追踪 Skill去帮他搜 AI 新闻。这类问题在已经不是第一次了。我们的 Agent 上挂了十几个 Skill——有查集中式日志平台的、有查 Pod 容器日志的、有做分布式链路追踪的、有直接跑 kubectl 的甚至通用 Bash 也能tail -f。“查日志三个字往里一丢五个 Skill 都举手说我能干”。这个问题困扰了我一段时间。最终把路由准确率从 65% 拉到 92%方法并不复杂但过程中踩了不少认知的坑今天整理出来。先把问题定义清楚当用户输入一句自然语言Agent 需要做一个决策从 N 个 Skill 加上不调用任何 Skill 直接回答这 N1 个选项中选出正确的那个。这本质是一个多类分类问题。分类器是 LLM 本身而类别定义就是每个 Skill 的 description 文本。理解了这一点后面所有的优化手段就有了统一的评估框架——路由准确率就是这个分类问题的 accuracy。路由靠什么靠 description 的质量目前主流 Agent 框架的路由机制出奇地一致——不管是 Claude Code 的 Skill、OpenAI 的 Function Calling、还是 LangChain 的 Tool底层都是同一套1.把所有可用工具的 name description 注入 system prompt2.LLM 根据用户输入做 in-context 分类3.输出决策调哪个、传什么参数所以路由准确率的天花板 description 写得有多好。我来展示一个真实的对比。我们有个一站式运维 Skill早期的 description 是这样的运维命令行工具支持日志查询、监控查看、配置管理等功能。触发精确率大约 65%。经常误触发也经常该触发时沉默。优化后的版本经过三轮迭代变成了这样一站式运维 CLI。覆盖 RPC 泛化调用、日志平台查询、Pod 容器日志、 APM 监控、分布式链路追踪、配置中心管理、SQL 执行、CI/CD 流水线。 即使用户没说运维遇到下列触发词也必须使用此 skill pod / 容器 / 机器 / IP / application.log / gc.log / logstore / traceId / ... 关键路由原则用户说查日志时—— pod/IP/具体文件名 → 容器日志子命令 logstore/project/结构化查询 → 日志平台子命令 模糊不清 → 反问用户要查哪种日志。触发精确率上升到 92%。核心差别在三个点第一从能力描述变成触发词枚举。LLM 做 in-context matching 时显式的关键词列表比模糊的能力描述有效得多。这不是直觉判断——我对同一个 Skill 跑了两版 description 的 A/B eval触发词枚举版的召回率高了 17 个百分点。第二内建子路由规则。单个 Skill 覆盖多种场景时不要指望 LLM 在外面帮你分发直接在 description 里写明什么条件走哪个子命令。需要强调的是这不是说 description 越长越好。把 500 字的模糊能力概述换成 200 字的结构化路由规则效果反而更好。关键是从我能做什么的视角切换到什么条件触发我的视角——触发词、SKIP 条件、子路由逻辑各司其职每一句都在帮 LLM 做分类决策而不是在堆砌信息。第三兜底策略是反问而不是猜。“模糊不清 → 反问用户要查哪种日志这条规则把误触发率从 12% 降到了 3%。因为 LLM 面对不确定情况时的默认行为是先试试”你得显式告诉它不确定就别动手。多个 Skill 都能干同一件事的冲突消解这是实际工程中最恶心的问题。我们的场景查 Pod 容器的 CPU 使用率运维 Skill 能查封装了 APM 监控平台的接口直接 Bash 跑kubectl top pod也能查。Agent 怎么选我总结出三条消解规则按优先级排列规则一显式否定 隐式推断Anthropic 在 Tool Use Best Practices 文档中建议Describe what the tool does NOT do or when it should NOT be used, rather than only describing what it does. 在工具描述中明确说明工具不适用的场景而不是只描述它能做什么。在工程实践中确实如此。我在每个 Skill 的 description 里加了SKIP条件SKIP: 用户问的是 git log / commit 历史 → 不触发 SKIP: 文件路径以 .log 结尾但语境是代码仓库 → 那是源码文件不是运维日志 SKIP: 用户在讨论 logging 库的配置 → 那是代码设计问题不是运维问题这比单纯加触发词管用。因为触发词再多也有边界 case但什么时候不要用可以直接阻断 LLM 的试一试冲动。规则二专用工具优先于通用工具用户问查下 Pod 的 CPU运维 Skill专用封装了鉴权、集群路由、格式化输出Bash kubectl通用需要用户自己处理 context 切换。选专用的。但这条规则需要在 description 里显式表达出来不能指望 LLM 自己推断当查询涉及容器监控指标时优先使用本 skill 而非直接 kubectl 命令—— 本 skill 已内置集群鉴权和多环境路由用户无需手动 switch context。规则三上下文锚定 合并优于路由同一个词在不同对话上下文里含义完全不同。做过微服务的人都知道——日志在运维对话里是日志平台查询在 code review 对话里是看 logger 调用在 CI/CD 对话里是构建日志。单靠触发词匹配解决不了这种歧义。但比优化上下文识别更有效的做法是直接减少需要路由的 Skill 数量。OpenAI 在 function calling 的文档里明确建议过这一点。如果两个 Skill 有 60% 的功能重叠合并成一个带子命令的 Skill比靠 LLM 在两者间做路由稳定得多。路由层的每次决策都有出错概率减少决策点本身就是在提升可靠性。我们后来把日志平台查询和Pod 文件日志合并到了一个运维 Skill 下面用内部子路由分发。合并后整体路由错误率下降了约 40%。这个收益比任何 description 优化都大。当 Skill 数量上去之后动态加载 分层路由前面讲的 description 优化和冲突消解在 Skill 数量 20 时够用了。但当 Skill 增长到 20 之后会撞上一个结构性问题所有 Skill 的 description 一起塞进 system promptLLM 的分类准确率会随候选数量增加而下降。Anthropic 的官方建议是单次调用不超过 20 个工具。这时候靠优化 description 文本已经不够了需要在架构层面做两件事。动态工具加载先筛再选核心思路不要一次把所有 Skill 都给 LLM先用轻量级检索筛出最相关的 5-8 个再让 LLM 从这个小集合里做最终选择。实现很简单——把每个 Skill 的 name description 做 embedding 存起来用户输入进来后算余弦相似度取 top-k 注入 prompt。开源库Semantic Router做的就是这件事支持 OpenAI / Cohere / 本地 embedding 模型pip 装上就能用路由延迟在 10ms 以内。用户输入 → embedding 检索 top-8 Skill → 仅这 8 个注入 prompt → LLM 精选我们在 Skill 数量到 25 个时上了这一层路由准确率回升了 6 个百分点从 86% 到 92%同时 prompt token 消耗减少了约 60%。分层路由先分类再选工具当 Skill 可以按领域分组时运维类、数据类、研发效能类可以做两级路由•第1级embedding 匹配或小模型分类确定 Skill 所属类别3-5 个类别•第2级只把该类别的 Skill3-5 个交给 LLM 做最终选择这个模式的好处是每一级的候选都很少分类准确率自然高。第一级用 Semantic Router 可以做到接近零延迟第二级用标准的 function calling。两级串联的整体准确率通常比单级全量路由高 8-15 个百分点。这两个方案不需要 fine-tune 模型不需要 GPU用现有的 embedding API 几十行代码就能落地。对大多数团队来说description 优化 动态加载两层组合就足以覆盖 30 个以内的 Skill 场景。超过 30 个再考虑 fine-tune 专用路由模型参考 Gorilla 项目的 OpenFunctions 方案。Eval-Driven用数据量化路由质量写了个 Skill怎么知道好不好光看能不能跑通是不够的。核心指标就三个指标定义达标线触发精确率触发时确实该用这个 Skill 的比例 90%触发召回率该用时确实触发了的比例 85%误触发率不该触发但触发了 5%怎么跑 eval推荐直接用 Skill Creator。主流 Agent 框架如 Claude Code内置的 Skill Creator 覆盖了 eval 全流程——AI 自动生成测试集包括同义改写、上下文干扰、相邻 Skill 混淆查询等人工难以穷举的 case、跑评估、输出指标、支持多版 description 的 A/B 对比。不需要手写脚本帮我跑一下这个 Skill 的 eval就能拿到结果。框架没有内置 eval 能力的可以用promptfoo或BFCL补位。一个 eval case 长这样query期望触发期望不触发“帮我看下 pod 的内存占用”运维 Skill资讯 Skill、文档 Skill“logging 的 level 配置怎么写”无直接回答运维 Skill“查下昨天这个服务的错误日志”运维 Skill日志平台子命令容器 Skill“帮我写个 logger 工具类”无直接回答运维 Skill50 个 case 就够。一条重要经验测试集里正例和反例的比例大约 6:4。我们早期犯的错就是全是正例精确率看着 95%但线上误触发率高达 15%——反例一个没测。每次改 description 前后各跑一次 eval对比数字有没有改进一目了然。改代码之前先写 eval case改完不达标不合并——这就是 Eval-Driven Development。持续迭代让 AI 优化 AIDescription 优化只是起点。Skill 上线后需要持续迭代——但这件事本身也应该交给 AI 来做而不是靠人手动改。主流 Agent 框架已经内置了 Skill 管理能力。以 Claude Code 为例它提供了两个内置 meta-skillSkill Creator负责创建、eval 测试、description 优化Skill Optimizer负责审查触发语义、检测相邻 Skill 的路由冲突、评估安全边界。这类用 AI 管理 AI 工具的模式并非 Claude Code 独有——任何支持 tool-use 的 Agent 都可以构建类似能力。核心思路是把 description 当作可优化的参数把 eval 指标当作优化目标让 AI 在参数空间里自动搜索。配合 Langfuse 等可观测性工具采集线上 trace可以搭建完整的迭代闭环线上最值得关注的三个信号重试用户换个说法重新问说明做了但没做对、放弃中途退出对话说明方向不对、绕过用户选择手动操作说明信任流失。这些信号喂给 Skill Optimizer 自动分类处理人只需确认优化方案。当优化工具持续指向的不是 description 文字问题而是职责边界问题时就该做拆分或合并了。该拆description 超过 500 字还在加条件、不同子功能的 eval 分数差异大。该合两个 Skill 被同一句话同时触发、用户完成任务需要连续调两个 Skill。最后从 65% 到 92%做对了四件事把 description 从能力说明改成结构化路由规则Skill 多了之后上 embedding 动态加载降低分类难度用 eval 把感觉变好了变成可量化的数字用 Skill Creator 把创建、测试、优化跑在 AI 工具里而不是手动迭代。一条建议从第一个 Skill 开始就用 Skill Creator 来创建和测试。别等到手动维护不动了才想起自动化——到那时候要修复的不只是准确率还有已经流失的用户信任。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】