回想一下：你是否曾让 Claude Code 读取项目文件，它是如何做到的？你是否好奇 Cursor 为何能理解你的代码库？TRAE 又是怎样操作本地目录的？

答案通常指向同一个：MCP。

MCP（Model Context Protocol）是 Anthropic 推出的大模型上下文协议。它既非工具，也非应用或 API Key，而是一种通信协议。它的核心目标在于：让任何 AI 都能通过统一的方式访问外部资源与工具。就像 USB-C 一根线缆即可解决充电、数据传输和视频输出问题一样，MCP 借助一套协议终结了 RAG 与函数调用各自为战的混乱局面。

一、MCP 出现之前：每个模型都是一座信息孤岛

在 MCP 诞生之前，大模型与外部世界的交互几乎全靠“打补丁”式方案。

想让模型读取本地文件？你需要写一段 Python 脚本，通过 fs.readFile 将内容读出，再拼接到 Prompt 里。想查询数据库？需要编写 SQL 语句，把结果格式化为文本，塞进上下文。想发送邮件？必须调用 Gmail API，获取返回数据后再喂给模型。

每个模型、每个数据源、每个工具都需要单独适配。同一个文件读取功能，你要给 Claude 写一套，给 GPT 写一套，给 Gemini 再写一套。代码量或许不大，但适配成本是 O(n×m)——n 个模型 × m 个数据源，呈指数级增长。

更致命的是，这些适配代码散落在各个项目的角落，缺乏统一标准、版本管理和安全校验。同样的功能，不同开发者写出的实现方式迥异，维护起来堪称噩梦。

Context Engineering 的理念已经说得很清楚——AI 需要上下文。但上下文从哪里来？如何接入？如何管理？在没有统一协议之前，这一切全靠手写胶水代码。MCP 解决的，正是这个“最后一公里”的问题。

二、MCP 的三层架构：Server、Client、Host

MCP 的架构分为三层，每层职责明确：

三者之间的协作关系可以用一句话概括：Host 是 AI 应用，内部配置了一系列 Client（类似插件），每个 Client 连接一个 Server。当用户提问时，Host 通过推理判断需要哪些上下文，然后借助对应的 Client 从 Server 获取数据，拼装成 Prompt 发送给 LLM。

举个实际例子：你在 Claude Code 中输入“帮我看看项目中 index.js 的内容”。Claude Code（Host）判断需要访问文件系统，找到已配置的 filesystem MCP Client，通过该 Client 向 filesystem MCP Server 发起请求，Server 读取文件内容并返回，Claude Code 将内容拼接到上下文中，最终交给 LLM 生成回答。

整个流程中，用户只看到一行自然语言指令，而底层 MCP 三层协作完成了文件读取、上下文组装和推理生成。

三、两个核心能力：Resources 与 Tools

MCP 为 LLM 提供了两种核心能力：Resources（资源）与 Tools（工具）。

Resources 是模型“想知道”的内容——数据、文件、API 返回、数据库记录等。例如飞书的文档、高德地图的 POI 数据、本地的 JSON 文件、数据库中的用户表，都属于 Resources。模型通过 MCP Server 读取这些资源，并将其作为上下文注入 Prompt。

Tools 是模型“想调用”的能力——发送邮件、创建日历事件、执行终端命令、远程控制设备等。模型不再局限于“只读”，还能“动手操作”。Tools 让 LLM 从“只能聊天”进化为“能干实事”。

两者的区别一目了然：

Resources 和 Tools 共同构成了 LLM 与外部世界交互的完整闭环：先读取资源获取上下文，再调用工具执行操作。 MCP 将这两件事统一到一套协议中，不再需要为“读文件”写一套代码、为“发邮件”再写另一套完全不兼容的代码。

![Resources vs Tools 对比图：读 vs 写，上下文 vs 能力]

四、实战：5 分钟搭建一个文件系统 MCP Server

理论讲清后，动手搭建一个。MCP 官方提供了开箱即用的 filesystem server，一行命令即可安装：

npm i -g @modelcontextprotocol/server-filesystem

然后配置 MCP Client。以 Claude Code 或 TRAE 为例，在 .mcp.json 中添加以下内容：

{
    "mcpServers": {
        "filesystem": {
            "type": "stdio",
            "command": "npx",
            "args": [
                "-y",
                "@modelcontextprotocol/server-filesystem",
                "F:/workspace/zzd_ai/ai/mcp/mcp-text"
            ]
        }
    }
}

其中 type: "stdio" 表示通过标准输入输出进行通信（本地进程间通信），command 指定启动命令，args 中的最后一个参数是允许访问的目录路径。配置完成后，重启 Host 即可生效。

现在你可以在聊天框中直接说“读取 F:/workspace/zzd_ai/ai/mcp/mcp-text 目录下的文件”，Host 将通过 MCP 协议调用 filesystem server，读取文件内容并返回给 LLM 处理。

这个配置的精妙之处在于：它将文件系统的访问权限精确控制到指定目录。 MCP Server 只能访问 args 中指定的路径，无法越界。这是 MCP 协议安全性的重要考量——并非给 LLM 打开整个文件系统的大门，而只开了一扇带锁的窗户。

![MCP 文件系统配置流程图：npx 启动 → stdio 通信 → 指定目录 → LLM 访问]

五、手写一个 MCP Server：从零开始

使用官方封装好的 Server 是第一步，理解其内部机制是第二步。手写一个最简单的 MCP Server，核心只有三件事：定义 Schema、实现处理逻辑、注册到 Server。

// 实例化 MCP Server
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
// 本地 stdio 通信
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
import fs from 'fs/promises';

const server = new Server(
    {
        name: 'simple-read-mcp',
        version: '1.0.0',
    },
    {
        capabilities: {
            tools: {}
        }
    }
);

async function main() {
    const transport = new StdioServerTransport();
    await server.listen(transport);
}
main();

这段骨架代码完成了以下操作：

1. new Server() 创建了一个 MCP Server 实例，声明了名称、版本和能力（tools: {} 表示该 Server 提供工具调用）
2. StdioServerTransport 建立了本地进程间通信通道——Client 通过标准输入输出与 Server 通信
3. server.listen(transport) 启动 Server，开始监听来自 Client 的请求

骨架搭建完成后，还需要注册具体的工具处理函数。核心依赖仅有以下两个：

• @modelcontextprotocol/sdk：MCP 协议的 SDK，负责通信层的协议实现
• zod：数据验证库，用于定义工具的 Schema（参数名称、类型、是否必填）

Schema 的作用是告诉 LLM：“我这个工具叫什么名字、接受什么参数、返回什么结果”。LLM 看到 Schema 后，就能在推理时判断“是否需要调用这个工具、如何传参”。本质上，Schema 就是 LLM 与外部工具之间的“API 文档”。

六、MCP 的真正革命性：从 Chatbot 到 Agentic AI

MCP 并不仅仅是一个便利工具，它从根本上重构了 AI 的应用架构。

在 MCP 之前，LLM 应用的本质是“聊天机器人（Chatbot）”——模型基于预训练数据回答问题，偶尔通过手写函数调用补充一些外部信息。能力的边界受限于模型本身的训练数据以及开发者为它专门编写的适配代码。

在 MCP 之后，LLM 应用演变为“智能体（Agentic AI）”——模型不再是一个孤立的对话引擎，而是连接了无数外部资源和工具的中央调度器。它可以通过 MCP 读写文件、查询数据库、调用 API、发送邮件、执行命令，在统一的协议框架下调度所有外部能力。

Context Engineering 为 AI 提供了“需要什么信息”的认知框架，而 MCP 则为 Context Engineering 提供了标准化的通信底座。两者结合，彻底终结了以往 RAG 与函数调用零散适配的乱象。

MCP 的核心价值可以用一个类比说清：HTTP 统一了浏览器和服务器之间的通信，MCP 统一了 AI 模型与外部世界之间的通信。 HTTP 出现之前，每个浏览器和每个服务器的通信方式各不相同。HTTP 出现之后，任意浏览器都能访问任意服务器。MCP 正在做同样的事情——让任何 AI 都能以统一的方式访问任何外部资源和工具。

七、一张图收束

用户自然语言指令
        ↓
MCP Host（Claude Code / Cursor / TRAE）
        ↓
推理：需要哪些上下文？
        ↓
MCP Client 层（插件式配置）
 ├── filesystem Client → MCP Server（本地文件读写）
 ├── database Client  → MCP Server（数据库查询）
 ├── gmail Client     → MCP Server（邮件收发）
 └── amap Client      → MCP Server（地图服务）
        ↓
获取 Resources（上下文数据）+ 调用 Tools（执行操作）
        ↓
拼装成 Prompt → LLM 推理 → 生成回答
        ↓
Agentic AI：不只是聊天，而是能读能写的智能体

MCP 并非魔法，它只是将“AI 需要访问外部世界”这件事，从手写胶水代码转变为标准化协议。然而，正是这种标准化，让 AI 从 Chatbot 迈向了 Agentic AI。

八、总结

MCP 是 2024 年底 AI 工程化方向最重要的基础设施之一。它并不复杂，但影响深远。

三个核心认知：

1. MCP 是一个协议，而非工具。 它定义的是通信标准，而不是具体实现。任何人、任何公司都可以基于该协议实现自己的 Server 和 Client，就像 HTTP 协议下有 Apache、Nginx、IIS 等无数种实现。

2. Resources 和 Tools 是 MCP 的两条腿。 Resources 让模型了解世界，Tools 让模型改变世界。读取和写入，缺一不可。

3. MCP 是 Context Engineering 的通信底座。 Context Engineering 回答了“AI 需要什么上下文”，MCP 回答了“上下文如何获取”。两者结合，AI 从 Chatbot 走向 Agentic AI。