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

Skill 匹配的本质，不是关键词搜索，而是语义理解、向量检索与 LLM 决策的三层叠加。

最近团队在做一个内部 Agent 项目，遇到一个特别现实的问题：Skill 库从最初的十几个，慢慢涨到了七八十个，选错技能的情况开始变得频繁。有一次同事让 Agent“帮忙整理一下会议纪要”，结果调用的是“写周报”的 Skill，输出的东西驴唇不对马嘴。

这事儿倒逼我们把 Skill 匹配这套机制彻底捋了一遍。今天就把这个过程记下来，也算是一次踩坑总结。

📌 本文看点

普通的对话机器人很简单：用户提问，模型直接生成答案，一问一答，结束。

但 Agent 不一样。它得先想清楚“用户到底要干什么”，然后判断“该用哪个能力去完成”，最后才是执行、交付结果。这个“先理解、再选择、后执行”的过程，才是 Agent 真正有意思的地方——也是最容易出问题的地方。

举个最直观的例子：用户说“帮我做一份季度汇报 PPT”，Agent 手里可能有 GeneratePPT、WriteEmail、SearchDocument、DrawFlowchart 好几十个 Skill，它凭什么就知道该选 GeneratePPT？

答案不是关键词匹配这么简单粗暴。真正在起作用的，是三件事情叠在一起：语义理解、语义检索、LLM 推理决策。下面一个个拆开说。

很多人会把 Skill 和 Tool 混为一谈，其实两者不是一回事。

Tool 更底层，是一个个具体的函数或工具，比如“发一封邮件”、“查一次数据库”、“生成一个文件”。而 Skill 是面向任务的能力组合，比如“生成一份完整的季度汇报 PPT”——这背后往往要调用好几个 Tool 才能拼出结果。

一个规范的 Skill 通常长这样：有名字、有功能描述、有适用场景说明、有输入参数定义、有输出格式约定、还得配几个调用示例。拿 GeneratePPT 举例：

这套结构化的描述，才是后面 LLM 能“看懂”并选对 Skill 的基础。描述写得含糊，匹配一定不准，这个后面会细说。

拆开来看，整个匹配过程大致分四步。

第一步，理解用户到底想干什么

Agent 先用 LLM 分析用户输入，把任务目标和限制条件提取出来。比如用户说“请根据这份销售数据，生成一份季度汇报 PPT”，LLM 需要识别出：任务类型是生成演示文稿，输入素材是销售数据，输出格式要求 PPT，业务场景是季度汇报。这一步做好了，后面的检索才有靶子。

第二步，把这个意图变成一串数字

这一步叫向量化，说白了就是把自然语言转换成机器能比较的数值表示。为什么非要绕这一圈？因为用户的说法千差万别：“做个汇报材料”、“整理成演示文稿”、“输出季度总结 PPT”——字面上完全不同，但意思其实是一回事。只靠关键词匹配，这种同义表达根本处理不了。向量化之后，语义相近的表达在向量空间里距离也会更近，这就是它的价值所在。

第三步，去 Skill 库里检索相关的候选项

Skill 库就是 Agent 所有可用能力的集合，比如 SearchDocument（检索文档）、GeneratePPT（生成 PPT）、WriteEmail（写邮件）、SQLQuery（查数据库）、CodeReview（代码审查）等等。系统会拿用户意图的向量，跟每个 Skill 描述的向量算相似度，选出最靠前的几个候选：

这里有个细节值得说一下：为什么要留 Top-K 而不是直接锁定第一名？因为很多任务其实需要多个 Skill 配合，只看单一最高分容易漏掉真正需要组合调用的情况——比如先查数据，再画图表，最后才生成 PPT。留几个候选，是给后面的判断留余地。

第四步，LLM 做最终拍板

检索解决的是“哪些 Skill 可能沾边”，真正决定用哪个，还得靠 LLM 结合上下文综合判断：这个 Skill 真能完成任务吗？用户给的信息够不够？要不要先调别的 Skill 打底？要不要先反问用户一句？最后输出的是文件还是文本还是结构化数据？还是那个季度汇报的例子，LLM 会这么想：任务目标是生成演示文稿，输入里带着销售数据，用户明确要 PPT 文件，GeneratePPT 能完成内容组织和文件生成——所以选它，而且大概率还得先调一次数据分析或图表生成的工具。

很多人以为 Skill 被选中之后就是“一步到位”生成结果，其实不是。复杂一点的 Skill，内部往往是一整条执行链路。

还拿 GeneratePPT 举例，它内部大致要走这几步：解析用户需求，识别汇报主题和受众；读取输入素材，导入 Excel 或 CSV 文件；分析业务数据，提取关键指标和趋势；生成内容结构，设计页面大纲；生成图表，把数据转成柱状图或折线图；调用 PPT 生成工具，完成排版；导出结果文件；最后把文件位置、页数、主要内容反馈给用户。

遇到这些情况，靠谱的 Agent 不会硬着头皮往下走，而是会请用户补充信息，或者换个备用 Skill 试试，或者先把中间结果丢出来让用户确认一下再继续。这种“留有余地”的设计，往往比一味追求“一次到位”更靠谱。

实践中大概有两条路子。

说白了，向量检索干的是“找得全”这件事，LLM 干的是“选得准”这件事。单靠检索，容易选出看着相似但根本用不了的 Skill；单靠 LLM 面对几十上百个候选，成本高、判断压力也大。两者搭配着用，先缩小范围再精细决策，目前看下来是相对稳妥的组合。

折腾了一圈之后，我们发现真正决定匹配效果的，往往不是算法多花哨，而是几个很朴素的细节。

结合这段时间的踩坑经验，几个改进方向基本是明确的。

只看 Skill 名字不看描述和参数，也很危险，名字像不代表能力就一样，得结合输入输出和场景一起判断。

Skill 数量一多还硬要 LLM 面对全部候选，上下文越拉越长，出错概率也跟着涨。

以为一个用户请求只能对应一个 Skill，这个假设在稍微复杂点的任务面前基本站不住脚。

还有一点容易被忽视：用户给的信息不够的时候，宁可先问一句，也别硬着头皮往下执行。

折腾下来最大的体会是，Skill 匹配这件事，本质上是 LLM 理解意图、向量检索召回候选、LLM 结合上下文做最终决策，这三步环环相扣。任务再复杂一点，还要考虑 Skill 组合、Tool 编排、执行过程中的监控和结果校验。

这也是我们这次重新梳理下来，觉得最值得记住的一句话。