AI Agent 是怎么选中正确 Skill 的？一文拆解“意图理解→向量检索→LLM 决策”全流程

Skill 匹配 的本质不是 关键词搜索 而是语义理解、向量检索与 LLM 决策的三层叠加。最近团队在做一个内部 Agent 项目遇到一个特别现实的问题Skill 库从最初的十几个慢慢涨到了七八十个选错技能的情况开始变得频繁。有一次同事让 Agent“帮忙整理一下会议纪要”结果调用的是“写周报”的 Skill输出的东西驴唇不对马嘴。这事儿倒逼我们把 Skill 匹配这套机制彻底捋了一遍。今天就把这个过程记下来也算是一次踩坑总结。 本文看点01匹配四步走02两条匹配思路03避坑与改进01DIFFERENCEAgent 和聊天机器人差在哪儿普通的对话机器人很简单用户提问模型直接生成答案一问一答结束。但 Agent 不一样。它得先想清楚“用户到底要干什么”然后判断“该用哪个能力去完成”最后才是执行、交付结果。这个“先理解、再选择、后执行”的过程才是 Agent 真正有意思的地方——也是最容易出问题的地方。举个最直观的例子用户说“帮我做一份季度汇报 PPT”Agent 手里可能有 GeneratePPT、WriteEmail、SearchDocument、DrawFlowchart 好几十个 Skill它凭什么就知道该选 GeneratePPT答案不是关键词匹配这么简单粗暴。真正在起作用的是三件事情叠在一起语义理解、语义检索、LLM 推理决策。下面一个个拆开说。02DEFINITION先搞清楚Skill 到底是个什么东西很多人会把 Skill 和 Tool 混为一谈其实两者不是一回事。Tool 更底层是一个个具体的函数或工具比如“发一封邮件”、“查一次数据库”、“生成一个文件”。而 Skill 是面向任务的能力组合比如“生成一份完整的季度汇报 PPT”——这背后往往要调用好几个 Tool 才能拼出结果。一个规范的 Skill 通常长这样有名字、有功能描述、有适用场景说明、有输入参数定义、有输出格式约定、还得配几个调用示例。拿 GeneratePPT 举例名称GeneratePPT功能根据用户提供的主题和素材生成 PPT输入主题、内容结构、页数、素材文件输出一个 .pptx 文件执行步骤分析主题→生成大纲→组织页面内容→调用生成工具→导出文件这套结构化的描述才是后面 LLM 能“看懂”并选对 Skill 的基础。描述写得含糊匹配一定不准这个后面会细说。03PIPELINE匹配是怎么一步步发生的拆开来看整个匹配过程大致分四步。第一步理解用户到底想干什么Agent 先用 LLM 分析用户输入把任务目标和限制条件提取出来。比如用户说“请根据这份销售数据生成一份季度汇报 PPT”LLM 需要识别出任务类型是生成演示文稿输入素材是销售数据输出格式要求 PPT业务场景是季度汇报。这一步做好了后面的检索才有靶子。第二步把这个意图变成一串数字这一步叫向量化说白了就是把自然语言转换成机器能比较的数值表示。为什么非要绕这一圈因为用户的说法千差万别“做个汇报材料”、“整理成演示文稿”、“输出季度总结 PPT”——字面上完全不同但意思其实是一回事。只靠关键词匹配这种同义表达根本处理不了。向量化之后语义相近的表达在向量空间里距离也会更近这就是它的价值所在。第三步去 Skill 库里检索相关的候选项Skill 库就是 Agent 所有可用能力的集合比如 SearchDocument检索文档、GeneratePPT生成 PPT、WriteEmail写邮件、SQLQuery查数据库、CodeReview代码审查等等。系统会拿用户意图的向量跟每个 Skill 描述的向量算相似度选出最靠前的几个候选GeneratePPT 0.92CreatePresentation 0.89WriteReport 0.78MakeSlides 0.74DrawChart 0.62这里有个细节值得说一下为什么要留 Top-K 而不是直接锁定第一名因为很多任务其实需要多个 Skill 配合只看单一最高分容易漏掉真正需要组合调用的情况——比如先查数据再画图表最后才生成 PPT。留几个候选是给后面的判断留余地。第四步LLM 做最终拍板检索解决的是“哪些 Skill 可能沾边”真正决定用哪个还得靠 LLM 结合上下文综合判断这个 Skill 真能完成任务吗用户给的信息够不够要不要先调别的 Skill 打底要不要先反问用户一句最后输出的是文件还是文本还是结构化数据还是那个季度汇报的例子LLM 会这么想任务目标是生成演示文稿输入里带着销售数据用户明确要 PPT 文件GeneratePPT 能完成内容组织和文件生成——所以选它而且大概率还得先调一次数据分析或图表生成的工具。04EXECUTION选中之后一个 Skill 内部是怎么跑起来的很多人以为 Skill 被选中之后就是“一步到位”生成结果其实不是。复杂一点的 Skill内部往往是一整条执行链路。还拿 GeneratePPT 举例它内部大致要走这几步解析用户需求识别汇报主题和受众读取输入素材导入 Excel 或 CSV 文件分析业务数据提取关键指标和趋势生成内容结构设计页面大纲生成图表把数据转成柱状图或折线图调用 PPT 生成工具完成排版导出结果文件最后把文件位置、页数、主要内容反馈给用户。「这中间任何一步都可能出岔子文件格式不支持、数据缺失、用户要求本身就没说清楚、目标 Skill 暂时不可用、工具调用失败、生成结果不符合预期。」遇到这些情况靠谱的 Agent 不会硬着头皮往下走而是会请用户补充信息或者换个备用 Skill 试试或者先把中间结果丢出来让用户确认一下再继续。这种“留有余地”的设计往往比一味追求“一次到位”更靠谱。05STRATEGY两种匹配思路各有各的坑实践中大概有两条路子。方案 A全量 Prompt 直选把所有 Skill 的描述一股脑塞进 Prompt让 LLM 直接从里面挑。这个方式实现起来很简单Skill 数量少的时候用起来也顺手。但问题也很明显——Skill 一多Prompt 越拼越长成本和延迟跟着往上走还容易撞上下文长度的天花板。更麻烦的是一旦库里出现好几个功能相近的 SkillLLM 挑起来经常摇摆不定。方案 B向量检索 LLM 精选先向量化再检索出 Top-K 候选最后交给 LLM 在这个小范围里做决策。这样一来喂给 LLM 的候选数量始终可控匹配效率明显更高也更适合像我们这种 Skill 库不断在长的场景。当然它也不是没有代价检索效果高度依赖 Embedding 模型的质量Skill 描述写得不清不楚检索照样会跑偏而且还得额外维护一套向量索引和更新机制。「向量检索干的是“找得全”LLM 干的是“选得准”。」说白了向量检索干的是“找得全”这件事LLM 干的是“选得准”这件事。单靠检索容易选出看着相似但根本用不了的 Skill单靠 LLM 面对几十上百个候选成本高、判断压力也大。两者搭配着用先缩小范围再精细决策目前看下来是相对稳妥的组合。06FACTORS匹配准不准说到底看这几点折腾了一圈之后我们发现真正决定匹配效果的往往不是算法多花哨而是几个很朴素的细节。Skill 描述要清楚能做什么、不能做什么、适用什么场景、需要什么输入、会给出什么输出这些交代不清楚检索和判断都会跟着乱。Skill 名称要直接取名叫 Process、HandleTask、Assistant 这种谁也猜不出它到底是干嘛的还不如老老实实叫 GeneratePPT、SearchDocument、SQLQuery 来得直接。示例要覆盖真实说法“做一份 PPT”、“整理成演示文稿”、“生成季度汇报材料”这些说法都得囊括进去不能只写一种标准表达。输入输出定义标准化参数名统一、类型明确、必填可选分清楚。Top-K 数量要反复调太少容易漏掉正确答案太多又会让 LLM 判断起来负担过重这个数值需要结合 Skill 总量和相似程度反复调整。07EXAMPLES几个实际跑过的例子CASE 01问采购制度走的是 SearchDocument检索企业文档拿到相关条款直接回答。CASE 02帮着回复邮件走的是 WriteEmail理解邮件场景之后生成邮件初稿。CASE 03要一份 Q2 业绩报表这次不是单个 Skill 能搞定的先是 SQLQuery 把数据库里的业绩数据查出来再交给 GenerateReport 整理成报告格式两个 Skill 接力完成。CASE 04想看某个品类的走势走的是 DrawFlowchart把数据变成一张可视化的图。 这几个案例里最值得说的是 Q2 报表——它说明 Skill 匹配很多时候不是“选中一个就完事了”复杂任务需要 Agent 先规划出一条任务链再按依赖关系一步步把各个 Skill 串起来执行。08REDESIGN如果要重新设计一套 Skill 匹配系统我们会怎么改结合这段时间的踩坑经验几个改进方向基本是明确的。1Skill 描述格式彻底标准化name、description、use_cases、inputs、outputs、examples、tools、constraints 这些字段一个都不能少靠这套 Schema 统一管理。2定期做 Skill 治理把功能重叠的合并掉给新加的 Skill 补齐示例失效的及时下线别让描述和实际能力对不上。3尝试分层检索先按任务领域筛一轮再按任务类型、输出格式、所需工具逐层收窄最后落到具体的 Skill 上而不是一上来就在几十个候选里硬比。4匹配结果可解释Agent 最好能说清楚“为什么选这个 Skill”、“识别到了什么需求”、“还缺哪些参数”这样出问题也好排查。5建一套评估指标召回率、Top-K 命中率、最终选择准确率、任务完成率、响应延迟、单次成本这些数字盯着看才知道系统到底哪里在拖后腿。09PITFALLS几个容易踩的坑踩坑提示 把 Skill 匹配当成关键词搜索来做是最容易翻车的一种想法——同义表达、语义差异关键词根本处理不了。只看 Skill 名字不看描述和参数也很危险名字像不代表能力就一样得结合输入输出和场景一起判断。Skill 数量一多还硬要 LLM 面对全部候选上下文越拉越长出错概率也跟着涨。以为一个用户请求只能对应一个 Skill这个假设在稍微复杂点的任务面前基本站不住脚。还有一点容易被忽视用户给的信息不够的时候宁可先问一句也别硬着头皮往下执行。∞THE END写在最后折腾下来最大的体会是Skill 匹配这件事本质上是 LLM 理解意图、向量检索召回候选、LLM 结合上下文做最终决策这三步环环相扣。任务再复杂一点还要考虑 Skill 组合、Tool 编排、执行过程中的监控和结果校验。「Agent 的智能不在于“能答出什么”而在于知道该调用什么、什么时候调用、怎么把多个能力串起来完成一件事。」这也是我们这次重新梳理下来觉得最值得记住的一句话。学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%免费】