夜雨聆风AI 四大热门概念深度解析：Agent、RAG、Skill、MCP 究竟是什么？
╔══════════════════════════════════════════════════════╗
║ ║
║ 🤖 AI 技术四大热门概念 ║
║ ║
║ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ║
║ │Agent│ │ RAG │ │Skill│ │ MCP │ ║
║ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ ║
║ │ │ │ │ ║
║ └────────┴────────┴────────┘ ║
║ │ ║
║ 构建完整 AI 应用 ║
║ ║
╚══════════════════════════════════════════════════════╝
最近跟几个朋友聊天，发现大家对 Agent、RAG、Skill、MCP 这些词都很陌生，或者是一知半解。今天我就用大白话把这些概念讲清楚，保证你看完就能跟人侃侃而谈。
前言：为什么突然冒出这么多新概念？
说实话，刚开始接触这些概念的时候，我也是一头雾水。大语言模型（LLM）出来的时候，我以为那就是终点了。结果没过多久，各种新名词就开始满天飞。
后来我慢慢想明白了：LLM 就像一个"大脑"，但光有大脑是不够的。
┌─────────────┐
│ LLM │
│ (大脑) │
└─────────────┘
⬇
只能回答问题，不能做事
加上这些后：
┌─────────────────────────────┐
│ │
│ 🧠 大脑 (LLM) │
│ 🤲 工具 (MCP) │
│ 📚 知识 (RAG) │
│ 📋 技能 (Skill) │
│ │
│ = AI Agent │
│ (能干活的助理) │
└─────────────────────────────┘
想象一下，如果一个人光有大脑，但没有手、没有脚、没有记忆、没有工具，他能干什么？顶多就是坐在那里回答问题。但现实中的需求可不止这些：
你希望 AI 能主动帮你做事，而不是被动回答问题 你希望 AI 能基于你的公司文档、个人笔记来回答问题 你希望 AI 能稳定地完成某项专业任务 你希望 AI 能调用各种外部工具和服务
这些需求催生了 Agent、RAG、Skill、MCP 这些技术。它们不是互相竞争的关系，而是互相补充，共同构建一个完整的 AI 应用生态。
下面我逐个给大家讲清楚。
一、Agent：从"问答机器人"到"智能助理"
什么是 Agent？
先讲个真实的对比。
之前我用普通的 ChatBot，问它："帮我排查一下线上 OOM 问题"，它只会给我一些通用的排查建议，比如"查看日志"、"分析堆栈"之类的。
但后来我用了一个基于 Agent 的系统，效果完全不一样：
我：帮我排查一下线上 OOM 问题
Agent：[自动执行]
1. 查询最近 1 小时的错误日志 ✓
2. 找到 3 条 OOM 记录，堆栈指向 UserService.batchQuery() ✓
3. 读取该方法的源代码 ✓
4. 查询最近的代码变更记录 ✓
5. 分析完成：根因是 batchQuery() 方法中存在未分页的全量查询
这就是 Agent 和普通 ChatBot 的区别：
普通 ChatBot：你问一句，它答一句，像个被动的客服 Agent：你给它一个目标，它能自己规划步骤、调用工具、调整策略，直到完成任务
Agent 的四大核心能力
1. 规划能力
Agent 能把复杂任务拆解成可执行的步骤。比如"分析用户流失原因"，它会拆解成：
查询用户数据 分析流失趋势 找出影响因素 给出改进建议
2. 记忆能力
Agent 记得住两件事：
短期记忆：当前对话的上下文 长期记忆：跨会话的信息，比如用户的偏好、历史经验
3. 工具调用
Agent 能调用各种工具：
搜索引擎 数据库 API 接口 文件系统
4. 自我调整
执行过程中发现问题能自动修正方向，不会一条路走到黑。
Agent 的核心架构
┌─────────────────────────────────────────┐
│ Agent 核心架构 │
├─────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ LLM │ ◄──► │ 规划 │ │
│ │ 大脑 │ │ 模块 │ │
│ └──────────┘ └──────────┘ │
│ ▲ ▲ │
│ │ │ │
│ ┌─────┴─────┐ ┌──────┴──────┐ │
│ │ 记忆 │ │ 工具 │ │
│ │ 模块 │ │ 模块 │ │
│ └───────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────┘
LLM 大脑：负责推理和决策规划模块：负责任务拆解和执行策略记忆模块：提供上下文管理工具模块：提供与外部世界交互的能力
实际应用场景
运维 Agent：自动排查线上故障
用户任务：排查线上故障
↓
1. 查询错误日志
2. 分析堆栈信息
3. 定位代码位置
4. 查看代码变更
5. 生成分析报告
客服 Agent：处理客户问题
用户任务：处理退款申请
↓
1. 理解用户诉求
2. 查询订单信息
3. 检查退款政策
4. 办理退款手续
5. 通知用户结果
二、RAG：让 AI 说的每句话都有据可查
什么是 RAG？
RAG（Retrieval-Augmented Generation），中文名叫"检索增强生成"。
名字听着挺学术，其实原理特别简单：先找资料，再给答案。
就像学生考试，开卷考试的时候，你会先翻书找相关知识点，然后基于这些内容来回答问题。RAG 就是让 AI 做同样的事情。
为什么需要 RAG？
LLM 有三个天生的短板：
举个真实的例子：
不用 RAG：
我：我们公司的请假流程是什么？
LLM：一般来说，公司请假流程是...
（给出一套通用的、可能完全错误的流程）
用 RAG：
我：我们公司的请假流程是什么？
RAG：[检索到《员工手册》第三章]
根据公司《员工手册》第三章规定：
1. 员工请假需提前 3 天提交申请
2. 1 天以内由直属主管审批
3. 3 天以内需部门经理审批
4. 3 天以上需总经理审批
来源：员工手册.pdf（2024年版）
RAG 的完整工作流程
RAG 分为两个阶段：离线索引和在线检索。
阶段一：离线索引（准备工作）
┌─────────────────────────────────────────┐
│ RAG 离线索引流程 │
├─────────────────────────────────────────┤
│ │
│ 📄 原始文档 │
│ (PDF, Word, Markdown...) │
│ ↓ │
│ ✂️ 文档切分 │
│ (切成小块，每块 256-1024 token) │
│ ↓ │
│ 🔢 向量化 │
│ (文字 → 数字向量) │
│ ↓ │
│ 💾 存入向量数据库 │
│ (可快速检索) │
│ │
└─────────────────────────────────────────┘
为什么需要切分？
想象一下，你要在图书馆找资料。如果整本书当成一个单元，检索的时候要么整本都相关，要么都不相关，这显然不合理。
所以要把文档切成合适大小的块，每个块包含一个完整的意思。通常一块 256-1024 个 token 比较合适。
什么是向量化？
简单说，就是把文字转换成数字。但这个转换不是随机的，而是语义相近的文本在向量空间中距离也相近。
语义空间示意图：
🍎 苹果 ────── 🍐 水果
│ │
│ │
└─────┐ ┌───┘
│ │
🚗 汽车
距离近 = 语义相近
为什么需要切分？
想象一下，你要在图书馆找资料。如果整本书当成一个单元，检索的时候要么整本都相关，要么都不相关，这显然不合理。
所以要把文档切成合适大小的块，每个块包含一个完整的意思。通常一块 256-1024 个 token 比较合适。
什么是向量化？
简单说，就是把文字转换成数字。但这个转换不是随机的，而是语义相近的文本在向量空间中距离也相近。
比如"苹果"和"水果"的距离，会比"苹果"和"汽车"的距离更近。
阶段二：在线检索（实际使用）
┌─────────────────────────────────────────┐
│ RAG 在线检索流程 │
├─────────────────────────────────────────┤
│ │
│ 👤 用户: "请假怎么申请？" │
│ ↓ │
│ 🔢 问题向量化 │
│ ↓ │
│ 🔍 向量检索 │
│ (找最相似的 K 个文档块) │
│ ↓ │
│ 📊 检索结果: │
│ • 员工手册 第三章 (相似度 0.92) │
│ • 请假制度说明 (相似度 0.87) │
│ • OA 操作指南 (相似度 0.75) │
│ ↓ │
│ 🤖 LLM 生成答案 │
│ (基于检索到的文档) │
│ ↓ │
│ 💬 返回带来源的回答 │
│ │
└─────────────────────────────────────────┘
RAG 进阶技巧
实际用起来，基础版 RAG 效果往往不够理想。这里有几个优化技巧：
1. 查询改写
用户的提问可能表述模糊，直接检索效果不好。可以用 LLM 先改写一下。
原始查询：请假怎么操作
↓
改写后：
1. 员工请假审批流程步骤
2. 年假事假病假申请方式
3. OA系统请假操作指南
2. 混合检索
向量检索擅长语义理解，但在精确匹配（如错误码、方法名）时效果不佳。混合检索结合了向量检索和关键词检索：
向量检索结果 + 关键词检索结果
↓
【融合】用算法合并两路结果
↓
最终结果
3. 重排序
检索出的文档不一定都相关。可以用更精确的模型重新排序，过滤掉噪声文档。
检索到 10 个文档
↓
【重排序】用更精确的模型打分
↓
保留最相关的 3-5 个
RAG vs 微调
这是个经常被问到的问题。简单总结一下：
一句话建议：
如果你想让 AI "知道更多东西" → 用 RAG 如果你想让 AI "用特定方式说话" → 用微调 如果两者都需要 → RAG + 微调一起上
三、Skill：给 AI 装上"专业技能包"
什么是 Skill？
直接跟 LLM 对话有个大问题：不稳定。
同一个任务，换个问法、换个时间，结果可能完全不一样。这在生产环境中是不可接受的。
Skill 的价值：把最佳实践固化下来
┌─────────────────────────────────────┐
│ Skill 的构成 │
├─────────────────────────────────────┤
│ • 精心设计的 Prompt 模板 │
│ • 预绑定的专业工具 │
│ • 明确的输入输出规范 │
│ • 可独立测试和迭代 │
└─────────────────────────────────────┘
用一个类比：如果 Agent 是一个"全能员工"，那 Skill 就是这个员工掌握的"标准作业流程（SOP）"。
Skill 的实际例子
代码审查 Skill：
输入：代码变更（diff 格式）
↓
执行流程：
1. 检查安全性问题
2. 检查性能问题
3. 检查可维护性
↓
输出：结构化的审查报告
{
"issues": [
{
"severity": "Critical",
"line": 42,
"description": "存在 SQL 注入风险",
"suggestion": "使用参数化查询"
}
],
"summary": "发现 1 个严重问题",
"approval": false
}
文章写作 Skill：
输入：主题和要求
↓
执行流程：
1. 拟定文章大纲
2. 撰写各部分内容
3. 检查质量和格式
↓
输出：符合规范的文章
Skill 与其他概念的区别
这几个概念经常被混淆：
Function Calling 是最底层的调用机制Plugin 是对工具的封装Skill 是在 Plugin 之上加入了领域知识和执行策略
Skill 在 Agent 中的应用
用户输入
↓
【意图识别】判断用哪个 Skill
↓
【参数提取】提取 Skill 需要的参数
↓
【执行】用 Skill 的专业流程处理
↓
返回结果
这种模式的好处是：通用对话和专业任务分离。
遇到有 Skill 的任务，就用 Skill 的高质量流程；遇到没有 Skill 覆盖的任务，就用通用能力兜底。
四、MCP：AI 世界的"USB 接口"
什么是 MCP？
MCP（Model Context Protocol），中文名叫"模型上下文协议"。
名字听着很抽象，其实就是 AI 世界的"USB 接口"。
有了这个标准，任何工具都可以用统一的方式接入任何 AI 应用。
MCP 要解决什么问题？
在 MCP 出现之前，想让 AI 调用外部工具：
没有 MCP 的时代：
AI应用1 ━━━━ GitHub
┃ ┃
┃ ┃
AI应用2 ━━━━ Slack
┃ ┃
┃ ┃
AI应用3 ━━━━ 数据库
需要写 3×3 = 9 套适配代码！
这就是 M×N 问题：
M 个 AI 应用 N 个工具 需要 M×N 个适配器
有了 MCP：M+N
有了 MCP：
AI应用1
┃
┏━━┻━━┓
┃ MCP ┃
┗━━┳━━┛
┃
┌─────┼─────┐
┃ ┃ ┃
GitHub Slack 数据库
每个工具只需实现一次 MCP Server！
每个 AI 应用只需实现一次 MCP Client！
每个工具只需实现一次，所有 AI 应用都能用！
MCP 的三种能力
MCP Server 可以提供三种类型的能力：
MCP 的架构
┌────────────────────────────────────────┐
│ MCP 架构 │
├────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Host │ ◄──► │ Client │ │
│ │ (AI应用)│ │ │ │
│ └──────────┘ └─────┬────┘ │
│ │ │
│ │ 协议通信 │
│ │ │
│ ┌─────┴─────┐ │
│ │ Server │ │
│ │ (工具提供)│ │
│ └───────────┘ │
│ │
└────────────────────────────────────────┘
Host：面向用户的 AI 应用（如 Claude Desktop）Client：负责与 Server 通信Server：工具和数据源的提供者
MCP vs OpenAI Function Calling
MCP 的野心更大——它要成为 AI 工具生态的通用标准，就像 HTTP 之于 Web、SQL 之于数据库。
五、四者的关系：一张图讲清楚
讲了这么多，最后用一张图把它们的关系串起来：
用户任务
↓
┌──────────────┐
│ Agent │ ← 自主规划和执行
│ (智能调度) │
└──────┬───────┘
│
├── 需要知识？→ 【RAG 提供资料】
│
├── 专业任务？→ 【Skill 标准流程】
│
└── 调用工具？→ 【MCP 统一接口】
具体案例：智能运维助手
用户：帮我排查 JIRA-1234 这个线上问题
↓
1. Agent 接收任务，规划执行步骤
↓
2. 激活"故障排查 Skill"
↓
3. 通过 MCP 调用 JIRA Server 获取问题详情
↓
4. 通过 MCP 调用日志查询 Server 搜索相关日志
↓
5. 利用 RAG 从代码知识库检索相关源码
↓
6. 综合所有信息，生成根因分析报告
四个概念各司其职，共同完成了一个完整的工作流。
六、技术选型指南：实际项目中怎么选？
场景一：企业知识问答机器人
核心需求：员工查询公司文档、规章制度
推荐方案：RAG 为主
将文档索引到向量数据库，通过 RAG 实现智能问答。
不需要 Agent（单轮问答就够了） 不需要 MCP（不需要调用外部工具）
场景二：AI 编程助手
核心需求：写代码、查问题、做审查
推荐方案：Agent + Skill + MCP
Agent 负责理解和编排 Skill 封装编程最佳实践 MCP 连接 IDE、Git、数据库 可选 RAG 提供项目文档知识
场景三：智能客服系统
核心需求：回答问题、办理业务
推荐方案：Agent + RAG + MCP
RAG 提供产品知识和 FAQ Agent 判断何时需要执行操作 MCP 连接订单系统、CRM Skill 封装常见操作流程
场景四：数据分析助手
核心需求：自然语言查询数据
推荐方案：Agent + MCP
Agent 理解分析需求 MCP 连接数据库执行查询 可选 RAG 存储表结构和业务术语
总结
它们不是竞争关系，而是互补关系，共同构建完整的 AI 应用能力！
┌─────────────────────────────────────────┐
│ AI 应用技术栈全景图 │
├─────────────────────────────────────────┤
│ │
│ ┌───────────┐ │
│ │ Agent │ ← 智能调度 │
│ │ (最上层) │ │
│ └─────┬─────┘ │
│ │ │
│ ┌──────────┼──────────┐ │
│ ▼ ▼ ▼ │
│ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │ RAG │ │ Skill │ │ MCP │ │
│ │ 知识 │ │ 技能 │ │ 连接 │ │
│ └───────┘ └───────┘ └───────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │向量库 │ │Prompt │ │外部API│ │
│ └───────┘ └───────┘ └───────┘ │
│ │
└─────────────────────────────────────────┘
写在最后
刚开始接触这些概念的时候，确实会被各种名词搞得头昏脑涨。但静下心来，逐个搞清楚它们的定位和关系，就会发现整个设计其实挺合理的。
技术发展从来不是一蹴而就的。每个新概念的出现，都是为了解决某个具体问题。理解了问题背景，理解起来就容易多了。
如果你在看这篇文章的时候，有些地方还是不太明白，没关系。多在实际项目中用一用，慢慢就有感觉了。
实践是最好的老师。
参考资料：
Anthropic MCP 官方文档 LangChain Agent 文档 RAG 论文（Lewis et al., 2020） OpenAI Function Calling 文档
本文首发于微信公众号，欢迎转载，请注明出处。 如果觉得有帮助，欢迎点赞、在看、分享给更多朋友。
关注我，获取更多 AI 技术干货！ 🚀
