前言¶

Model Context Protocol（MCP）是连接 AI Agent 与外部工具、数据源的开放标准。自 Anthropic 于 2024 年 11 月发布以来，它已迅速成为 Agent 工作流的事实性「连接层」——Anthropic、Google Cloud、Microsoft、AWS、Cloudflare 等厂商均将其视为 Agent 基础设施的关键组件。

2026 年 7 月 28 日，MCP 维护团队在 Linux Foundation 旗下 Agentic AI Foundation（AAIF） stewardship 下，正式发布 2026-07-28 版规范。这是 MCP 自远程 MCP 上线一年多以来最重要的一次升级：协议核心从双向有状态模型转向 无状态请求/响应 架构，同时硬化 OAuth 授权、确立正式扩展框架，并将 MCP Apps、Tasks 等能力毕业为官方扩展。

据 MCP 官方博客，Tier 1 SDK（TypeScript、Python 等）月下载量已接近 5 亿次，TypeScript 与 Python SDK 累计下载均突破 10 亿。Anthropic 同期披露 MCP SDK 月下载量超 4 亿，年内增长约 4 倍。VentureBeat 援引联合维护者 David Soria Parra 的说法，SDK 周下载量已达约 2.5 亿。这组数字背后，是大量企业正把 MCP 从试点推向生产。

本文基于 MCP 官方发布说明、Anthropic Claude 产品博客及 VentureBeat 采访，梳理本次更新的核心变化、对开发者的实际影响，以及迁移时需要留意的 breaking changes。

为什么要有无状态核心¶

在旧版设计中，MCP 客户端必须与特定服务端实例维持持久会话。客户端需完成 initialize/initialized 握手，并通过 Mcp-Session-Id 头标识会话。在 Kubernetes、Serverless 等现代云环境中，计算节点随时扩缩，负载均衡器后端的实例并不固定——一旦持有会话状态的 Pod 下线，Agent 的工作就可能中断。

联合维护者 Den Delimarsky 在接受 VentureBeat 采访时直言：「以前你需要 session store 来管理 session ID，某个 compute pod 挂掉后请求就会失败。新版本里这不再是问题。」AAIF 执行董事 Mazin Gilbert 则将其类比为 Web 本身的无状态设计——浏览器无需「粘」在某台服务器上，才能访问任意网站。

2026-07-28 规范正式废弃协议级握手与会话头（SEP-2575、SEP-2567）。每个请求自描述，在 _meta 中携带协议版本、客户端身份与能力；任意请求均可落在负载均衡器后的任意实例上，无需共享存储或 sticky routing。若客户端希望提前了解服务端能力，可调用可选的 server/discover RPC，但并非强制。

需要强调的是：协议层无状态，并不强制应用层无状态。若工具调用间需传递上下文，服务端可显式返回 handle，由模型在后续调用中作为参数传回——状态由开发者按需管理，而非隐藏在传输层。

无状态请求长什么样¶

官方博客给出了 Streamable HTTP 下的典型请求示例：

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

{"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. 无 Mcp-Session-Id：每个 POST 独立完整，可路由到任意后端。
2. Mcp-Method 与 Mcp-Name 头（SEP-2243）：网关、WAF、限流器可直接按头路由与鉴权，无需解析 JSON body。
3. MCP-Protocol-Version: 2026-07-28：显式声明协议版本，便于多版本共存与灰度。

对部署而言，这意味着 MCP Server 可以像普通 HTTP 服务一样跑在 Cloudflare Workers、AWS Lambda、Netlify Edge 等无状态基础设施上——Google Cloud、Cloudflare、Netlify 等已在发布当日宣布 Day Zero 支持。

MRTR：无状态协议下的交互式调用¶

完全无状态后，一个棘手问题是：工具执行到一半需要用户确认或补参怎么办？旧版依赖服务端发起的 elicitation/create、sampling/createMessage 等请求，并要求保持双向长连接。

新版引入 Multi Round-Trip Requests（MRTR，SEP-2322）：服务端返回 resultType: "input_required" 及待回答的请求列表，客户端在原调用上附带 inputResponses 重试。Supabase 产品负责人 Inian Parameshwaran 在官方 testimonial 中提到，MRTR 使其能在无状态架构下支持「创建项目前确认费用」「删除数据前确认」等 elicitation 流程。

Roots、Sampling、Logging 等旧能力已正式 deprecate（SEP-2577），至少保留 12 个月；新实现不应再采用它们。Legacy HTTP+SSE 传输同样进入弃用轨道。

可缓存的列表响应¶

tools/list、prompts/list、resources/list、resources/read 的响应现携带 ttlMs 与 cacheScope（SEP-2549）。客户端可据此制定缓存策略，减少重复拉取；列表顺序确定性也有助 prompt cache 在重连后保持稳定。对高频调用工具目录的 Agent 客户端，这是直接的性能收益。

正式扩展框架：MCP Apps 与 Tasks¶

2026-07-28 将扩展机制正式锁定。除核心协议外，能力以版本化扩展独立演进，避免核心规范臃肿。

MCP Apps 允许服务端在对话中渲染交互式 UI——表单、仪表盘、可视化等，而不仅是文本输出。Figma、Netlify 等已在探索将设计稿、生成结果直接嵌入 Agent 对话界面。

Tasks（io.modelcontextprotocol/tasks 扩展，SEP-2663）从实验性核心毕业，面向长耗时异步任务：服务端返回 durable task handle，客户端可断开、重启后通过 poll 型 tasks/get 与 tasks/update 继续跟踪。AWS 贡献了 Tasks 扩展，Amazon Bedrock AgentCore 已支持在新规范下部署 MCP Server。变更通知从旧 HTTP GET 端点迁移至客户端按类型 opt-in 的 subscriptions/listen 流。

Enterprise Managed Authorization（EMA） 则与 Okta 等身份提供商协作，使企业 IdP（如 Entra、Okta）成为 MCP 访问的统一门禁——管理员一次授权，用户通过现有 IdP 组继承权限，Claude 等产品已实现 zero-touch 连接器配置。

OAuth 2.0 硬化与企业级授权¶

维护者坦言，授权集成是 MCP 落地最耗时的环节之一。2026-07-28 在 OAuth/OIDC 对齐上迈出几步：

1. RFC 9207 iss 校验（SEP-2468）：授权服务器返回 issuer，客户端兑换 code 前必须验证，封堵 mix-up 类攻击。维护者强调这是预防性加固，并非响应已发生漏洞。
2. 客户端凭证绑定 issuer（SEP-2352）：禁止跨授权服务器复用凭证。
3. DCR 正式 deprecate，转向 CIMD（Client ID Metadata Documents）：Dynamic Client Registration 仍向后兼容，但未来版本将移除；CLI/桌面客户端的 localhost redirect 问题亦通过 application_type 等 SEP-837 变更缓解。

VentureBeat 将「12 个月弃用策略 + 开放标准 + 无状态扩展性」称为企业信任的三条腿——对 Fortune 500 而言，安全与可预期性有时比无状态本身更关键。

12 个月弃用窗口¶

规范首次写入 正式弃用政策：任何被 deprecate 的特性，至少保留 12 个月方可移除。维护者与 Google、Microsoft、Amazon 等咨询后选定该窗口；遥测显示多数生态在 6–8 个月内完成升级。Roots、Sampling、Logging、HTTP+SSE 等均在此政策保护下逐步退场。

SDK 与生态现状¶

Tier 1 SDK——TypeScript、Python、Go、C#——均已支持 2026-07-28，并提供 breaking changes 迁移说明；Rust SDK 处于 beta。Claude 连接器目录已收录超 950 个 MCP Server，新规范支持正逐步 rollout 至 Claude 各产品面。

AAIF 自 2025 年 12 月成立以来，成员已从约 40 家增至 240 家；Anthropic 在贡献占比上已低于一半。联合维护者团队横跨 Anthropic、Microsoft、OpenAI、Google、Amazon 等，核心决策通常一致通过——VentureBeat 将此视为 MCP 从单一厂商项目走向中立开放标准的关键节点。

对开发者的迁移建议¶

若你维护 MCP Server 或 Client，建议按以下顺序评估：

1. 检查是否依赖 session ID 或 initialize 握手——这是本次最大 breaking change，官方 SDK 会吸收大部分改动，但自定义传输层需手动适配。
2. 评估长连接交互——elicitation、sampling 等应迁移至 MRTR 模式。
3. 更新 OAuth 集成——启用 iss 校验，规划从 DCR 向 CIMD 过渡。
4. 利用缓存头——在 Client 侧为 list 响应实现合理 TTL，降低冷启动开销。
5. 长任务改用 Tasks 扩展——避免为批处理作业维持 fragile 长连接。

Soria Parra 表示，多数基于官方 SDK 的项目迁移成本可控，「世界上任意一个模型大概都能 one-shot 帮你改完」——这本身也反映了维护者对 AI 辅助升级路径的设计考量。

小结¶

2026-07-28 不是增量补丁，而是 MCP 向 企业级 Agent 基础设施 的架构性跃迁：无状态核心解决规模化部署瓶颈，MRTR 与 Tasks 扩展覆盖交互与异步场景，OAuth 硬化与 EMA 回应生产环境的安全诉求，12 个月弃用策略则给出可预期的演进节奏。

对正在构建 Agent 工作流的团队而言，现在是用官方 SDK 对齐新规范、在标准 HTTP 栈上部署 MCP Server 的合适窗口。协议仍在快速演进——AAIF 已预告 Agent Gateway 等项目——但正如 Gilbert 所类比：HTTP 用了三十年才成为无人察觉的基础设施；Agent 互联网的「 plumbing」，或许正从这一次无状态转向开始真正承重。

参考来源

• The 2026-07-28 Specification | MCP Blog
• Bringing MCP 2026-07-28 to Claude | Anthropic
• MCP just got its biggest update ever | VentureBeat