rag、mcp和agent到底是个啥

你大概遇到过这种场面：方案文档里 RAG、MCP、Agent 三个词混着出现，看完还是不知道代码该从哪写起。有人说要上 Agent，有人说先做 RAG，还有人说 MCP 是标准。这篇不讲玄学，只做一件事——三者放到同一张系统图里，标清楚谁负责取资料、谁负责接外部能力、谁负责做决策，再给你一套判断顺序，看完能决定自己这个需求到底需要几个。

你大概遇到过这种场面：方案文档里 RAG、MCP、Agent 三个词混着出现，看完还是不知道代码该从哪一行写起。有人说要上 Agent，有人说先做 RAG，还有人说 MCP 才是标准。这篇不讲玄学，只做一件事——把三者塞进同一张系统图里，标清楚谁负责取资料、谁负责接外部能力、谁负责做决策，再给你一套判断顺序。

看完你至少能回答两个问题：我这个需求到底需要几个？先写哪一层？判断不了的，去站内对照当时的资料和价格再定，别靠感觉拍。

为什么这三个词老被搅在一起

混淆的根源是它们的出身不一样。RAG 从搜索和问答那边长出来，动机是「模型不知道我的资料」；MCP 从工具接入这边长出来，动机是「每家都自己写一套接口太乱」；Agent 从自动化编排那边长出来，动机是「流程要自己走完，别每步都等人点」。三个动机本来就不重叠，只是近两年被同一批人写进同一份方案里。

另一个原因是它们经常同时出现在一篇宣传稿里，读起来像是三个可以互相替代的选项。实际上它们分属不同层：一个管资料，一个管能力接入，一个管决策和循环。你可以只用其中一个，也可以用三个，互相不冲突。

判断方法很简单：先问自己缺的是「模型不知道的事」、「模型够不到的系统」，还是「没人盯着也得自己跑完的流程」。答完基本就定了，不用把三个词摆一起纠结。

一张图看懂三者的位置

把一次请求画成一条链：用户提问 → 决策方决定下一步 → 取资料或调工具 → 汇总成回答。RAG 只占「取资料」那一段，MCP 只占「怎么把工具接进来」那一段，Agent 是串起整条链、决定下一步走哪的那个角色。位置不同，改的代码也不同。

各自的最小形态可以这样记：RAG 是「检索一段文本，拼进上下文」；MCP 是「一份统一的工具描述，让调用方知道有哪些工具、参数长什么样」；Agent 是「一个带循环和停止条件的调用流程」。三者都能单独跑起来，不需要另外两个配合。

资料层

负责把私有资料找出来，塞进模型看得见的地方

能力层

负责把外部系统按统一约定暴露成模型可调用的工具

决策层

负责判断下一步该查资料、该调工具，还是该停下来回答

图层关系里有个容易记反的点：Agent 可以调用 RAG，也可以走协议去调工具；但反过来，RAG 和工具接入单独成立，不需要 Agent 也能跑。所以不存在「上了 Agent 就自动有 RAG」这回事。

RAG 的位置：让模型看到私有资料

它解决的是知识边界问题，跟模型聪不聪明没关系。资料没进检索库，模型只能编或者拒答，提示词再怎么调也变不出你的内部文档。反过来说，模型换一个，只要检索这一段没坏，回答质量通常不会崩。

落地时最容易出问题的往往不是模型，而是进料这一段。文档怎么切、切完保不保留标题层级、要不要加一层重排，这几项直接决定召回质量。切片粒度太粗会掺进无关内容，太细又会丢掉上下文，通常需要按文档类型分几档试。

• 切片时保留标题层级，检索命中后能还原出「这条来自哪份文档的哪一节」；
• 给每条资料带上来源和更新时间，回答里能标出处，出问题好追；
• 检索结果先做一次重排再拼进上下文，能明显减少答非所问；
• 定期抽样检查召回，别只看最终答案对不对，中间取错了照样能蒙对

什么时候不需要 RAG：资料量小到能整段塞进上下文，或者答案本来就落在公开知识里。这两种情况下硬上检索，只会多一层延迟和一套要长期维护的索引，收益不明显。

MCP 的位置：把外部能力标准化地接进来

它管的是「模型怎么知道有哪些工具、参数长什么样、调完怎么把结果拿回来」，本质是一层接口约定。和以前那种各写各的函数调用相比，差别在于工具的描述和发现是协议的一部分，工具那边换一个实现，调用方不用改代码。

什么时候不需要它：你只有一个内部接口、团队就一套代码，直接写函数调用更省事，引一层协议反而多出一堆排查面。协议的价值在工具多、来源杂、要跨团队甚至跨产品复用的时候才体现出来。

需要留意的成本主要是运维侧：连接超时怎么处理、工具报错怎么回传给模型、哪些工具允许自动执行。这些不定清楚，工具一多就会变成「谁都不敢动」的状态。

Agent 的位置：决定下一步做什么的东西

它的输出不是一段文本，而是一个动作：这次去查资料，下次去调接口，信息够了就停下来回答。真正定义 Agent 的不是「用了某个框架」，而是「它自己决定调用的顺序」，顺序固定写死的那叫编排链，不叫 Agent。

它的能力上限不取决于模型本身，而取决于你能给它多少可用的工具和资料。前两层没搭好就去上 Agent，结果通常是循环半天拿不到有效信息，最后靠不断调提示词硬撑，越调越脆。

1. 先定停机条件写清楚最大步数、单次任务的时间上限和花费上限，超了就中断并返回当前结果，别让它无限循环。
2. 再做工具权限分级读操作和写操作、查询和删除分成不同通道，破坏性操作必须人工确认，这条要在代码里卡住而不是靠提示词。
3. 最后接观测每次决策中间调了什么、返回了什么、为什么停，都要落日志，否则复盘时只能靠猜。

什么时候不需要 Agent：流程固定、步骤已知的场景，用一条写死的编排链更稳也更便宜。只要分支不多、异常处理能枚举完，就没必要让模型自己决定下一步。

真实系统里它们怎么串起来

最省事的搭法是有顺序的：先做通「模型 + 自己的资料」这一段，确认回答质量达标；再考虑加工具，把外部能力接进来；最后才考虑让模型自己决定调用顺序。跳步搭最容易返工，因为后面两层的效果都建立在第一层靠谱的基础上。

常见组合形态是把检索封装成一个工具注册进去，Agent 在需要时才触发检索，而不是每轮都无脑把资料塞进上下文。这样既省上下文，也让检索这个动作在日志里可追踪。

• 失败原因是「答得不对」→ 多半在资料层，先看召回和切片；
• 失败原因是「做不到」→ 多半在能力层，先看工具有没有接、参数对不对；
• 失败原因是「跑不完、跑偏」→ 才轮到决策层，看停机条件和权限分级；
• 三层都查过还不对 → 再回头怀疑模型本身，别一上来就换模型

排错顺序建议就按上面这个走：从资料层往决策层查，先别急着换模型。换模型是成本最高、最不解决问题的那一步。

给你的选型清单与不适用条件

拿到需求先做一次关键词扫描，命中哪条就先动哪一层，不用一次性全上。下面几条可以直接当清单对着勾。

• 需求里出现「我们内部的资料、文档、工单」→ 先做资料层；
• 出现「要操作别的系统、查实时数据」→ 再考虑能力层，先看有没有现成协议可复用；
• 出现「多步骤、有分支、失败要重试」→ 才考虑决策层，并且必须同时设计停机条件；
• 出现「只是回答风格不对」→ 先改提示词和产品交互，别动架构

不适用情形也要提前说清。延迟极敏感的场景，多层串起来会一路累加耗时，能砍层就砍层；合规严格到不允许数据流出内网的场景，能自建的先自建，外部协议接入要单独评估；资料每天都在大改的场景，索引维护成本会吃掉大部分收益，先想清刷新频率再决定要不要建库。

这些数字不要凭印象填，站内有对应的对照页，用当时的数字为准，改一次架构就回看一次。

最容易踩的几个坑

第一个坑是把三个词当同义词用，方案里写「上 Agent 做 RAG」，实际上是两件事，拆开写才写得下去。写到「谁检索、谁决策、谁执行」，方案自然就清楚了。

第二个坑是先上决策层再补资料层，结果 Agent 循环半天拿不到有效信息，只能靠调提示词硬撑。顺序反了，返工成本比一开始搭对高得多。

• 工具没有权限分级，一个读操作和一个删操作共用一条通道，出事就是大事；
• 没有留观测手段，记不清每次决策中间调了什么，复盘时只能靠猜；
• 把检索结果每轮都全量塞进上下文，既慢又贵，还挤掉真正有用的信息；
• 一次性想接完所有外部系统，结果哪一层都没做扎实

这些坑的共同点是把架构当成宣传词在堆，而不是按问题分层解决。回到那张图：资料层解决「不知道」，能力层解决「够不到」，决策层解决「没人管」。对不上号的功能，先别加。

三个词不是三选一，是三层：缺资料先补资料，够不到先接能力，没人盯才上决策。