Skills 能替代 RAG 吗？把文档按主题分级写进 Skills 的利与弊

2026/8/14 22:38:35

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 都不是最优解。实践中最有效的是分层混合：

MERMAID_BLOCK_0

上层用 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人工智能时代，转载请注明出处。