文章目录
- 1. 常见混淆
- 2. 结论
- 3. 同一场景里各自干什么
- 3.1 RAG
- 3.2 Agent
- 3.3 MCP
- 4. 边界
- 5. 工作流
- 6. 按痛点决定先建哪一层
- 7. 落地顺序
- 8. 常见误区
- 8.1 三个词当成同一件事的三种叫法
- 8.2 一上 Agent，就默认 RAG 可以随便做
- 8.3 一要接仓库和数据库，就先研究协议细节
- 8.4 追求“全都有”，却说不清每层解决什么
- 9. 术语速查
- 10. 小结
- 11. 相关内容
摘要：搭本地知识库时，容易卡住的不是选哪个向量库，而是把 RAG、Agent、MCP 混成一件事。本文按角色拆开：谁取信息，谁决定下一步，谁接外部能力。适合做过基础 RAG、开始接触 Agent 或 MCP 的读者。读完应能判断：先补检索、先加编排，还是先接工具。
说明：承接 RAG 过时了吗，为什么 Agentic RAG 又火了，并把 MCP 与 function calling 放回同一套知识库图景。侧重分工，不讲框架安装。
1. 常见混淆
团队内部知识库的需求通常是：
- 能问文档、接口说明、排障手册
- 复杂问题能多查几轮
- 必要时看代码仓库、工单或数据库
讨论里很快就会出现 RAG、Agent、MCP，然后变成：
反正都是让 AI 更聪明，先全上。
这三个词对应的工作并不相同：
RAG 取信息，Agent 做决策，MCP 连工具。
图1. 名字都热，职责不同。
2. 结论
- RAG：把私有知识变成可检索、可引用的证据。
- Agent：判断下一步做什么——再查、再验证，还是调工具。
- MCP：用更统一的方式，把文件、仓库、数据库等能力接进 AI 应用。
- 不必三者齐备；按痛点叠加。
顺序通常是：先让知识能被正确取到 → 再加编排 → 最后接外部系统。
3. 同一场景里各自干什么
问题示例：
支付回调最近总超时，按现行文档和最近变更，先查哪几处？还要看仓库配置吗？
3.1 RAG
- 从制度、接口文档、变更说明、故障案例里找出相关片段
- 把片段作为回答依据交给后续流程
解决的是：模型参数里没有的私有信息，怎么拿进来。
若问题只是“回调签名字段叫什么”，到 RAG 通常就够了。
3.2 Agent
- 判断一次检索够不够
- 要不要拆成：现行超时配置、最近变更、已知故障
- 证据不够时要不要再查
- 要不要去代码仓库核对
解决的是：流程怎么推进，不是单次检索本身。
上一篇的 Agentic RAG，就是把这类决策加进检索增强流程。
3.3 MCP
MCP 不负责“想出答案”，而是：
- 连接文档库之外的能力：代码仓库、本地文件、数据库、工单
- 尽量让这些能力可被发现和复用
解决的是：外部能力怎么接进来，不是这一次要不要调用。
只有一个应用、几个写死工具时，应用内 function calling 往往就能跑通；
工具多、客户端多、要复用时，MCP 才更有存在感。
层次差别见：MCP 和 function calling 的差别。
图2. 先分清职责，再决定补哪一层。
4. 边界
| 角色 | 解决什么 | 典型产出 | 单独做不到的事 |
|---|---|---|---|
| RAG | 私有知识如何被检索和引用 | 文档片段、证据上下文 | 复杂任务的多步规划 |
| Agent | 下一步做什么、何时停止 | 计划、重试、校验、工具选择 | 替代扎实的检索质量 |
| MCP | 外部能力如何被接入和复用 | Server / 工具 / 资源连接 | 自动提高文档召回率 |
补充：Function calling 更靠近“这一次怎么调用”；MCP 更靠近“能力怎么组织进应用”。两者常一起工作，不是互相替换。
5. 工作流
- 用户提问
- Agent 判断：简单查找，还是需要拆解
- 需要文档证据 → RAG 检索
- 证据不足 → Agent 换查询或补检索
- 还需要仓库、日志、数据库 → 工具层（MCP 或应用内工具）
- Agent 汇总证据后回答，必要时留引用
图3. Agent 编排；RAG 提供私有证据；MCP / 工具接文档库之外的能力。
好处是定位清楚：检索差、编排差，还是工具没接好；也可以按阶段建设，不必第一天就上完整平台。
6. 按痛点决定先建哪一层
| 痛点 | 优先补什么 | 原因 |
|---|---|---|
| 简单问题都答不准，引用经常跑偏 | 先做 RAG | 证据层不稳，加 Agent 只会更忙地用错材料 |
| 单次问答还行，跨文档综合就翻车 | 给 RAG 加 Agent 回环 | 需要拆问题、多步取证 |
| 文档够用，但还要看代码 / 工单 / 库表 | 再接工具层 | 已超出纯文档检索 |
| 工具在单个应用里写死，换客户端就要重做 | 再看 MCP | 复用和标准化开始值钱 |
| 只有一个客户端、几个固定 API | 先 function calling | 不必为热词提前上协议复杂度 |
图4. 顺序服从任务复杂度，不服从热词发布时间。
检索没过关之前，不要急着做成很重的 Agent 平台。
7. 落地顺序
- 定义问题类型：FAQ、手册查找、排障综合，还是要动外部系统
- 把文档切片、索引、召回和引用做稳（RAG）
- 用错误案例判断要不要加多步编排（Agent）
- 确认哪些动作必须离开文档库（代码、日志、工单、数据库）
- 决定工具怎么接：少量固定工具用应用内调用；要复用再看 MCP
- 再谈权限、审计、人工确认点
图5. 从上到下：任务 → 编排 → 证据 → 外部能力。
8. 常见误区
8.1 三个词当成同一件事的三种叫法
不是。复杂知识库会同时需要取信息、做决策、连工具，不等于三者等价。
8.2 一上 Agent，就默认 RAG 可以随便做
反过来。Agent 会放大坏检索的成本：更频繁地基于错误证据继续行动。
8.3 一要接仓库和数据库，就先研究协议细节
先问：
- 是不是真需要这些外部能力
- 是不是只有一个应用在用
- 有没有复用和统一接入的压力
没有这些压力时，先把调用跑通，比先背协议划算。
8.4 追求“全都有”，却说不清每层解决什么
能画清分工，比先把名词堆进架构图重要。
9. 术语速查
| 术语 | 本文用法 |
|---|---|
| 本地知识库 | 面向团队或个人私有文档的检索与问答系统 |
| RAG | 检索增强生成，提供私有证据 |
| Agent | 任务规划、回环、校验与编排 |
| MCP | AI 应用更统一地连接外部能力的协议层 |
| Function calling | 模型这一轮发起工具调用的机制 |
| Agentic RAG | 把 Agent 能力加进检索增强流程后的形态 |
MCP 基础概念：MCP 到底是什么，为什么它突然火了。
10. 小结
- RAG：私有知识怎么被取到
- Agent：复杂任务怎么推进
- MCP：外部能力怎么接入和复用
多数项目不是“三个一起上”，而是：先让检索可用，再按复杂度加编排，真正需要外部系统时再接工具层。
11. 相关内容
上一篇可以从这里回看：RAG 过时了吗，为什么 Agentic RAG 又火了
如果后面继续写相关主题，也可以再展开知识库里的权限和人工确认点该怎么放。
如果这篇帮你把三个易混角色分开了，欢迎点赞、收藏，也欢迎关注后续更新。