模型上下文协议 (MCP) -架构

根据官方规范-架构 -- Model Context Protocol （MCP），MCP的核心架构可以用一张图来概括：

```mermaid

flowchart TB

subgraph Host $"应用程序主机进程"$

direction TB

H $主机$ --> C1 $客户端 1$

H --> C2 $客户端 2$

H --> C3 $客户端 3$

end

subgraph Local $"本地环境"$

S1 $服务器 1\（文件、Git）$ --> R1 $(本地资源)$

S2 $服务器 2\（数据库）$ --> R2 $(本地资源)$

end

subgraph Remote $"远程服务"$

S3 $服务器 3\（外部API）$ --> R3 $(远程资源)$

end

C1 --> S1

C2 --> S2

C3 --> S3

```

这张图清晰地展示了三个核心组件的关系，下面我为你逐一拆解。

🧩 核心组件职责

从开发视角看，这三个组件各司其职，共同构成了MCP的骨架：

| 组件 | 核心职责 | 关键点 |

| :--- | :--- | :--- |

| **主机 (Host)** | 是用户环境和AI交互的**协调者与容器**。 | 负责创建和管理多个客户端实例、控制连接权限、执行安全策略，并协调AI（如LLM）与客户端的交互。它是用户与MCP世界交互的入口。 |

| **客户端 (Client)** | 是与服务器建立**一对一连接**的会话管理者。 | 每个客户端由主机创建，并**只能连接到一个服务器**。它负责协议协商、消息路由和维护与服务器之间的安全边界。 |

| **服务器 (Server)** | 是**专业能力的提供者**，专注于具体功能。 | 通过资源、工具和提示等原语暴露能力，可以运行在本地或远程。它只处理自己职责范围内的请求，不感知其他服务器的存在。 |

🎯 核心设计原则

官方规范中强调的几个设计原则，对开发者理解架构意图至关重要：

**服务器要简单可组合**：服务器只聚焦单一功能，像"乐高积木"一样。主机负责将这些"积木"组合起来提供给AI。
**服务器要高度隔离**：每个服务器只能获取完成任务所必需的上下文，**无法读取完整对话或感知其他服务器**。这既是安全边界，也是隐私保护。
**能力协商是基础**：客户端和服务器在建立会话时，会通过初始化握手明确声明各自支持的能力（如：服务器是否支持工具调用？客户端是否支持AI采样？），后续通信严格遵守这些约定。

🔄 基础通信模式与能力协商

基于上述组件和原则，MCP的通信自然衍生出两种基础模式：

* **本地进程通信 (Stdio)**：当服务器与客户端在同一主机时，通常通过标准输入/输出进行通信。这是实现本地隔离的常用方式。

* **远程网络通信 (SSE/HTTP)**：当服务器作为独立服务远程部署时，客户端通过Server-Sent Events或HTTP流与其交互。

无论是哪种模式，通信都遵循**JSON-RPC 2.0**格式，并通过**能力协商**确保双方"说同一种语言"。下面是官方的协商和交互流程：

```mermaid

sequenceDiagram

participant Host

participant Client

participant Server

Host->>+Client: 初始化客户端

Client->>+Server: 初始化（携带自身能力）

Server-->>Client: 初始化响应（携带自身能力）

Note over Host,Server: 会话建立，能力已知

loop 客户端请求（如调用工具）

Host->>Client: 用户或AI发起的操作

Client->>Server: 请求（工具/资源）

Server-->>Client: 响应

Client-->>Host: 更新UI或响应模型

end

loop 服务器请求（如请求AI采样）

Server->>Client: 采样请求

Client->>Host: 转发给AI

Host-->>Client: AI响应

Client-->>Server: 采样结果

end

Host->>Client: 终止会话

Client->>-Server: 结束会话

```

🔗 从官方架构到部署模式

理解了上述核心，我们再回看你之前提到的各种部署模式，就能明白它们都是在官方架构框架内的合理变体：

* **多Server聚合模式**：这正是**主机创建多个客户端**，每个客户端连接一个服务器的标准用法。主机负责聚合所有服务器的能力。

* **链式代理模式**：一个服务器本身可以作为一个**嵌套的"主机"**，在其内部创建自己的客户端去连接其他服务器。这并不违反规范，但要求这个"代理服务器"承担起主机的部分协调职责。

* **混合部署模式**：完美体现了"服务器可以是本地进程或远程服务"的灵活性。主机可以通过不同的客户端，同时管理stdio连接和SSE连接。

💡 开发者要点总结

**主机是核心**：实现一个MCP主机是最复杂的部分，因为它要负责管理多个客户端、聚合上下文、与AI交互并执行安全策略。
**服务器尽量精简**：开发服务器时，保持功能单一和明确。它不需要关心外部环境，只需通过协议暴露自己的能力。
**能力协商是起点**：在设计客户端或服务器时，首先明确自己支持的能力，并在初始化阶段正确声明。这是保证互操作性的关键。
**安全隔离是红线**：永远不要在设计上打破"服务器无法看到完整对话"的边界。这是MCP安全模型的基础。

希望这份梳理能帮助你更好地理解MCP架构。如果你在开发具体组件（如实现一个特定功能的服务器，或设计主机聚合逻辑）时有更深入的问题，我们可以继续探讨。