2026年7月28日，MCP 发布了新规范，这是 MCP 的第五个规范版本，也是「协议诞生以来最大、最系统性的一次修订」
MCP：模型上下文协议
在 MCP 出现之前，每个 AI 应用连接每个外部工具，都要单独写一套对接代码。
假设有 x 个 AI 应用、y 个外部工具，传统方式需要维护接近 x*y 套适配代码。
MCP 在模型和工具之间增加了一层通用协议：AI 应用实现 MCP Client，工具开发者实现 MCP Server，双方只需要遵守同一套标准。
这也是 MCP 被称为 AI 世界的 USB-C 的原因。
从 x*y 套适配代码到一个通用协议------AI 世界的 USB-C
核心变化对照
| 维度 | 旧版 | 新版（2026-07-28） |
|---|---|---|
| 初始化 | 必须执行 initialize / initialized | 删除握手；Server 必须支持 server/discover，Client 可按需调用 |
| 会话 | Mcp-Session-Id 绑定会话 | 删除协议层 Session，每个请求自包含 |
| 能力信息 | 初始化时交换一次 | 协议版本、客户端信息与能力随请求放入 _meta |
| 水平扩容 | 常依赖粘性会话或共享 Session Store | 协议层不再依赖粘性会话；无业务状态或状态已经外置时，请求可由任意实例处理 |
| 网关路由 | 网关通常要解析 JSON Body | Mcp-Method、Mcp-Name 直接进入 HTTP Header |
| 补充信息 | Server 通过双向连接向 Client 发起请求 | MRTR 返回 input_required，Client 补充信息后重试 |
| 长时间任务 | 实验性 Tasks 混在核心协议里 | Tasks 成为正式扩展，通过持久化句柄轮询和更新 |
| 变化通知 | Server 主动推送多类通知 | Client 通过 subscriptions/listen 显式订阅 |
变化很多，但真正决定新版 MCP 架构方向的，是下面几组改动：
无状态
旧版 MCP 像一家还没有共享点餐系统的餐厅。你第一次由服务员 A 接待，菜单、忌口和加菜记录都写在 A 手里的点餐本上。后续请求必须继续找 A；如果服务员 B 来了，他看不到前面的记录，就无法接着服务。
新版 MCP 则像使用了标准订单系统。每次请求都带有处理本次操作需要的协议信息；需要跨步骤保存的点餐状态，则通过明确的 order_id 查找。于是服务员 A、B、C 都能接手，而不用把顾客固定给某一个人。
从"服务员记一切"到"标准订单系统"------无状态架构
旧版：先握手，再携带 Session ID 调用
- 客户端首先发送初始化请求：
POST /mcp HTTP/1.1Content-Type: application/json
{ "jsonrpc": "2.0", "id": 1, "method": "initialize", "params": { "protocolVersion": "2025-11-25", "capabilities": {}, "clientInfo": { "name": "my-app", "version": "1.0" } }}- 服务器可以在响应头里返回一个会话标识：
HTTP/1.1 200 OKMcp-Session-Id: 1868a90c-3a3f-4f5bContent-Type: application/json- 之后每次调用工具，都要继续携带这个 Session ID：
POST /mcp HTTP/1.1Mcp-Session-Id: 1868a90c-3a3f-4f5bContent-Type: application/json
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": { "name": "search", "arguments": { "q": "otters" } }}新版：一次请求包含完整的协议调用信息
新版不再要求先执行 initialize，也不再携带 Mcp-Session-Id：
POST /mcp HTTP/1.1MCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: searchContent-Type: application/json
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "search", "arguments": { "q": "otters" }, "_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientInfo": { "name": "my-app", "version": "1.0" }, "io.modelcontextprotocol/clientCapabilities": {} } }}可路由
新版 Streamable HTTP 请求必须提供 Mcp-Method 和 Mcp-Name：
例如：
Mcp-Method: tools/callMcp-Name: searchAPI Gateway、WAF 和限流器只看 Header，就能知道这次请求调用了哪个方法、哪个工具，从而按工具完成路由、鉴权、限流、计量和审计。
网关只看 Header 就能路由------MCP 流量进入企业 API 基础设施
这看似只是增加了两个 Header，实际意味着 MCP 流量终于可以更自然地进入企业现有的 API 基础设施。
可缓存
过去，客户端重新连接后经常再次获取 tools/list。即使工具列表没有变化，也可能重复拉取、重复加入模型上下文。
新版要求 tools/list、prompts/list、resources/list、resources/read 和 resources/templates/list 等结果携带：
-
ttlMs：结果可以保持新鲜多长时间
-
cacheScope：结果属于 public 还是 private 缓存
服务器还应以稳定顺序返回工具列表。这样不仅能减少重复请求，也能避免工具顺序在重连后反复变化，提高上游大模型 Prompt Cache 的命中率
TTL + cacheScope------减少重复拉取，提升 Prompt Cache 命中率
可追踪
新版在 _meta 中定义了 OpenTelemetry Trace Context 的传播约定，包括 traceparent、tracestate 和 baggage。
一次用户提问可能依次经过 AI 应用、模型、MCP Client、网关、MCP Server 和企业内部 API。现在这些跨度很大的调用，可以被串进同一条 Trace 中，排查慢请求和错误时不再只能翻找分散日志。
无状态、可路由、可缓存、可追踪放在一起，才是这次更新的完整意义：MCP 不只是能跑在 HTTP 上，而是开始真正适配 HTTP 世界已经成熟多年的运行方式。
以前的 MCP Server 需要推倒重写吗
不是所有 Server 都要推倒重写，但多数仍在使用旧 SDK 和旧入口的项目，都需要至少完成一次迁移检查。
不同 Server 类型对应不同迁移难度------从机械升级到实质性重构
| 旧 Server 类型 | 改造程度 |
|---|---|
| 纯工具调用、没有 Session 状态 | 主要是 SDK、注册 API 和启动入口的机械迁移 |
| 已经采用无状态 Streamable HTTP | 可直接迁到 createMcpHandler()，改造相对较小 |
| 使用 Mcp-Session-Id 保存跨调用状态 | 需要重新设计状态边界，属于实质性重构 |
| 使用 Server→Client 的 Sampling、Elicitation、Roots | 需要迁移到 MRTR 或直接调用相应服务 |
| 使用实验版 Tasks | 需要迁移到正式 Tasks 扩展的新方法 |
| 使用旧 HTTP+SSE、Logging 或 DCR | 可以暂时运行，但已经进入迁移窗口 |
案例一：单个工具，只需要升级外层接口
以一个天气查询 Server 为例：接收城市名称、调用天气 API，然后返回结果。每次查询都能独立完成，不需要记住上一次请求，因此没有依赖 Session 状态。
旧版的核心代码如下：
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
const server = new McpServer({ name: "weather-mcp", version: "1.0.0"});
server.tool( "query_weather", { city: z.string() }, handler);
const transport = new StdioServerTransport();await server.connect(transport);升级到新版后，天气 API 的地址、参数和返回结果都不需要修改，变化主要发生在 MCP 外层：
import { McpServer } from "@modelcontextprotocol/server";import { serveStdio } from "@modelcontextprotocol/server/stdio";import * as z from "zod/v4";
function createServer() { const server = new McpServer({ name: "weather-mcp", version: "1.0.0" });
server.registerTool( "query_weather", { inputSchema: z.object({ city: z.string() }) }, handler ); return server;}
void serveStdio(createServer);| 旧版 | 新版 |
|---|---|
| @modelcontextprotocol/sdk | @modelcontextprotocol/server |
| server.tool() | server.registerTool() |
| 手动连接 StdioServerTransport | 使用 serveStdio(createServer) |
案例二：重新设计状态
以一个购物车 Server 为例，用户可能先让 AI 添加牛奶，过一会儿再添加咖啡，最后才结算。这几次工具调用必须操作同一辆购物车，因此 Server 需要记住前面发生了什么。
旧版购物车 Server 可能直接使用 sessionId 查找购物车：
const basketsBySession = new Map();
server.tool( "add_item", { product: z.string() }, async ({ product }, extra) => { const basket = basketsBySession.get(extra.sessionId) ?? []; basket.push(product); basketsBySession.set(extra.sessionId, basket); return { content: [{ type: "text", text: `已加入：${product}` }] }; });此时，AI 只传递商品名称：
add_item({ product: "咖啡"});Server 必须通过当前 Session 才能知道要操作哪辆购物车。后续请求通常需要回到保存该 Session 的服务器实例。
新版则把购物车变成明确的业务对象：
server.registerTool( "create_basket", { inputSchema: z.object({}) }, async () => { const basketId = await basketStore.create(); return { content: [{ type: "text", text: `basket_id: ${basketId}` }] }; });
server.registerTool( "add_item", { inputSchema: z.object({ basket_id: z.string(), product: z.string() }) }, async ({ basket_id, product }) => { await basketStore.addItem(basket_id, product); return { content: [{ type: "text", text: `已加入：${product}` }] }; });后续调用必须明确携带购物车编号：
add_item({ basket_id: "bsk_a1b2", product: "咖啡"});basketStore 可以由 Redis 或数据库实现。这样无论请求落到 Server A、B 还是 C，都能根据 basket_id 找到同一辆购物车。
写在最后
这不是一次简单的接口升级，而是一次典型的基础设施成熟过程：早期先证明"它能工作"，进入生产阶段后，再重新处理可靠性、扩展性、安全性和兼容性。
无状态也不意味着复杂性消失。它只是把复杂性放回了真正应该存在的地方：业务状态归业务，任务状态归任务，协议负责清晰、独立、可路由地传递请求。
负载均衡、网关、缓存、链路追踪、鉴权------MCP 正在成为 Agent 生态的基础设施
当一项协议开始认真处理负载均衡、网关、缓存、链路追踪、鉴权和弃用周期时，它就不再只是开发者手里的连接工具，而是在成为整个 Agent 生态的基础设施。