MCP协议深度解析：AI概念核心指南

AI_概念篇_MCP

让 AI 真正能"动手"的标准协议

没有 MCP 之前：重复造轮子的时代

有没有想过，没有 MCP 之前是什么样子？大概在 2023 年前后，AutoGPT 和早期 GitHub Copilot 那个阶段，任何 Agent 想要调用一个外部工具，都得自己手动硬编码一套逻辑来实现。

举个例子：Cursor 自己写一套读文件的代码，Copilot 也自己写一套，你自己开发的项目还得再写一套。如果 GitHub 想让自己的 AI 能操作 PR，那就得分别适配 Cursor、Copilot、JetBrains、VS Code……每多一个平台，就重新适配一遍。这背后的本质是 M 个平台 × N 个工具 = M×N 个适配。工具越多、平台越多，适配成本就像滚雪球一样指数级增长，而且彼此完全不通用。

而 MCP 的核心贡献，就是把 M×N 变成了 M+N。工具开发者只需实现一次 MCP Server，所有支持 MCP 的平台都能直接用；反过来，平台只要支持 MCP，就能调用所有已有的 Server。这大概就是 MCP 后续能快速爆发的根本原因——它的真正价值不在于协议本身有多复杂，而在于它成为了跨厂商的"最小公约数"。

MCP 是什么

MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 于 2024 年 11 月发布的开放协议，它定义了一套标准：工具如何向 AI 声明自己的能力，AI 如何通过统一接口调用这些工具。

简单来说，MCP 就是工具和 LLM 之间的统一通信标准。不过需要说明的是，MCP 其实包含了三种能力：Tools、Resources 和 Prompts，只是在实际工程中 Tools 用得最广，所以大家常把它等价理解为"工具调用协议"。

这就像 USB 接口——它规定了接口的形状和通信协议，U 盘、键盘、摄像头都能往上插。MCP 做的是同样的事，只不过连接的是 AI 和各类外部工具。

MCP Host（宿主应用）是协调并管理所有 MCP Client 的 AI 应用程序。它负责启动和回收 Server 进程、创建和管理 Client 实例、协调 Agent 的决策流程——说白了，就是用户直接交互的那个入口，比如 Cursor、Claude Desktop 这些。

MCP Client（客户端）是由 Host 创建的通信组件，专门负责与某个 MCP Server 维持一对一的专属连接，并把 Server 提供的上下文能力交付给 Host 使用。

MCP Server（服务端）则是向 MCP Client 提供上下文能力的程序。它负责把某类外部能力（比如文件系统、数据库、GitHub API）封装成符合 MCP 协议的标准接口，可以在本地运行，也可以部署在远程。

三层架构：谁在干什么

MCP 在协议层面约定了一个清晰的三层架构。关键是，每一层都可以由不同的开发者独立实现，只要大家遵守通信规范就能互相配合——这正是 MCP 最核心的价值所在：A 开发的 Client，能和 B 开发的 Server 通信，还能被 C 开发的 Host（比如 Cursor）使用。

理解这个架构，可以从 Host 开始看起。

Host：管理者，不只是界面

Host 是整个 MCP 运行环境的管理者。当你打开 Cursor 时，Host 会读取配置文件（比如 mcp_settings.json），把需要的 Server 作为子进程在后台启动，并创建对应的 Client 实例建立连接。至于是在启动时全部初始化还是按需创建，那取决于 Host 的具体实现，协议本身不做强制规定。整个过程对用户完全透明。当你关闭编辑器时，Host 也会负责断开连接、回收所有 Server 进程。

有意思的是，Host 完全可以由任何人自己开发。比如你想做一个专门用于法律文书审查的 AI 工具，完全可以开发一个自己的 Host，内嵌 Client，连接文件系统和数据库 Server，定制自己的 UI 和交互逻辑。Host 也不限于桌面应用——像 Claude Code、Gemini CLI 这类命令行工具同样是 MCP Host，只不过把用户界面换成了终端交互，底层的 Server 管理和 Agent 协调机制完全一致。

Client：Agent 的通信子模块

Client 是 Agent 用来和 Server 通话的模块，由 Host 创建和管理。这里有个容易误解的地方：Client 本身不包含决策能力，也不依赖 Agent 存在——即使没有 Agent（比如只是简单的规则系统），Client 仍然可以独立工作。这就像员工（Agent）用电话（Client）打外线，但电话是公司（Host）装的，也是公司负责维护的。

Client 的职责很单纯：选择合适的传输方式建立连接、发请求、收结果。复杂的决策逻辑在 Agent 里，具体的工具实现在 Server 里，Client 只做中间传话的角色。

Client 与 Server 的连接方式有两种：

Streamable HTTP 是 MCP 在 2025年3月26日规范修订后推荐的传输方式，取代了早期的 HTTP/SSE（双通道：HTTP 请求 + SSE 长连接推送）。新方案用单一 HTTP 连接同时支持请求/响应与流式推送，SSE 变成可选，更适合无状态的云端部署。如果你看到旧文章提到的 HTTP/SSE，指的就是同一类场景下的旧版实现。实际工程中，本地工具（文件系统、终端执行）用 Stdio；第三方云服务（GitHub、Slack、Gmail）用 Streamable HTTP。

Server：能力的适配层，不是工具本身

Server 既是一个协议概念（适配层的角色定义），也是一个具体运行的程序。它做两件事：对上实现 MCP 协议接口（响应 tools/list、执行 tools/call、回传结果），对下调用实际的底层能力（比如 fs 模块、Puppeteer、GitHub API 等）。

你在生态表里看到的 filesystem、Puppeteer、GitHub 等，指的就是对应的 MCP Server 程序，而不是底层的 fs 模块或 Puppeteer 库本身。Server 程序把这些底层能力包装成了标准接口。比如你开发了一个闹钟应用，也可以同时开发一个对应的 MCP Server——Server 负责把"获取明天的闹钟列表"、"新增一个闹钟"这些操作，翻译成 MCP 能理解的标准格式，任何支持 MCP 的 AI 应用就能直接调用你的闹钟了。

Server 的工具列表由 Server 自身决定，与客户端或操作系统无关。主流实现中，工具通常在 Server 代码里静态声明；协议也支持在响应 tools/list 时动态返回，常见用途是根据配置或鉴权状态过滤可用工具集。对于动态数据（比如数据库的表结构），主流做法是通过通用工具的参数传入，而不是将每条数据映射为独立工具。这就像餐厅的菜单由厨房决定，今天有什么食材就能做什么菜。

实际工作流：Cursor 中的完整一次调用

假设你在 Cursor 中输入了"请帮我设计一个登录页面，考虑到我项目的 UI 组件、技术栈以及 UI 风格"，看看这三层架构是怎么协作的：

首先，Host（Cursor）接收输入，交给 Agent 决策。Agent 判断：要回答这个问题，必须先"读懂"这个项目，于是决定调用工具。Agent 通过 Client 发送 tools/list 请求（通过 Stdio 通信），Server 返回可用的工具列表：read_file / list_dir / search_code / write_file……

接下来，Agent 决策调用顺序，进行多轮工具调用：先 list_dir("src/components") 了解有哪些 UI 组件，然后 read_file("package.json") 确认技术栈（React 还是 Vue？），再 read_file("tailwind.config") 了解 UI 风格配置，最后 search_code("Button") 查看现有组件的实际用法。每一轮都是 Client 到 Server 再到回传 Agent。

最后，Agent 把收集到的项目上下文和用户需求一起拼入 Prompt，发给 LLM。LLM 基于真实项目代码，生成符合项目风格的登录页面。这里有一个关键点：在 MCP 架构下，LLM 通常不会直接访问文件系统，而是通过 Server 间接获取数据。是 Agent 通过 MCP 这套管道把文件内容"搬运"过来的，LLM 只负责最后的推理和生成。

没有 MCP，Cursor 要实现这个能力，就得自己写一套文件读取逻辑；有了 MCP，直接接入标准的 filesystem-server 即可，其他平台也能复用同一个 Server。

Server 的生命周期

当你打开 Cursor（Host 启动），Host 读取配置文件，找到需要的 Server 列表。对于本地 Server，Host 作为子进程拉起（比如 npx filesystem-server），通过 Stdio 与 Client 建立连接；对于远程 Server，Host 通过 Streamable HTTP 建立连接，不负责启动。Agent 开始工作，通过 Client 调用 Server 工具。当你关闭 Cursor 时，Host 断开所有连接，回收本地 Server 子进程（远程 Server 独立运行，不受影响）。

工具不可用时怎么办

Server 不会自动感知环境变化，但做得好的 Server 会在启动阶段主动做环境检测：检测依赖是否安装（比如 which ffmpeg）、检测 API Key 是否配置、检测系统版本是否满足。满足就注册该工具，让它出现在 tools/list 里；不满足就跳过，Client 拿到的列表里就不会有它。

如果工具已经暴露但执行时才发现报错，处理链路是这样的：Client 发起 tools/call，Server 执行时报错（比如环境不支持），Server 返回标准错误响应，Agent 收到错误，决定下一步：换一个工具、提示用户、或者带着错误信息重新请求 LLM 决策。这就像点外卖，理想情况是菜单上直接标注"售罄"（启动时检测），但有时候是下单后才告知没货（运行时报错）——这时候换菜还是退单，是 Agent 的职责，不是协议的职责。

工具列表变化时如何通知

连接建立后，如果 Server 的工具列表发生变化（新增、删除、修改），MCP 协议支持 Server 主动推送一条通知给 Client：notifications/tools/list_changed，Client 收到后再发一次 tools/list 请求拉取最新列表。

不过有两个前提条件需要注意：第一，Server 必须在初始化时声明 listChanged: true 能力，才会发送这条通知——这是 Server 开发者主动选择支持的功能，不是默认行为。第二，Client 端也必须实现对应的监听处理逻辑，否则通知发过来也没用。部分 Host 实现目前还存在这个问题——通知到了但没有注册处理器，工具列表只在初始化时拉取一次，动态变化感知不到。换句话说，这个机制协议层有规定，但实际落地程度参差不齐——这是目前 MCP 生态还在成熟过程中的真实现状。

业界常见的 Server 生态

MCP 是开放协议，任何人都可以开发 Server。目前生态已经非常丰富：文件系统方面有 filesystem，可以读写本地文件、管理目录；代码托管方面有 GitHub 和 GitLab，支持 PR、commit、issue、代码审查；数据库方面有 Supabase、PostgreSQL；浏览器自动化有 Puppeteer、Playwright；效率工具有 Notion、Slack、Gmail；支付商业有 Stripe；媒体控制有 Spotify；系统控制有 Windows Control，可以控制鼠标键盘、截屏、管理窗口。

开发一个自己的 Server 只需做两件事：实现 tools/list 返回工具描述，再实现 tools/call 执行工具逻辑并返回结果。常用的开发库包括：系统操作方面用 subprocess 或 child_process 执行 Shell，os 或 pathlib 处理文件系统；HTTP 请求方面用 requests 或 httpx（Python），axios 或 fetch（Ja vaScript）；浏览器自动化方面用 Playwright、Puppeteer；云服务方面用 boto3（AWS）、google-cloud-*（GCP）。

顺便提一下，除了上面提到的 Tools，MCP 协议还定义了另外两个原语：Resources（Server 向 Agent 提供结构化数据，比如文件内容、数据库记录）和 Prompts（可复用的提示词模板，比如"代码 review 模板"、"SQL 生成模板"）。实际工程中这两者使用较少，当前大多数 MCP Server 的核心能力都通过 Tools 实现。

MCP vs Function Calling

说到 Agent 调用工具，很多人会想到 Function Calling。它们之间有什么区别？简单来说，Function Calling 的工具定义是嵌在 Prompt 或 API 里的，随请求传入，而且强绑定模型提供商；而 MCP 的工具定义在 Server 侧声明，通过协议动态发现（tools/list），与模型解耦，任何 LLM 都可以使用。一句话总结：Function Calling 是"模型内能力"，MCP 是"系统级能力"。

小结

从本质上看，MCP 在协议层基于 JSON-RPC 2.0，tools/list、tools/call 本质上是标准的 RPC 调用。传输层（Stdio 或 Streamable HTTP）只是"载体"，真正的核心是"统一的方法调用协议"。

MCP 真正解决的是解耦问题——工具开发者实现一次，就能接入所有平台；平台支持一次，就能调用所有工具。它的生态价值会随着 Server 数量的增长而指数级放大。

当然，MCP 也存在一些挑战：Prompt Injection 可能诱导调用危险工具，Server 往往直接暴露系统能力，协议本身还不规定统一的认证机制。但话说回来，MCP 的出现是为了解决连接问题，而不是安全问题——这是理解这个协议的出发点。