做本地知识库时,RAG、Agent、MCP 怎么分工

发布时间:2026/7/24 19:37:58
做本地知识库时,RAG、Agent、MCP 怎么分工 文章目录1. 常见混淆2. 结论3. 同一场景里各自干什么3.1 RAG3.2 Agent3.3 MCP4. 边界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 MCPMCP 不负责“想出答案”而是连接文档库之外的能力代码仓库、本地文件、数据库、工单尽量让这些能力可被发现和复用解决的是外部能力怎么接进来不是这一次要不要调用。只有一个应用、几个写死工具时应用内 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任务规划、回环、校验与编排MCPAI 应用更统一地连接外部能力的协议层Function calling模型这一轮发起工具调用的机制Agentic RAG把 Agent 能力加进检索增强流程后的形态MCP 基础概念MCP 到底是什么为什么它突然火了。10. 小结RAG私有知识怎么被取到Agent复杂任务怎么推进MCP外部能力怎么接入和复用多数项目不是“三个一起上”而是先让检索可用再按复杂度加编排真正需要外部系统时再接工具层。11. 相关内容上一篇可以从这里回看RAG 过时了吗为什么 Agentic RAG 又火了如果后面继续写相关主题也可以再展开知识库里的权限和人工确认点该怎么放。如果这篇帮你把三个易混角色分开了欢迎点赞、收藏也欢迎关注后续更新。