# MCP 协议演进史：从诞生到成熟的四个版本

> 一个协议的生命周期，折射出 AI 应用生态的快速进化。

---

## 为什么需要 MCP？

在 MCP 出现之前，AI 应用面临一个尴尬的现实：

你想让 Claude 读取本地文件？需要写专门的代码。
你想让 ChatGPT 访问你的数据库？需要写专门的代码。
你想让 Cursor 连接公司内部 API？需要写专门的代码。

**每个 AI 应用 + 每个数据源 = 一套定制集成代码。**

这就像在 USB 出现之前，每个外设都需要专门的接口——打印机有打印口，鼠标有鼠标口，键盘有键盘口。

MCP（Model Context Protocol）就是为了解决这个问题而诞生的通用"接口"。它让 AI 应用能够以统一的方式连接任何数据源和工具。

MCP 由 David Soria Parra 和 Justin Spahr-Summers 设计，灵感来自 LSP（Language Server Protocol）。LSP 让 VS Code 能和任何编程语言"对话"，MCP 则让任何 AI 应用能和任何数据源"对话"。两者的核心理念一致：**定义一个标准协议，让生态中的每个参与者只需要实现一次。**

---

## MCP 的诞生：2024年11月

### 2024-11-05：协议的第一个版本

2024年11月，Anthropic 开源了 MCP 协议，同时发布了 Claude Desktop 对 MCP 的支持。

**初代架构**：

```
┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Host      │────▶│   Client    │────▶│   Server    │
│ (Claude)    │     │  (连接器)    │     │ (数据源)    │
└─────────────┘     └─────────────┘     └─────────────┘
```

- **Host**：发起连接的 AI 应用（如 Claude Desktop）
- **Client**：Host 内部的连接器
- **Server**：提供数据和能力的服务

**初代核心能力**：

| 能力 | 说明 |
|------|------|
| **Resources** | 让 AI 读取文件、数据库等数据 |
| **Prompts** | 预定义的提示模板 |
| **Tools** | AI 可执行的函数 |
| **Sampling** | 服务器发起的 LLM 调用 |

**传输方式**：
- stdio：本地进程通信
- HTTP+SSE：远程通信

**初代设计决策**：

初代 MCP 选择了一个有状态的模型——客户端必须先进行 `initialize` 握手，建立会话后才能发送其他请求。这个决策简化了初始实现，但也埋下了后续问题的种子。

**架构图**：

![architecture.png](https://developer.qcloudimg.com/http-save/yehe-7136204/bdc2702f0e021f7fddb993ec0ef14ef6.png)

**生命周期（2024-11-05 ~ 2025-11-25）**：

![lifecycle-stateful.png](https://developer.qcloudimg.com/http-save/yehe-7136204/99f728410881c38767dca4c22ae990a8.png)

---

## 第一次进化：2025-03-26

### 从实验室走向生产环境

五个月后，MCP 发布了第一个重要更新。这次更新让 MCP 从"能用"变成了"好用"。

#### 1. 授权框架：企业级的入场券

初代 MCP 没有标准的授权机制，每个实现都得自己解决"谁有权限访问什么"的问题。

2025-03-26 版本引入了基于 **OAuth 2.1** 的授权框架。这意味着企业可以：
- 用现有的 OAuth 基础设施管理 MCP 访问
- 实现细粒度的权限控制
- 审计谁在什么时候访问了什么

**设计者的思考：** 安全不是事后补充，而是协议设计的核心需求。OAuth 2.1 的选择是经过深思熟虑的——它是最成熟的授权标准，企业已经有现成的基础设施。

#### 2. Streamable HTTP：更灵活的网络传输

初代的 HTTP+SSE 有个问题：服务器只能单向推送消息。

新版引入了 **Streamable HTTP** 传输，支持双向流。好处：
- 支持服务器主动发送消息
- 更好的错误恢复机制
- 更适合长时间运行的任务

#### 3. JSON-RPC 批处理：一个实验性的功能

允许在一个请求中发送多个操作：

```json
[
  {"jsonrpc": "2.0", "method": "tools/list", "id": 1},
  {"jsonrpc": "2.0", "method": "resources/list", "id": 2}
]
```

这个功能的初衷是减少网络往返次数，对高延迟环境尤其有用。但后来的实践证明，这是一个**错误的决策**。

#### 4. 工具注释：让 AI 更"懂"工具

新增的 `annotations` 字段让开发者能标注工具的特性：

```json
{
  "name": "delete_file",
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true
  }
}
```

AI 可以根据这些提示做出更智能的决策。

---

## 第二次进化：2025-06-18

### 回归本质，拥抱实用主义

这个版本做了一些"反直觉"的决定——移除了刚加不久的功能，同时引入了重要的新能力。

#### 1. 移除 JSON-RPC 批处理：敢于承认错误

等等，不是刚加的吗？

**真实的原因**：在实践中发现，批处理的复杂度远超预期。

开发者社区反馈：
- 错误处理复杂：一个批请求中部分成功、部分失败怎么处理？
- 顺序依赖：请求之间的依赖关系难以表达
- 实际收益有限：大多数场景下，网络延迟不是瓶颈

这是 MCP 团队的务实态度——不为了"功能完整"而保留实际上不好用的功能。**好的协议设计不是堆砌功能，而是保持精简。**

#### 2. Elicitation：服务器主动询问用户

这是一个重要的能力增强。服务器现在可以请求用户提供额外信息：

```
Server: "我需要知道你想导出的文件格式"
        ↓
Client: 显示选项给用户
        ↓
User: 选择 "PDF"
        ↓
Server: 收到选择，继续执行
```

**设计者的思考：** 之前的协议假设所有信息都在工具调用时提供，但实际场景中，工具执行过程中可能需要用户输入。Elicitation 填补了这个空白。

#### 3. 结构化工具输出：告别纯文本

之前的工具只能返回文本或图片。新版本支持两种结构化输出：

**结构化内容（structuredContent）**：工具可以返回结构化的 JSON 对象：

```json
{
  "content": [{"type": "text", "text": "查询成功"}],
  "structuredContent": {
    "users": [
      {"id": 1, "name": "张三", "email": "zhangsan@example.com"},
      {"id": 2, "name": "李四", "email": "lisi@example.com"}
    ],
    "total": 2
  }
}
```

**输出模式（outputSchema）**：工具可以预先声明输出结构：

```json
{
  "name": "search_users",
  "inputSchema": { "type": "object", "properties": {...} },
  "outputSchema": {
    "type": "object",
    "properties": {
      "users": { "type": "array" },
      "total": { "type": "number" }
    }
  }
}
```

这让 AI 能更好地理解工具返回的数据结构，而不是解析非结构化的文本。

**资源链接（resource links）**：工具结果中还可以包含资源链接，指向相关资源：

```json
{
  "content": [...],
  "structuredContent": {...},
  "_meta": {
    "resourceLinks": [
      {"uri": "file:///path/to/user.json", "mimeType": "application/json"}
    ]
  }
}
```

#### 4. 强制协议版本头

HTTP 请求现在必须在头中指定协议版本：

```
MCP-Protocol-Version: 2025-06-18
```

这解决了版本协商的模糊性问题——服务器可以在早期就拒绝不兼容的客户端。

---

## 第三次进化：2025-11-25

### 生态繁荣，标准成熟

这个版本标志着 MCP 从"协议"成长为"生态"。

#### 1. OpenID Connect 支持

授权发现进一步增强，支持 OIDC Discovery。这让 MCP 可以利用企业现有的身份基础设施。

#### 2. 增量授权同意

用户不需要一次性授权所有权限，可以在需要时增量授权。这减少了用户的授权焦虑。

#### 3. 采样中的工具调用

Sampling（服务器发起的 LLM 调用）现在可以指定工具。这让服务器能够构建更复杂的代理行为。

#### 4. 任务支持（实验性）

引入了任务的概念，用于长时间运行的操作。

#### 5. 治理结构正式化

成立了工作组（Working Groups）和兴趣组（Interest Groups）：
- Security Interest Group
- Authorization Interest Group
- Transports Interest Group

**设计者的思考**：从个人项目到有工作组、兴趣组的正式治理结构，这是成为行业标准必经的路。

---

## 下一个版本预览：Draft

### 无状态化：最激进的转变

Draft 版本（截至 2026 年 5 月开发中）计划做出最激进的改变：**移除会话概念，拥抱无状态**。

**无状态协议的调用流程**：

![lifecycle-stateless.png](https://developer.qcloudimg.com/http-save/yehe-7136204/5b57e849397066e4464e7bc4b49dbdaa.png)

**对比：有状态 vs 无状态**：

![comparison.png](https://developer.qcloudimg.com/http-save/yehe-7136204/d46b0da0d438d89fd31c956e112cc470.png)

这是一个经过深思熟虑的决策，记录在 SEP-2575 和 SEP-2567 两份提案中。让我们深入了解设计者的思考过程。

#### 问题：Session 的生命周期是未定义的

初代 MCP 要求客户端先进行 `initialize` 握手，建立会话。但会话的生命周期是什么？

设计者在 SEP-2567 中详细分析了这个问题：

> "规范没有说明会话何时开始或结束，因为这取决于宿主应用。在实践中，不同客户端的行为差异巨大：
>
> - **ChatGPT**：每次工具调用都创建新会话，调用结束就关闭
> - **Claude Desktop**：应用启动时创建会话，进程生命周期内保持
> - **Web 客户端**：每次页面加载创建新会话
> - **几乎没有任何客户端**：在断开或重启后恢复之前的会话"

这意味着：**服务器开发者无法知道一个会话对应什么**。

一个 Playwright 服务器把浏览器实例绑定到会话，但它不知道这个会话是一次对话、一个应用进程，还是整个页面加载周期。

#### 问题：购物车困境

设计者举了一个经典的例子：

假设你有一个购物车服务器：

```
// 旧版：隐式会话状态
add_item("apple")  // 添加到哪个购物车？
add_item("banana")
checkout()
```

会话模式下，购物车是隐式的——但会话生命周期不确定导致问题：

- 如果客户端每次工具调用都创建新会话（如 ChatGPT），购物车在第二次调用就丢失了
- 如果客户端在应用启动时创建会话（如 Claude Desktop），购物车会在不相关的对话间共享

#### 解决方案：显式状态句柄

Draft 版本的解决方案是：**用显式的句柄（handle）替代隐式的会话**。

```
// 新版：显式句柄
basket_id = create_basket()
add_item(basket_id, "apple")
add_item(basket_id, "banana")
checkout(basket_id)
```

句柄只是一个字符串，出现在工具结果和参数中，协议层面没有任何特殊处理。但它解决了所有问题：

- 模型决定什么共享、什么隔离
- 多个子代理可以共享同一个购物车
- 句柄会出现在聊天记录中，持久化是自然的

#### 句柄安全性

句柄会出现在聊天记录、复制粘贴缓冲区中，这是设计者重点考虑的安全问题。

对于需要认证的服务器，句柄应该只是一个名称，真正的访问控制由认证上下文决定。就像 Google Doc 的 URL 中的文档 ID——任何人有链接不一定能访问，还需要有权限。

对于无认证的服务器，句柄本身是持有令牌（bearer token），需要足够随机（至少 128 位熵）且有过期时间。这和"任何人都可通过链接访问"的分享链接是同样的安全模型。

#### 问题：列表端点无法缓存

会话还导致了另一个问题：`tools/list` 可能因会话而异，客户端无法缓存结果。

对于一个会派生子代理的编排器，每个子代理都需要重新获取 `tools/list`。如果有 10 个子代理、5 个服务器，就是 50 次调用——即使服务器的工具集从未改变。

移除会话后，`tools/list` 的结果不再与会话相关，编排器可以缓存并共享给所有子代理。

#### 设计原则：Pay As You Go

SEP-2575 明确了设计原则，按优先级排列：

1. **优先无状态**：每个请求都应该自包含
2. **其次用状态引用**：如果必须，用句柄引用状态
3. **最后才用状态连接**：只有当更简单的方案都无法满足时

这被称为 **"Pay As You Go"** 原则——只为实际需要的功能付出复杂度的代价。

#### 为什么不把会话变成可选的？

设计者考虑过保留会话但设为可选：

> "支持两种并行的交互模型会极大地增加协议和每个实现的复杂度。服务器和客户端都需要构建、测试、维护两条独立的逻辑路径，导致更大的 bug 表面积。"

干净的断代升级，让整个生态向前移动，比保留向后兼容更重要。

#### 考虑过的替代方案

SEP-2575 记录了被否决的替代方案：

**方案 A：可选的初始化握手**
- 客户端可以选择握手或跳过
- 被否决：两种模型并行会翻倍实现复杂度

**方案 B：单一的大型握手 RPC**
- 把所有协商放在一个 RPC 中
- 被否决：单一 RPC 难以演进，强制所有客户端理解最复杂的特性

最终选择了分离关注点：`server/discover` 用于发现，`_meta` 字段用于每请求的能力声明。

#### 影响分析：破坏性变更

设计者承认这是破坏性变更。他们对 GitHub 上的开源 MCP 服务器做了自动分析：

| 类别 | 占比 | 迁移难度 |
|------|------|---------|
| 没有使用会话 ID | 90.0% | 无需迁移 |
| 仅 SDK 样板代码 | 6.3% | SDK 更新自动处理 |
| 会话级别的应用状态 | 2.5% | 需要迁移到显式句柄 |
| 网关粘性路由 | 0.7% | 需要重新设计 |

只有约 3% 的服务器需要实质性迁移。

---

## 协议设计的启示

从 MCP 的演进中，我们能学到什么？

### 1. 敢于做减法

JSON-RPC 批处理加进来又删掉。Session 概念从核心变成弃用。这体现了好的协议设计不是堆砌功能，而是保持精简。

设计者在 SEP-2567 中写道：

> "更少的原语减少实现面积。每个协议概念都需要 SDK 作者实现、文档化、新用户学习。"

### 2. 实践驱动决策

移除批处理不是理论分析的结果，而是实际使用中的反馈。移除 Session 也不是设计之初的想法，而是观察了不同客户端的行为差异后得出的结论。

### 3. 无状态是成熟的标志

从有状态到无状态，这是协议成熟的标志。HTTP 从 1.1 到 2 到 3 也是这个方向。

设计者在 SEP-2575 中引用了维基百科的定义：

> "无状态协议是指接收方不得保留之前请求的会话状态。发送方将相关的会话状态传输给接收方，使得每个请求都能被独立理解。"

这并不意味着不能构建有状态的应用——HTTP 是无状态的，但 Web 上充满了有状态的应用。状态应该在应用层，而不是协议层。

### 4. 安全是核心需求

OAuth 2.1 授权在第一个正式更新就引入了。安全不是事后补充，而是设计时就考虑的核心需求。

### 5. 治理是生态的一部分

从两位作者的项目，到有工作组、兴趣组的正式治理结构。这是成为行业标准必经的路。

---

## 版本对比总览

| 版本 | 发布时间 | 核心主题 | 关键决策 |
|------|---------|---------|---------|
| **2024-11-05** | 2024年11月 | 协议诞生 | 有状态模型、initialize 握手 |
| **2025-03-26** | 2025年3月 | 企业就绪 | OAuth 2.1、Streamable HTTP、批处理 |
| **2025-06-18** | 2025年6月 | 实用主义 | 移除批处理、Elicitation |
| **2025-11-25** | 2025年11月 | 生态成熟 | 任务支持、治理结构 |
| **Draft** | 开发中 | 无状态化 | 移除 Session、移除 initialize |

---

## 对开发者的意义

### 服务器开发者

- 迁移到显式句柄模式（如果使用会话状态）
- 支持 OAuth 授权（如果需要远程访问）
- 实现结构化输出
- 考虑无状态化部署

### 客户端开发者

- 实现协议版本协商
- 支持 Elicitation 交互流程
- 每个请求携带版本和能力信息
- 不再依赖 initialize 握手

### 工具使用者

- 理解不同版本的兼容性
- 关注安全配置
- 利用工具注释做出更好的决策

---

## 参考资料

- MCP 官方文档：https://modelcontextprotocol.io
- MCP 规范仓库：https://github.com/modelcontextprotocol/specification
- SEP-2575: Make MCP Stateless：https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575
- SEP-2567: Sessionless MCP：https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2567
- SEP-2322: Multi Round-Trip Requests：https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322

---

*MCP 的演进还在继续。如果你在使用或开发 MCP 工具，欢迎在评论区分享你的经验和问题。*

你想让 Claude 读取本地文件？需要写专门的代码。你想让 ChatGPT 访问你的数据库？需要写专门的代码。你想让 Cursor 连接公司内部 API？需要写专门的代码。

MCP 协议演进史：从诞生到成熟的四个版本

软件研发

人工智能

网络与通信

MCP协议演进史：从2024年11月诞生到2025年11月成熟，经历了四个关键版本迭代。该协议解决了AI应用与数据源之间定制集成的痛点，实现了统一连接标准。演进过程体现了实用主义设计理念：引入OAuth2.1授权框架、结构化工具输出等企业级功能，同时果断移除JSON-RPC批处理等不实用特性。最新草案版本计划实现无状态化架构，标志着协议向行业标准迈进。MCP的快速发展折射出AI应用生态的成熟进程。

网络延迟

数据结构

数据库

服务器

ChatGPT

路由

GitHub

OAuth

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MCP协议演进史：从2024年11月诞生到2025年11月成熟，经历了四个关键版本迭代。该协议解决了AI应用与数据源之间定制集成的痛点，实现了统一连接标准。演进过程体现了实用主义设计理念：引入OAuth2.1授权框架、结构化工具输出等企业级功能，同时果断移除JSON-RPC批处理等不实用特性。最新草案版本计划实现无状态...

MCP 协议演进史：从诞生到成熟的四个版本-腾讯云开发者社区-腾讯云

MCP 协议演进史：从诞生到成熟的四个版本

MCP 协议演进史：从诞生到成熟的四个版本

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐