llm、rag、ai agent、mcp

团队里讨论方案时经常混着说：要不上个 RAG、要不上个 Agent、听说 MCP 也要接。名字都会念，但一落到「我这活儿到底缺哪一层」就开始绕。这篇不解释原理，只做一件事：把四者画成一张位置图，再给一张按症状判断该补哪一层的对照表，以及接入前要准备的工程清单。

团队里讨论方案时经常混着说：要不上个 RAG、要不上个 Agent、听说 MCP 也要接。名字都会念，但一落到「我这活儿到底缺哪一层」就开始绕。这篇不解释原理，只做一件事：把四者画成一张位置图，再给一张按症状判断该补哪一层的对照表，以及接入前要准备的工程清单。

先定一个基调：这四样东西不是并列的四个选项，不是四选一。大模型是唯一的推理内核，另外三个都是挂在它外面、方向不同的补充层。想清楚这一点，后面的判断会顺很多。各家模型在工具调用、上下文长度上的差异，可以到 /models 的模型资料库里核对当时的说明。

一张图定位：四个东西各占哪一格

把它们放进一条链路里看就清楚了：中间是大模型，负责理解与生成；左边挂 RAG，属于知识侧；右边挂智能体，属于行动侧；MCP 不是独立一层，它是行动侧的统一接插件。也就是说，RAG 和智能体是两种不同的「外挂」，MCP 是让外挂工具接得规整的一种规范。

大模型（LLM）

唯一的推理内核，负责读懂输入、组织语言、决定下一步做什么

RAG

知识侧外挂，把外部资料检索出来再喂给模型，解决它不知道你的私有内容

AI Agent

行动侧外挂，让模型能调工具、多步执行，解决它只会说不会做

MCP

行动侧的统一接插件，规定工具怎么被描述和调用，解决接口一对接一次的重复劳动

按症状选层：什么情况加哪一层

上一节是位置图，这一节是能直接对照着用的判断表。左边写你实际观察到的现象，右边写优先补的那一层，以及为什么不是另外几层。注意这张表是默认建议，不是硬性规则。文档量很小、直接塞进上下文就够用的场景，上 RAG 是给自己找活；流程完全固定、分支写死在代码里的场景，用工作流比上智能体更稳。

还有一个常被忽略的「不适用」情形：如果问题只是检索结果里混进了不相关的内容，那属于调优而不是加层。先把召回条数往下调、把切分粒度改细，再考虑是不是要动架构。反过来，如果工具数量不多、短期内也不换客户端，那直接写函数调用往往比架一套 MCP 省事。

真动手接的时候，四层各自的检查清单

判断完该加哪层，真正动手前还有几件事要确认。下面按四层分开列，每条都对应一个动作和一个验证方式，别只当成清单打勾。

1. 内核层：先确认能力边界确认模型对工具调用的支持情况，以及上下文窗口够不够同时塞下系统提示、检索结果和对话历史；拿一批最长的真实输入跑一次，看有没有被截断。
2. 知识层：先定切分和召回定好切分粒度、召回条数，并给 rerank 留好位置；验证方式是拿一批已知答案的问题跑一遍，看正确内容有没有被召回进来。
3. 行动层：先划工具白名单只放当前任务真正需要的工具，设好步数上限和单次任务的成本上限；跑一个会绕圈的任务，确认到限额能停下来。
4. 接插件层：分清它管什么MCP 只解决「怎么接」，不解决「接什么」和「能不能用」；鉴权、超时、失败重试这些仍要自己配，并在断网和工具报错两种情况下各测一次。

什么情况下别急着加层

层数越加越多、后来没人敢删，是这种架构最常见的结局。所以最后给三类典型的「先别加」场景，每个场景配一个更省的替代动作。

• 只是模型选错了：先换一档模型或换个供应商试一轮，到 /rankings 看当前的可选情况，别急着上外挂。
• 只是提示词没说清：先补格式约束和几个正反示例，用同一批用例对比改动前后的差别。
• 只是检索结果没排好：先把召回条数往下调、把切分粒度改细，属于调优不属于加层。
• 接口要在多个客户端复用的需求还没出现：先写函数调用，等真的出现第二、第三个客户端再考虑 MCP。

判断改得对不对，靠的是固定用例对比：改动前后各跑一批同一组问题，看结果有没有变好；没变好就回退，不要因为「已经写了」就留着。工具调用失败率这类运行数据，可以到 /tools/speed-test 做参考，具体数值以页面上当时的展示为准。