三种常见的失败，对应三个词
这三个词经常被放在一起比较，像要在里面挑一个。它们其实不在同一层，各自对着一种失败。
要最新资料的问题，它一本正经地编一个看着合理的答案——资料不在手边，只能靠记忆凑。想让它读邮件、改表格、查数据库，它连这些系统都进不去——模型本身够不着公司的数据。让它处理一件多步骤的事，比如整理本周数据再发一份周报，它答完一句就停下来等你——它只会应答，不会接手。
这三种失败，分别对应 MCP（模型上下文协议）、RAG（检索增强生成）和 AI Agent（智能体）：一个管连接，一个管取料，一个管执行。三者不是竞品，可以单独用，也可以叠在一个应用里。ByteByteGo 第 224 期用三段定义加一张结构图把它们并排讲了一遍，下面挨个拆开看。
先从最外面那层说起：AI 要动手碰外部系统，靠什么接上？
MCP：给 AI 一个通用插座，不用为每个系统单独接线
模型要动 Gmail、Slack、GitHub、数据库这类外部系统，靠的是 MCP。
MCP 是一个开放标准协议，把 AI 模型连接到外部工具和数据源，例如 API、数据库或 Gmail、Slack、GitHub 等应用。它要消灭的麻烦很具体：如果没有标准，每接一个应用——邮箱、聊天软件、代码仓库——都要单独写一套集成。有了 MCP，连接变成一次标准化、到处复用，不用再逐个系统写对接代码。
对比图把结构拆成三块：最上面是 Claude Desktop、IDE、Agent 应用这些「MCP 主机」，每个主机里装一个 MCP 客户端；中间由统一的 MCP 协议连接；底下是 MCP 服务器，分别负责调用 API、查询数据库、读写文件。你不需要知道每套系统内部长什么样，只要它们各自实现一个 MCP 服务器，AI 应用就能访问。
这和 USB 接口的道理一样：设备内部千差万别，做成同一个接口，电脑就不用为每种设备单独开孔。
MCP 的边界也要记住：它管「能不能连上」，不管「连上之后说什么、做什么」。回答得好不好是模型和 RAG 的事，要不要自主行动是 Agent 的事。
类比MCP 的标准协议通用插座：设备各不相同，统一成同一个接口之后即插即用。
接口通了之后，下一个问题是：模型凭什么知道该说什么？
RAG：查询那一刻才去翻资料，模型不用自己编
第二个麻烦是模型爱编。模型的知识有截止日期，遇到资料里没有的新问题，它会给一个看着合理的答案。
RAG 的办法是开卷考试：收到提问时，模型先去外部资料库把相关内容捞回来，再连问题一起交给模型作答。它的取数时机很明确——查询到来时模型会拉取新鲜信息，从文档、PDF、数据库等外部数据源获取，以给出最新的答案，不必凭记忆硬答。这些数据源，就是放着真实资料的地方。
对比图把流程画成五步：用户提问，检索器在索引里搜索，取回相关片段，问题和片段一起送进大模型，生成答案。左下角的「知识库」里存着两份东西：原始内容（PDF、文档、代码）和供检索用的索引；右下角才是真正作答的模型（图上画了 GPT、Gemini、Claude）。
关键差别在这里：RAG 不是把资料背下来，而是让资料在回答的那一刻到场。所以它擅长回答「答案就藏在你提供的资料里」的问题，比如产品手册、内部文档、刚出炉的财报。
边界同样清楚：RAG 只管回答什么，不管接下来去做什么。它能准确告诉你怎么做，但不会替你做。
资料齐了、话也说对了，剩下「谁去把事做完」这一层。
AI Agent：从一问一答，到接手一整件事
第三个麻烦是 AI 只会答、不会干。聊天机器人是请求-响应：你问一句，它答一句，事情到此为止。
AI Agent 是自主执行任务并做决策的 AI 系统，与请求-响应式的聊天机器人不同。ByteByteGo 给的定义还多补了半句：确保一切正常运作。对比图把它画成一个循环：先有目标，把目标拆成任务，做出计划；然后执行动作、观察结果、根据反馈决定下一步，循环往复，直到出结果。这个循环里，Agent 手里有工具可用：API、文件、应用、数据库、记忆。图里那句话概括了它的本质——用推理和工具去追求一个目标。
自主既是它的价值，也是它风险的来源。一个会自己决定下一步的 AI，可能把事情办得很漂亮，也可能在没人盯着的时候越走越偏。「确保一切正常运作」这半句，其实暗示了 Agent 需要被监督、需要有边界。
三个词分别看完，就该把它们装回同一个应用里试一次。
装回同一个应用：知识、连接、执行，各管一层
三个词不在同一个层面。用「哪个更好」来比较它们，本身就把问题问错了：它们解决三个不同的问题，可以单独存在，也可以叠在一起用。
一句话记住分工：RAG 负责「知道」，MCP 负责「够到」，Agent 负责「做到」。
一个典型的组合是这样：Agent 接到一个多步骤目标，自己规划执行顺序；中间需要最新资料时，走 RAG 去检索；需要动外部系统时，走 MCP 去调用。这就像一家公司：Agent 是项目经理，RAG 是资料室，MCP 是行政通道——资料室保证答案有据可依，行政通道保证工具用得上，项目经理保证事情做完。
需要说清楚的是，这个三层叠加的结构，是在三个定义上整理出来的用法，ByteByteGo 并没有给出这样一套集成流程。
类比三者的配合关系公司里的三类角色：项目经理（Agent）、资料室（RAG）、行政通道（MCP）。
三个词的分工一览
| 对比维度 | MCP | RAG | AI Agent |
|---|---|---|---|
| 要解决的麻烦 | AI 接不上外部工具和数据源 | 模型会凭记忆编造答案 | AI 只会问答、不会干活 |
| 核心动作 | 用标准协议统一连接系统 | 查询时检索外部资料再作答 | 规划、执行、观察、反馈循环 |
| 典型对象 | API、数据库、Gmail、Slack、GitHub、文件系统 | 文档、PDF、数据库 | API、文件、应用、数据库、记忆 |
| 一句话类比 | 通用插座 | 开卷考试 | 会自己安排的执行者 |
落到自己手上的项目，该从哪一层开始补？
该补哪一层，看 AI 卡在哪儿
既然不是三选一，那该从哪儿开始？判断方法就藏在三个词的定义里——看你的 AI 卡在哪一层的麻烦上。
回答总是不准、爱编造，或者必须结合大量最新资料才能答好，问题出在知识层，补 RAG；需要让 AI 访问公司系统和第三方应用，又不想挨个写集成，问题出在连接层，补 MCP；想让 AI 不只回答，而是接手多步骤任务、自己做决定，问题出在执行层，上 Agent。
三层可以单独上，也可以叠加：先解决最痛的那一层，再向上下扩展。举个叠加之后的样子——目标是「整理本周的销售数据并发一份周报」：Agent 收到目标后拆成任务、排好先后顺序；需要最新数据时走 RAG 检索；需要动外部系统时走 MCP 调用 API 或读写文件；最后执行、观察结果、根据反馈调整，循环到完成。
这条组合流程同样是在三个定义上整理出的示意，并没有现成的集成步骤可以照抄。
最后要交代清楚：这份材料能回答什么、回答不了什么。
边界：这张速查卡能回答什么、回答不了什么
这三个词靠 ByteByteGo 第 224 期里的三段定义和一张结构图就能摆正位置：定义各只有两三句话，属于速查卡式的概括，没有展开实现细节，也没有给出性能对比数据。ByteByteGo 同一期还并排放着 JVM、分布式系统模式、虚拟化与容器、HTTP 与 HTTPS 四条独立速览，与这三者无关。
具体说，MCP 没有规范版本号和协议字段；RAG 没有检索方式、向量库和切分策略；Agent 没有能力边界和评测口径。所以「哪个技术更强」「该选哪个框架」这类问题，这份材料回答不了。它适合用来把三个词摆到正确位置，不适合当技术选型的依据。
回到开头：MCP、RAG、AI Agent 不是一场比赛里的三个选手，而是同一台机器上的三个零件。下次再看到有人把三者放在一起比，可以先问一句——他说的到底是「知道」、「够到」，还是「做到」。
