2026 年 7 月 28 日，Anthropic 发布了 Model Context Protocol（MCP）的第五版规范2026-07-28。官方将其定义为"自协议发布以来最大的一次修订"——这不是营销话术：新规范移除了会话握手、删除了三个核心特性、重写了授权模型，并引入了扩展框架。同一天，GitHub 宣…
这件事的分量在于数字：MCP 月 SDK 下载量已突破 4 亿，年内翻了 4 倍。当一个协议的下载量达到这个量级，它就不再是"Claude 生态的私有协议"，而变成了"整个 AI 编程行业的事实标准"。Claude Code、Cursor、Copilot、Gemini 都开始说同一种协议语言。
但这次改版的核心不是"用的人多了"，而是协议本身做了一次结构性减法。本文拆解这次改版的三处关键架构决策——无状态内核、扩展框架、认证硬化——并给出可执行的迁移路径。所有事实均来自官方规范、SEP 提案与权威分析交叉验证。
一、无状态内核：为什么必须干掉"会话"
1.1 旧模型在分布式环境下崩塌
2025-11-25版本的 MCP 是为"单个 AI 应用连接一个本地进程"设计的：客户端打开连接，执行initialize/initialized握手，双方在整个会话周期内记住彼此。会话由Mcp-Session-Id头部追踪。
这个模型在单机环境下没问题，但一旦你把 MCP 服务部署到负载均衡器后面、Kubernetes 集群里、或跨多个云区域，有状态就成了瓶颈，三个问题会叠加放大：
- 负载均衡失效：客户端被"钉"在持有其会话的那个实例上，标准轮询负载均衡器无法分发流量，必须引入粘性会话或共享会话存储。
- 连接脆弱：一个中断的 SSE 流意味着整个会话状态丢失，客户端需要复杂的重连和重新初始化逻辑。
- 协议啰嗦：维护长会话带来大量保活开销，即使没有实际工作发生。
2026-07-28用六个规范增强提案（SEP）把内核改成了无状态请求/响应模型。设计哲学是"按需付费的复杂性"：默认无状态，只有当某个特性显式需要时才引入状态。官方在发布说明中强调，这是 2025 年 12 月《MCP 传输未来》一文中规划方向的实际落地。
1.2 握手与会话头被移除
initialize/initialized握手被移除（SEP-2575）。协议版本、客户端身份、能力标志现在通过每个请求的_meta对象携带。Mcp-Session-Id头部也被移除（SEP-2567）——这是运维影响最大的改动，远程 MCP 服务此前需要的粘性会话、共享会话存储、网关深度包检测都不再必要。
对比旧版与新版的一次工具调用。旧版（2025-11-25）需要两步，且第二步被钉在固定实例：
# 第一步：初始化获取会话ID 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: 1868a90c-3a3f-4f5b 第二步：每次后续请求必须携带会话ID，客户端被钉在该实例上 POST /mcp HTTP/1.1 Mcp-Session-Id: 1868a90c-3a3f-4f5b Content-Type: application/json {"jsonrpc":"2.0","id":2,"method":"tools/call", "params":{"name":"search","arguments":{"q":"otters"}}}新版（2026-07-28）是一次自包含请求，任何实例都能处理：
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"}}}}注意新增的Mcp-Method和Mcp-Name头部（SEP-2243）——它们让负载均衡器和网关无需解析 JSON body 就能按操作路由流量，服务端会拒绝头部与 body 不一致的请求。配合列表与资源读取结果新增的ttlMs和cacheScope字段（SEP-2549，借鉴 HTTPCache-Control），客户端能精确知道tools/list响应的新鲜期，长连接 SSE 不再是感知列表变更的唯一途径。
1.3 无状态协议，有状态应用
一个常见疑问是："我的服务需要跨多次工具调用追踪状态，没有会话怎么行？"
答案与 HTTP API 几十年来的做法一致：显式句柄。服务端从一个工具调用中铸造一个标识符（basket_id、browser_id、workflow_id），作为结果返回；模型在后续调用中把这个标识符作为普通参数传回：
1. 客户端调用: create_checkout({items: ["widget-a", "widget-b"]}) 服务端返回: {basket_id: "bsk_8f3a", status: "created"} 客户端调用: add_shipping(basket_id: "bsk_8f3a", address: {...}) 服务端返回: {basket_id: "bsk_8f3a", status: "ready_to_pay"} 客户端调用: confirm_order({basket_id: "bsk_8f3a"}) 服务端返回: {order_id: "ord_91cb", status: "confirmed"}这不仅是权宜之计，往往比隐藏的会话状态更好。模型可以对句柄进行推理、跨工具组合、在工作流步骤间传递——而这些是传输元数据里隐藏的会话状态永远做不到的。协议不再替你管理状态，但也不阻止你自己管理。官方维护者在发布说明中明确指出：把状态对模型可见而非隐藏在传输元数据中，是更强大的模式。
二、扩展框架：让协议"插件化"
内核变瘦后，高级行为被建模为扩展——可选的、自包含的模块，客户端和服务端可独立采用。扩展获得反向 DNS 标识符、独立仓库、委托维护者，版本独立于主规范演进（SEP-2133）。本次随候选版发布两个官方扩展。
2.1 MCP Apps：服务端渲染的交互式 UI
旧版 MCP 工具只返回结构化数据（JSON、文本、资源 URI）。用户需要与这些数据交互（探索仪表盘、填表单、审阅文档）时，客户端要自己搭 UI——每个客户端搭得都不一样，或干脆不搭。
MCP Apps（SEP-1865）允许服务端声明交互式 HTML 界面，宿主在沙箱 iframe中渲染。架构有三个组件：
- 声明：服务端注册工具，通过
_meta.ui.resourceUri指向ui://资源。工具提前声明 UI 模板，宿主可在运行前预取、缓存并做安全审查。 - 渲染：工具被调用时，宿主在会话内的沙箱 iframe 中渲染 HTML/JS。沙箱阻止 UI 访问宿主页面、Cookie 或容器外的任何东西。
- 双向通信：UI 与宿主（及通过宿主回到服务端）通过
postMessage上的 JSON-RPC 通信。用户在 UI 中的操作触发服务端逻辑，服务端更新推送回 UI，无需重新加载 iframe。
关键在于：每个 UI 发起的动作都走与直接工具调用相同的审计与同意路径。这是把 MCP 从"开发者集成层"变成"面向用户生态"的基础原语。若宿主不支持 MCP Apps，服务端可回退为返回纯文本或结构化数据，工具依然可用。
2.2 Tasks：长任务的持久化生命周期
旧版工具调用是同步的：客户端发请求，服务端处理，返回结果。如果操作需要几分钟（CI/CD 流水线、批量数据迁移、复杂分析），连接可能超时。每个需要异步行为的服务端都得自己发明轮询机制。
Tasks 扩展引入标准化的异步模式，围绕无状态模型重新设计：
- 任务创建：服务端不再阻塞，返回
CreateTaskResult，含唯一taskId、初始状态、建议轮询间隔。任务创建由服务端主导：客户端声明支持扩展，服务端决定某次调用是否应作为任务运行。 - 轮询：客户端调用
tasks/get检查进度，状态包括working、input_required、completed、failed、cancelled。 - 中途交互：任务进入
input_required（如部署流水线等待人工审批）时，客户端通过tasks/update发送输入，实现单任务内多步交互工作流。 - 取消：客户端可请求取消，服务端在可能时尊重它。
- 终态：任务到达
completed/failed/cancelled后不可变，结果或错误详情可在终态对象上获取。
任务句柄设计为可承受连接中断——客户端断开重连后，可用同一个taskId继续轮询。需要注意的是tasks/list端点被移除，因为它在没有会话的情况下无法安全地做作用域限定。任何在2025-11-25实验性 Tasks API 上构建的实现都需迁移到新生命周期。
三、认证硬化：从"能用"到"企业可用"
旧版 MCP 的认证是"自带令牌"式的，企业环境中常处于安全合规的灰色地带。2026-07-28把授权对齐到 OAuth 2.1 和 OpenID Connect，使其真正企业级可用。六个 SEP 共同硬化授权规范：
| 改动 | SEP | 解决的问题 |
|---|---|---|
客户端必须按 RFC 9207 验证iss参数 | SEP-2468 | 防止单客户端多服务端场景下的混淆攻击 |
客户端注册时声明application_type | SEP-837 | 避免桌面/CLI 客户端被默认为 web 而拒绝 localhost 回调 |
| 凭证绑定到授权服务器 issuer，资源迁移时重新注册 | SEP-2352 | 防止跨授权服务器的凭证混用 |
| 文档化 refresh token 请求方式 | SEP-2207 | 旧版 refresh token 行为未定义，各实现各异 |
| 阐明 step-up 授权时的 scope 累积 | SEP-2350 | 渐进式权限请求更可控 |
Resource Indicators（RFC 8707）直接解决了"混淆代理"问题：客户端请求令牌时必须指定令牌目标 MCP 服务端，为服务端 A 颁发的令牌无法对服务端 B 重放——这在协议层强制，而非依赖应用层检查。
更值得关注的是 Enterprise-Managed Authorization（EMA）扩展：IT 管理员可通过身份提供商集中配置 MCP 服务端访问权限，用户登录时自动连接所需服务端，无需逐应用 OAuth 弹窗。这是对企业级反馈的直接回应——很多组织无法在不掌控"员工连哪些服务端"的情况下采用 MCP。
四、治理与迁移：12 个月废弃窗口
4.1 正式废弃策略
2026-07-28引入正式的特性生命周期策略（SEP-2596）：任何标记废弃的特性必须保持功能至少 12 个月才能移除，废弃特性记录在公共注册表中并有明确时间线。这是 MCP 首次拥有结构化的规范演进流程。
本次三个核心特性被标记废弃（SEP-2577），最早 2027 年 7 月 28 日后移除：
| 特性 | 废弃原因 | 迁移路径 |
|---|---|---|
| Roots | 文件系统假设不适用于远程/云环境 | 作为工具参数或服务端配置传递路径 |
| Sampling | 服务端反向调用客户端 LLM，复杂化信任边界 | 服务端直接对接 LLM 提供商 API |
| Logging | 协议级日志非标准化 | stdio 用 stderr；HTTP 用 OpenTelemetry |
这是注解式废弃——方法、类型和能力标志在本版本及此后一年内发布的所有规范版本中继续工作，移除任一特性都需在生命周期策略下走单独 SEP。此外，Standards Track SEP 在有匹配场景进入一致性套件前不得达到 Final 状态（SEP-2484），与新的 SDK 分级系统共同保证实现质量。
4.2 迁移清单
如果你在生产环境运行 MCP 服务端，按官方建议执行迁移：
- 检查会话依赖：找出所有基于
Mcp-Session-Id存取状态的位置，替换为显式句柄。负载均衡器上的粘性路由可在迁移完成后移除。 - 更新授权实现：若接受未认证连接，现在是接入 OAuth 2.1 的时机。服务端需暴露
.well-known/oauth-protected-resource端点或通过WWW-Authenticate头携带resource_metadata。使用 Dynamic Client Registration 的需规划迁移到 Client ID Metadata Documents。 - 更新工具 schema：规范现支持完整 JSON Schema 2020-12（SEP-2106），允许
oneOf/anyOf/$ref组合，输出 schema 不再受限。 - 更新客户端：每个请求须携带
MCP-Protocol-Version、Mcp-Method、Mcp-Name头部；initialize握手已移除，用server/discover获取能力；令牌请求须包含 Resource Indicators。 - 测试多实例部署：在轮询负载均衡器后部署多个实例跑测试套件，任何失败的测试都指向一个漏掉的会话依赖。
- 检查错误码：缺失资源的错误码从 MCP 自定义的
-32002改为 JSON-RPC 标准的-32602Invalid Params（SEP-2164），按字面值匹配错误码的客户端需更新。
局限性
本文基于2026-07-28候选版规范分析，部分被描述为"强制/移除/最终"的细节仍需对照 7 月 28 日正式版核实。以下几点值得注意：
- 无状态内核解决了传输层与会话管理问题，但未定义如何信任外部数据：协议规定了数据怎么传，却没规定如何判断服务端返回的数据可信。Agent 通过完美协议连上数据库、却被返回内容里的恶意指令操纵的风险，仍需上层防护。
Mcp-Method/Mcp-Name头部让网关路由更便捷，但未提供协议级的速率限制与配额标准，仍需基础设施层补充。- EMA 扩展虽回应了企业集中管控诉求，但其具体实现细节依赖身份提供商支持，落地成本在异构 IdP 环境下未经验证。
- 本文未对迁移后的性能做基准测试，"标准轮询负载均衡可用"是规范设计目标，而非实测结论。
结论
MCP2026-07-28的价值不在新增了多少特性，而在于它做了一次结构性的减法：把会话从协议层剥离，让 AI Agent 的工具调用能跑在标准 HTTP 基础设施上。这与 HTTP 当年标准化推动上层应用繁荣的逻辑一致——不是因为技术多先进，而是因为它形成了"所有人说同一种语言"的网络效应。
对开发者而言，一个新基础设施层正在形成：二十年前你需要懂 HTTP 才能做 Web 开发，不久后你可能需要懂 MCP 才能做 Agent 开发。本次改版的迁移窗口已经打开，建议在正式版发布后尽快验证多实例部署，移除粘性路由，把状态从传输层迁移到应用层显式句柄。Intuit、Figma、Block、Apollo 等公司已基于 MCP 构建生产级产品，当头部玩家用你的协议定义下一代数据流时，标准便已锁定。
相关可视化与工程实践项目（含交互式 SVG 实验室）已开源：https://github.com/wangzifan396-wzf/TW
