MCP 架构
类别: MCP LLM 标签: MCP LLM目录
模型上下文协议(MCP)采用客户端-主机-服务器架构,每个主机可以运行多个客户端实例。这种架构使用户能够跨应用程序集成AI功能,同时保持明确的安全边界和关注点隔离。MCP基于JSON-RPC构建,提供专注于客户端和服务器之间上下文交换和采样协调的有状态会话协议。
核心组件
graph LR
subgraph "应用程序主机进程"
H[主机]
C1[客户端 1]
C2[客户端 2]
C3[客户端 3]
H --> C1
H --> C2
H --> C3
end
subgraph "本地机器"
S1[服务器 1<br>Files 和 Git]
S2[服务器 2<br>数据库]
R1[("本地<br>资源 A")]
R2[("本地<br>资源 B")]
C1 --> S1
C2 --> S2
S1 <--> R1
S2 <--> R2
end
subgraph "互联网"
S3[服务器 3<br>外部API]
R3[("远程<br>资源 C")]
C3 --> S3
S3 <--> R3
end
主机
主机进程作为容器和协调器:
- 创建和管理多个客户端实例
- 控制客户端连接权限和生命周期
- 执行安全策略和同意要求
- 处理用户授权决策
- 协调AI/LLM集成和采样
- 管理跨客户端的上下文聚合
客户端
每个客户端由主机创建,并维护独立的服务器连接:
- 每个服务器建立一个有状态会话
- 处理协议协商和能力交换
- 双向路由协议消息
- 管理订阅和通知
- 维护服务器之间的安全边界
主机应用程序创建和管理多个客户端,每个客户端与特定服务器保持1:1关系。
服务器
服务器提供专门的上下文和功能:
- 通过MCP原语公开资源、工具和提示
- 独立运行,职责明确
- 通过客户端接口请求采样
- 必须遵守安全约束
- 可以是本地进程或远程服务
设计原则
MCP基于几个关键设计原则,这些原则指导其架构和实现:
-
服务器应该极易构建
- 主机应用程序处理复杂的编排责任
- 服务器专注于特定、明确定义的功能
- 简单接口最小化实现开销
- 清晰分离使代码可维护
-
服务器应高度可组合
- 每个服务器在隔离环境中提供专注功能
- 多个服务器可以无缝组合
- 共享协议实现互操作性
- 模块化设计支持可扩展性
-
服务器不应能读取整个对话,也不应”窥视”其他服务器
- 服务器仅接收必要的上下文信息
- 完整对话历史保留在主机中
- 每个服务器连接保持隔离
- 跨服务器交互由主机控制
- 主机进程执行安全边界
-
功能可以逐步添加到服务器和客户端
- 核心协议提供最低所需功能
- 可根据需要协商附加功能
- 服务器和客户端独立演化
- 协议设计支持未来扩展性
- 保持向后兼容性
能力协商
模型上下文协议使用基于能力的协商系统,客户端和服务器在初始化过程中明确声明其支持的功能。能力决定会话期间可用的协议功能和原语。
- 服务器声明能力,如资源订阅、工具支持和提示模板
- 客户端声明能力,如采样支持和通知处理
- 双方必须在整个会话期间尊重声明的能力
- 可以通过协议扩展协商附加能力
sequenceDiagram
participant Host
participant Client
participant Server
Host->>+Client: 初始化客户端
Client->>+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: 资源更新
Client--)Server: 状态变更
end
Host->>Client: 终止
Client->>-Server: 结束会话
deactivate Server
每项能力在会话期间解锁特定的协议功能。例如:
- 已实现的服务器功能必须在服务器的能力中公布
- 发出资源订阅通知需要服务器声明订阅支持
- 工具调用需要服务器声明工具能力
- 采样需要客户端在其能力中声明支持
这种能力协商确保客户端和服务器明确理解支持的功能,同时保持协议的可扩展性。