为什么 Agent Skill 不是通过向量 RAG 召回的？

一个真实的困境

假设你让 AI 帮你新增一个用户管理页面，用表格展示数据，写完后 review 一下代码再 commit。

这背后有一个关键问题：AI 怎么知道该调用哪些 skill？它面前可能有几十个 skill——新增页面、表格开发、code review、commit、国际化、权限配置……它必须从里面挑出需要的那几个，还要按正确的顺序组合起来。

那 skill 是怎么实现的呢？之前我之前文章已经详细说过，是给 skill 列表给大模型，让大模型自行选择。 但为什么是给 skill 让大模型自己选，而不是大模型通过查找的方式召回 skill 呢？比如用 RAG 做向量检索，或者用关键词匹配，本质都是一回事——让外部系统替模型决定该用什么。

如果通过查找召回 Skill

如果用查找来解决这个问题，以 RAG 为例，首先得在本地搭一套基础设施：一个向量数据库，一个 embedding 模型。每个 skill 的名称、描述、使用场景都要做向量化存进去。skill 新增或更新了，向量库要同步更新。

搭完之后，每次模型需要用到某个能力时，流程是这样的：

review-commit

模型从头到尾都不知道有哪些 skill 可用。它只能描述"我现在需要什么能力"，然后等查找系统返回候选集。模型甚至不知道自己漏掉了什么——如果某一步没有命中正确的 skill，链路就断在这里了。

这套方案有两个根本问题。

查找阶段没有模型参与

不管是向量检索还是关键词匹配，查找的本质都是数学计算——它能回答"这两段文本像不像"，但不能回答"完成 A 之后应该做什么"。

"新增页面 → 表格开发 → 代码审查 → 提交"是一条有先后顺序的开发链路。查找衡量不了这种时序关系——就像搜索引擎能帮你找到相关文档，但不能帮你规划先读哪篇、再读哪篇。

模型在整个查找过程中是被动的：它只能在返回的结果里挑选，无法主动思考"我还有哪些 skill 可以用"。

模型看不到全局

每一步查找都只返回一个候选集，模型只能在这个"小窗口"里做决策。它不知道全局有哪些 skill 可用，也无法提前规划多步工作流。

如果某一步的查询没有命中正确的 skill，整个链路就断了。用户说"写完 review 再 commit"，但查找系统认为"review"和 code review skill 的描述不够相似，模型就会漏掉这一步——它甚至不知道自己漏掉了什么。

更麻烦的是组合场景。假设你有四个 skill：新增页面、表格开发、code review、commit。用户说"帮我新增一个用户管理页面，用表格展示，写完 review 再 commit"。查找方案下，模型可能在第一步匹配到"新增页面"，执行完后不知道还有"表格开发"——因为它从未看到过完整的 skill 列表，每一步都只能看到查找系统给的局部结果。

让模型自己选 Skill

另一种思路更直接：把所有可用 skill 的列表一次性交给模型，让模型自己决定调用哪些。

review-commit-02

关键区别在于：模型在对话开始时就知道有哪些 skill 可用，不需要每一步都去问别人。

这种方案下，模型能做的远不止"找到匹配的 skill"：

1. 1. 提前规划：看到用户说"新增页面，用表格展示，review 再 commit"，模型一开始就知道四个 skill 都在列表里，直接规划出完整链路
2. 2. 组合编排：模型能自行决定先调哪个、再调哪个，比如先建页面骨架，再填充表格组件，最后审查和提交
3. 3. 灵活应变：如果开发过程中发现页面需要路由配置，模型知道列表里有哪些相关 skill，可以中途插入调用

查找 vs Skill 列表：核心区别

两种方案的本质差异不在于"用了什么技术"，而在于决策权在谁手里。

用一个日常场景类比：

• • 查找 像是你问图书管理员"有没有关于机器学习的书"，管理员根据关键词帮你找了几本。你不知道书架上还有什么其他书，也无法让管理员帮你规划"先读哪篇、再读哪篇"。
• • Skill 列表 像是整个图书馆的目录摆在你面前，你自己决定借哪些、按什么顺序读。

查找在知识库检索、文档问答等场景仍然是最佳选择。但在"skill 选择"这个特定场景下，让模型直接面对全量列表、自主决策，比通过查找预筛选更可靠。

结论

这背后其实是一个 Agent 系统的设计模式问题：模型是决策者，还是消费者？

查找模式把模型当成消费者——外部系统先帮模型筛好候选集，模型再从里面挑一个用。模型的视野被限制在每一步的检索结果里，它不理解全局，也无法规划。

列表模式把模型当成决策者——系统负责提供上下文（skill 列表），模型负责理解任务、规划链路、选择工具。决策权在模型手里，系统不做越俎代庖的事。

人人都想当决策者掌控全局，但这不轻松。就像一个公司的老板，手下有 10 个人时，谁干什么活一目了然；手下有 100 个人时，就得设部门、设层级，不能事事亲力亲为了。

skill 列表也一样——几十个 skill，模型能直接看、直接选；几百个 skill，描述就得压缩；几千个 skill，就得分层，先看分类摘要，再看详情。这不是列表方案的缺陷，而是所有决策者都要面对的信息过载问题。

但至少，决策者知道自己缺什么、该找谁。消费者不知道。