1. 什么是 MCP 架构？ #
MCP 架构采用「主机 - 客户端 - 服务器」三层模型：一个主机（AI 应用）可运行多个客户端，每个客户端连接一个服务器。该设计让 AI 能安全、模块化地接入外部数据和工具。
| 通俗理解 | 说明 |
|---|---|
| 主机 = 总指挥 | AI 应用（如 Claude Desktop、VS Code）负责协调、授权、聚合上下文 |
| 客户端 = 对接代表 | 每个服务器对应一个客户端，维护独立会话，互不干扰 |
| 服务器 = 能力提供方 | 提供工具、资源、提示，可以是本地进程或远程服务 |
MCP 基于 JSON-RPC 构建，提供有状态会话，专注于客户端与服务器之间的上下文交换和采样协调。
2. 本章你将学到 #
- 主机、客户端、服务器各自的职责
- 三者如何协作（请求、响应、通知）
- 设计原则与能力协商机制
- 如何在本系列文档中继续深入学习
3. 架构一览 #
┌─────────────────────────────────────────────────────────┐
│ 主机（AI 应用） │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 客户端 1 │ │ 客户端 2 │ │ 客户端 3 │ ... │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
└───────┼─────────────┼─────────────┼──────────────────────┘
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 服务器 1 │ │ 服务器 2 │ │ 服务器 3 │ （文件、数据库、API…）
└─────────┘ └─────────┘ └─────────┘要点：一个主机 → 多个客户端 → 每个客户端 1:1 连接一个服务器。
4. 核心组件 #
4.1 架构图 #
flowchart LR
subgraph Host[主机进程]
MCPHost[MCP主机]
Client1[Git客户端]
Client2[DB客户端]
Client3[API客户端]
end
subgraph Local[本地环境]
GitServer[Git服务器]
DBServer[数据库服务器]
LocalFS[本地文件系统]
DB[(数据库)]
end
subgraph Remote[远程环境]
APIServer[API服务器]
CloudAPI[云服务]
end
MCPHost --> Client1 & Client2 & Client3
Client1 --> GitServer --> LocalFS
Client2 --> DBServer --> DB
Client3 --> APIServer --> CloudAPI
4.2 主机 #
主机是容器和协调者，负责：
| 职责 | 说明 |
|---|---|
| 管理客户端 | 创建、销毁客户端，控制连接权限和生命周期 |
| 安全与授权 | 执行安全策略、同意要求，处理用户授权决策 |
| AI 集成 | 协调 LLM 与采样，管理跨客户端的上下文聚合 |
举例：Claude Desktop 作为主机，管理多个 MCP 客户端，每个客户端连接一个服务器（文件、Git、Sentry 等）。
4.3 客户端 #
每个客户端由主机创建，与一个服务器保持 1:1 连接：
| 职责 | 说明 |
|---|---|
| 有状态会话 | 为每个服务器建立并维护独立会话 |
| 协议协商 | 处理能力交换、双向路由协议消息 |
| 订阅与通知 | 管理资源订阅、接收服务器通知 |
| 安全边界 | 保持服务器之间的隔离，不跨服务器泄露数据 |
4.4 服务器 #
服务器提供专门的上下文和能力：
| 职责 | 说明 |
|---|---|
| 暴露原语 | 通过 MCP 提供资源、工具、提示 |
| 职责聚焦 | 独立运行，每个服务器专注一类能力 |
| 请求采样 | 通过客户端接口请求 LLM 采样（若客户端支持） |
| 遵守约束 | 必须遵守安全约束；可以是本地进程或远程服务 |
举例：文件系统服务器提供 read_file、list_dir；Sentry 服务器提供错误查询工具。
5. 设计原则 #
MCP 基于以下设计原则构建：
| 原则 | 通俗理解 |
|---|---|
| 服务器易于构建 | 主机承担复杂编排，服务器只做具体、定义明确的能力；接口简单，代码易维护 |
| 服务器高度可组合 | 每个服务器聚焦单一功能，多个服务器可无缝组合；共享协议实现互操作 |
| 服务器不能读取完整对话 | 服务器仅接收必要上下文；完整对话历史保留在主机；每个连接隔离，跨服务器交互由主机控制 |
| 功能可渐进式添加 | 核心协议提供最小必需功能；可按需协商额外能力；服务器和客户端独立演进，保持向后兼容 |
6. 能力协商 #
6.1 什么是能力协商？ #
在初始化会话时，客户端和服务器会显式声明各自支持的功能。只有声明的能力，才能在会话中使用。
| 声明方 | 可声明的能力示例 |
|---|---|
| 服务器 | 资源订阅、工具支持、提示模板等 |
| 客户端 | 采样支持、通知处理等 |
双方在整个会话期间必须遵守已声明的能力；可通过协议扩展协商额外能力。
6.2 能力与功能的对应关系 #
| 能力 | 解锁的功能 |
|---|---|
| 服务器声明工具 | 客户端可调用该服务器的工具 |
| 服务器声明资源订阅 | 可发送资源变更通知 |
| 客户端声明采样 | 服务器可请求客户端发起 LLM 采样 |
6.3 会话流程示意 #
sequenceDiagram
participant Host as 主机
participant Client as 客户端
participant Server as 服务器
Host->>Client: 初始化客户端
activate Client
Client->>Server: 初始化会话，协商能力
activate Server
Server-->>Client: 返回支持的能力
Note over Host,Server: 活跃会话，已协商功能
loop 客户端请求（用户/模型发起）
Host->>Client: 操作请求
Client->>Server: 请求（工具/资源）
Server-->>Client: 响应
Client-->>Host: 更新 UI 或响应模型
end
loop 服务器请求（采样等）
Server->>Client: 请求（采样）
Client->>Host: 转发给 AI
Host-->>Client: AI 响应
Client-->>Server: 响应
end
loop 通知
Server--)Client: 资源更新
Server--)Client: 状态变更
end
Host->>Client: 终止
deactivate Client
Client->>Server: 结束会话
deactivate Server