MCP（Model Context Protocol）模型上下文协议 进阶篇1 - 组件和功能

前言

在准备实战篇2的代码部分时，我意识到之前的架构篇虽然对MCP的整体设计进行了介绍，但关于具体的消息交互细节描述得还不够详细。然而，在实际开发中，消息交互的细节往往是最关键的部分。因此，我决定再开一篇新的进阶篇，作为理论篇向实战篇的过渡，详细说明开发过程中会实际用到的具体组件和功能。希望通过这篇文章，能够帮助大家更好地理解MCP的实际应用场景，并为后续的实战开发打下坚实的基础。

架构概述

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

核心组件

主机（Host）

主机进程作为容器和协调者：

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

客户端（Clients）

每个客户端由主机创建并维护一个独立的服务器连接：

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

服务器（Servers）

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

• 通过MCP原语暴露资源、工具和提示
• 独立运行并专注于特定职责
• 通过客户端接口请求采样
• 必须遵守安全约束
• 可以是本地进程或远程服务

设计原则

MCP基于以下关键设计原则：

• 服务器应易于构建
• 主机应用程序处理复杂的编排责任
• 服务器专注于特定的、定义明确的能力
• 简单的接口最小化实现开销
• 清晰的分离使代码易于维护
• 服务器应高度可组合
• 每个服务器提供隔离的功能
• 多个服务器可以无缝组合
• 共享协议实现互操作性
• 模块化设计支持可扩展性
• 服务器不应能够读取整个对话，也不能“窥探”其他服务器
• 服务器仅接收必要的上下文信息
• 完整的对话历史保留在主机中
• 每个服务器连接保持隔离
• 跨服务器交互由主机控制
• 主机进程执行安全边界
• 可以逐步向服务器和客户端添加功能

消息类型

MCP定义了三种基于JSON-RPC 2.0的核心消息类型：

• 请求（Requests）：双向消息，带有方法和参数，期望响应
• 响应（Responses）：成功的结果或与特定请求ID匹配的错误
• 通知（Notifications）：无需响应的单向消息

能力协商

MCP使用基于能力（Capabilities）的协商系统，客户端和服务器在初始化期间明确声明其支持的功能。能力决定了会话期间可用的协议功能和原语。

例如：

支持资源的服务器必须声明resources功能：

{
  "capabilities": {
    "resources": {
      "subscribe": true,
      "listChanged": true
    }
  }
}

该功能支持两个可选特性：

• subscribe：客户端是否可以订阅以接收单个资源的变更通知（Notifications）。
• listChanged：服务器是否会在可用资源列表发生变化时发出通知（Notifications）。

subscribe 和 listChanged 都是可选的——服务器可以不支持任何特性，也可以支持其中一个或两个

总结

MCP通过客户端-主机-服务器架构，实现了AI能力的集成，同时保持了安全边界和关注点的隔离。其设计原则确保了服务器的易构建性、可组合性和安全性，并通过能力协商机制实现了协议的灵活扩展。MCP的核心消息类型和能力协商机制使其成为一个强大且可扩展的协议，适用于多种AI应用场景。

在下一章的进阶篇中，我们将深入探讨MCP的详细消息格式和生命周期管理。这些内容是实际开发中不可或缺的部分，能够帮助大家更好地理解MCP的内部机制，并为实战开发提供更具体的指导。希望通过进阶篇的详细解释，能够让大家在实际项目中更加得心应手。