架构

模型上下文协议 (MCP) 采用客户端-宿主-服务器 (client-host-server) 架构，每个宿主可以运行多个客户端实例。这种架构使用户能够在集成各应用程序 AI 能力的同时，保持清晰的安全边界并隔离关注点。MCP 基于 JSON-RPC 构建，提供了一种有状态的会话协议，专注于客户端与服务器之间的上下文交换和采样协调。

​

核心组件

​

宿主 (Host)

宿主进程充当容器和协调者

• 创建并管理多个客户端实例
• 控制客户端连接权限和生命周期
• 执行安全策略和同意要求
• 处理用户授权决策
• 协调 AI/LLM 集成和采样
• 跨客户端管理上下文聚合

​

客户端 (Clients)

每个客户端由宿主创建，并维护一个隔离的服务器连接

• 为每个服务器建立一个有状态会话
• 处理协议协商和能力交换
• 双向路由协议消息
• 管理订阅和通知
• 维护服务器之间的安全边界

宿主应用程序创建并管理多个客户端，每个客户端与特定的服务器保持 1:1 的关系。

​

服务器 (Servers)

服务器提供专门的上下文和功能

• 通过 MCP 原语公开资源、工具和提示词
• 独立运行，职责明确
• 通过客户端接口请求采样
• 必须遵守安全约束
• 可以是本地进程或远程服务

​

设计原则

MCP 基于几个关键设计原则构建，这些原则指导了其架构和实现

1. 服务器应该极易构建
   • 宿主应用程序处理复杂的编排职责
   • 服务器专注于特定的、定义明确的功能
   • 简单的接口最大限度地减少了实现开销
   • 清晰的分离实现了可维护的代码
2. 服务器应该是高度可组合的
   • 每个服务器独立提供专注的功能
   • 多个服务器可以无缝组合
   • 共享协议实现了互操作性
   • 模块化设计支持扩展性
3. 服务器不应能够读取整个对话，也不应能“透视”其他服务器
   • 服务器仅接收必要的上下文信息
   • 完整的对话历史记录保留在宿主中
   • 每个服务器连接保持隔离
   • 跨服务器交互由宿主控制
   • 宿主进程强制执行安全边界
4. 功能可以逐步添加到服务器和客户端中
   • 核心协议提供最基本的必要功能
   • 可以根据需要协商额外的能力
   • 服务器和客户端独立演进
   • 协议设计考虑了未来的扩展性
   • 保持向后兼容性

​

能力协商

模型上下文协议使用基于能力的协商系统，客户端和服务器在初始化期间明确声明其支持的功能。能力决定了会话期间哪些协议功能和原语可用。

• 服务器声明资源订阅、工具支持和提示词模板等能力
• 客户端声明采样支持和通知处理等能力
• 双方在整个会话期间必须遵守声明的能力
• 可以通过协议扩展协商额外的能力

每种能力都解锁了会话中使用的特定协议功能。例如：

• 实现的 服务器功能 必须在服务器能力中公开
• 发出资源订阅通知需要服务器声明订阅支持
• 工具调用需要服务器声明工具能力
• 采样 需要客户端在能力中声明支持

这种能力协商确保了客户端和服务器对所支持的功能有清晰的了解，同时保持了协议的可扩展性。