MCP架构深度解析

MCP 三层架构

Model Context Protocol (MCP) 的核心在于其优雅的三层架构，它将 AI 应用的不同关注点清晰地分离。这种设计不仅提升了模块化程度，还极大地增强了系统的可扩展性和安全性。这三层分别是：Hosts、Clients 和 Servers。

Host 是用户直接交互的前端应用程序。把它想象成一个容器或平台，例如像 Cursor 这样的 AI 原生代码编辑器，或者 Claude Desktop 这样的桌面应用。Host 的主要职责是管理用户界面、处理用户输入，并决定何时以及如何与 AI 模型交互。它本身不直接与外部工具通信，而是将这个任务委托给 Client。

Client (在 MCP 规范中也称为 MCP Host) 是整个架构的“大脑”和协调中心。它位于 Host 内部，负责管理与一个或多个 Server 的连接。Client 的核心任务是：

发现 Servers 提供的能力 (Tools, Resources)。
将来自 Host 的用户请求和上下文信息整合成对 LLM 的提示 (prompt)。
解析 LLM 的响应，如果响应中包含调用工具的指令，则将该指令路由到相应的 Server 执行。

Server (MCP Server) 是一个独立的进程，它将外部数据源或功能“封装”成 MCP 标准接口。每个 Server 都专注于一项特定能力，比如连接到 GitHub API、查询公司内部数据库或与 Slack 工作区交互。这种设计将工具的具体实现细节与 Client 和 LLM 完全解耦，使得添加新工具就像启动一个新的 Server 一样简单。

MCP 采用客户端-服务器架构，其中 MCP 主机（例如 Claude Code 或 Claude Desktop 等 AI 应用程序）建立与一个或多个 MCP 服务器的连接。

这种分层方法使得系统非常灵活。你可以为同一个 Host 应用连接任意数量的 Server，每个 Server 提供不同的功能，而无需修改 Host 或 Client 的核心代码。这正是 MCP 被称为“AI 时代的 USB 接口”的原因：即插即用，轻松扩展。

通信与生命周期

为了确保不同组件之间能够顺畅、可靠地通信，MCP 选择了一个经过实践检验的协议：JSON-RPC 2.0。这是一种轻量级的远程过程调用 (RPC) 协议，使用 JSON 进行数据编码。所有 MCP 消息，无论是请求、响应还是通知，都遵循其严格的规范。

一个典型的交互流程如下：

Client 发送请求：Client 希望执行某个 Server 上的操作，于是构造一个 JSON-RPC 请求。该请求包含方法名（例如 tools/execute）和参数（例如工具名称和输入）。
Server 处理并响应：Server 接收到请求，执行相应的逻辑，然后返回一个 JSON-RPC 响应，其中包含结果或错误信息。

// Client -> Server: 请求执行一个名为 "get_repo_issues" 的工具
{
  "jsonrpc": "2.0",
  "method": "tools/execute",
  "params": {
    "tool_name": "get_repo_issues",
    "inputs": {
      "owner": "my-org",
      "repo": "my-project"
    }
  },
  "id": 1
}

// Server -> Client: 响应，返回获取到的 issue 列表
{
  "jsonrpc": "2.0",
  "result": [
    { "id": 123, "title": "Fix the login bug" },
    { "id": 124, "title": "Update documentation" }
  ],
  "id": 1
}

在任何通信开始之前，Client 和 Server 之间必须经历一个明确的生命周期管理过程，这通常被称为“握手”或能力协商 (Capability Negotiation)。

当 Client 启动并连接到一个 Server 时，它会首先发送一个 initialize 请求。Server 收到后，会返回自己的元数据，详细说明它提供哪些 Resources、Tools 和 Prompts。这个过程确保了 Client 确切地知道 Server 能做什么，从而可以有效地将这些能力呈现给 LLM。这种启动时的协商机制避免了硬编码和配置错误，是 MCP 鲁棒性的关键所在。

核心原语

MCP 的强大之处在于它将所有外部信息和功能抽象为三个核心原语。这种抽象为 LLM 提供了一个统一且结构化的世界观，使其能够一致地处理不同来源的数据和工具。

原语 (Primitive)	类型	描述
Resources	静态数据	表示 LLM 可以“读取”的上下文信息。这通常是相对静态的数据，如打开的文件内容、项目的文件树结构或数据库的 schema。
Tools	动态操作	表示 LLM 可以“执行”的动作。这些是函数或 API 调用，能够改变状态或从外部世界获取动态信息，例如发送 Slack 消息、执行终端命令或运行数据库查询。
Prompts	预定义模板	为常见任务提供的高质量、可复用的提示片段。例如，一个用于“根据代码生成文档”的 Prompt Server 可以为 LLM 提供一个精心设计的模板，确保输出质量。

通过这三个原语，MCP 将复杂的外部世界分解为 LLM 易于理解和操作的构建块。当 Client 准备向 LLM 发出请求时，它会将当前可用的 Resources、Tools 和 Prompts 一并打包，作为上下文提供给模型。这样，LLM 就不仅仅是在回答问题，而是在一个丰富且可交互的环境中进行推理和行动。

传输协议的选择

为了在 Client 和 Server 之间传输 JSON-RPC 消息，MCP 支持两种主要的传输协议，开发者可以根据具体场景进行权衡选择。

STDIO (Standard I/O) 这种模式下，Client 和 Server 通过标准输入/输出流进行通信。Client 启动 Server 进程，然后通过 Server 进程的 stdin 写入请求，并从其 stdout 读取响应。这种方式非常适合本地部署，例如在代码编辑器插件中，Host 可以直接管理 Server 进程的生命周期。它的优点是设置简单、延迟低，并且不需要网络配置。

HTTP Streaming (SSE - Server-Sent Events) 当 Server 需要部署在远程机器上时，或者需要支持多个 Client 连接时，HTTP Streaming 是更好的选择。在这种模式下，Server 作为一个标准的 HTTP 服务器运行，Client 通过 HTTP 连接与之通信。使用 SSE 允许 Server 主动向 Client 推送更新（例如，文件系统发生了变化），这对于需要实时更新上下文的场景至关重要。它的优点是支持网络通信、可伸缩性好，但相比 STDIO 会有更高的网络延迟和配置复杂性。

MCP 的设计允许这两种模式共存，为不同的应用场景提供了灵活性。

现在，让我们来测试一下你对 MCP 架构的理解。

Quiz Questions 1/5

MCP 架构的核心由哪三个主要层级组成？

Quiz Questions 2/5

在 MCP 中，哪个组件负责将外部功能（如 GitHub API）封装成标准接口供 AI 模型使用？

理解 MCP 的三层架构、通信机制和核心原语，是构建可扩展、模块化 AI 应用的关键。通过将能力封装在独立的 Server 中，并通过标准化的 Client 进行协调，MCP 为解决日益复杂的 AI 集成挑战提供了一个强大而灵活的框架。

MCP 协议深度实战与架构应用