从RAG乱象走向统一标准：MCP凭什么成为Agentic AI的底座？

前言：AI 的“通天塔”困境

你有没有想过，为什么现在的 AI 虽然能写诗作画、对答如流，但一旦让它帮你订个机票、改个本地文件，它就无能为力了？

传统的大模型就像一个博学的“书呆子”——脑子里装满了互联网上的海量知识，但对外面的世界（你的本地文件、邮件、日历）一无所知，更无法动手操作。它和外部世界之间，似乎隔了一堵无形的墙。

为了让 AI 能调用外部工具，开发者们做过各种尝试：RAG（检索增强生成）、Function Calling（函数调用）、各种 SDK 和插件……但每一次接入，都需要为不同的模型写不同的适配代码，繁琐且重复。

直到 MCP（Model Context Protocol，模型上下文协议）  的出现，这堵墙开始崩塌了。

Part 1：初识 MCP——AI 世界的“USB-C 接口”

一句话定义 MCP

MCP 是 Anthropic 公司于 2024 年 11 月 25 日 推出的开放协议。你完全可以把它理解为 AI 应用领域的  “USB-C 接口” 。

为什么是 USB-C？

回想一下 USB-C 接口给数码产品带来的革命：

有了 MCP，AI 模型不需要再为不同的数据源写定制代码，它能以统一的方式访问任何接入了 MCP 标准的资源和工具。

MCP 不是什么？

很多人第一次接触 MCP 会困惑它到底是什么。这里给出一个清晰的定义边界：

• 它不是一个工具（像 ChatGPT 那样的应用）
• 它不是一个应用（不需要单独下载安装）
• 它不是一个 API SDK（不需要为每个模型单独集成）
• 它不是一个产品（不直接面向终端用户）
•  它是一个协议——就像 HTTP 是网站和浏览器之间的协议一样，MCP 是大模型和外部世界之间的通信协议。

Part 2：为什么需要 MCP？—— 告别“各自为政”的混乱时代

MCP 出现之前的困境

在 MCP 诞生之前，想让 AI 接入外部工具和数据，开发者面临的是“碎片化地狱”：

1. 为每个模型单独适配：想让 AI 读本地文件，你需要为 Claude 写一套接入代码，为 OpenAI 写另一套，为 Gemini 再写一套……
2. 多种技术栈混用：RAG、Fine-tuning、Function Calling、Plugin……每一种技术都有自己的接入方式，学习成本极高。
3. 维护成本巨大：每当模型升级或 API 变更，所有适配代码都可能需要重写。
4. 上下文来源受限：没有统一标准，大模型能调用的外部资源非常有限。

MCP 如何解决这些问题？

我的笔记里有这样一段话：

有了 MCP 之后：

• 一次构建，到处使用：开发者只需要按照 MCP 标准构建一次 Server，任何支持 MCP 的 Client——比如 Cursor、Trae、Claude Code、Codex——都能直接调用。
• 上下文来源极大扩充：各类网盘服务、远程服务、邮件服务、本地文件……只要接入了 MCP，大模型就能轻松调用。
• AI 从 Chatbot 进化为 Agentic AI：这不再是简单的“你问我答”，而是 AI 能自主判断需要哪些工具、调用哪些资源来完成任务。

Part 3：MCP 核心架构——三个角色，各司其职

要深入理解 MCP，我们需要先搞清楚它的核心架构。整个 MCP 体系由三个关键角色构成：

text

 复制代码┌─────────────────────────────────────────────────────────────┐
│                      MCP Host（宿主）                       │
│          Cursor / Trae / Claude Code / Codex               │
│                                                             │
│   ┌─────────────────────────────────────────────────────┐   │
│   │              MCP Client（客户端）                    │   │
│   │         负责与 MCP Server 通信的中间层              │   │
│   └─────────────────────────────────────────────────────┘   │
│                          │                                  │
│                          │ MCP 协议通信                     │
│                          ▼                                  │
└─────────────────────────────────────────────────────────────┘
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│                    MCP Server（服务端）                     │
│                                                             │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│   │ 本地文件  │  │  数据库  │  │  邮件服务 │  │ 高德地图  │  │
│   └──────────┘  └──────────┘  └──────────┘  └──────────┘  │
└─────────────────────────────────────────────────────────────┘

逐一拆解三个角色

1. MCP Host（宿主）

这是运行 AI 模型的环境，是你与 AI 交互的前端界面。比如你电脑上的 Cursor、Trae、Claude Code 等 IDE 或 AI 客户端。

2. MCP Client（客户端）

它运行在 Host 内部，是 Host 和 Server 之间的“通信兵”。当用户提出的任务需要外部数据或工具时，Client 会向 Server 发起请求。一个 Host 可以配置一推的 MCP Client，就像浏览器可以安装多个插件一样。

3. MCP Server（服务端）

这是整个架构中的关键角色。它提供了大模型想要使用的各种“上下文”：

• 资源（Resources） ：数据库、API、本地文件、SaaS 服务（飞书、高德地图、Gmail 等）
• 工具（Tools） ：创建日历、发邮件、执行命令、远程控制等

Server 定义了如何与 Client 交互（通信方式），将这些资源和服务“标准化”地提供给大模型。

Part 4：实战上手——搭建一个 MCP 文件系统服务

理论说再多，不如动手实践。接下来，我们通过一个完整的案例，搭建一个 MCP 官方文件系统服务端，让 AI 能够安全读写我们电脑上的指定目录文件。

案例背景

我们要实现的目标：让 AI 能够读取、修改我们电脑上 mcp-test 文件夹里的文件。

整个流程分为三步：安装 → 配置 → 使用。

第一步：安装 MCP 文件系统服务包

打开你的终端（命令行工具），输入以下命令，将 MCP 的文件系统服务包全局安装到你的电脑上：

bash

 复制代码npm i -g @modelcontextprotocol/server-filesystem

第二步：配置 MCP Client

在你的项目根目录下，找到或创建一个 .mcp.json 配置文件（有些 IDE 也支持 {}.mcp.json 的命名方式），添加如下配置：

json

 复制代码{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "C:Users24502Desktopworkspacehhaiaimcpmcp-test"
      ]
    }
  }
}

配置参数解析：

第三步：验证配置是否生效

配置完成后，打开你的 IDE（比如 Trae 或 Cursor），查看 MCP 服务是否已经成功连接。

你可以在 AI 对话中提问：“请帮我查看 mcp-test 目录下有哪些文件？”

如果配置正确，AI 会通过 MCP 协议调用 filesystem 服务，列出目录下的文件列表。在我的笔记中，mcp-test 目录下就包含了 .claude 文件夹、settings.json、JS test.js 等文件。

第四步：实战——让 AI 修改文件

接下来，我们来做一个真正的实战操作：让 AI 通过 MCP 修改一个 JS 文件。

假设 mcp-test 目录下有一个 JS test.js 文件，内容如下：

javascript

 复制代码Let i = 1;
var b = 2;
var c = 3;

现在，我们通过 AI 对话让它修改这个文件：

用户提问：请把 JS test.js 中的 Let i = 1; 改成 let i = 10;，并且把 var 都改成 const。

AI 的思考过程（来自笔记中的 Agent 思考记录）：

text

 复制代码Thought: 在工作区搜索 '**/test.js'
Thought: hhaiaimcpmcp-testtest.js
Thought: filesystem/edit_file
Thought: 已通过 MCP filesystem 工具的 edit_file 方法完成修改

最终，AI 通过 MCP 调用了 filesystem/edit_file 工具，成功完成了文件的修改。整个过程 AI 自主完成了：

1. 定位文件位置
2. 选择合适的工具（edit_file）
3. 执行修改操作

Part 5：MCP 的深层价值——重构 AI 应用架构

很多人第一次接触 MCP 时，会觉得它只是一个“增强版的插件系统”。但我的笔记里有一句非常重要的话：

什么是 Agentic AI？

传统的 AI（Chatbot）：

• 你问一句，它答一句
• 回答基于预训练知识，无法获取实时信息
• 只能“说”，不能“做”

Agentic AI（智能体 AI）：

• 你提出目标，它自主规划步骤
• 它会通过推理判断：我的预训练知识够不够回答这个问题？不够的话，去 Host 里看看有哪些 MCP Client 可以调用？
• 它会主动调用工具：读文件、查数据库、发邮件、执行命令……
• 它能“说”也能“做”

MCP 如何实现这个转变？

笔记里有一段话概括得很好：

MCP 通过标准化的方式，把这两类内容开放给大模型：

这两者结合起来，大模型就从一个“纸上谈兵”的顾问，变成了一个“能打能抗”的执行者。

Part 6：深入理解 MCP 的交互模式

推理驱动的交互

MCP 的交互不是简单的“收到指令→执行指令”，而是基于推理的：

1. 用户提出一个任务
2. AI 模型进行推理：我的预训练知识能回答吗？
3. 如果不能，AI 会去看 Host 里配置了哪些 MCP Client
4. AI 判断哪些 Client 可以为当前任务提供上下文
5. AI 通过 MCP 协议调用对应的 Server
6. Server 返回数据或执行操作
7. AI 基于获取的上下文，完成最终的回答或操作

这就像你遇到了一个专业问题，先自己思考，发现知识不够，然后去翻阅工具箱里的各种参考资料和工具，最终完成任务。

与“插件”的本质区别

很多人会把 MCP 理解为“AI 的插件系统”，但实际上有本质区别：

MCP 就像古代的“通用文字”——秦朝统一六国文字后，各地之间才能高效沟通。MCP 为 AI 生态提供了统一的“通用语言”。

总结：MCP 为什么值得你关注？

四个核心要点

1. 标准化底座：为 Context Engineering 提供统一的通信标准，终结了 RAG、函数调用各自为政的混乱局面。
2. 生态扩展性：极大地扩展了大模型的能力边界，让 AI 从“信息处理”走向“任务执行”。
3. 架构升级：MCP 不是简单的插件升级，而是从根本上重构了 AI 应用架构，让 Agentic AI 成为可能。
4. 开放生态：任何服务都可以接入 MCP——网盘、邮件、地图、数据库……一个开放的 AI 工具生态正在形成。

一句话总结

MCP 的出现，标志着 AI 不再是孤立的“大脑”，而是开始长出能够感知和改变世界的“手和脚”。