MCP架构与工作原理
深入理解MCP的技术架构、核心组件和通信机制
2.1 MCP架构概览
MCP采用经典的Client-Server（客户端-服务端）架构，基于JSON-RPC 2.0协议进行通信。这种设计既保证了协议的通用性，又提供了足够的灵活性来支持各种应用场景。
2.1.1 整体架构图
┌─────────────────────────────────────────────────────────────────────────────┐
│ MCP 整体架构 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ MCP Host（主机应用） │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ MCP │ │ MCP │ │ MCP │ │ │
│ │ │ Client 1 │ │ Client 2 │ │ Client N │ │ │
│ │ │ (Git工具) │ │ (数据库) │ │ (文件系统)│ │ │
│ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │ │
│ │ └──────────────────┼──────────────────┘ │ │
│ │ │ │ │
│ │ ┌─────────┴─────────┐ │ │
│ │ │ AI 模型核心 │ ← 推理引擎 │ │
│ │ │ (Claude/GPT等) │ │ │
│ │ └─────────────────┘ │ │
│ │ │ │
│ │ 示例：Claude Desktop / Cursor / Zed Editor │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ JSON-RPC 2.0 通信协议 │ │
│ (stdio / HTTP / WS) │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ MCP Servers（服务层） │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Git MCP │ │ PostgreSQL │ │ Filesystem │ │ │
│ │ │ Server │ │ MCP Server │ │ MCP Server │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Slack MCP │ │ Brave │ │ Custom │ │ │
│ │ │ Server │ │ Search │ │ MCP Server │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
📐 架构核心特点：
- 解耦设计：Host和Server相互独立，可以独立开发和部署
- 多对多关系：一个Host可以连接多个Server，一个Server可以被多个Host使用
- 标准协议：基于成熟的JSON-RPC 2.0协议，降低实现门槛
- 灵活传输：支持多种传输方式（stdio、HTTP、WebSocket）
2.2 核心组件详解
MCP架构包含三个核心角色，每个角色都有明确的职责和边界。理解这些组件是掌握MCP的关键。
2.2.1 MCP Host（主机应用）
Host是运行AI模型的应用程序，它是用户与AI交互的入口，也是MCP生态系统的"宿主"。
🏠 Host的核心职责：
- 承载AI模型：提供模型推理能力（如Claude、GPT等）
- 管理MCP Client：创建、配置和维护与各个Server的连接
- 协调交互：判断何时调用工具、传递哪些参数、如何处理结果
- 用户界面：提供用户与AI交互的界面（GUI或CLI）
| Host示例 | 类型 | 特点 |
|---|---|---|
| Claude Desktop | 桌面应用 | 官方支持，配置简单，适合日常使用 |
| Cursor | 代码编辑器 | 编程场景优化，支持复杂开发工作流 |
| Zed | 代码编辑器 | 高性能，原生MCP支持 |
| Cody | IDE插件 | 企业级，深度集成开发工具链 |
2.2.2 MCP Client（客户端）
Client是Host内部的具体实现，负责与一个特定的MCP Server建立和维护连接。可以把Client看作是Host和Server之间的"翻译官"。
┌─────────────────────────────────────────────────────────────────┐
│ MCP Client 内部结构 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌───────────────────────────────────────────────────────────┐ │
│ │ MCP Client │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────────────┐ │ │
│ │ │ Transport Layer（传输层） │ │ │
│ │ │ │ │ │
│ │ │ • 建立连接（stdio / HTTP / WebSocket） │ │ │
│ │ │ • 维护连接状态 │ │ │
│ │ │ • 处理重连和错误恢复 │ │ │
│ │ └─────────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────────────────────────────┐ │ │
│ │ │ Protocol Layer（协议层） │ │ │
│ │ │ │ │ │
│ │ │ • JSON-RPC 2.0 消息编码/解码 │ │ │
│ │ │ • 请求-响应匹配 │ │ │
│ │ │ • 消息路由和分发 │ │ │
│ │ └─────────────────────────────────────────────────────┘ │ │
│ │ │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────────────────────────────┐ │ │
│ │ │ Capability Layer（能力层） │ │ │
│ │ │ │ │ │
│ │ │ • 工具发现和管理 │ │ │
│ │ │ • 资源访问接口 │ │ │
│ │ │ • 提示模板管理 │ │ │
│ │ └─────────────────────────────────────────────────────┘ │ │
│ │ │ │
│ └───────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
2.2.3 MCP Server（服务端）
Server是实现具体功能的服务端程序，它暴露一组工具、资源或提示模板供Host调用。Server是MCP生态中数量最多、最活跃的部分。
🔧 Server的核心职责：
- 能力暴露：通过Capabilities声明自己能提供什么功能
- 工具实现：实现具体的工具逻辑（如查询数据库、发送邮件）
- 资源管理：管理可被访问的数据资源
- 安全控制：验证请求权限，保护敏感操作
💡 Server的开发自由度：
MCP Server可以用任何编程语言实现（Python、Node.js、Go、Rust等），只要遵循MCP协议规范即可。这种语言无关性大大促进了生态的繁荣。
MCP Server可以用任何编程语言实现（Python、Node.js、Go、Rust等），只要遵循MCP协议规范即可。这种语言无关性大大促进了生态的繁荣。
2.2.4 三者关系图解
┌──────────────────────────────────────────────────────────────────────────┐
│ 组件关系图解 │
├──────────────────────────────────────────────────────────────────────────┤
│ │
│ 用户 │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ MCP Host │ │
│ │ ┌─────────────────────────────────────────────────────────┐ │ │
│ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │
│ │ │ │Client A │ │Client B │ │Client C │ ... │ │ │
│ │ │ │(Git) │ │(DB) │ │(Files) │ │ │ │
│ │ │ └───┬─────┘ └────┬────┘ └────┬────┘ │ │ │
│ │ │ │ │ │ │ │ │
│ │ │ └─────────────┴─────────────┘ │ │ │
│ │ │ │ │ │ │
│ │ │ ▼ JSON-RPC 2.0 │ │ │
│ │ └─────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────────────┼─────────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Git MCP │ │ PostgreSQL │ │ Filesystem │ │
│ │ Server │ │ MCP Server │ │ MCP Server │ │
│ │ │ │ │ │ │ │
│ │ • git status│ │ • query │ │ • read_file │ │
│ │ • git commit│ │ • insert │ │ • write_file│ │
│ │ • git log │ │ • update │ │ • list_dir │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ 1个 Host 包含多个 Client │
│ 1个 Client 连接 1个 Server │
│ N个 Host 可以共享同一个 Server │
│ │
└──────────────────────────────────────────────────────────────────────────┘
2.3 通信流程详解
MCP的通信是一个有序的过程，从建立连接到完成交互，每一步都有明确的规范和目的。理解这个流程对开发和调试MCP服务至关重要。
2.3.1 完整通信流程图
┌─────────────────────────────────────────────────────────────────────────────┐
│ MCP 完整通信流程 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ MCP Client MCP Server │
│ │ │ │
│ │ ┌────────────────────────────────────────┐ │ │
│ │ │ 1. 初始化连接阶段 │ │ │
│ │ └────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ────────────────initialize────────────────> │ │
│ │ { │ │
│ │ "protocolVersion": "2024-11-05", │
│ │ "capabilities": { ... }, │
│ │ "clientInfo": { name, version } │
│ │ } │ │
│ │ │ │
│ │ <──────────────initialized────────────────── │ │
│ │ { │ │
│ │ "protocolVersion": "2024-11-05", │
│ │ "capabilities": { ... }, │ │
│ │ "serverInfo": { name, version } │
│ │ } │ │
│ │ │ │
│ │ ────────────────initialized────────────────> │ │
│ │ （确认初始化完成） │ │
│ │ │ │
│ │ ┌────────────────────────────────────────┐ │ │
│ │ │ 2. 能力发现阶段 │ │ │
│ │ └────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ────────────────tools/list────────────────> │ │
│ │ │ │
│ │ <────────────────tools/list───────────────── │ │
│ │ { │ │
│ │ "tools": [ │ │
│ │ { │ │
│ │ "name": "calculator", │ │
│ │ "description": "...", │ │
│ │ "inputSchema": { ... } │ │
│ │ }, │ │
│ │ ... │ │
│ │ ] │ │
│ │ } │ │
│ │ │ │
│ │ ┌────────────────────────────────────────┐ │ │
│ │ │ 3. 工具调用阶段 │ │ │
│ │ └────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ────────────────tools/call────────────────> │ │
│ │ { │ │
│ │ "name": "calculator", │ │
│ │ "arguments": { │ │
│ │ "operation": "multiply", │ │
│ │ "a": 12345, │ │
│ │ "b": 67890 │ │
│ │ } │ │
│ │ } │ │
│ │ │ │
│ │ <────────────────tools/call───────────────── │ │
│ │ { │ │
│ │ "content": [ │ │
│ │ { │ │
│ │ "type": "text", │ │
│ │ "text": "838102050" │ │
│ │ } │ │
│ │ ] │ │
│ │ } │ │
│ │ │ │
│ │ ┌────────────────────────────────────────┐ │ │
│ │ │ 4. 断开连接阶段 │ │ │
│ │ └────────────────────────────────────────┘ │ │
│ │ │ │
│ │ ────────────────────close──────────────────> │ │
│ │ │ │
└─────────────────────────────────────────────────────────────────────────────┘
2.3.2 各阶段详解
阶段1：初始化握手（Initialize）
- 目的：建立通信，协商协议版本和能力
- 过程：
- Client发送initialize请求，携带自身能力
- Server返回initialized响应，告知自身能力
- Client发送initialized确认，完成握手
- 关键点：协议版本必须兼容，否则连接失败
阶段2：能力协商（Capability Negotiation）
- 目的：了解Server能提供哪些功能
- 过程：
- Client请求工具列表（tools/list）
- Server返回所有可用工具的元数据
- Client了解每个工具的名称、描述、参数要求
- 作用：AI模型根据这些信息决定何时、如何调用工具
阶段3：工具调用（Tool Invocation）
- 目的：实际执行工具功能
- 过程：
- AI决定需要调用某个工具
- Client发送tools/call请求，包含工具名和参数
- Server执行对应逻辑
- Server返回执行结果
- Client将结果传递给AI模型
- 特点：可多次调用，支持串行和并行
阶段4：结果处理与响应
- 目的：将工具结果整合到AI回复中
- 过程：
- AI接收工具返回结果
- AI理解结果内容
- AI生成自然语言回复（或决定继续调用其他工具）
- 智能点：AI可以根据结果动态调整后续策略
2.4 协议层：JSON-RPC 2.0
MCP基于JSON-RPC 2.0协议进行通信。JSON-RPC是一种轻量级的远程过程调用协议，使用JSON格式传输数据，简单、通用、易于实现。
2.4.1 消息格式
MCP定义了三种消息类型：
1. 请求（Request）
{
"jsonrpc": "2.0", // 协议版本，固定为2.0
"id": 1, // 请求ID，用于匹配响应
"method": "tools/call", // 方法名
"params": { // 方法参数
"name": "calculator",
"arguments": {
"operation": "add",
"a": 10,
"b": 20
}
}
}
2. 成功响应（Success Response）
{
"jsonrpc": "2.0",
"id": 1, // 对应请求的ID
"result": { // 执行结果
"content": [
{
"type": "text",
"text": "30"
}
],
"isError": false
}
}
3. 错误响应（Error Response）
{
"jsonrpc": "2.0",
"id": 1,
"error": { // 错误信息
"code": -32602, // 错误代码
"message": "Invalid params", // 错误描述
"data": { // 额外错误信息
"details": "Missing required parameter: operation"
}
}
}
2.4.2 标准错误代码
| 错误代码 | 含义 | 说明 |
|---|---|---|
| -32700 | Parse error | 服务器接收到无效的JSON |
| -32600 | Invalid Request | 发送的JSON不是有效的请求对象 |
| -32601 | Method not found | 方法不存在或不可用 |
| -32602 | Invalid params | 无效的参数 |
| -32603 | Internal error | 服务器内部错误 |
| -32000 to -32099 | Server error | 保留给具体服务器实现的错误 |
💡 为什么选择JSON-RPC 2.0？
- 简单：基于JSON，几乎所有语言都原生支持
- 轻量：无需复杂的IDL定义，消息格式直观
- 成熟：经过多年验证，稳定可靠
- 灵活：支持请求-响应和通知两种模式
2.5 Capabilities（能力系统）
Capabilities是MCP的核心概念，用于描述Client和Server各自支持的功能。通过能力协商，双方可以确定可以进行的交互类型。
2.5.1 主要Capability类型
🔧 Tools（工具调用）
Tools是MCP最常用的能力，允许AI调用外部函数来完成特定任务。
工具示例：calculator
┌─────────────────────────────────────────────────────┐
│ { │
│ "name": "calculator", │
│ "description": "执行数学计算", │
│ "inputSchema": { │
│ "type": "object", │
│ "properties": { │
│ "operation": { │
│ "type": "string", │
│ "enum": ["add", "subtract", "multiply", "divide"],
│ "description": "计算操作类型" │
│ }, │
│ "a": { │
│ "type": "number", │
│ "description": "第一个数字" │
│ }, │
│ "b": { │
│ "type": "number", │
│ "description": "第二个数字" │
│ } │
│ }, │
│ "required": ["operation", "a", "b"] │
│ } │
│ } │
└─────────────────────────────────────────────────────┘
📁 Resources（资源访问）
Resources允许AI访问和操作结构化数据，类似于REST API的资源概念。
资源示例：文件系统
┌─────────────────────────────────────────────────────┐
│ 资源URI格式：file:///path/to/file │
│ │
│ 支持的交互： │
│ • resources/list - 列出可用资源 │
│ • resources/read - 读取资源内容 │
│ • resources/subscribe - 订阅资源变更通知 │
└─────────────────────────────────────────────────────┘
📝 Prompts（提示模板）
Prompts允许Server提供预定义的提示模板，帮助AI更好地完成特定任务。
提示模板示例：代码审查
┌─────────────────────────────────────────────────────┐
│ { │
│ "name": "code_review", │
│ "description": "对代码进行全面审查", │
│ "arguments": [ │
│ { │
│ "name": "code", │
│ "description": "要审查的代码", │
│ "required": true │
│ }, │
│ { │
│ "name": "language", │
│ "description": "编程语言", │
│ "required": false │
│ } │
│ ] │
│ } │
│ │
│ 模板内容： │
│ "请审查以下{language}代码，检查： │
│ 1. 潜在的bug和安全问题 │
│ 2. 代码风格和可读性 │
│ 3. 性能优化建议 │
│ 4. 最佳实践遵循情况 │
│ │
│ 代码： │
│ {code}" │
└─────────────────────────────────────────────────────┘
📊 Logging（日志记录）
Logging能力允许Server向Client发送日志信息，用于调试和监控。
日志级别：
┌─────────────────────────────────────────────────────┐
│ • debug - 调试信息 │
│ • info - 一般信息 │
│ • notice - 重要提示 │
│ • warning - 警告信息 │
│ • error - 错误信息 │
│ • critical- 严重错误 │
│ • alert - 需要立即关注 │
│ • emergency - 系统不可用 │
└─────────────────────────────────────────────────────┘
2.5.2 能力协商过程
┌─────────────────────────────────────────────────────────────────┐
│ 能力协商示意 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Client 宣布支持的能力： │
│ { │
│ "capabilities": { │
│ "tools": { "listChanged": true }, // 支持工具列表变更通知 │
│ "resources": { "subscribe": true }, // 支持资源订阅 │
│ "prompts": { "listChanged": true } // 支持提示列表变更 │
│ } │
│ } │
│ │
│ Server 宣布支持的能力： │
│ { │
│ "capabilities": { │
│ "tools": { "listChanged": false }, // 支持工具，无变更通知 │
│ "resources": {} // 不支持资源 │
│ // 不支持 prompts │
│ } │
│ } │
│ │
│ 最终协商结果（交集）： │
│ ✅ 可以使用 tools │
│ ❌ 不能使用 resources（Server不支持） │
│ ❌ 不能使用 prompts（Server不支持） │
│ │
└─────────────────────────────────────────────────────────────────┘
💡 能力系统的价值：
- 渐进增强：Server可以选择实现部分能力，不必全有
- 向后兼容：新增能力不会影响旧的实现
- 动态发现：Client可以实时了解Server的能力变化
- 清晰边界：明确双方职责，避免误解
2.6 生命周期管理
MCP连接从创建到销毁经历完整的生命周期，了解生命周期有助于编写健壮的MCP应用。
┌─────────────────────────────────────────────────────────────────────────────┐
│ MCP 连接生命周期 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 创建 初始化 交互阶段 维护 结束 │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ ┌─────┐ ┌─────┐ ┌───────────┐ ┌─────┐ ┌─────┐ │
│ │ 创建 │───▶│ 握手 │───▶│ 工具调用 │──▶│ 保活 │───▶│ 断开 │ │
│ │ 连接 │ │ 协商 │ │ 资源访问 │ │ 检测 │ │ 清理 │ │
│ └─────┘ └─────┘ └───────────┘ └─────┘ └─────┘ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ 启动进程 交换能力 执行实际业务 ping/pong 关闭连接 │
│ 建立连接 验证版本 动态发现 超时检测 释放资源 │
│ 订阅变更 │
│ │
│ ╔═══════════════════════════════════════════════════════════════════╗ │
│ ║ 详细状态流转 ║ │
│ ╠═══════════════════════════════════════════════════════════════════╣ │
│ ║ ║ │
│ ║ [idle] ──▶ [connecting] ──▶ [initializing] ──▶ [active] ║ │
│ ║ (交换capabilities) ║ │
│ ║ │ ║ │
│ ║ ┌───────────────┼───────────────┐ ║ │
│ ║ ▼ ▼ ▼ ║ │
│ ║ [calling_tool] [reading_resource] [logging] ║ │
│ ║ │ │ │ ║ │
│ ║ └───────────────┴───────────────┘ ║ │
│ ║ │ ║ │
│ ║ ▼ ║ │
│ ║ [closed] ◀─── [disconnecting] ◀──┘ ║ │
│ ║ ▲ ║ │
│ ║ │ ║ │
│ ║ [error] ◀─── 任何阶段出错 ║ │
│ ║ ║ │
│ ╚═══════════════════════════════════════════════════════════════════╝ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2.6.1 各阶段说明
| 阶段 | 状态 | 主要工作 |
|---|---|---|
| 创建 | idle → connecting | 启动Server进程，建立传输连接 |
| 初始化 | connecting → initializing | JSON-RPC握手，交换capabilities |
| 交互 | active | 工具调用、资源访问等实际业务 |
| 维护 | active | ping/pong保活，监控连接健康 |
| 结束 | disconnecting → closed | 优雅关闭，清理资源 |
| 错误 | error | 处理异常，尝试恢复或退出 |
⚠️ 重要注意事项：
- 优雅关闭：应该发送close通知后再断开，避免正在进行的操作中断
- 超时处理：工具调用可能耗时较长，需要合理设置超时
- 错误恢复：连接断开时应尝试重连，或提示用户手动重启
- 资源释放：确保进程、文件句柄等资源被正确释放
2.7 Transport传输方式
MCP协议不强制特定的传输方式，而是定义了抽象接口，允许根据场景选择最合适的传输机制。目前主要有三种传输方式：
2.7.1 stdio（标准输入输出）
🎯 适用场景：本地进程通信
┌─────────────────────────────────────────────────────────────────┐
│ stdio 传输方式 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ MCP Host MCP Server (子进程) │
│ │ │ │
│ │ 启动子进程 │ │
│ │ ───────spawn("server.py")────▶│ │
│ │ │ │
│ │ stdin (请求) │ │
│ │ ───────JSON-RPC消息──────────▶│ │
│ │ │ │
│ │ stdout (响应) │ │
│ │ ◀──────JSON-RPC消息───────────│ │
│ │ │ │
│ │ stderr (日志) │ │
│ │ ◀──────日志/错误信息───────────│ │
│ │ │ │
│ │ 关闭子进程 │ │
│ │ ───────kill──────────────────▶│ │
│ │
└─────────────────────────────────────────────────────────────────┘
stdio 特点：
- ✅ 简单直接：无需网络配置，进程间直接通信
- ✅ 安全隔离：Server以独立进程运行，崩溃不影响Host
- ✅ 本地优先：适合访问本地资源（文件、数据库）
- ❌ 仅限单机：无法跨网络通信
- ❌ 进程管理：Host需要负责启动和停止Server进程
2.7.2 HTTP with SSE（服务器推送事件）
🎯 适用场景：远程服务、Web应用
┌─────────────────────────────────────────────────────────────────┐
│ HTTP + SSE 传输方式 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ MCP Host MCP Server (HTTP服务) │
│ │ │ │
│ │ POST /mcp/v1/messages │ │
│ │ ───────(JSON-RPC请求)───────▶│ │
│ │ │ │
│ │ GET /mcp/v1/sse │ ← Server-Sent Events │
│ │ ───────(建立SSE连接)────────▶│ 服务端推送通道 │
│ │ ◀──────(实时推送事件)────────│ │
│ │ │ │
│ │ POST /mcp/v1/messages │ │
│ │ ───────(tools/call)─────────▶│ │
│ │ ◀──────(HTTP Response)───────│ │
│ │ │ │
│ │ POST /mcp/v1/messages │ │
│ │ ───────(close)──────────────▶│ │
│ │
│ 特点： │
│ • HTTP请求用于Client发送消息 │
│ • SSE通道用于Server推送异步消息和通知 │
│ • 支持跨网络，可通过HTTPS保障安全 │
│ │
└─────────────────────────────────────────────────────────────────┘
HTTP + SSE 特点：
- ✅ 跨网络：可部署在远程服务器
- ✅ Web友好：天然支持浏览器环境
- ✅ 可扩展：易于负载均衡和水平扩展
- ⚠️ 复杂度：需要处理连接管理和重连
- ⚠️ 双向限制：SSE只能Server向Client推送
2.7.3 WebSocket
🎯 适用场景：实时双向通信
┌─────────────────────────────────────────────────────────────────┐
│ WebSocket 传输方式 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ MCP Host MCP Server (WebSocket服务) │
│ │ │ │
│ │ ws://host/mcp │ │
│ │ ───WebSocket握手──────────▶│ │
│ │ ◀────连接建立确认───────────│ │
│ │ │ │
│ │ ═══双向实时通信通道═══════════════════════ │
│ │ │ │
│ │ ─────JSON-RPC消息─────────▶│ Client发送请求 │
│ │ │ │
│ │ ◀────JSON-RPC消息───────────│ Server推送响应/通知 │
│ │ │ │
│ │ ─────JSON-RPC消息─────────▶│ Client可随时发送 │
│ │ ◀────JSON-RPC消息───────────│ Server可随时推送 │
│ │ │ │
│ │ ───关闭连接────────────────▶│ │
│ │
│ 特点： │
│ • 真正的全双工通信 │
│ • 低延迟，适合高频交互 │
│ • 一条连接完成所有通信 │
│ │
└─────────────────────────────────────────────────────────────────┘
WebSocket 特点：
- ✅ 全双工：双方可同时发送消息
- ✅ 低延迟：连接建立后无需重复握手
- ✅ 高效：消息头小，适合频繁通信
- ⚠️ 兼容性：某些网络环境可能限制WebSocket
- ⚠️ 复杂性：需要处理心跳和断线重连
2.7.4 传输方式对比
| 特性 | stdio | HTTP+SSE | WebSocket |
|---|---|---|---|
| 通信方向 | 双向 | Client主动，Server推送 | 全双工 |
| 网络需求 | 无（本地进程） | HTTP(S) | WebSocket |
| 适用场景 | 本地工具 | 远程API、Web | 实时应用 |
| 部署复杂度 | 低 | 中 | 中 |
| 跨平台 | 同机 | 跨网络 | 跨网络 |
| 安全性 | 进程隔离 | HTTPS/TLS | WSS/TLS |
2.8 与LangChain/Function Calling的关系
理解MCP在整个AI技术栈中的位置，有助于我们正确地使用它。MCP不是LangChain或Function Calling的替代品，而是它们的有力补充。
2.8.1 技术栈层次对比
┌─────────────────────────────────────────────────────────────────────────────┐
│ AI 工具集成技术栈 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ 第4层：应用层（Applications） │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Claude │ │ Cursor │ │ 你的AI应用 │ │ │
│ │ │ Desktop │ │ Editor │ │ │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ ┌─────────────────────────────────┼─────────────────────────────────────┐ │
│ │ 第3层：框架层（Frameworks） │ │ │
│ │ ┌─────────────┐ ┌─────────────┼──┐ ┌─────────────┐ │ │
│ │ │ LangChain │ │ LlamaIndex │ │ │ CrewAI │ │ │
│ │ │ │ │ │ │ │ │ │ │
│ │ └─────────────┘ └─────────────┘ │ └─────────────┘ │ │
│ └────────────────────────────────────┼──────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────┼──────────────────────────────────┐ │
│ │ 第2层：协议层（Protocols） │ │ │
│ │ ▼ │ │
│ │ ┌─────────────────────────────────────────────────────────────────┐ │ │
│ │ │ 🔌 MCP (Model Context Protocol) │ │ │
│ │ │ │ │ │
│ │ │ 统一标准 | 开放协议 | 跨平台 | 动态发现 │ │ │
│ │ └─────────────────────────────────────────────────────────────────┘ │ │
│ └────────────────────────────────────────────────────────────────────────┘ │
│ ▲ │
│ ┌─────────────────────────────────┼─────────────────────────────────────┐ │
│ │ 第1层：能力层（Capabilities） │ │ │
│ │ ┌─────────────┐ ┌─────────────┼──┐ ┌─────────────┐ │ │
│ │ │ Function │ │ Tool Use │ │ │ Plugins │ │ │
│ │ │ Calling │ │ (Claude) │ │ │ (OpenAI) │ │ │
│ │ └─────────────┘ └─────────────┘ │ └─────────────┘ │ │
│ └────────────────────────────────────┼──────────────────────────────────┘ │
│ │ │
│ ┌────────────────────────────────────┼──────────────────────────────────┐ │
│ │ 第0层：模型层（Models） │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ ┌─────────────┐ │ │
│ │ │ Claude │ │ GPT-4 │ │ │ Llama │ │ │
│ │ │ Gemini │ │ ... │ │ │ Qwen │ │ │
│ │ └─────────────┘ └─────────────┘ │ └─────────────┘ │ │
│ └────────────────────────────────────┴──────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
2.8.2 关系详解
MCP vs Function Calling
| MCP | Function Calling |
|---|---|
| 协议标准（通信方式） | 模型能力（能否调用函数） |
| 解决"如何通信" | 解决"能否调用" |
| 独立于具体模型 | 模型特定功能 |
| 需要模型支持Function Calling才能使用 | 是MCP能够工作的前提之一 |
关系：Function Calling是底层能力，MCP是使用这种能力的标准化方式。
MCP vs LangChain
| MCP | LangChain |
|---|---|
| 协议层（Protocol） | 应用框架（Framework） |
| 定义通信标准 | 提供开发工具和抽象 |
| 语言无关 | Python/JS特定 |
| Server可以独立存在 | 通常在应用内部使用 |
关系：LangChain可以集成MCP作为工具来源，两者可以协同工作。
┌─────────────────────────────────────────────────────────────────┐
│ 三者协同工作示例 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 你的AI应用 (使用LangChain构建) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ LangChain 框架 │ │
│ │ • Chain定义 • Prompt管理 • Memory管理 • Agent编排 │ │
│ └─────────────────────┬───────────────────────────────────┘ │
│ │ │
│ │ 调用 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ MCP Client (LangChain Adapter) │ │
│ │ (适配器模式) │ │
│ └─────────────────────┬───────────────────────────────────┘ │
│ │ MCP协议 │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Git MCP │ Database MCP │ Search MCP │ ... │ │
│ │ Server │ Server │ Server │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 在这个架构中： │
│ • LangChain负责应用逻辑编排 │
│ • MCP负责标准化工具接入 │
│ • 底层依赖模型的Function Calling能力 │
│ │
└─────────────────────────────────────────────────────────────────┘
✅ 最佳实践建议：
- 如果你开发工具：按MCP标准开发，可被任何框架使用
- 如果你开发应用：使用LangChain等框架，通过MCP接入工具
- 如果你配置AI助手：选择支持MCP的Host（如Claude Desktop），自由组合工具
🎓 本章小结
通过本章的学习，你已经掌握了MCP的技术核心：
通过本章的学习，你已经掌握了MCP的技术核心：
- MCP采用Client-Server架构，Host包含多个Client
- 通信基于JSON-RPC 2.0，包含初始化、发现、调用等阶段
- 四种Capabilities（Tools、Resources、Prompts、Logging）定义了交互能力
- 支持stdio、HTTP/SSE、WebSocket三种传输方式
- MCP位于协议层，与LangChain（框架层）、Function Calling（能力层）互补