MCP 协议 2026-07-28 重大改版：从工具调用协议走向基础设施

2026 年 7 月 28 日，Model Context Protocol 发布了自诞生以来最大规模的规范修订。无状态化、多轮往返请求、异步任务扩展、正式扩展体系四项变化叠加在一起，把 MCP 从一个面向开发者的工具调用协议推向了企业级生产基础设施的位置。本文从协议规范、关键变化和生产就绪三个层面拆解这次改版。

---

一、新规范全貌

1.1 MCP 的定位

MCP（Model Context Protocol）解决的核心问题是：AI 模型如何以标准方式调用外部工具和数据。

在 MCP 出现之前，每个 AI 应用要自己实现工具调用机制。OpenAI 有 Function Calling，LangChain 有 Tool 抽象层，各家格式不兼容。一个工具如果要被三个不同的 AI 应用调用，就要写三套适配代码。

MCP 定义了一层标准协议：任何工具只要实现 MCP Server 端，就能被任何支持 MCP 的 AI 应用直接调用。MCP 之于 AI 工具调用，大致相当于 USB 之于硬件接口——一个标准插头，插什么都能用。

Anthropic 于 2024 年 11 月将协议开源。此后 OpenAI Agents SDK、Google Gemini API、Microsoft Copilot Studio、GitHub Copilot 陆续原生支持。协议已捐赠给 Linux Foundation，治理权中性化。下载量数据来自 CSDN 2026 年 7 月的技术分析文章，口径为各官方 SDK（TypeScript、Python、Java、C#、Kotlin）的累计下载量，约 9700 万次，具体分平台数字待进一步核实。

1.2 架构：Client-Host-Server 三层

MCP 采用三层架构：

• Host（宿主）：运行 LLM 的应用程序，如 Claude Desktop、Cursor IDE。Host 创建并管理多个 Client 实例，控制连接权限和生命周期，执行安全策略，协调 AI 集成，并根据 LLM 的 tool 调用意图选择对应的 Client/Server 路由请求。
• Client（客户端）：Host 内部的连接器。每个 Client 与一个 Server 一对一通信，在请求中携带协议版本和能力声明，路由消息双向流转。
• Server（服务端）：暴露三种核心原语（Resources、Tools、Prompts），以及 2026-07-28 新增的 Elicitation 机制。Server 是独立进程或远程服务，只接收必要的上下文信息，看不到完整对话历史。

控制层级如下：

Elicitation（新增）：服务端在处理过程中向用户请求额外信息，支持表单和 URL 两种模式。它不是第四种原语，而是嵌入在 Tools/Prompts/Resources 调用过程中的交互机制。

1.3 设计原则

2026-07-28 版本重申了四条设计原则：

1. Server 应该极其容易构建。Host 承担复杂的编排职责，Server 只聚焦于特定能力。
2. Server 应该高度可组合。每个 Server 独立工作，多个 Server 可以无缝组合。
3. Server 不应读取完整对话，也不应"看到"其他 Server。每个 Server 只接收必要的上下文信息，完整对话历史留在 Host。
4. 功能可以渐进式添加。核心协议提供最小必需功能，附加能力按需协商，保持向后兼容。

1.4 消息与模式

MCP 基于 JSON-RPC 2.0。每个请求带唯一 ID，必须包含 _meta 元数据（协议版本、客户端能力）。响应带 resultType 字段，支持多态结果：complete（成功完成）、input_required（需要额外输入，触发 MRTR）、task（创建了异步任务）。

三种消息模式：

• Request-Response：标准请求-响应循环
• Multi Round-Trip Requests（MRTR）：服务端返回需要额外输入的响应，客户端补充信息后重试，详见第二节
• Subscribe-Notify：客户端通过 subscriptions/listen 订阅变更通知，服务端通过 SSE（Server-Sent Events，服务器推送的 HTTP 流）推送

传输层方面，Streamable HTTP 移除了 GET 流端点和协议级 Session，改为纯无状态的 POST 请求模式。请求元数据通过三个标准 HTTP 头（MCP-Protocol-Version、Mcp-Method、Mcp-Name）镜像到 HTTP 层，让负载均衡器和网关可以不解包 body 就做路由决策。传输层的无状态化是整体无状态设计的一部分，机制细节在第二节展开。

---

二、关键变化的深入分析

2.1 无状态化：协议的底层重写

旧规范（2025-11-25 及更早）采用"握手-会话"模式。客户端发送 initialize 请求，服务端分配 Mcp-Session-Id，后续所有请求必须携带这个 ID，绑定到固定服务实例。会话结束时发送 initialized 通知。这和传统 Web 的 Cookie/Session 机制逻辑一致。

新规范（2026-07-28）彻底移除了这套机制：

• 移除 initialize 握手和 Mcp-Session-Id
• 每个请求通过 _meta 字段自包含协议版本、客户端能力、身份凭证
• 任意服务实例可独立处理任意请求
• 连接不等于会话，同一 STDIO（标准输入输出）连接上可以交替发送不相关的请求

规范原文："Servers MUST NOT rely on prior requests over the same connection to establish context."

版本协商也从一次性握手变成了每次请求的行为。每个请求在 _meta 中携带 protocolVersion，服务端独立接受或拒绝，不支持时返回 UnsupportedProtocolVersionError（错误码 -32022），列出自己支持的版本。服务端必须实现 server/discover 方法，客户端可选择性地在发其他请求前调用它做前置能力发现，但不是必须的。

这个变化对部署拓扑的影响：

这是 MCP 走向基础设施的必要条件。 有状态设计在原型阶段够用，但在生产环境中，它把部署架构锁死在了单实例或会话亲和模式上。无状态化打开了水平扩展、多区域容灾、Kubernetes 原生部署等全部生产级能力。

但无状态不是免费的。每个请求现在要携带完整的元数据（协议版本、能力声明、身份信息），payload 体积增大。版本协商从一次握手变成每次请求，虽然省了往返但增加了每请求的处理开销。MRTR 中的 requestState blob 需要服务端加密生成、每次验证，对高 QPS 的简单工具调用来说是不成比例的成本。对于需要增量上下文构建的场景（比如多轮对话中逐步建立 Server 端的理解），新规范下需要把状态显式编码到每次请求中，或者通过 Tasks 扩展维护长生命周期的上下文，工程复杂度反而上升。

旧规范下一些依赖有状态会话的自然用例，在新规范中变得困难。例如，一个 Server 想在第一次调用时了解客户端的环境（操作系统、项目结构），后续调用复用这些信息。旧规范下这发生在 initialize 握手中，零额外开销。新规范下，要么每次请求都传，要么用 requestState 编码，要么通过 Tasks 维持一个长期上下文。这是"无状态税"的具体体现。

权衡的结果是：对于单次无状态工具调用这类常见场景，新规范净收益为正。对于需要持续会话上下文的场景，新规范引入了额外的工程负担。规范选择偏向前者，这是合理的工程判断，但不是没有代价。

2.2 MRTR：请求重试替代双向通道

旧规范允许服务端直接向客户端发起 JSON-RPC 请求（如 sampling/createMessage、roots/list）。这需要双向通信通道：客户端的请求挂着等待，服务端在处理中间反向调用客户端。有状态模型下可行，无状态模型下不成立。

Multi Round-Trip Requests（MRTR）用请求重试加加密状态 blob 解决了这个问题。

第一轮：客户端发 tools/call（id: 1），服务端发现需要额外信息，返回 InputRequiredResult（resultType: "input_required"），包含 inputRequests（描述需要什么信息）和 requestState（服务端上下文的不透明字符串）。

第二轮：客户端收集到用户输入后，重新发送原始请求（id: 2，必须不同于 id: 1），附带 inputResponses 和原样的 requestState。任意服务实例处理这个重试请求，从 requestState 中恢复上下文，返回最终结果。

requestState 是这套机制的安全核心。客户端不得检查、解析或修改它。规范要求服务端将其视为攻击者可控输入：如果 requestState 影响授权或资源访问，服务端必须用 HMAC（基于哈希的消息认证码）或 AEAD（认证加密关联数据，Authenticated Encryption with Associated Data）保护完整性。防重放方面，规范建议在加密载荷中包含认证主体、短过期时间（TTL）、原始请求标识符。单次使用不保证：需要严格一次性语义的场景（如一次性兑换），服务端必须自行实现去重。

MRTR 改变了 Server 的交互模型。旧模型中 Server 是被动的，等 Client 发请求后同步返回，需要更多信息时通过反向请求挂起当前处理。新模型中 Server 可以主动要求输入，但通过"返回而非反向调用"实现。Server 的逻辑变成一个状态机：每次收到请求时，根据 requestState 和新的 inputResponses 决定下一步。这个模式更像 Web 表单的 POST-Redirect-GET，牺牲一轮往返延迟，换来完全无状态的部署架构。

MRTR 支持在 tools/call、prompts/get、resources/read 三种客户端请求上触发，覆盖了三种服务端向客户端的请求：Elicitation（向用户收集信息）、Sampling（请求客户端 LLM 补全）、List Roots（请求文件系统根目录，已废弃但保留兼容）。

2.3 Elicitation：结构化人机交互

Elicitation 是 MRTR 的第一个应用场景。Form Mode 收集结构化数据，URL Mode 处理敏感操作。

Form Mode 通过 JSON Schema 定义期望的数据结构，客户端渲染表单。Schema 限制为扁平对象的原始类型（string、number、boolean、enum），不支持嵌套。这是刻意的简化，让客户端不需要完整的 JSON Schema UI 引擎就能渲染。安全约束明确：禁止通过 Form Mode 收集密码、API Key、Token 或支付凭证。

URL Mode 用于 OAuth 授权、支付、第三方认证等场景。服务端返回 URL，用户在浏览器中完成操作，数据不经过 MCP 客户端。客户端的责任是显示目标域名、获取用户确认后打开浏览器。

两种模式的分工把"谁处理敏感数据"的边界划清楚了。MCP 客户端不是密码管理员，不接触凭证。

2.4 Tasks 扩展：异步长任务

旧协议只能同步调用。一个工具调用如果跑几分钟，连接要么阻塞要么超时。对于 CI/CD（持续集成/持续部署）、批量数据处理、模型训练等场景不可行。

Tasks 扩展补上了这块拼图。当服务端判断一个请求是长任务时，返回一个任务句柄：

1. 创建：tools/call 响应返回 CreateTaskResult（resultType: "task"），包含 taskId、初始状态、TTL、建议轮询间隔
2. 轮询：客户端定期调用 tasks/get(taskId) 获取状态
3. 中途交互：任务进入 input_required 状态时，客户端通过 tasks/update 提交用户输入
4. 终态：completed（含最终结果）、failed（含错误）、cancelled

关键特性：taskId 是持久化 handle，客户端断开重连后用同一个 ID 继续轮询。任务暂停在 input_required 等待人类确认后继续，让工作流中的审批环节成为原生支持。服务端可通过 notifications/tasks 推送状态变更替代轮询。

需要注意的是，Tasks 是扩展，不是核心协议变更。核心协议仍然以同步调用为基础，Tasks 为需要异步的场景提供了一条可选路径。但这条路径的生态意义是实质性的：CI/CD 管道封装、数据处理流水线、人类审批工作流、外部异步任务系统集成，都可以在 MCP 框架内完成。

2.5 扩展体系：模块化演进

新规范建立了正式的扩展机制。官方扩展用 io.modelcontextprotocol/{name} 标识，第三方扩展用反向域名前缀（如 com.example/my-extension）。扩展通过 SEP（Specification Enhancement Proposal）流程标准化。

协商在能力声明中进行：客户端在每次请求的 clientCapabilities.extensions 中声明支持的扩展，服务端在 server/discover 的响应中声明自己的。双方都不支持的扩展自动降级到核心协议行为。扩展默认关闭，需要开发者显式启用（opt-in）。

当前扩展生态：

扩展体系让 MCP 的能力边界可以不修改核心规范就扩展。一个新能力先作为实验扩展孵化，验证后通过 SEP 升级为官方扩展。这比把所有功能塞进核心协议灵活得多，也降低了规范本身的复杂度。

2.6 其他重要变化

Roots 功能（向 Server 暴露文件系统根目录）标记为 deprecated（SEP-2577），12 个月宽限期后可移除。替代方案是通过 tool 参数、resource URI 或服务端配置传递文件路径。在无状态模型下，Roots 的"客户端声明可用目录"这一交互变成了冗余开销。

Result 类型系统：每个响应的 result 必须包含 resultType 字段。客户端根据结果类型选择处理路径。向后兼容：缺省视为 complete。

错误码重组：JSON-RPC 保留的 -32000 到 -32099 区间正式分区。-32000 到 -32019 为历史遗留不再分配新码。-32020 到 -32099 由规范定义，已有 HeaderMismatch（-32020）、MissingRequiredClientCapability（-32021）、UnsupportedProtocolVersion（-32022）。

分页与缓存：tools/list 和 resources/list 支持 cursor 分页。响应可带 ttlMs（缓存有效期）和 cacheScope（public/private）。服务端建议返回确定性排序，同样的工具集不变化时排序一致，直接提高 LLM prompt cache 命中率。

x-mcp-header：Tool 参数可标注此属性，在 Streamable HTTP 传输中映射为 Mcp-Param-{name} HTTP 头。负载均衡器和 WAF（Web Application Firewall）可基于参数值路由，不需要解析 JSON body。禁止标注敏感参数。

OpenTelemetry 原生支持：_meta 保留 traceparent、tracestate、baggage 三个 W3C TraceContext 标准字段用于分布式追踪。一次 Agent 操作跨多个 MCP Server 时，调用链从协议层就能串联。

JSON Schema 升级到 2020-12 版本。$ref 不得自动解引用网络 URI（SSRF，服务器端请求伪造防护），组合关键词建议设深度和数量限制（DoS 防护）。

---

三、生产就绪的结构性变化

从第二节的技术分析到生产落地，需要理解新规范在部署架构、安全模型和兼容性三个层面的结构性要求。

3.1 部署架构：云原生就绪

旧规范的部署本质上是单机的。一个 Host 进程通过 STDIO 连接本地 MCP Server，或通过 HTTP 连一个固定实例。Session 绑定让水平扩展不可行。

新规范打开的部署模式：

多副本负载均衡：MCP Server 像普通 HTTP 微服务一样部署多副本，前面放 round-robin 负载均衡。MCP-Protocol-Version、Mcp-Method、Mcp-Name 三个标准 HTTP 头让 API Gateway 可以按方法分流（tools/call 走计算密集型实例，resources/read 走缓存层），按工具名分发，按协议版本灰度。

Kubernetes 原生：无状态意味着 Pod 可随时创建销毁。HPA（Horizontal Pod Autoscaler，水平自动伸缩）直接适用。滚动更新零停机。

多区域容灾：请求可路由到任意区域，全局负载均衡器按延迟路由，区域故障自动切换，不需要跨区域复制会话状态。

CDN 缓存：cacheScope: "public" 的 tools/list 响应可被 CDN 或代理缓存。工具列表变化不频繁，缓存命中率高。

3.2 安全模型：六个层面

新规范的安全设计比旧版本系统化得多。

协议级原则：用户同意与控制（必须明确同意所有数据访问）、数据隐私（Host 获得同意后才暴露数据）、工具安全（工具代表任意代码执行，annotations 视为不可信除非来自可信 Server）。

requestState 安全：影响授权或资源访问时必须用 HMAC 或 AEAD 保护。服务端必须视为攻击者可控输入。防重放建议包含认证主体、TTL、原始请求标识符。单次使用不保证。

Elicitation 安全：Form Mode 禁止收集凭证，URL Mode 用于敏感操作，客户端必须显示是哪个 Server 在请求信息。

传输安全：服务端必须验证 Origin 头防 DNS 重绑定，本地运行应只绑定 localhost，应对所有连接实现认证。X-Accel-Buffering: no 头确保 SSE 流不被反向代理缓冲。

JSON Schema 安全：$ref 默认不解引用网络 URI，组合关键词建议设复杂度限制。

扩展安全：默认关闭需显式启用，第三方扩展使用自有域名前缀避免冲突。

3.3 可观测性：协议级内建

_meta 保留三个 OpenTelemetry 标准字段（traceparent、tracestate、baggage）用于 W3C TraceContext 分布式追踪。io.modelcontextprotocol/logLevel 让客户端按请求指定日志级别，Server 日志通过 notifications/message 推送。响应中的 ttlMs 和 cacheScope 让缓存行为可控可追踪。

3.4 向后兼容：双时代共存

新规范定义了完整的兼容矩阵。"双时代兼容"（Dual-era）指同时支持新旧两套协议的 Server 或 Client。

双时代 Server 通过检测客户端开场行为选择模式：带 _meta 的请求走 modern 语义，initialize 请求走 legacy 语义，可在同一端点上并发。这让生产环境可以渐进迁移：先升级到双时代，等所有客户端迁移完再切换到 Modern-only。

3.5 生产迁移清单

必须做的：

1. Server 端实现 server/discover 方法
2. 每个请求的 _meta 携带 protocolVersion 和 clientCapabilities
3. 移除对 initialize 握手和 Mcp-Session-Id 的依赖
4. Server 到 Client 的请求改为 MRTR 模式
5. requestState 用 AEAD 或 HMAC 保护完整性
6. Streamable HTTP 请求携带三个标准头

应该做的：

1. 实现双时代支持，平滑过渡
2. 确定性排序返回工具列表，提高缓存命中率
3. 响应中带 ttlMs 和 cacheScope
4. 对长任务评估 Tasks 扩展
5. 实现 OpenTelemetry trace context 传播
6. 评估 Elicitation 两种模式替换旧交互方案

不该做的：

1. 不要再用 Roots（已废弃）
2. 不要在 Form Mode 中收集凭证
3. 不要自动解引用外部 $ref
4. 不要假设同一连接上的请求共享上下文
5. 不要让 requestState 包含未加密的敏感信息

---

结论

MCP 2026-07-28 版本做了三件结构性的事。

第一，把协议从有状态变成无状态。 这打开了水平扩展、负载均衡、多区域容灾、Kubernetes 原生部署等全部生产级能力。MCP 可以像普通微服务一样部署了。代价是每请求的元数据开销和 requestState 的加密成本，对简单工具调用场景是不成比例的额外负担，但对绝大多数生产部署来说净收益为正。

第二，用 MRTR 替代了双向通道。 请求重试加加密状态 blob 的模式，让任意实例都能处理任意重试，兼容了无状态架构下的服务端到客户端交互需求。代价是多一轮往返延迟。

第三，建立了扩展体系。 Tasks、Apps、Elicitation 等能力作为可选扩展存在，不污染核心协议。Tasks 扩展让异步工作流在 MCP 框架内成为可能，但这仍是扩展层面的能力，不改变核心协议的同步性质。

结合协议捐赠给 Linux Foundation 和主流厂商的支持，MCP 正在从"Anthropic 的工具协议"走向"行业中性的 AI 工具调用标准"。这个方向上，无状态化和扩展体系是两块关键的架构基石。

下一步值得盯的是 Skills over MCP：如果 Agent 工作流定义可以通过 MCP 标准发现和消费，可能催生 Agent 生态的标准化能力市场。

---

参考来源：MCP 官方规范 modelcontextprotocol.io/specification/2026-07-28、SEP-2322（MRTR）、Tasks 扩展文档 modelcontextprotocol.io/extensions/tasks/overview。数据截止 2026 年 7 月 29 日。