Skills 能替代 RAG 吗？把文档按主题分级写进 Skills 的利与弊
Skills 能替代 RAG 吗？把文档按主题分级写进 Skills 的利与弊
先收藏，回头一定用得上。这个问题问的人越来越多了。
最近被问得最多的一个 Agent 架构问题：能不能用 Skills 替代 RAG 来回答问题？比如把文档按主题、分级写入不同的 Skill，让 Agent 按需加载，不再做向量检索。
这个想法有意思，因为它指向了一个正在发生的范式转移。但答案不是"能"或"不能"，而是"看你处理的是哪类文档"。
本文提纲
- 短答案：只在特定场景成立
- 两者检索范式的根本差异
- Skills 的五个独特优势
- Skills 替代 RAG 的硬约束：规模
- 按文档类型拆：谁该用谁
- 真正的答案：混合架构
- 一个心智模型帮你做决策
短答案：只在特定场景成立
Skills 和 RAG 解决的其实不是同一个问题。
Skills 是"按意图路由的过程性知识"--Agent 读 skill 的 description，判断当前任务需要哪个，加载整块内容。RAG 是"按相似度检索的事实性知识"--把文档切块做 embedding，查询时用向量相似度找到最相关的片段。
用 Skills 完全替代 RAG，在中小规模、过程性强的文档场景下可行且更优；一旦文档量大到千级以上、或查询以精确事实查找为主，Skills 的检索机制就会撞墙。
两者检索范式的根本差异
这是理解一切的前提。
| 维度 | Skills | RAG |
|---|---|---|
| 检索单元 | 一个完整 skill（500-5000 token） | 一个 chunk（200-500 token） |
| 检索信号 | 模型读 description，按意图/主题选 | 向量相似度，按内容相关性选 |
| 粒度 | 粗粒度（话题级） | 细粒度（段落级） |
| 返回内容 | 整个话题的完整上下文 | 孤立片段，可能脱离上下文 |
| 知识形态 | 过程性（怎么做事），curated | 事实性（是什么），automated |
| 维护方式 | 人工编写、审核、结构化 | 自动分块 + embedding |
| 更新成本 | 手动改 skill 文件 | 重新 embedding |
| 缓存 | 内容稳定可进 prompt cache | top-k 组合每次不同，cache 命中率低 |
一句话概括差异：Skills 是"给你整本说明书"，RAG 是"给你翻到相关那页的某一段"。 前者完整但贵，后者精准但碎。
Skills 的五个独特优势
1. 连贯性。 一个 skill 是自洽的整体。你问"怎么配置 compaction"，skill 给你触发条件、五步流程、切断点规则、配置项一整套。RAG 给你三个 chunk，可能一个讲触发条件、一个讲切断点、中间那个刚好被切断了。
2. 指令跟随能力。 Skill 不只是知识，还能包含流程："当用户问 X 时，先检查 Y，再执行 Z"。RAG chunk 是静态文本，没有这个过程性。这是 Skills 能做而 RAG 做不了的核心能力--RAG 只能告诉你"是什么"，Skills 还能告诉你"怎么做"。
3. 渐进式披露（progressive disclosure）。 "按主题且分级"正好对应这个设计--一个 skill 可以引用子文件，按需加载。顶层 skill 给概览，需要细节时再 load reference。这比 RAG 的扁平检索多了"深度"维度。
4. 可缓存。 Skill 内容稳定时可以进 prompt cache。RAG 每次查询的 top-k chunk 组合都不同，cache 命中率极低。
5. 质量可控。 人工 curate 的 skill 没有垃圾 chunk、没有切断在句子中间的问题、没有重复内容。
Skills 替代 RAG 的硬约束：规模
撞墙点只有一个：规模。
Skills 的检索依赖"模型读 description 来选"。这意味着所有 skill 的 description 必须同时放进上下文让模型判断：
- 100 个 skill × 50 token/description ≈ 5,000 token 索引 -> 完全可行
- 1,000 个 skill × 50 token ≈ 50,000 token 索引 -> 上下文吃紧，模型在 1000 个 description 里做选择的准确率会显著下降
- 10,000 个 skill -> 不现实，索引本身比内容还大
RAG 没有这个问题--向量检索是近似搜索，百万级文档照跑。
你提的"分级"能解决深度，解决不了广度。层级结构让单个话题可以越挖越深（顶层 skill -> 子 skill -> reference 文件），但顶层的 skill 数量仍然受限于上面这个索引规模约束。层级压缩的是"每个 skill 内部的复杂度"，不是"skill 总数"。
第二个问题是检索精度。问"函数 Y 的参数 X 的默认值是什么"，skill 给你整个函数的 2000 token 文档，你只需要 20 token。RAG 直接给你那 20 token。对于精确事实查找，Skills 是杀鸡用牛刀，还占上下文。
按文档类型拆：谁该用谁
这是最实用的判断框架。文档不是铁板一块，不同类型适合不同方案：
| 文档类型 | 适合方案 | 原因 |
|---|---|---|
| 教程 / 操作指南 | Skills | 过程性、需要完整步骤、连贯性要求高 |
| 架构 / 概念设计 | Skills | 需要整体理解，碎片化检索会丢失全局 |
| 工作流 / SOP | Skills | 纯过程性，skill 能编码"先做什么后做什么" |
| API Reference（数千端点） | RAG | 体量太大、查询是精确事实查找 |
| Changelog / Release Notes | RAG | 高频更新、体量大、时间敏感 |
| 产品目录 / 知识库工单 | RAG | 体量巨大、查询是关联性查找 |
| Troubleshooting / FAQ | 两者皆可 | 看体量：几十条用 skill，几千条用 RAG |
| 内部最佳实践 / 编码规范 | Skills | 需要被"遵守"而非"引用"，过程性强 |
真正的答案：混合架构
纯 Skills 或纯 RAG 都不是最优解。实践中最有效的是分层混合：
graph TB
subgraph Layer1["Layer 1: Skills (curated / procedural)"]
S1[Tutorials]
S2[Architecture]
S3[Workflows]
S4[Best Practices]
end
subgraph Layer2["Layer 2: RAG (volumetric / factual)"]
R1[API Reference]
R2[Changelog]
R3[Knowledge Base]
end
Query[User Query] --> Router{Skill or RAG?}
Router -->|Procedural| Layer1
Router -->|Factual| Layer2
style Query fill:#FF6B6B,color:#000000
style Router fill:#FFEAA7,color:#000000
style Layer1 fill:#FFF9E6,color:#000000
style Layer2 fill:#FFF9E6,color:#000000
style S1 fill:#4ECDC4,color:#000000
style S2 fill:#4ECDC4,color:#000000
style S3 fill:#4ECDC4,color:#000000
style S4 fill:#4ECDC4,color:#000000
style R1 fill:#45B7D1,color:#000000
style R2 fill:#45B7D1,color:#000000
style R3 fill:#45B7D1,color:#000000上层用 Skills 管理人工 curate 的过程性知识（教程、架构、工作流、最佳实践），几十到一百个。下层用 RAG 兜底大体量的事实性文档（API reference、changelog、知识库），百万级自动检索。
还有一种更精巧的混合：用 RAG 来检索 Skills。两阶段检索--
- 第一阶段：把所有 skill 的 description 做 embedding，查询时向量检索 top-k 相关 skill
- 第二阶段：load 这些 skill 的完整内容进上下文
这样 skill 数量的索引规模约束就被打破了，因为索引不再需要全部塞进上下文，而是用向量检索预筛。Claude Code 的 skill search 机制本质上就在走这条路--先搜索再加载，而非全量加载 description。这个设计把 Skills 的"过程性优势"和 RAG 的"规模优势"缝合在了一起。
一个心智模型帮你做决策
最实用的判断方式，记一个比喻：
Skills 像程序性记忆（procedural memory）--你会骑自行车、会调试代码，是"怎么做"的知识，需要连贯、需要练习、不容易碎。
RAG 像陈述性记忆（declarative memory）--法国首都是巴黎、某函数参数默认值是 16384，是"是什么"的知识，可以孤立、可以碎片化、量可以很大。
人脑两种记忆都有，Agent 也该两种都有。
回到最初的问题：把文档按主题分级写进 Skills，能不能替代 RAG？
如果文档体量在百级话题以内，且文档本质是过程性的（教人怎么做、怎么配置、怎么排查），Skills 完全可以替代 RAG，而且体验更好--连贯、可缓存、能编码流程。
如果文档里有大量精确事实需要查找（API 参数、配置项默认值），或者体量会增长到千级以上，那这部分必须留给 RAG，Skills 管不了。
最务实的做法：先用 Skills 把高价值、过程性的核心文档 curate 进去（这部分收益最大），剩余的大体量事实性文档用 RAG 兜底。两者不是替代关系，是分层互补。
参考文档与链接
- Claude Code Skills 官方文档 - Skill 的 progressive disclosure 机制与 description 编写规范
- Anthropic: Context Engineering 实践 - 上下文工程的官方方法论，涵盖 Skills 与检索的关系
- LangChain Deepagents Skills Middleware - SkillsMiddleware 的 source/source_labels 机制，Skill 作为中间件的实现
- Pi Compaction 文档 - 上一篇拆解的上下文压缩机制，与本文的缓存讨论互为补充
- RAG 检索增强生成综述 - RAG 的基本原理与适用场景
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
