本文介绍了在 Agent 中配置 Skill 时如何通过优化 Skill 的描述、分组加载、延迟加载以及分层管理来提升大模型的路由成功率。文章指出Skill 和 Tool 的分工要明确Skill 负责方法Tool 负责执行Skill 描述要清晰明确任务对象、触发场景和职责边界Skill 多时先分组加载再进行细选同时命中率要分开计算分别评估索引、选择和执行三个环节。最后文章建议在生产环境中保留人工确认并通过日志记录候选、选择和执行过程以便后续优化。给 Agent 装十个 Skill 时路由通常不是大问题。用户一开口模型扫一眼描述大多能猜到该读哪份说明。Skill 涨到几百个怪事开始出现。明明装了“经营复盘”用户让它分析季度销售它却跑去做 PPT。十页内容排得挺完整经营结论没几句。遇到这种情况很多团队会去改 description描述。description 主要影响候选发现和初步判断。正确的 Skill 进了候选以后模型选不选它、什么时候调用、最后有没有把事情办完还要看后面的路由和执行。我习惯把整个过程分成三段找候选、做选择、看交付结果。每一段都可能出错修法也不一样。Skill 规定方法Tool 执行具体动作Skill 和 Tool工具很容易被说成一回事其实分工挺清楚。还是拿季度经营复盘举例。Agent 先读“经营复盘”Skill里面写着工作顺序校验数据口径找异常提炼经营判断再组织汇报结构。真到执行时它会查 SQL、用 Python 算数据可能还要调用 PowerPoint 生成器。这些能查、能算、能写文件的东西是 Tool。Skill 规定办事方法Tool 完成具体动作。真实任务也很少只碰一个 Skill。销售数据要先分析再写成经营复盘最后才做演示文稿。系统如果硬逼模型单选选得再准也只能做完一部分。Skill 决定按什么方法办Tool 决定具体怎么执行复杂任务通常要串联多个 Skill。Agent 开工前看到了什么Anthropic 在 Agent Skills 文档里把加载方式称为 progressive disclosure渐进式披露。它指的是按需加载先看目录确定相关后再读正文。Agent 启动时通常先看到每个 Skill 的name和description。Anthropic 给出的参考量级约为每个 Skill 100 tokens。这些元数据告诉模型这里有哪些能力大概在什么情况下用。模型认为某个 Skill 相关才会读取完整的SKILL.md。工作步骤、限制条件和检查项到这时才进入上下文。Skill 里如果还引用了脚本、模板或案例Agent 用到哪份再读哪份。这样做能省上下文。description 管发现SKILL.md管执行。任何一边写坏了用户看到的都是“这个 Skill 不好用”。Agent 先看名称和描述找入口确定相关后才加载完整说明发现和执行是两道关。具体怎么发现候选各个平台不完全一样。有的直接让大模型比较描述有的先做关键词或向量检索有的提供 namespace命名空间和 tool search工具搜索。所以不能笼统地说 Skill 路由就是 embedding向量匹配。向量只是一种找候选的方法。Skill 多了description 越容易重叠数量会增加选择成本。Skill 越多描述相似的情况也越多。假设系统里有“数据分析”“经营复盘”和“演示文稿”。用户说“把销售数据做成季度汇报。”三个 Skill 都有理由出现。数据分析负责算清楚经营复盘负责把数字变成判断演示文稿负责交付形式。如果描述只写“处理数据”“生成报告”“制作 PPT”模型看到的是三个差不多的入口。Skill 越多真正增加的不只是能力也是相似入口之间的选择成本。路由失败常见有几种。有时正确 Skill 根本没进候选有时它进来了模型却选了职责相近的另一个 Skill还有一种更冤Skill 选对了执行时因为说明缺项或 Tool 报错任务还是没完成。团队如果把这些情况都记成“命中率低”最后往往只会反复润色 description。问题如果出在执行环节改 description 并不会解决。description 要和容易混淆的邻居一起改下面这种描述几乎帮不上路由负责生成 PPT。它只说了功能没有说触发场景。改成下面这样信息就够用了当用户需要把经营分析、融资路演、季度复盘或项目方案制作成演示文稿时使用。输入可以是提纲、Markdown 或报告。负责内容结构和演示文稿交付不替代原始数据分析。这里有任务对象、使用场景、常见输入也写了最容易混淆的边界。description 要写清任务对象、触发场景和职责边界并和最容易混淆的邻居一起改。Anthropic 的编写指南要求 description 同时写清“做什么”和“什么时候用”并放入具体关键词。“什么时候不要用”不是 Agent Skills 规范里的必填项不过两个 Skill 总在抢同一类任务时写清边界可以减少误触发。我会把经常混淆的 Skill 成对检查。比如“数据分析”改了描述就顺手看一眼“经营复盘”拿同一批请求同时测两个而不是各改各的。路由错误经常发生在它们的交界处。候选太多时先分组加载几十个 Skill 平铺在一起清楚的元数据加上能力不错的模型往往还能应付。到了几百、几千个继续平铺就开始浪费上下文模型也更容易在相似描述间摇摆。一个直接的办法是先分组。先看任务属于研发、运营、销售还是内容生产进入内容生产后再判断是写文章、做演示还是生成视频。分组也会分错。如果第一步把季度经营汇报分到“内容生产”后面可能再也看不到“经营分析”。分组的作用只是缩小每次比较的范围分类边界仍然要测。分组和延迟加载能缩小每次比较的范围但不能保证第一次分类永远正确。OpenAI 在 Function Calling 文档里给过一个相邻建议一轮开始时可见的函数尽量少于 20 个准确率通常更好。官方把它称为软建议。它不是通用上限也不是 Skill 的数量上限。工具很多时可以用 tool search 延迟加载再用 namespace 把相关工具归到一组。Skill 库也可以按使用频率分层。高频 Skill 常驻低频 Skill 放进可检索目录。用户没提到视频就没必要让模型先读几十个视频制作 Skill 的描述。上百个 Skill先粗筛再细选Skill 库继续长大通常会加一层 Retrieve Re-Rank召回与重排。第一轮用关键词、标签或 embedding从全库找出一小批候选。比如用户说“分析季度销售并做成汇报”系统先拿回数据分析、经营复盘、演示文稿等十个候选。第二轮再把用户请求、对话上下文和候选描述一起交给更强的模型。上下文里如果写着“先找出华东区毛利下滑的原因再给管理层汇报”模型就应该先跑经营分析再做演示文稿而不是一上来生成十页幻灯片。规模上来后先用快速检索召回候选再让更强的模型结合上下文重排。Sentence Transformers 的 Retrieve Re-Rank 文档讲的也是这个结构速度快的检索器先找候选计算更贵的 Cross-Encoder 再重排。它和 RAG 确实有点像但两边拿回来的东西不同。RAG 通常在找回答所需的知识Skill 路由是在找完成任务要用的工作方法。命中率要分开算只挑三个例子试过全对就上线很容易漏掉问题。用户只要换一种说法或者把两个任务揉在一句话里之前的结果就可能失效。测试集里至少要放进四种请求正常触发、很像但不该触发、没有合适 Skill以及必须串联多个 Skill 的任务。指标也要分开看RecallK看正确 Skill 有没有进入前 K 个候选Routing Accuracy看候选出来后最终选择和调用顺序对不对End-to-End Success看用户交代的事情最后有没有完成。假设有 100 条测试请求。正确 Skill 有 96 次进入 Top 10Recall10就是 96%。重排后选对 90 次路由准确率是 90%。最后只有 82 次交付成功最终成功率就是 82%。把三项分开统计才能知道问题出在哪。96 太低去看索引和描述96 到 90 掉得多去看候选边界和重排模型90 到 82 的损失则要查 Skill 内容、Tool 和执行过程。拆开看 RecallK、路由准确率和最终成功率才知道该修索引、选择还是执行。Anthropic 的编写指南也建议先做 evaluation评测从代表性任务和已经出现的失败入手再补说明。底层模型换了也要重新测。同一份 Skill 放到不同模型上效果本来就可能不同。模型拿不准时先别调用退款审批、合同审查、数据删除这类任务误触发一次的代价可能比漏掉一次高得多。模型拿不准时可以追问一句也可以停下来等人工确认。如果考核只奖励“调用成功”Agent 就会养成一个坏习惯不管会不会先挑一个 Skill 再说。表面上调用率很高线上事故也会跟着涨。高风险任务宁可追问或停下也不要为了调用率强行选一个 Skill。生产日志最好能留下当时的候选、最终选择、调用过的 Tool以及有没有被人工纠正。真实失败再补回评测集。以后改 description、换路由器或升级模型都跑一遍回归。落地时先做四件事列出最容易互相抢任务的 Skill补齐相似请求和空路由测试把候选与最终选择写进日志高风险动作保留人工确认。Skill 库一大偶尔选错并不奇怪。麻烦的是团队只看到“它又选错了”却不知道错在候选、选择还是执行。日志把这三段分别记录下来下一次就知道该查哪里。继续往 description 里堆形容词解决不了另外两段的问题。最后当下AI大模型是当下实打实的优质风口岗位缺口大、发展前景广、薪资待遇突出对比内卷严重、涨薪晋升困难的传统技术岗是普通人转行逆袭的绝佳选择。但很多想要入局大模型领域的朋友都面临无系统学习路径、无实战资源、求职无方向的难题一个人硬啃最容易走弯路、浪费大量时间精力。这里我结合多年一线实战与教学经验整理出一套零基础大模型专属资料包含系统化学习路线图零基础到精通大模型学习书籍 文档电子版2026 最新行业报告项目实战 配套源码大厂面试真题需要的朋友微信扫描下方 CSDN 官方认证二维码免费领取保证 100% 免费。扫码免费领取全部内容下面简单介绍一下资料包含的内容1、大模型系统化学习路线图专属定制从零基础入门到企业级实战的全阶段学习体系划分清晰的四大学习阶段规避碎片化学习弊端适配新手2、0基础到进阶视频教程配套完整高清实操教程覆盖Prompt提示工程、RAG知识库搭建、Agent智能体开发、模型微调、部署落地等核心知识点所有课程搭配实操演示零基础也能轻松看懂、上手实操。3、大模型学习书籍 文档汇总30本行业经典AI、大模型、深度学习精选书籍涵盖理论原理、开发实战、算法基础、AI产品思维等各类内容4、AI大模型最新行业报告整理2024-2026年最新大模型行业白皮书、市场分析报告清晰展现行业发展趋势、技术迭代方向、岗位需求变化帮助学习者精准把握行业风口找准学习和就业方向5、大厂面试真题汇总了常见的AI大模型面试问题、知识点梳理和面经参考方便求职时针对性准备。6、大模型项目实战 配套源码包含GPT应用开发、RAG私有知识库、智能问答系统等多个企业级实战项目配套完整可运行源码从简易Demo到完整商业应用全覆盖帮助学习者将理论转化为落地实战能力积累项目经验。7、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。8、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料