从 LLM、RAG、Agent 到 MCP：一文看懂 AI 系统的演进

AI 的变化，不只是模型越来越聪明。更关键的变化是：围绕模型的系统架构，正在一层层补齐。

很多人对 AI 的理解，还停留在“一个可以聊天的机器人”。

但今天的 AI 系统，早已不只是一个聊天窗口。它可以检索企业文档、查询数据库、调用 API、执行代码、浏览网页、管理任务，甚至像一个软件员工一样完成多步骤工作流。

从“输入 Prompt，让模型回答”到“连接业务系统，让 AI 执行任务”，中间真正发生的变化，是 AI 产品架构的分层演进。

每一层能力的出现，几乎都在解决上一层暴露出来的问题：

• LLM 解决自然语言理解与生成；
• RAG 解决知识和事实依据；
• Agent 解决行动与多步骤任务；
• MCP 解决工具和数据源连接标准化；
• 上下文工程解决记忆、状态、工具、检索之间的协同。

理解这条演进路线，就能更快看懂今天大多数严肃 AI 产品的底层逻辑。

先看全局：AI 正在从模型变成系统

早期 AI 产品通常很简单：

用户输入 → LLM → 文本回答

这个形态适合闲聊、写作、总结、翻译和解释概念。但进入真实业务场景后，很快会遇到一堆问题：

• 模型不知道企业私有文档；
• 模型不知道最新事实；
• 模型不能直接执行任务；
• 模型不会天然记住长期偏好；
• 模型无法稳定连接复杂业务系统；
• 多步骤任务容易丢失状态。

于是，AI 系统开始从单点模型调用，变成多层架构。

这条路线可以概括为：

LLM：能说
RAG：有依据地说
Agent：能做事
MCP：更容易连接外部世界
上下文工程：让整个系统稳定运行

下面按阶段拆开看。

阶段一：LLM，让 AI 拥有自然语言入口

LLM，全称 Large Language Model，也就是大语言模型。

从底层来看，LLM 是一个预测引擎。它接收一段文本，然后预测下一个最可能出现的 token，再继续预测下一个 token，直到生成完整回答。

输入：法国的首都是
模型：预测下一个 token
输出：巴黎

这里的 token 可以粗略理解为模型处理文本的基本单位。英文里，一个 token 大约对应 3 到 4 个字符。模型的成本、速度和上下文长度，都和 token 有关。

LLM 真正令人震撼的地方，不在于“预测下一个词”这个机制本身，而在于训练规模足够大之后，模型从海量文本中学到了语言、知识、代码、推理模式和表达方式。

LLM 第一次让很多人感受到，机器不只是执行固定规则，还可以通过自然语言沟通：

• 用多种语言对话；
• 写代码；
• 总结长文档；
• 解释复杂概念；
• 生成文案、邮件、报告和方案。

这也是为什么很多 AI 产品一开始都做成聊天机器人。

但纯 LLM 很快会撞到天花板。

它有几个天然限制：

• 幻觉：生成的内容可能看起来合理，但事实错误；
• 知识截止：训练数据有时间边界，无法天然知道最新信息；
• 没有长期记忆：默认只能依赖当前对话上下文；
• 无法访问私有数据：公司文档、数据库、内部系统里的信息默认不可见；
• 不能真正行动：可以建议，但不能直接发邮件、查库、下单、更新记录。

所以，纯 LLM 更像一个非常强的语言与推理核心。它能表达，但不一定知道最新事实；能回答，但不能天然访问业务数据；能建议，但不能真正执行。

这就引出了下一层：RAG。

阶段二：RAG，让回答有外部依据

RAG 是 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。

它的核心思想很简单：

回答之前，先检索相关资料，再把资料交给模型作为上下文。

也就是说，模型不再只依赖训练时学到的知识，而是在每次回答问题时，先从外部知识库、文档库、数据库或网页中找到相关信息，再基于这些资料生成答案。

一个好理解的类比是：

纯 LLM：闭卷考试，靠记忆回答。
RAG：开卷考试，先翻资料再回答。

RAG 并没有改变模型本身，而是改变了模型拿到的信息环境。

典型 RAG 流程大致是：

用户问题
  ↓
检索相关文档
  ↓
把文档注入 Prompt
  ↓
LLM 基于上下文生成回答
  ↓
输出更有依据的答案

支撑 RAG 的关键技术之一是 Embedding，也就是向量嵌入。系统会把文本转成向量，用数学方式表达语义。语义越接近，向量距离通常越近。

比如：

• “汽车”和“轿车”更接近；
• “汽车”和“光合作用”距离更远。

当用户提出问题时，问题也会被转成向量。系统再到向量数据库里找到语义最接近的文档，把这些资料交给模型参考。

常见向量数据库和检索工具包括：

• Pinecone；
• Weaviate；
• Chroma；
• FAISS。

RAG 让很多真实产品变得可行：

• 企业知识库助手；
• PDF 问答；
• 内部制度问答；
• 客服知识库机器人；
• 基于最新资料的搜索总结；
• 需要私有知识的问答系统。

RAG 的价值不是让模型“自己知道一切”，而是让系统先把正确资料找出来，再让模型组织成可读答案。

但 RAG 也有边界。

它解决的是“知识问题”，不是“行动问题”。

它可以回答“退款政策是什么”，但不能真正帮用户处理退款；可以列出航班选项，但不能真正完成订票；可以解释数据库字段含义，但不能自己安全地更新生产数据。

想让 AI 从回答走向行动，就需要 Agent。

阶段三：Agent，让 AI 从回答走向执行

Agent 的关键变化是：AI 不再只回答一句话，而是围绕目标持续行动。

传统 AI 流程是：

用户提问 → 模型回答 → 结束

Agent 流程更像：

用户设定目标
  ↓
Agent 制定计划
  ↓
调用工具
  ↓
观察结果
  ↓
决定下一步
  ↓
持续执行直到完成任务

Agent 的基础能力是 Tool Calling，也就是工具调用。

LLM 本身不能搜索网页、调用 API、运行代码、写数据库。但通过工具调用，模型可以决定使用哪个工具、传入什么参数、如何理解返回结果，以及下一步该做什么。

比如用户提出：

帮忙找下个月从德里到新加坡最便宜的机票。

Agent 可能会这样执行：

1. 调用航班搜索 API；
2. 传入出发地、目的地和时间范围；
3. 读取返回结果；
4. 按价格、转机次数和时间排序；
5. 总结最合适的几个方案。

这已经不是简单文本生成，而是任务执行。

能力较完整的 Agent 可以：

• 浏览网页并提取信息；
• 编写、运行和调试代码；
• 查询和更新数据库；
• 分析文件；
• 发送邮件或消息；
• 调用带权限的 API；
• 协调多步骤工作流；
• 与其他 Agent 协作。

为了降低构建难度，生态里出现了很多 Agent 框架：

• LangChain / LangGraph；
• AutoGen；
• CrewAI；
• OpenAI Agents SDK。

但 Agent 越强，失败模式也越多。

常见问题包括：

• 上下文窗口被填满，早期指令被遗忘；
• 任务跑久后丢失主线；
• 工具太多导致选错工具；
• 参数传错；
• 声称调用了工具但实际没有；
• 缺少停止条件，陷入循环；
• 外部系统集成越来越重。

尤其是最后一点很现实：每接一个系统，都要写一套定制连接器。Slack 一套，Google Drive 一套，Salesforce 一套，数据库又一套。

工具越多，集成越重，维护越难。

这正是 MCP 出现的背景。

阶段四：MCP，让工具连接更标准

MCP，全称 Model Context Protocol，可以理解为“模型上下文协议”。

它试图解决的问题不是“模型够不够聪明”，而是“模型如何用统一方式连接外部工具和数据源”。

在 MCP 之前，AI 系统连接外部能力通常会遇到这些麻烦：

• 每个工具都要单独定制集成；
• 每个 API 的格式不同；
• 模型不知道当前有哪些工具可用；
• 工具调用、上下文、返回结果缺少统一规范；
• 连接越多，维护成本越高。

MCP 的常见类比是：

MCP 之于 AI 模型，就像 USB-C 之于设备连接。

USB-C 让不同设备和外设更容易连接；MCP 则让模型、工具和数据源更容易连接。

在 MCP 架构里，MCP Server 通常会向模型暴露三类能力：

• Tools 工具：模型可以调用的动作，例如搜索、写文件、查数据库、调用 API；
• Resources 资源：模型可以读取的数据，例如文件、文档、数据库记录；
• Prompts 模板：面向特定任务或工具的提示模板。

模型可以先查询当前可用能力，再用结构化方式调用这些能力。

这带来的变化是：AI 系统不需要为每个工具重复写一套“模型如何理解它、如何调用它、如何读取结果”的集成逻辑，而是可以逐步通过统一协议接入外部世界。

但 MCP 不是银弹。

连接变简单后，安全问题会更重要：

• Prompt 注入；
• 工具权限过大；
• 数据外泄；
• 恶意工具伪装；
• 缺少审计和沙箱；
• 缺少细粒度权限控制。

所以 MCP 更像连接层标准，而不是完整安全方案。真正进入企业生产环境，还需要认证、授权、审计、加密、沙箱、权限边界和风险控制。

上下文工程：把所有能力串起来

到这里，LLM、RAG、Agent、MCP 分别解决了不同问题：

• LLM 负责理解和生成语言；
• RAG 负责获取外部知识；
• Agent 负责规划和执行任务；
• MCP 负责统一连接工具和数据源。

但要让这些能力稳定协同，还需要更关键的一层：上下文工程。

很多人熟悉 Prompt Engineering，也就是提示词工程。它关注的是如何写好一条指令。

上下文工程比提示词工程更大。

提示词工程是写一句好指令；上下文工程是设计模型在执行任务时能看到的完整信息环境。

上下文工程通常包括：

• Memory 记忆：用户偏好、历史交互、长期项目背景；
• Retrieval 检索：当前任务应该检索哪些文档和数据；
• Tools 工具：模型可以使用哪些动作，工具如何描述；
• History 历史：对话历史保留多少、如何压缩；
• System State 系统状态：任务进展到哪里；
• Workflow Position 流程位置：多步骤流程当前处在哪个节点。

今天最强的 AI 系统，不只是用了更好的模型，而是围绕模型设计了更好的上下文环境。

上下文做得好，Agent 才可能在生产环境稳定运行；上下文做不好，Agent 可能只在演示里显得很厉害。

现代 AI 产品架构：不再只是一次 API 调用

严肃的 AI 产品，通常已经是一套系统，而不是一次模型调用。

可以把它拆成几层：

用户界面
  ↓
编排层
  ↓
上下文管理器
  ├── 记忆层
  ├── 检索层
  └── 状态管理
  ↓
工具层
  ├── Web 搜索
  ├── 数据库查询
  ├── API 调用
  ├── 代码执行
  └── 文件操作
  ↓
LLM
  ↓
响应 + 动作

每一层都在解决具体问题。

去掉检索层，系统就只能凭模型记忆回答；去掉工具层，系统只能说不能做；去掉上下文管理，复杂任务会丢状态；去掉编排层，多步骤流程难以稳定执行。

这也是现代 AI 产品和普通 Chatbot 最大的区别：

Chatbot 是入口，AI 产品是架构。

决策框架：到底需要哪一层

并不是所有 AI 产品都需要堆满复杂架构。

如果只是生成文案、总结内容、解释概念，直接使用 LLM 可能就够了。

如果需要围绕私有文档、企业知识库或最新信息回答，就需要 RAG。

如果不只是回答，还要跨系统完成动作，比如查资料、调用 API、写入数据库、发送消息，就需要 Agent。

如果 Agent 要连接很多外部工具、数据源和业务系统，并希望连接方式标准化，就可以考虑 MCP。

如果任务长期、多轮、复杂，涉及记忆、检索、工具、流程状态，就必须认真设计上下文工程。

可以用这张表快速判断：

需求类型	推荐架构
生成、改写、总结	LLM
基于私有文档或知识库回答	LLM + RAG
执行多步骤任务	LLM + Agent
连接大量外部系统	Agent + MCP
长期记忆和复杂任务状态	上下文工程 + 编排层

一个重要原则是：不要过度工程化。

很多文档问答场景，用稳定的 RAG 管道就够了，不需要强行引入复杂 Agent。复杂性应该在简单系统无法满足需求时再增加，而不是一开始就把所有技术名词都堆进去。

接下来，AI 系统会继续怎么演进

未来 AI 系统大概率会继续朝几个方向发展。

第一，长期持久记忆会变得更重要。AI 不只记住当前会话，还会跨项目、跨周期记住偏好、背景和工作方式。

第二，多 Agent 协作会更多出现。不同 Agent 扮演不同角色，围绕同一目标协作完成任务。

第三，真实世界执行会更深入。AI 会连接操作系统、业务软件、工作流平台和内部服务，不只是建议，而是真正执行。

第四，个性化 AI 系统会成为趋势。模型会逐渐适应用户所在领域、语言风格、工作流程和决策习惯。

第五，自主工作流会越来越常见。Agent 不再每一步都等待指令，而是能管理自己的任务队列，并在关键节点请求确认。

AI 产品的竞争，也会从“谁的模型更强”，转向“谁能把模型、数据、工具、记忆、流程和安全治理组合得更好”。

最核心的结论

AI 最大的误区，是把模型当成整个产品。

模型很重要，但模型不是全部。

现代 AI 系统更像一个架构组合：

• 记忆系统；
• 检索管道；
• 编排层；
• 工具体系；
• 上下文管理器；
• 执行环境；
• 安全治理；
• 最后才是被包裹在其中的大语言模型。

LLM 让 AI 能说，RAG 让 AI 有依据地说，Agent 让 AI 能做事，MCP 让 AI 更容易连接外部世界，而上下文工程决定这一切能否稳定运行。

未来真正可用的 AI 产品，不会只靠一个更强的模型取胜，而会靠更好的系统设计取胜。