一文详解模型上下文协议MCP

致Great

发布于 2025-04-19 14:35:06

78600

代码可运行

文章被收录于专栏：自然语言处理自然语言处理

运行总次数：0

代码可运行

引言

Anthropic 公司在 2024 年 11 月发布了模型上下文协议 (Model Context Protocol, MCP)。开发者社区最初对此反应积极，但很少有人意识到它的全部潜力。 快进到 2025 年 3 月，MCP 突然成为了人工智能领域最热门的话题。

当流行的消费级 IDE，如 Cursor、Cline 和 Goose 官方宣布支持 MCP 时，这种转变变得显而易见。随着越来越多的客户端应用采用 MCP，服务器端集成变得愈发重要，进一步放大了其影响力。

然而，尽管 MCP 备受瞩目，许多开发者仍然心存疑问：“MCP 到底是什么？我应该关注它吗？这真的是下一个重大技术趋势，还是又一个 AI 炒作？”这些困惑是真实存在的，也是可以理解的。

在本文中，我们将揭开 MCP 的神秘面纱，阐明其用途，并剖析它为何重要（或不重要）。

那么，MCP 究竟是什么？

为了更清晰地说明，MCP 既不是像 LangChain 这样的框架，也不是一个工具；它是一种协议，类似于 Web 的 HTTP 协议或消息传递的 SMTP 协议。

一个更相关的例子是语言服务器协议 (Language Server Protocol, LSP)，它规范了在开发工具生态系统中添加对编程语言支持的方式。类似地，MCP 规范了将额外的上下文和工具集成到 AI 应用生态系统中的方式。

它提供了一套通用规则，允许任何客户端与任何服务器通信，而无需考虑组件的构建者，从而为多样化和可互操作的 AI 生态系统奠定基础。Anthropic 公司将 MCP 定义为智能代理系统的 USB-C 端口。它标准化了 AI 应用、大型语言模型 (LLM) 和外部数据源（数据库、Gmail、Slack 等）之间的连接。

机器是客户端，外围设备是工具，而 MCP 就是 Type-C 端口。因此，无论设备或外围设备由谁制造，它们都可以无缝协作。

图片来源：https://www.linkedin.com/in/norah-klintberg-sakal

MCP 定义了客户端应如何与服务器通信，以及服务器应如何处理工具（API、函数等）和资源（只读文件，如日志、数据库记录等）。稍后将对此进行详细介绍。

为什么你应该关注 MCP？

标准化的优势

统一集成 ：一个用于连接任何 LLM 和任何工具的通用协议。
缩短开发时间 ：用于资源访问和工具执行的标准模式。
清晰的职责分离 ：数据访问（资源）和计算（工具）被清晰地分离。
一致的发现机制 ：用于查找可用功能（工具、资源、提示词、根目录、采样）的统一机制。
跨平台兼容性 ：为一个系统构建的工具可以与其他系统协同工作。

MCP 具有革命性吗？

简短的回答：不。

即使没有 MCP，你也能正常生活。它并不具有革命性，但为原本混乱的智能代理开发领域带来了标准化。如果你的应用符合 MCP 客户端规范，你就可以连接到任何符合 MCP 客户端规范的服务器。在另一种情况下，作为客户端开发者，你必须根据自己的需求定制服务器，其他人也无法为你的平台构建应用。服务器开发者的情况也是如此。

例如，在 Cursor 内部，如果 MCP 服务器遵循协议，你就可以连接到任何 MCP 服务器。

至此，你或多或少应该清楚 MCP 的用途了。现在，让我们更深入地了解 MCP，以获得更清晰的认识。

MCP 架构

模型上下文协议 (MCP) 包含几个协同工作的关键组件。以下是 Matt Pocock 在 Twitter 上发布的高级架构图。

完整的 MCP 架构包含四个部分：

宿主 (Host) ：协调整个系统并管理 LLM 交互。
客户端 (Client) ：将宿主与服务器连接，采用一对一关系。
服务器 (Server) ：通过工具、资源和提示词提供专门的功能。
基础协议 (Base Protocol) ：定义所有这些组件如何通信。

在上面的图表中，客户端和宿主被合并在一起；为了更清晰地说明，我们将它们分开。接下来，让我们详细了解每个组件，从内部理解 MCP。

1. 宿主 (Host)

宿主是期望从服务器获取数据的 LLM 应用。宿主可以是 IDE、聊天机器人或任何 LLM 应用。它们负责：

初始化和管理多个客户端。
客户端-服务器生命周期管理。
处理用户授权决策。
管理跨客户端的上下文聚合。

示例包括 Claude Desktop、Cursor IDE、Windsurf IDE 等。

2. 客户端 (Client)

每个客户端都有以下关键职责：

专用连接 ：每个客户端与单个服务器保持一对一的有状态连接。这种专注的关系确保了清晰的通信边界和安全隔离。
消息路由：客户端处理所有双向通信，高效地在宿主和其连接的服务器之间路由请求、响应和通知。我们将在 Cursor IDE 与Linear 和 Slack 的示例中看到一个简单的例子。
功能管理 ：客户端通过维护有关可用工具、资源（上下文数据）和提示模板的信息，来监控其连接的服务器的功能。
协议协商 ：在初始化期间，客户端协商协议版本和功能，确保宿主和服务器之间的兼容性。
订阅管理 ：客户端维护对服务器资源的订阅，并在这些资源发生更改时处理通知事件。

3. 服务器 (Server)

服务器是丰富 LLM 外部数据和上下文的基本构建块。关键的服务器原语包括：

工具 (Tools) ：可执行函数，允许 LLM 与外部应用交互。工具的功能类似于传统 LLM 调用中的函数。工具可以是向 API 端点发送的POST 请求；例如，一个名为 LIST_FILES 的工具，以目录名作为参数，将获取目录中的文件并将它们发送回客户端。工具也可以是对外部服务（如 Gmail、Slack、Notion 等）的 API 调用。
资源 (Resources) ：可以是任何类型的数据，例如文本文件、日志文件、数据库模式、文件内容和 Git 历史记录。它们为 LLM 提供额外的上下文信息。
提示模板 (Prompt Templates) ：预定义的模板或指令，用于指导语言模型的交互。

工具由模型控制，而资源和提示词由用户控制。模型可以根据给定的上下文自动发现和调用工具。

MCP 中的 “协议 (Protocol)”

协议构成了模型上下文协议 (MCP) 架构的基础。它定义了不同组件（宿主、客户端和服务器）之间的通信方式。有关更深入的信息，请参阅官方的 MCP 规范。

MCP 的底层结构（协议层）

该协议由几个关键层组成：

协议消息 (Protocol Message) ：核心 JSON-RPC 消息类型。
生命周期管理 (Lifecycle Management) ：客户端-服务器连接初始化、功能协商和会话控制。
传输机制 (Transport Mechanisms) ：客户端-服务器如何交换消息，通常有两种类型：用于本地服务器的 Stdio 和用于托管服务器的 SSE (服务器发送事件)。
服务器功能 (Server Features) ：服务器暴露的资源、提示词和工具。
客户端功能 (Client Features) ：客户端提供的采样和根目录列表。

在以上五个层中，基础协议，即 JSON-RPC 消息类型和生命周期管理，对于每个 MCP 实现都至关重要。其他组件可以根据特定应用的需求来实现。

协议的关键部分

1. 消息 (Messages)

MCP 的核心是使用 JSON-RPC 2.0 作为其消息传递格式，为客户端和服务器之间的通信提供了一种标准化的方式。基础协议定义了三种基本的消息类型：

请求 (Requests) ：用于启动从客户端到服务器或反之亦然的操作的消息。示例：

{
  "jsonrpc": "2.0",
  "id": "string | number",
  "method": "string",
  "params"?: {
    "[key: string]": "unknown"
  }
}

响应 (Responses) ：为响应请求而发送的消息。

{
  "jsonrpc": "2.0",
  "id": "string | number",
  "result"?: {
    "[key: string]": "unknown"
  },
  "error"?: {
    "code": "number",
    "message": "string",
    "data"?: "unknown"
  }
}

通知 (Notifications) ：不需要响应的单向消息。

{"jsonrpc": "2.0",
  "method": "string",
  "params"?: {
    "[key: string]": "unknown"
  }
}

2. 传输机制 (Transport Mechanisms)

该协议可以基于不同的传输层实现，具体取决于部署需求：

stdio ：通过标准输入/输出流进行通信。
- 客户端和服务器通过标准输入 (stdin) 接收 JSON 消息，并通过标准输出 (stdout) 响应。
- 简化了本地进程集成和调试。
- 非常适合本地服务器，如文件服务器、Git 服务器等。

基于服务器发送事件 (Server-Sent Events, SSE) 的 HTTP ：
- 通过 HTTP 建立双向通信模式。
- 服务器维护一个 SSE 连接，用于向客户端推送消息。
- 客户端通过标准的 HTTP POST 请求发送命令。
- 支持具有多个并发客户端的分布式架构。
- 更适合托管服务器。

自定义传输 (Custom transports) ：实现可以根据需要创建额外的传输机制。

3. 生命周期管理 (Lifecycle Management)

基础协议为客户端和服务器之间的连接实现了结构化的生命周期：

初始化阶段 (Initialization Phase) ：
- 客户端和服务器协商协议版本。
- 它们交换功能信息（客户端与服务器共享工具和采样功能，服务器与客户端共享工具、资源和提示词）。
- 它们共享实现细节。
操作阶段 (Operation Phase) ：
- 进行正常的协议通信。- 双方都遵守协商好的功能。
关闭阶段 (Shutdown Phase) ：
- 优雅地终止连接。

MCP 交互生命周期：Cursor IDE 到 Linear/Slack 示例

让我们通过一个简单的例子来理解我们目前所学的内容。其中：

宿主是 Cursor IDE。
服务器是 Linear 和 Slack。

以下是 MCP 交互生命周期过程的详细工作流程：

初始化阶段 (Initialization Phase)

建立连接 (Connection Establishment) ：当用户在 Cursor IDE 中激活 Linear 集成时，IDE 会启动与 Linear MCP 服务器的连接，通常通过 stdio 或WebSockets。
功能协商 (Capability Negotiation) ：
- Cursor 发送一个 initialize 请求，其中包含其功能（它支持的功能）。
- Linear 服务器响应其功能（可用的资源、工具、协议版本）。
- Cursor 评估兼容性，确保双方都支持必要的协议功能。
功能发现 (Feature Discovery) ：
- Cursor 请求可用的工具 (tools/list)。
- Linear 响应工具列表，例如 create_ticket、assign_ticket、add_comment 等。
就绪通知 (Ready Notification) ：Cursor 发送一个 initialized 通知，表明它已准备好开始正常操作。

操作阶段 (Operation Phase)

工具执行 (Tool Execution) ：
- 用户告诉 Cursor：“创建一个关于登录页面崩溃的 Bug 工单”。 -Cursor 中的 LLM 确定需要使用一个工具。
- Cursor 发送一个 tools/call 请求，调用 create_ticket 工具，并附带适当的参数。
- Linear 服务器创建工单并返回结果。
- Cursor 向用户显示结果。
跨服务集成 (Cross-Service Integration) ：
- 用户说：“在 Slack 上通知团队关于这个新工单”。
- Cursor 连接到 Slack MCP 服务器（一个单独的连接，有自己的生命周期）。
- Cursor 向 Slack 服务器发送一个 tools/call 请求。
- Slack服务器发布消息并返回成功状态。
- Cursor 确认通知已发送。

维护阶段 (Maintenance Phase)

健康检查 (Health Checks) ：
- Cursor 定期发送 ping 请求，以确保连接仍然存活。
- Linear 服务器响应以确认可用性。

终止阶段 (Termination Phase)

优雅关闭 (Graceful Shutdown) ：
- 当用户关闭工作区或禁用集成时。
- Cursor 向 Linear 发送一个 shutdown 请求。
- Linear 确认收到响应。 -Cursor 发送一个 exit 通知。
- Linear 服务器释放与会话关联的资源。
错误恢复 (Error Recovery) ：
- 如果连接意外失败。
- Cursor 实现带有指数退避的重试逻辑。
- 成功重新连接后，初始化生命周期重新开始。

这种标准化的生命周期确保了任何 MCP 宿主和服务器之间可靠、可预测的交互，而无需考虑它们的具体实现。无论是 Cursor 连接到 Linear 进行工单管理，还是连接到 Slack 进行消息传递，都应用相同的协议模式，从而使集成保持一致性和互操作性。