12 月 15 日的 RAG 知识库调优讲的是怎么从文档中找出能支撑答案的内容。后来用 Skill 时，我反复遇到一个问题：Skill 里也放 Markdown、规则和参考资料，模型也要把它们读进上下文。那它和 RAG 到底差在哪？一个能不能替掉另一个？

先给结论：它们在小范围内可以互相代用，在多数 Agent 任务里不应该互相替代。

• RAG 回答的是：面对这个问题，现在要查哪些事实？
• Skill 回答的是：为了完成这类任务，应该怎么做？
• 权限和业务校验回答的是：这一步是否允许执行？

这套划分在业务 Agent 和 AI Coding 两类场景里都成立，差异在于每一层的实现方式和严格程度。

把三件事混在一起，最常见的结果是：流程被拆散后靠检索碰运气，容易漏步骤；易变的事实写进 Skill，几次更新后就不可信；原本应该由系统拦截的操作，变成一段希望模型遵守的文字。

Skill 如何工作

一个 Skill 通常是一个目录，入口文件是 SKILL.md。它有名称和描述，目录里还能放脚本、模板、参考资料与检查清单。运行时不需要把所有 Skill 正文都塞进上下文，先只暴露名称和描述；模型判断当前任务相关，再读取正文和所需资源。这种按层读取的方式叫渐进式披露。11 月的能力按需加载已经写过其实现和使用问题。

一个退款处理 Skill 可能这样组织：

refund-handling/
├── SKILL.md          # 触发条件、处理步骤、停止条件
├── reply-template.md # 回复模板
└── checklist.md      # 身份、资格、审批检查项

它的价值在于把一项重复任务的做法组织成一个完整单元，而不只是替模型多存一些资料。比如先核验用户身份，再查询订单，再判断资格，满足条件才提交退款；其中任何一步失败就记录原因、停止或转人工。任务开始后，这些步骤应该被一起读取和遵守，而不是从十几段相似文本中临时拼出来。

Skill 也不能直接执行操作。查询订单、发起退款、发送消息由工具或 API 完成；SKILL.md 只说明何时调用、如何组织参数、调用后检查什么。工具权限和后端业务规则仍在模型之外。

RAG 解决什么问题

RAG 将大量外部资料切分、建立索引。用户发来问题后，系统用 query 召回候选，必要时使用混合检索和 Reranker 排序，再把少量文本交给模型生成答案。它更适合处理模型参数中没有、不断更新、且每次只需要其中一小部分的内容。

例如用户问“我的订单现在能退款吗”，订单状态、支付渠道、签收时间以及该渠道的当前政策都可能影响结果。这些信息不是写一遍就稳定不变的流程，需要从订单服务、规则服务或相关文档里获取。RAG 可以用于检索政策解释、历史记录、产品文档等非结构化资料；订单状态这类结构化实时数据，直接调业务 API 通常更合适。

RAG 的输出是证据，不构成流程。模型拿到的某段政策、某条发布记录或某份故障复盘，只能说明当前问题有哪些已知事实。检索命中不代表答案已经正确，仍需检查内容是否过期、是否覆盖问题中的条件，以及模型有没有写出证据之外的结论。

两者可以互相替代到什么程度

它们确实有交集：都能把文件内容送进上下文，也都依赖模型选择和阅读。因此，在内容少、风险低的原型阶段，可以先只用其中一个。

资料很少、问题固定时，可以把资料直接写进一个 Skill。例如只有一份不常更新的产品说明，任务就是按固定模板回答咨询，Skill 里附上说明文件足够用。等资料变多、版本增加、用户问题开始开放，再把事实资料移到 RAG 或查询系统。

流程很短、没有前后依赖时，也可以从 RAG 检索操作说明。例如用户问“怎么创建项目”，召回一段文档后生成一份操作指引没有问题。任务一旦包含前置条件、多个工具、异常分支、审批或验收，靠检索拼步骤就不稳。此时流程应该进入 Skill，检索只负责补充流程执行时需要的事实。

这张表可以作为判断起点：

表格只覆盖典型情况，同一条信息在不同语境下可能进入不同层。比如“退款时限为签收后七天”：系统判断当前订单能否退款时，应该调规则引擎或订单服务；客服要向用户解释时，Skill 可以规定该查哪个字段、怎么说明；用户问去年政策时，才需要从 RAG 找历史版本。

RAG 选片段，Skill 选做法

RAG 和 Skill 容易混淆，因为两者都会“按需加载”。差别在于模型先要选什么。

RAG 选的是片段。系统问的是：这段文字和用户当前问题相关吗？它可以从几万篇文档中找出两三段内容。选错的后果通常是证据缺失、排位靠后或拿到过期资料。相应的调优对象是切分、embedding、query 改写、元数据过滤、召回和重排。RAG 知识库调优里的 Context Recall、Context Precision、Faithfulness 等指标，都是在检查这条证据链。

Skill 选的是一套做法。系统问的是：当前任务是否应该采用这套步骤、模板和约束？一旦选中，通常要读完整的 SKILL.md，还可能继续读同目录资源。选错的后果是没走必要流程、误触发无关流程，或者多个流程规则冲突。这里要检查的是描述写得是否能区分任务，模型是否真的读了正文，异常分支是否完整，工具和脚本有没有随流程版本一起更新。

这个差别解释了为什么“把所有材料向量化”经常不够。RAG 可以找回“退款需要核验身份”这段文字，却无法保证这段一定被召回，也无法保证它排在提交退款之前。Skill 可以规定核验身份必须发生在提交之前，却不能知道当前订单的签收时间。前者需要当前事实，后者需要固定顺序。

RAG 的优点、代价和适用范围

RAG 的优点是能处理规模大、持续变化且问题难以穷举的资料。新增文档后重建或增量更新索引即可；同一套资料可以回答不同问法；不需要把所有文档一次性塞进上下文。对于产品文档、内部 Wiki、故障复盘、历史政策、研究资料这类非结构化语料，它通常是比长提示词更可维护的选择。

RAG 的代价来自检索链路本身。它依赖切分、索引和排序，相关资料可能根本没被召回；版本不同的资料可能一起出现；相似的文本未必能回答问题。RAG 还要处理索引更新、来源追溯、权限过滤和评估集维护。资料少、更新慢、问题固定时，这些成本未必值得。

适用范围可以概括为：“我不知道用户会问什么，但资料库里可能有答案。” 这时应先考虑 RAG；如果数据是实时且结构化的，先考虑 API 或数据库查询。

Skill 的优点、代价和适用范围

Skill 的优点是把流程、模板和工具使用方式组织成完整能力包。模型不必每次从零理解任务，也不必把所有工作说明常驻在系统提示词里。它适合重复发生、边界相对稳定、需要遵守步骤和验收要求的任务，例如生成周报、处理退款工单、发布服务、审查代码、制作表格。

它的代价是维护流程本身。Skill 的描述要能让模型正确触发；正文不能只写理想路径，还要覆盖前置条件、异常、停止和交接；依赖的工具、脚本、模板改动后需要一起回归。Skill 数量变多后，重复职责和相互冲突也需要治理。把每份业务文档都封装成 Skill，只会把检索问题变成能力目录的维护问题。

适用范围可以概括为：“这类事会反复做，而且做法可以说明白。” 如果每次任务都要临时查大量、变化的资料，Skill 自身不够，需要配合 RAG 或查询工具。

一个任务里怎么配合

处理故障工单是一个常见组合。Skill 先规定任务骨架：确认服务和时间范围，查询监控与变更记录，区分已知故障和未知故障，输出影响、证据、处置和待确认项。执行到“查询监控与变更记录”时，再调用监控、发布系统，或者从运行手册和事故复盘里检索证据。

Skill 还可以规定证据的使用方式：优先采用带时间和来源的记录；监控数据和文档冲突时标记冲突；证据不足时列出待确认项并停止推断。这样，Skill 约束的是怎么工作，RAG 和工具提供的是工作时要用的事实。

两者组合后，排查也能分开做。回答缺少事实、引用过期内容、召回了无关段落，优先看 RAG 和查询链路。漏做资格检查、调用顺序错误、异常后继续执行，优先看 Skill 和工具编排。金额上限、数据范围、审批这类问题，不管 RAG 或 Skill 写得多完整，都要回到系统权限和后端规则。

业务 Agent 和 AI Coding 场景的差异

三层的职责划分不变，但每一层在两边的实现不同。

检索的形态不同。 业务 Agent 的检索通常是前置管道：切分、索引、召回、重排在生成回答之前完成，模型拿到的是系统选好的片段。AI Coding 场景里，模型更多通过 grep、读文件、沿调用链追踪来自己获取事实，检索嵌在执行循环中，每一步查什么由前一步的结果决定。代码事实以仓库本身为准，向量索引在这个场景里更多用来找入口，不是主要的获取路径。

Skill 装的内容不同。 业务 Skill 以流程为主，事实大多留在外部系统里。Coding 场景的 Skill 和规则文件经常同时装项目事实和做法：目录约定、URL 生成规则是事实，校验命令、提交流程是做法。两者写在一起时可以接受，但要按更新频率区分维护方式：做法相对稳定，项目事实随仓库变化，Skill 里写的事实越多，过期越快。

强制层和反馈条件不同。 业务 Agent 的强制层是后端权限、审批和额度，回答错了没有低成本的兜底：客服答错、退款审错，只能事后发现，所以流程要一次写全，约束要进系统。Coding 场景的强制层是 hooks、linter、typecheck 和测试，执行反馈来自工具运行结果：测试失败、构建报错会立刻暴露问题，Agent 还能据此自己修正。因此 Coding 的 Skill 可以少写一部分异常分支，把完整性交给反馈回路；业务 Agent 没有这种反馈，前置条件和停止条件不能省。

事实过期的原因不同。 业务事实随政策和活动变化；Coding 场景里代码每天都在被改，事实过期更快。所以承载代码知识的 Skill 更适合写“去哪查、怎么判断”，少写“当前是什么”。

组件库知识的分层放置

组件库的用法是一个典型的混合案例：一部分适合 Skill，一部分不适合。

适合放进 Skill 的是选择和组合规则：什么场景用哪个组件，Table 和 List、Modal 和 Drawer 怎么取舍；项目级约束，如主题 token、禁用的属性、必须走的封装组件；以及高频配方，如表单加校验加提交的标准写法。这部分重复发生、说得清楚，选中后完整读取的成本值得付。

不适合塞进 SKILL.md 正文的是长尾 API 细节：每个组件的全部属性、边界行为、版本变更记录。一个几十个组件的库，完整 API 文档可能有几万 token。全量放进 Skill 有两个后果：每次触发都要为这次用不到的细节付上下文成本；库升级之后，这些细节是 Skill 里最先过期的部分。

长尾部分有三种放法，按规模选择：

1. Skill 目录内的参考文件。 SKILL.md 只放选择规则和高频用法，每个组件的细节拆成同目录的参考文件，模型用到哪个读哪个。适合单个库、组件数量可控的情况，本质是用目录结构代替检索。
2. MCP 或 CLI 查询层。 按组件名精确查询属性、示例和版本说明。组件名是精确的，不需要语义匹配，这对应前面表格里“业务 API 或结构化查询”一行。
3. RAG。 跨多个库、版本碎片化、问法模糊（“哪个组件能实现带虚拟滚动的穿梭框”），或者要检索散落在各仓库里的使用先例时，选集大、问题开放，才需要向量检索。

三种放法对应的仍是同一个判断：取舍规则是做法，放 Skill；单个 API 的行为是可精确查询的事实，放查询层；跨库的开放问题和先例检索，才轮到 RAG。把组件文档全部向量化，等于把“查某个组件的属性”这个确定性问题变成召回率问题。

结尾

RAG 和 Skill 都在给 Agent 补充模型参数之外的信息，但它们不是同一种组件。RAG 管的是“查到什么”，Skill 管的是“怎么做”，工具和后端管的是“能不能做”。

如果只是回答开放问题，先看资料是否适合检索；如果要完成一项重复任务，先看流程能不能写清；如果操作会修改数据或产生风险，先把限制放到系统里。把这三件事分开，RAG、Skill、工具和权限的职责才不会互相挤占。

三层划分不变，变的是每层的实现：检索是前置管道还是模型在执行中主动进行，约束靠后端拦截还是靠测试与构建的反馈兜底，要按场景提供的反馈条件来定。