MCP 2026-07-28 规范：传输层变为无状态

# 2026-07-28 规范 来源：https://blog.modelcontextprotocol.io/posts/2026-07-28/ 自从我们去年 11 月发布（https://blog.modelcontextprotocol.io/posts/2025-11-25-first-mcp-anniversary/）以来，MCP 继续以惊人的速度增长。在我们的 Tier 1 SDK 中，我们看到每月下载量接近 5 亿次，TypeScript 和 Python SDK 的总下载量均突破了 10 亿次大关。短短几个月内，该协议继续作为代理工作流的数据和交互性载体不断成长。 今天，我们正式按下发布按钮，推出下一版本的 MCP 规范 `2026-07-28`，以及相应的 SDK，让您可以立即开始构建客户端和服务器。 本次发布的亮点是一个无状态协议核心——MCP 正在从双向有状态协议转变为请求/响应无状态协议。这是开发者们最强烈要求的功能之一，他们渴望为 MCP 服务器获得更好的可靠性和可扩展性。 一个简短的无状态协议核心演示。当然，我们在这个版本中引入的远不止这些： - 每个请求都是自描述的，带有一个可选的发现调用，供希望预先获取能力的客户端使用，因此任何请求都可以落在普通轮询负载均衡器后面的任何实例上。 - 方法名称和工具名称通过 `Mcp-Method` 和 `Mcp-Name` HTTP 头部传输，因此网关可以直接根据这些头部进行路由和授权。 - 服务器对客户端的请求（如采样和启发）正在重新设计为使用多轮交互请求（MRTR），从而消除了持续开放双向流的需求。 - 列表响应携带缓存提示和确定性顺序，因此客户端可以缓存工具目录，并在重新连接时保持上游提示缓存稳定。 - 正式锁定一个合适的扩展框架，Tasks 加入了其他扩展，如 MCP Apps 和企业托管授权（EMA）。 - 一系列授权强化更改，包括 RFC 9207 发行者验证，以及从动态客户端注册（DCR）正式转向客户端元数据文档（CIMD）。 - 正式弃用策略，至少提供十二个月的窗口期，以便您可以规划升级而不是被动应对。 TypeScript、Python、Go 和 C# SDK 已相应更新，并提供了针对破坏性变更的详细迁移说明——您可以立即开始使用新规范。 ## 变更内容 ### 无握手或会话 在新规范版本中，我们正式淘汰了 `initialize`/`initialized` 交换以及 `Mcp-Session-Id` 头部（请参阅 SEP-2575 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2575)、SEP-2567 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2567)）。每个请求现在独立传输，在 `_meta` 中携带其协议版本、客户端身份和客户端能力。如果客户端希望在执行任何其他操作之前了解服务器的能力，有一个新的 `server/discover` 远程过程调用（RPC）可用于此目的；但这并非必需。任何请求现在都可以落在普通轮询负载均衡器后面的任何服务器实例上，而无需共享存储。 ``` 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"}}}} ``` 放弃协议级会话并不意味着您的应用程序必须是无状态的。如果您的服务器需要在调用之间保持状态，请从工具中创建一个显式句柄，并让模型将其作为参数传回。我们发现这比隐藏在传输中的会话状态效果更好——模型可以看到句柄并在工具之间传递。 ### 多轮交互请求（MRTR） MRTR 取代了服务器发起的 `elicitation/create`、`sampling/createMessage` 和 `roots/list` 请求，这些请求以前需要保持开放的流。 有时，工具在调用过程中需要从用户那里获取某些信息，例如确认或缺失的参数。MRTR（SEP-2322 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2322)）通过无状态协议实现了这一场景：服务器返回 `resultType: "input_required"` 以及需要回答的请求，客户端使用附加在 `inputResponses` 中的答案重试原始调用。 可流式 HTTP 请求现在必须包含 `Mcp-Method` 和 `Mcp-Name`（SEP-2243 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2243)）。您的网关、速率限制器或 WAF 可以直接根据这些头部进行路由和计量，而无需解析 JSON 主体。 ### 列表结果可缓存 来自 `tools/list`、`prompts/list`、`resources/list` 和 `resources/read` 的响应现在携带 `ttlMs` 和 `cacheScope`（SEP-2549 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2549)）。这使得客户端能够确定最佳的缓存策略，减少不必要的重新获取。 根据过去一年与实施者的讨论，授权是实施者花费最多集成时间的领域。通过本次规范修订，我们继续改进了 MCP 的授权和安全态势。 - 授权服务器应返回符合 RFC 9207 (https://www.rfc-editor.org/rfc/rfc9207) 的 `iss` 参数，客户端必须在兑换授权码之前验证该参数（SEP-2468 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2468)）。这填补了授权服务器混淆的漏洞。 - 客户端在动态客户端注册（DCR）期间设置 `application_type`，以便授权服务器不再拒绝桌面和 CLI 应用的 `localhost` 重定向（SEP-837 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/837)）。如果您曾疑惑为什么 CLI 客户端的 OAuth 流程出现了 `redirect_uri` 错误，这很可能是原因。同时，我们正在转向客户端 ID 元数据文档（CIMD）作为标准，这是一项强化措施，使协议符合 OAuth 规范要求。 - 客户端凭据绑定到颁发它们的发行者。不能跨授权服务器重用（SEP-2352 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2352)）。 - 动态客户端注册本身现在正式被弃用，转而使用 CIMD。DCR 将继续工作以保持向后兼容性，但将在未来版本的 MCP 规范中被移除。 ### Tasks Tasks 从实验性核心移出，进入 `io.modelcontextprotocol/tasks` 扩展，带有基于轮询的 `tasks/get` 和新的 `tasks/update`（SEP-2663 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2663)）。变更通知从旧的 HTTP GET 端点转移到单个 `subscriptions/listen` 流，客户端按通知类型选择加入。 ### 弃用 Roots、Sampling 和 Logging 已被弃用（SEP-2577 (https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2577)）。它们仍然有效，并且至少会继续工作十二个月。新的实现不应采用它们。传统的 HTTP+SSE 传输也被视为正式弃用，有一年的退出期。 ## SDK 所有四个 Tier 1 SDK 自今日起支持 `2026-07-28`： - TypeScript (https://github.com/modelcontextprotocol/typescript-sdk) - Python (https://github.com/modelcontextprotocol/python-sdk) - Go (https://github.com/modelcontextprotocol/go-sdk) - C# (https://github.com/modelcontextprotocol/csharp-sdk) 除了 Tier 1 之外，Rust SDK (https://github.com/modelcontextprotocol/rust-sdk) 也已支持新规范（beta 版）。 这些 SDK 实现了允许您使用新规范版本构建服务器和客户端的 API。正如我们在 SDK beta 博客文章（https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/）中提到的，会有一些迁移成本，特别是对于依赖会话标识符的开发者；然而，我们整合了早期测试反馈，使得这一过程更加容易。 ## 生态系统支持 与任何大型发布一样，没有生态系统中各位的贡献，我们与 MCP 相关的工作就不可能实现。我们尤其感谢一些贡献者和合作伙伴，他们在规范正式发布前帮助我们进行了测试和验证。 > 新版本是 MCP 自一年多前首次推出远程 MCP 以来最重要的一次。它是在可扩展的 MCP 服务器服务方面的一次飞跃，并吸取了过去 18 个月的所有经验教训，为 MCP 的未来奠定了坚实的基础。新添加的扩展展示了更广泛开源项目的持续创新。我很期待看到人们将如何利用 MCP 的新能力。 David Soria Parra 技术专家，MCP 共同发明者 > 这次发布是最清晰的信号，表明 MCP 正成为真正的生产级基础设施。最大的变化是破坏性的，而社区选择了做艰苦的工作而不是掩盖差距。这与我们在合作的企业中看到的情况一致：MCP 已经成为这些团队构建的默认选择，而这次发布正是他们一直等待的成熟过程。这是一个协议在不断成长以适应生产团队的实际需求，对于任何构建企业代理的人来说，这是一次进步。 Alex Salazar CEO 兼联合创始人 > AWS 和 Anthropic 致力于支持 MCP 社区，并帮助开发者大规模交付企业级代理。借助新的 MCP 规范及其在 Amazon Bedrock AgentCore 中可用的无状态协议核心，开发者可以在标准、可扩展的基础设施上部署 MCP 服务器，而无需管理会话或持久连接。Tasks 作为首批官方 MCP 扩展之一，由 AWS 贡献，为可靠、长时间运行的代理带来了支持，使开发者可以花更少的时间在基础设施上，更多的时间进行创新。 Swami Sivasubramanian Agentic AI 副总裁 > MCP 2026-07-28 是将代理基础设施打造得与其他网络服务一样的重要一步：无状态、可缓存、可路由、可全球扩展。Cloudflare 的 Agents SDK 从第一天起就支持该规范，因此开发者可以直接在 Workers 中运行 MCP 服务器，无需传输会话开销即可调用工具，并支持更丰富的流程（如用于审批的启发）。因为 MCP 是一个开放标准，Cloudflare 的客户（如 Sentry 和 Linear）可以从第一天开始采用，并立即将这些改进带给他们的用户。 Brendan Irvine-Broque 产品管理高级总监 > 越来越多的构建者正在使用我们的 MCP 服务器将生成的输出带入 Figma 的画布，在那里他们可以与团队一起探索、即兴发挥和完善，打造出脱颖而出的产品。随着使用量的增长，我们的无状态架构可以随之扩展，借助 MCP Apps、Tasks 和企业托管授权，我们可以做更多事情，将设计和代码保持在一个连接的工作流中。 Josh Clemm Google Cloud 工程副总裁 > 2026-07-28 的 Model Context Protocol 发布代表了企业 AI 可扩展性的巨大飞跃。通过演变为无状态架构，该规范消除了大规模部署代理工作流的摩擦。在 Google Cloud，我们很高兴能够在我们整个开发者工具生态系统中利用这些强大的新能力。这次发布为我们的客户（以及我们自己的团队）构建下一代 AI 应用程序提供了稳健、安全且可扩展的基础，我们很自豪能够继续共同塑造这一开放标准的未来。 Anna Berenberg 工程研究员 > 在 honeycomb.io，我们看到了 MCP 的极佳采用率——现在近 20% 的月度交互式查询是由代理完成的！新的规范发布使我们能够在企业规模下运行的同时，支持更高级的功能，如启发。 Austin Parker AI 策略总监 > MCP 规范的新版本证明了维护者倾听社区的反馈。它解决了我们在 Manufact 面临的实际问题，无论是在我们的开源框架 mcp-use 中，还是在托管数千个 MCP 服务器的 Manufact Cloud 上。新的 SDK v2 驱动着 mcp-use，得益于新的客户端-服务器拆分，帮助我们削减了约 83% 的包大小，同时提升了 25% 的速度。随着 MCP 走向无状态，我们能够更可靠、更安全、大规模地处理生产流量，而无需不切实际的基础设施变通方法。 Enrico Toniato CTO > 开放协议创造的生态系统比任何一家公司单独构建的都要大。MCP 是 Microsoft Foundry 的基础，使我们能够从几十个集成扩展到数千个。我们通过 Foundry 工具箱的统一 MCP 端点来利用它，该端点将工具整合在一起，同时集中治理、身份和可观测性。借助无状态操作、用于长时间运行任务的 Tasks 以及企业托管身份，下一代 MCP 使得构建安全、可扩展、生产就绪的代理系统比以往任何时候都更容易。 Tina Schuchman Microsoft Foundry 工程企业副总裁 > 2026-07-28 规范中的无状态核心使 MCP 成为一等 HTTP 工作负载，无需处理会话管理。我们的客户希望 Netlify 上的 MCP 像平台其他部分一样简单，而新规范从根本上解锁了这一点。将 MCP Apps 构建到新的扩展框架中，对于整个生态系统的可扩展性、可访问性和能力来说是一大步。 Sean Roberts 应用 AI 副总裁 > MCP 现在大约有一年半的历史。感谢开发者和其他与我们一起工作的人的反馈，它正在演变为一个更成熟的协议，吸收了数十年网络协议设计的经验教训。与之前的修订版一样，最有趣的部分将是看到人们用它构建出意想不到的东西。 Nick Cooper MTS 与 MCP 核心维护者 > 将 MCP 转变为无状态协议使我们更容易扩展自己的服务，也更容易为客户端的 MCP 服务器添加分析功能。更容易向人们展示他们的 MCP 工具是如何被使用的，以及缺少哪些用户希望使用的工具。很高兴看到协议朝这个方向发展。 Paul D'Ambra 产品工程师 > 对于任何大规模构建 MCP 的人来说，这是一个里程碑式的发布。FastMCP 一直致力于将规范最强大的能力转化为直观的开发者体验，我们很高兴在 FastMCP 4.0 中为后台任务、无状态交互、企业授权等提供一流支持。我们的 MCP 治理平台 Horizon 从一开始就是以无状态方式构建的，以应对巨大规模，因此看到这种方法成为协议的本土部分，真是令人难以置信。 Jeremiah Lowin CEO > 这次发布使 MCP 比以往任何时候都更具备企业就绪性。Runlayer 正在将这些进步带给我们平台上的每一个企业，为跨组织部署 MCP 和代理提供更简单、更安全的基础。 Tal Peretz 联合创始人兼 CPO > 最新的 MCP 修订版是一个重要的里程碑。它反映了严谨的态度和用户的输入，表明协议正在以企业可以放心使用的方式成熟。我们已经实施了修订版，向无状态模型的转变消除了操作复杂性，并释放了 MCP 在企业规模上的潜力。这是一个强有力的信号，表明社区正在被真实的部署经验所塑造。 Craig McLuckie CEO > 支持启发功能在我们的路线图上已经有一段时间了，但由于 Supabase MCP 以无状态方式运行，这并不容易实现。MRTR 改变了这一点——它允许我们的工具在行动之前先与用户确认，比如在创建新项目之前确认成本，或者排队