前言¶

Model Context Protocol（MCP）是连接大模型与外部工具、数据源的开放协议。自 2024 年底 Remote MCP 推出以来，它迅速成为 Agent 工具链的事实标准之一——官方博客披露，Tier 1 SDK 每月下载量接近 5 亿次，TypeScript 与 Python SDK 累计下载均已突破 10 亿。

2026 年 7 月 28 日，MCP 维护团队正式发布 2026-07-28 版规范。这是 Remote MCP 上线以来最大的一次协议修订：协议核心从双向有状态模型，改为无状态的请求/响应模型，移除了 initialize/initialized 握手与 Mcp-Session-Id 会话头。对部署 Remote MCP Server 的开发者而言，这意味着服务器可以像普通 HTTP 服务一样挂在负载均衡后面水平扩展，而不必再维护粘性会话或共享 Session Store。

本文基于 MCP 官方发布博客、Release Candidate 说明 以及 SEP-2567 原文，梳理这次变更的核心内容与落地影响。

有状态到无状态：协议层到底改了什么¶

在 2025-11-25 版规范中，通过 Streamable HTTP 调用工具需要先建立会话：

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

服务端返回 Mcp-Session-Id，后续每次请求都必须携带该头，客户端因此被「钉」在签发 Session 的那台实例上。水平扩展时，网关需要粘性路由，后端往往还要共享 Session 存储。

2026-07-28 版将同一次工具调用压缩为单个自描述请求，任意实例均可处理（SEP-2567、SEP-2575）：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

变化可以概括为三点：

1. 握手消失：不再要求 initialize/initialized 交换；协议版本、客户端身份与能力改由每次请求的 _meta 字段携带。
2. Session 头移除：Mcp-Session-Id 从规范中删除，协议层不再维护会话生命周期。
3. 可选发现：客户端若需提前了解服务端能力，可调用新的 server/discover RPC；不调用也不影响后续请求。

水平扩展：为什么这对生产部署很重要¶

Release Candidate 文档用一句话概括了生产侧的直接收益：Remote MCP Server 不再需要粘性 Session、共享 Session Store，以及网关上对 JSON Body 的深度包检测；普通轮询负载均衡即可分发流量，网关可按 Mcp-Method 头路由，tools/list 等列表响应也可按服务端声明的 ttlMs 缓存。

这与 SEP-2567 的分析一致。旧模型下，tools/list、resources/list、prompts/list 的结果可能随 Session 变化（例如调用 connect_database 后工具列表才出现），客户端无法安全跨 Session 复用缓存。Orchestrator 为每个子 Agent 重复拉取各 Server 的工具列表，开销可达 O(子 Agent 数 × Server 数)。Session 移除后，列表与 Session 解耦，配合 SEP-2549 引入的 ttlMs 与 cacheScope 提示，同一 Server 的工具目录可被缓存并在子 Agent 间复用，复杂度降为 O(Server 数)。

Streamable HTTP 传输还要求请求携带 Mcp-Method 与 Mcp-Name 头（SEP-2243），且必须与 Body 中的 method/name 一致。负载均衡器、API 网关、WAF 可以直接按头部分流与限流，无需解析 JSON。

无 Session 不等于无状态应用：显式状态句柄¶

移除协议层 Session，并不强制业务逻辑无状态。SEP-2567 推荐的模式与 HTTP API 常见做法一致：由工具显式创建并返回状态标识，模型在后续调用中作为普通参数传回。

典型写法如下——服务端提供 create_basket，返回 basket_id，后续 add_item 携带该 ID：

// tools/call → create_basket
{ "name": "create_basket", "arguments": {} }

// ← 结果
{ "structuredContent": { "basket_id": "bsk_a1b2c3" } }

// tools/call → add_item
{ "name": "add_item", "arguments": { "basket_id": "bsk_a1b2c3", "sku": "shoes" } }

官方认为，相比隐藏在传输层的 Session 状态，显式句柄对模型更可见：Orchestrator 可以让多个子 Agent 共享同一个 basket_id，同时为各自分配独立的 browser_id，粒度由应用设计决定，而非被「一个 Session 一种作用域」所限制。

服务端主动交互：MRTR 取代长连接¶

无状态模型仍需支持「工具执行中途向用户确认」等场景。此前 elicitation/create、sampling/createMessage 等 Server 发起的请求依赖保持打开的双向流；2026-07-28 引入 Multi Round-Trip Requests（MRTR，SEP-2322） 解决这一问题。

Server 在处理客户端请求时，可返回 resultType: "input_required" 及待回答的 inputRequests；客户端收集用户输入后，携带 inputResponses 与 requestState 重试原调用。相关状态均在 Payload 中传递，任意实例可接续处理，无需持久连接。Supabase 等已在 RC 阶段表示，正是 MRTR 使其在无 Session 架构下实现了费用确认、危险操作二次确认等 Elicitation 流程。

扩展框架：MCP Apps 与 Tasks¶

本次发布还正式确立了扩展（Extensions）机制（SEP-2133）：扩展以反向 DNS ID 标识，在独立仓库维护，版本与核心规范解耦。

两个官方扩展值得关注：

• MCP Apps（SEP-1865）：Server 可提供沙箱 iframe 内渲染的交互式 HTML 界面，Host 可预取、缓存并完成安全审查；UI 操作仍走 JSON-RPC，审计路径与直接 Tool Call 一致。
• Tasks（SEP-2663）：从实验性核心能力迁出为 io.modelcontextprotocol/tasks 扩展，采用基于轮询的 tasks/get、tasks/update；适合长时运行的 Agent 任务。AWS 贡献了 Tasks 扩展，并已在 Amazon Bedrock AgentCore 中提供支持。

此外，Roots、Sampling、Logging 三项核心能力被标注弃用（SEP-2577），至少保留 12 个月；旧版 HTTP+SSE 传输同样进入弃用窗口。规范还引入正式弃用策略：功能从 Active 到 Deprecated 再到 Removed，最短间隔 12 个月，便于团队规划升级而非被动应对。

授权方面，客户端须按 RFC 9207 校验授权响应中的 iss 参数（SEP-2468）；Dynamic Client Registration（DCR）正式弃用，转向 Client ID Metadata Documents（CIMD），客户端凭证与签发方绑定，不可跨 Authorization Server 复用。

SDK 与生态：Tier 1 已对齐，云厂商 Day Zero 跟进¶

TypeScript、Python、Go、C# 四套 Tier 1 SDK 已支持 2026-07-28，Rust SDK 处于 Beta。官方提供了针对破坏性变更的迁移说明；依赖 Session ID 的集成需要重点改造。

生态侧表态密集。AWS 与 Anthropic 称新版规范已在 Amazon Bedrock AgentCore 可用，MCP Server 可部署在标准可扩展基础设施上；Netlify 表示无 Session 核心使其平台托管 MCP 与托管普通 Web 服务同样简单；Cloudflare Agents SDK、Google Cloud、Microsoft Foundry、FastMCP 4.0 等也宣布 Day Zero 或近期支持。

对正在构建 Agent 工具链的团队，可优先评估以下迁移项：

1. 移除对 initialize 握手与 Mcp-Session-Id 的依赖，改为在 _meta 中传递客户端信息。
2. 网关与可观测性接入 Mcp-Method / Mcp-Name 头；列表接口利用 ttlMs 减少重复拉取。
3. 若业务依赖跨调用状态，设计显式句柄工具，而非假设 Session 作用域。
4. 若使用 experimental Tasks API，对照扩展版生命周期迁移；关注 MRTR 以支持用户确认类交互。

小结¶

2026-07-28 版 MCP 把协议核心对齐到现代 HTTP 运维范式：无 Session、可路由、可缓存、可水平扩展。这是自 Remote MCP 推出以来最重要的一次架构修订，Breaking Change 较多，但配合 12 个月弃用窗口与扩展框架，官方意图是在此次「干净断代」之后，让后续演进以可选扩展与小步迭代为主。

对开发者而言，MCP Server 终于更接近「部署一个 REST 服务」的心智模型；对 Agent 平台而言，工具目录缓存、子 Agent 并行、企业级网关治理的成本都会下降。若你已在生产环境运行 Remote MCP，建议对照官方 SDK 迁移文档与 SEP 原文，尽早启动适配——这一次不是小版本补丁，而是协议层的换底。