你手上有个需求：让模型能读我们的内部资料，或者让它能直接操作某个系统。搜一圈，一半人说上 RAG，一半人说接 MCP Server，看文档越看越糊。这篇不堆概念，先把两者的边界划清，再按「你的资料在哪、要不要动外部系统」分两条路，各给一套新手能照着走完的步骤，最后补上走不通时换哪套打法。
你手上有个需求：让模型能读我们的内部资料，或者让它能直接操作某个系统。搜一圈，一半人说上 RAG，一半人说接 MCP Server，看文档越看越糊。这篇不堆概念，先把两者的边界划清，再按「你的资料在哪、要不要动外部系统」分两条路，各给一套新手能照着走完的步骤，最后补上走不通时换哪套打法。
提前说一句：下面所有流程都只讲顺序和判断标准，不给你任何具体数字。选型时真正该看的指标（延迟、命中率、每次调用成本）会随时间和你自己的数据变，拿不准就先去站内核对当时的值，再回来做决定。
先分清两者各管什么
别被名字唬住，本质区别就一句：RAG 是「读」，MCP Server 是「做」。RAG 把资料切片、检索、塞进上下文，模型看完再回答，全程对外部世界没有任何影响；MCP Server 把工具能力按协议暴露给模型，模型能去查库、发请求、改状态，动作一旦发出去就收不回来。
| 维度 | RAG | MCP Server |
|---|---|---|
| 核心动作 | 检索后阅读 | 调用工具执行 |
| 有无副作用 | 基本没有 | 可能有，写操作尤其要小心 |
| 适合的答案在哪 | 在已有文档里 | 在某系统里现查或现算 |
| 出错代价 | 答错一句话 | 可能改错数据、下错单 |
| 起步门槛 | 清洗 + 切片 + 检索闭环 | 工具定义 + 传输 + 权限收口 |
判断口诀：答案在文档里就先想 RAG，答案要去某个系统里现查、或者要执行操作才想 MCP。但两者不互斥，很多实际场景是 MCP 里挂一个检索工具，把 RAG 当工具用。新手先别急着二选一，按下面三步走一遍再定。
三步判断该走哪条路
这三步是有顺序的，前一步能排除掉就不要再往后想。每一步都给了一个「什么情况下不适用」的反例，别拿自己的场景硬套。
- 第一步：看资料形态静态文档、手册、FAQ 这类固化内容，RAG 更省事；实时库存、订单状态这类必须现查的，走 MCP 或直接包一层接口。反例：资料是固定几条 SOP，那连检索都不用。
- 第二步：看是否需要副作用只读就 RAG 起步成本最低；要写、要下单、要改状态，必须有 MCP 或工具调用那一层，光靠检索做不了。反例：需要「查完之后人再确认」，那就把写操作拆成建议 + 人工执行。
- 第三步：看更新频率一天改几次的用检索现查；一年不动的直接塞进提示词更划算。反例：内容更新很少但体量巨大，塞不进上下文，那还是得走检索。
三步都走完，你会得到两个结论之一：要么「只读 + 文档型」，走 RAG；要么「要执行 + 系统型」，走 MCP。两个都占，就先上 RAG，等确认模型真需要动手时再补 MCP 那一层，别一上来就双线开工。
走 RAG：新手最小流程
先给结论：RAG 做不好，八成问题出在进料和切片，不在模型。所以流程里清洗和验收这两步千万别省，省下来的时间后面都要加倍还回去。
- 整理进料：把 PDF、扫描件、表格清洗成干净文本，脏数据进去检索一定差
- 切片段落化：切片长度按文档结构定，别按字数硬切，标题和正文尽量别拆开
- 接问答：检索 top-k 拼进提示词，要求模型只基于检索内容回答，答不了就说不知道
- 验收：自己准备二十来条真实问题跑一遍，看命中率和乱答率，别只看能不能出话
验收时重点看两类失败：一类是「没检索到正确片段」，那回去查清洗和切片；一类是「检索到了但模型乱答」，那调提示词、加引用约束。这两类混在一起看，很容易白调半天。想对延迟和成本有个底，去站内的 /price-watch 页面核对当时的数字再决定链路长度。
替代方案：文档量小、结构规整时，直接全文塞上下文或关键词检索可能就够，不必上向量库。关键词检索在专有名词多的场景里表现往往比想象中好，而且几乎没有额外组件要维护。
走 MCP Server：新手最小流程
MCP 这边最容易犯的错是「先搭架子再想工具」。正确的顺序反过来：先把工具设计清楚，再挑传输方式，最后收权限。工具定义含糊，接多好的客户端都白搭。
- 定工具粒度一个工具做一件事，参数写清类型和必填项，别做万能大工具。验证方法：把工具描述单独给一个没参与开发的同事看，他能看懂就算过关。
- 选传输方式本机调试用本地进程方式，跨机器共享再考虑 HTTP 那套，别一上来就搞远程。验证方法：能在本地用固定参数跑通一次调用，再谈共享。
- 权限收口给 MCP Server 的账号只开必要权限，写操作先做到可回滚或加人工确认。验证方法：故意触发一次越权操作，看它是否被拦住。
- 验收先用固定参数手工触发一次工具调用，确认返回结构稳定，再让模型自由调。返回结构飘忽的话，模型会把错误结果当成事实。
替代方案：只有一个固定接口要调，直接写工具调用比上 MCP 简单。MCP 的价值在多工具、多客户端复用；你只有一个客户端、一个接口，用协议就是给自己加层维护成本。想找现成的客户端和目录，可以去 /tools 分类翻一翻，比自己造轮子快。
走不通时换什么
两条路都可能卡住，卡住时先别推翻重来，按下面这张表定位，大部分问题在链条前段就能解决。
| 症状 | 先查什么 | 换什么方案 |
|---|---|---|
| 检索答不准 | 切片和清洗 | 关键词混合检索或重排，别先换模型 |
| MCP 连不上 | 传输方式、命令路径 | 换成本地进程方式先跑通 |
| 调用报权限错 | 账号权限范围 | 缩小权限，或加人工确认环节 |
| 成本压不住 | 调用频次和链路长度 | 高频固定问答做缓存 |
| 团队没人维护 | 组件数量 | 换开箱工具，别自己发明协议 |
- 卡在检索质量：先人工看二十条失败案例的原始片段，八成能直接看出问题
- 卡在连接失败：按传输方式、命令路径、权限三处依次排查，多数问题在前两处
- 卡在效果不稳：把每次调用的输入输出记下来，拿固定样本回放对比
- 卡在没人懂：换现成方案，宁可少点定制也别留一个没人维护的组件
最后提醒一句，选型是迭代出来的，不是一次定终身。先跑通最小闭环，记录失败样本，再根据实际情况增删组件。资料和工具本身在变，方案也跟着变，定期回来对一遍判断标准比纠结选哪条路更有用。
下一步实际选型前，建议先去站内工具目录看现有方案的形态，再对照价格追踪页核对当时的调用成本，把账算清楚再开工。→常见问题
只想让模型回答内部文档的问题，是不是一定要上 RAG？
不一定。文档总量不大、更新少，直接整理成提示词或一次性塞上下文就能跑；只有资料多到塞不下、或者要频繁更新时才值得上检索链路。先用手工方式跑通效果，再决定要不要工程化。
MCP Server 能不能替代 RAG？
替代不了，方向不同。MCP 是让模型能调用外部能力，检索只是其中一种工具；RAG 是一套围绕资料检索的做法。真要组合，常见做法是把检索包装成 MCP 工具暴露出去，模型需要查时再调。
两条路都想要，先做哪个？
先做能把效果验证出来的那个。通常先搭 RAG，因为资料和问题都在自己手上，一两天能看出准不准；MCP 涉及权限和外部系统，沟通成本高，等检索这条跑顺、确认模型确实需要动手再上。
