一个真实的困境

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

使用者痛点：AI 必须在几十个可能的 skill 中快速定位并组合出「新增页面 → 表格开发 → 代码审查 → 提交」的完整链路。却常常因为缺乏全局视野而漏掉关键步骤，导致工作流中断。

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

之前的文章已经说明过一种做法是把 skill 列表直接喂给大模型。让模型自行选择，但为什么不是让大模型通过查找来召回 skill 呢？比如用向量检索或关键词匹配，本质上都是让外部程序替模型决定该用什么。

如果通过查找召回 Skill

以 RAG 为例，需要先搭建一套基础设施：向量数据库 + embedding 模型。每个 skill 的名称、描述、使用场景都要向量化并存入库中。skill 新增或更新时还要同步更新向量库。其实，

流程如下的观点是。

1. 模型描述「我现在需要什么能力」并发送给检索程序。
2. 检索程序返回候选 skill 集合。
3. 模型在候选集中挑选并执行。话说回来，

使用者痛点：模型对可用 skill 完全未知。只能被动接受检索结果，只要某一步未命中正确的 skill。整个链路就会在此处断裂，使用者甚至不知道哪里出错了。

查找阶段没有模型参与

无论是向量检索还是关键词匹配。主要都是数学相似度计算——只能回答「这两段文本像不像」，却无法判断「完成 A 之后应该做什么」。

"新增页面 → 表格开发 → 代码审查 → 提交" 是有先后顺序的开发链路。怎么说呢，检索程序无法衡量这种时序关系。就像搜索引擎能帮你找到相关文档，却不能帮你规划阅读顺序。

skill 可以用」或「接下来应该怎么走」。

模型看不到全局

skill，也无法提前规划多步工作流。

如果某一步查询没有命中正确的 skill，整个链路就会断掉。 例如使用者说「写完 review 再 commit」，但检索程序认为「review」与 code review skill 的描述不够相似。导致 model 漏掉这一步——它甚至不知道自己漏掉了什么。

使用者痛点：组合场景下更容易出错。面对「新增页面、表格展示、review、commit」四个需求时模型可能只匹配到「新增页面」，随后因为看不到完整列表而忘记后续步骤。怎么说呢，

让模型自己选 Skill

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

skill 可用。不需要每一步都去询问外部程序。

• 提前规划：看到使用者需求后模型立即能够规划出完整链路。
• 组合编排：模型自行决定调用顺序。例如先建页面骨架，再填充表格组件，最终进行审查和提交。
• 灵活应变：如果开发过程中发现需要路由配置。模型能够即时插入对应的 skill，而不必重新发起检索。老实说，

查找 vs Skill 列表：主要区别

* 注：两者并非互斥，在特定场景下可以混合使用。但针对“skill 选择”这一特定任务，让模型直接面对全量列表往往更可靠。

结论

This is fundamentally a design‑pattern question for Agent systems: "Is model a decision‑maker or a consumer?"

• If model is treated as a consumer,its vision is limited to each retrieval result. It cannot understand whole task space nor plan multi‑step workflows.
• If model is treated as a decision‑maker。system only provides context . The model owns planning,sequencing and dynamic insertion of skills.

使用者痛点再现：

• 工具可以用” —— 传统 RAG 只能返回几条相似项，缺乏全局感知。
• B) “某一步骤没有命中导致整个流程卡死” —— 检索失误直接导致业务中断。
• C) “需要手动补齐遗漏的步骤” —— 人工干预破坏了自动化体验。
• D) “Skill 越多越难维护” —— 因为技能数量增长。需要分层、摘要等策略，而不是无限制地扩大向量库。

The pragmatic answer:

1. Simplify decision space – keep number of skills within LLM’s context window .
2. If you have hundreds/thousands of skills。introduce hierarchical categories and let model first pick a category,n drill down.
3. You can still use retrieval for *knowledge* while keeping *skill selection* purely list‑driven.