一、对比背景：三个高频概念，为什么容易混淆

大模型应用开发的演进路径大致经历了四个阶段：最早是“写好 Prompt”，开发者把所有要求塞进一次性指令；后来出现 RAG（检索增强生成），为模型外挂知识库；再后来 MCP（Model Context Protocol，模型上下文协议）兴起，让模型能够 standardized 地调用外部工具与数据源；近一年左右，Skill（智能体技能，业内也称 Agent Skills）成为社区关注热点，开发者开始把成熟经验打包成可复用的“技能包”。社区中甚至出现了“Prompt 已死、Skill 当立”的说法——这类表述虽有夸张成分，但确实反映出 Skill 正在改变很多人组织上下文的方式。

概念一多，混淆随之而来。实践中常见的选型错误包括：本该用检索解决的知识问题，硬靠堆长 Prompt 解决，导致 Token 爆炸；本该沉淀为技能的固定流程，每次重写一遍，经验无法积累；本该通过协议调用真实系统的操作，靠模型“凭记忆想象”，结果不可靠。本文就将系统对比 RAG、MCP、Skill 三者（并以传统 Prompt 作为参照基线），说清它们分别解决什么问题、差异来自哪里、不同场景下该如何选择。

二、对象定义：三者分别是什么

rag-">1. RAG（检索增强生成）

RAG 的核心思路是“先检索、后生成”：在模型回答之前，先从外部知识库中检索与问题相关的内容，再将其注入上下文供模型参考。一条完整的 RAG 链路通常包括文档解析、切片、向量化与索引、召回、重排、注入生成等环节。它解决的核心问题是：模型训练数据之外的知识从哪来——包括企业私有知识、时效性知识，以及通过“给依据”来降低幻觉。

2. MCP（模型上下文协议）

MCP 是一种开放的模型上下文协议，用于标准化“模型与外部工具、数据源”之间的连接方式，典型架构是客户端—服务端模式：服务端注册一组工具并对外描述其能力，模型根据任务判断调用哪个工具、传入什么参数，服务端执行后返回结果。它解决的核心问题是：模型只能“说”，不能直接触达真实系统——协议把“说”变成“做”，让模型能够查数据库、调接口、触发流程。

agent-skills-">3. Skill（智能体技能 / Agent Skills）

Skill 是把某个领域的完整方法论——执行流程、规范标准、模板示例、辅助脚本——打包成结构化的文件集合。在多数实现中，它就是一个包含说明文档（通常是 Markdown 格式的技能清单）与资源文件的文件夹，例如：

report-skill/                 # 一个"月度报告"技能包的通用示意
├── SKILL.md                  # 技能清单：名称、描述、触发条件、执行流程
├── references/               # 数据口径、图表规范等参考文档（按需加载）
├── templates/                # 报告模板与示例
└── scripts/                  # 可选的数据处理辅助脚本

它的核心机制是渐进式披露（progressive disclosure）：运行时只有技能的名称和一句话描述常驻上下文（开销极小），模型根据任务判断是否命中某技能，命中后才按需加载完整内容：

会话启动
 └─ 仅注入各技能的元数据（名称 + 一句话描述）
用户任务到达
 └─ 模型匹配任务与技能描述
      ├─ 未命中 → 常规对话处理
      └─ 命中   → 按需读取该技能完整文档与资源
                   └─ 按文档中的流程与规范执行任务

4. 参照基线：传统 Prompt

传统做法是每次对话都把系统提示词、few-shot 示例、风格要求、注意事项全部塞进上下文。它的问题很典型：Token 消耗大、风格随会话漂移、调好的经验无法沉淀、复杂任务上下文承载不住。

三、相同点：三者共享的底层逻辑

在谈差异之前，先明确三者的共同点，避免把它们误认为互斥方案：

1. 目标一致：三者都是为了提升模型输出的相关性、稳定性与可控性，让模型更贴合业务需求。
2. 底层逻辑一致：无论检索结果、工具描述还是技能文档，最终都要以文本形式进入模型上下文。因此三者本质上都是“上下文工程”的不同手段，区别只在于管理上下文的层次和方式。
3. 可以组合使用：三者并不冲突。一个典型的智能体应用完全可以同时具备 RAG 提供事实、MCP 执行动作、Skill 约束方法。
4. 都需要工程化治理：版本管理、效果评估、权限控制，三者都逃不开，只是治理重点不同。

四、核心差异：七个维度的深入对比

1. 工作层次不同，回答的问题不同

这是最本质的差异。用“生成月度数据分析报告”这一个任务贯穿来看：

• RAG 在知识层，回答“事实是什么”：提供业务数据口径文档、历史报告原文等依据；
• MCP 在执行层，回答“能对哪些系统做什么”：连接数据库或报表接口，拉取真实数据；
• Skill 在方法论层，回答“这件事应该按什么流程、什么标准做”：沉淀报告结构、分析框架、图表规范、文风要求。

一句话概括：RAG 补“知道”，MCP 补“做到”，Skill 补“做得又快又稳”。

2. 技术形态与部署依赖不同

RAG 需要搭建数据处理与检索链路，涉及文档解析、向量索引、召回服务等组件；MCP 需要部署并维护常驻的服务端进程，处理协议对接、认证配置；Skill 则是静态文件集合，没有运行时服务，放入约定目录即可被识别，部署依赖最轻。

3. Token 消耗与上下文管理方式不同

• RAG：每轮对话注入召回片段，Token 占用与召回数量、片段长度正相关，控制不当会挤占推理空间；
• MCP：工具描述通常需要常驻上下文供模型感知能力边界，注册的工具一多，开销显著，社区实践中数千甚至上万 Token 的工具描述并不罕见；
• Skill：渐进式披露使常驻开销压缩到元数据级别，任务命中才加载全文。有实践者反馈，用 Skill 替换长 Prompt 后，上下文占用可下降 60%~80%——具体幅度因任务而异，但“按需加载优于全量注入”的方向是明确的。

4. 输出一致性不同

RAG 的输出受召回质量波动影响，语料更新或检索抖动都会带来输出变化；MCP 的动作结果本身是确定的，但“何时调用、如何组织结果”仍靠模型自由发挥；Skill 把流程、规范、模板固化下来，不同会话、不同成员使用同一技能时，输出结构与风格高度一致，效果接近“给团队配了统一操作手册”。

5. 接入与配置复杂度不同

RAG 涉及数据链路搭建与检索调优，复杂度中等偏高；MCP 涉及服务部署、协议、认证、接口变更处理，复杂度最高；Skill 只需编写文档、组织文件夹，复杂度最低。

6. 运维成本与故障面不同

RAG 需要持续做语料更新、索引重建、检索效果评估；MCP 需要保障服务可用性、处理接口兼容与版本升级，故障面最大；Skill 主要是内容维护，没有服务宕机风险，故障面最小。

7. 安全关注点与复用性不同

RAG 的风险集中在数据隔离与召回越权；MCP 涉及对真实系统的操作，最小权限、凭证管理、调用审计的要求最高；Skill 的风险主要在内容可信度——来源不明的技能可能携带误导性说明或恶意脚本，脚本执行需要沙箱与权限控制。复用性方面：RAG 偏项目内资产，迁移需搬运语料与管道；MCP 的服务端可跨项目复用但依赖部署环境；Skill 以文件夹为载体，可纳入代码仓库版本化管理，克隆即用，天然适合沉淀为团队资产，也具备产品化潜力。

五、结构化对比表

维度	RAG	MCP	Skill（Agent Skills）
定位层次	知识检索层	工具/数据接入协议层	经验方法论层
解决的问题	模型不知道“事实”	模型够不到“系统与数据”	模型不稳定掌握“怎么做”
技术形态	检索管道 + 索引服务	服务端 + 协议 + 认证	文件夹 + 说明文档
Token 消耗	中（随召回量增长）	较高（工具描述常驻）	低（渐进式按需加载）
输出一致性	中（受召回质量影响）	中（动作确定，组织靠模型）	高（流程规范被固化）
接入复杂度	中高	高	低
运维成本	索引与语料维护	服务运维、接口兼容	以文档维护为主
安全关注点	数据隔离、召回越权	最小权限、审计、凭证	内容可信、脚本沙箱
复用与分享	偏项目内	跨项目，依赖部署环境	仓库化分发，克隆即用
典型场景	知识问答、客服	自动化操作、流程触发	周期报告、规范执行

六、典型场景选择

1. 企业知识问答、智能客服、文档检索：以 RAG 为主。核心矛盾是“模型不知道”，检索是正解。
2. 自动化操作、跨系统工作流：以 MCP 为主。核心矛盾是“模型够不到”，需要协议打通真实系统。
3. 周期性报告、代码评审、文档规范、固定风格写作：以 Skill 为主。核心矛盾是“每次都要重新教”，沉淀技能一次解决。
4. 复合场景：三者组合价值最大。例如自动化运维巡检：Skill 沉淀巡检清单与判断标准，MCP 连接监控与工单系统执行动作，RAG 提供历史故障案例作为参考。
5. 个人效率提升：把高频使用的长 Prompt 逐步沉淀为个人技能库，减少重复输入与风格漂移。

七、选型建议：条件化的决策思路

选型前先诊断瓶颈，建议按“三问”决策：

• 模型缺知识吗？ 缺私有知识、缺时效信息 → 优先 RAG；
• 模型缺通道吗？ 需要操作真实系统 → 优先 MCP；
• 模型缺方法吗？ 任务流程固定、要求稳定复现 → 优先 Skill。

再结合团队与成本条件判断：团队运维能力有限时，可优先考虑 Skill 这类低运维方案，或托管化程度更高的 RAG 服务；Token 成本敏感、任务高频重复时，Skill 的按需加载优势明显；涉及真实系统写操作时，应先补齐 MCP 的权限与审计配套再上线，而非直接投入使用。需要说明的是，无论基于百度智能云等大模型服务平台构建应用，还是自建开源链路，三类机制的定位差异是一致的，可以按同一框架评估平台能力覆盖情况。三者不存在“谁取代谁”的关系——Skill 再成熟，也替代不了检索与执行通道。

八、迁移与使用注意事项

1. 从长 Prompt 迁移到 Skill：先梳理经验中“每次都一样”与“每次都不同”的部分，只把前者沉淀进技能；技能描述与触发条件要写得准确，否则会出现“该加载时不加载”；控制单个技能的粒度，避免“巨型技能”退化回 Token 爆炸。
2. 引入 MCP：精简工具描述、控制注册工具数量以压低常驻开销；坚持最小权限与凭证管理；为接口变更预留兼容策略。
3. 引入 RAG：语料质量优先于算法调优；切片策略与召回质量需要持续评估，而不是一次配置永久生效。
4. 共性事项：建立版本管理与变更评审机制；准备效果评估集，避免“感觉变好了”式迭代；多机制并用时，注意技能文档与工具描述之间不要出现相互冲突的约定。

九、总结

RAG、MCP、Skill 分别工作在知识层、执行层、方法论层：RAG 解决“知道”，MCP 解决“做到”，Skill 解决“稳定地做好”。它们是分层互补关系，而非替代关系。选型的核心不是追问“哪个更先进”，而是回答三个问题：模型缺什么——缺知识、缺通道，还是缺方法？想清楚这一点，再叠加团队能力、Token 预算与合规要求做条件化判断，就能避免在错误层次上用力。随着技能包作为可沉淀、可分享、可版本化的团队资产被越来越广泛地接受，“检索取事实、协议做动作、技能管方法”的组合，正在成为大模型应用工程化的通用范式。