MCP 2026-07-28 无状态协议实战从状态管理到显式句柄的架构迁移指南MCP 协议在 2026 年 7 月 28 日发布了自诞生以来最大的一次更新这次更新彻底改变了协议的核心架构。从双向有状态协议转变为请求/响应无状态协议这个变化让 MCP 终于能够真正支持企业级大规模部署。过去运行 MCP 服务器需要粘性路由或共享状态来维持会话连续性这给大规模生产部署带来了巨大的运维负担。现在每个请求都是自描述的可以路由到任何服务器实例就像普通的 HTTP API 一样简单。这次更新的核心变化是移除了 initialize/initialized 握手和 Mcp-Session-Id 头。以前客户端需要在连接时交换协议版本、客户端信息和客户端能力现在这些信息都放在每个请求的 _meta 字段里。服务器可以通过新的 server/discover RPC 方法按需暴露自己的能力客户端不需要预先知道任何信息。这种设计让任何服务器实例都能处理任何请求无需共享存储或粘性路由。对于需要跨调用保持状态的场景MCP 采用了显式句柄模式。服务器可以生成一个显式标识符比如 basket_id、session_token、workflow_id作为工具调用的结果返回。然后 LLM 在后续调用中把这个标识符作为普通参数传递回来就像 HTTP API 几十年来一直做的那样。这个模式比隐藏在传输层中的会话状态更好因为模型可以看到句柄并在工具之间传递它。Multi Round-Trip RequestsMRTR是另一个重要创新它解决了无状态协议中的交互问题。有时候工具在执行过程中需要向用户确认或获取缺失的参数以前这需要保持长连接。现在服务器可以返回 resultType: input_required 和需要回答的请求客户端在重试原始调用时附上答案。这种模式在 AWS Lambda 等无服务器环境中特别有用因为服务器不需要保持连接开放。MCP Apps 和 Tasks 作为官方扩展正式发布它们采用独立的版本控制和生命周期管理。MCP Apps 允许服务器在 AI 客户端中渲染交互式 HTML 界面从纯文本输出转向仪表板、表单和可视化。Tasks 扩展则重新设计了长时间运行操作的生命周期服务器可以返回持久的任务句柄。客户端可以断开连接、崩溃、重启后继续轮询这使得任务具有崩溃恢复能力。授权方面也进行了重大强化现在与 OAuth 2.0 和 OpenID Connect 的实际部署更加一致。最关键的是现在强制验证颁发者iss参数关闭了整个类别的混合攻击漏洞。EMA 扩展让企业可以通过身份提供商集中配置 MCP 服务器访问。用户通过现有的 IdP 组继承访问权限首次登录时自动连接实现零接触设置。协议还引入了正式的废弃策略任何被标记为废弃的功能都必须保持至少 12 个月的功能性才能被移除。Roots、Sampling、Logging 和 HTTPSSE 传输层都进入了废弃周期最早移除日期是 2027 年 7 月。对于正在迁移的开发者建议首先审计服务器对会话的依赖检查是否依赖 initialize、Mcp-Session-Id 或任何连接级状态。然后准备处理 _meta 字段跟踪 server/discover RPC 方法并规划废弃功能的迁移路径。AWS Well-Architected 框架的 Agentic AI 镜头已经将标准化协议集成列为最佳实践。新的无状态核心让 MCP 服务器可以在 AWS Lambda 上原生运行不再需要外部化状态到共享存储。协议级别的缓存也得到了增强list 和资源读取结果现在必须包含 ttlMs 和 cacheScope 字段。客户端可以精确知道 tools/list 响应的新鲜度以及是否可以跨用户共享缓存。工具列表现在以确定性顺序返回这允许跨调用保持 LLM 提示缓存的稳定性。Streamable HTTP 请求现在必须包含 Mcp-Method 和 Mcp-Name 头让网关、速率限制器或 WAF 可以直接在头部进行路由和计量。服务器会拒绝头部和正文不一致的请求这增强了协议的安全性。MCP 协议已经从一个小众工具注册表转变为代理基础设施的基础轨道。NPM 下载量超过 9700 万SDK 下载量达到每周 2.5 亿次协议已经达到了临界质量。在 Agentic AI Foundation 的治理下MCP 正在定义代理如何与世界交互的标准。但更深层的问题是行业如何在这个开放标准之上构建专有护城河。我们正在见证 MCP 作为接口模式在三个不同领域的收敛。CIQ 的 Fuzzball 4.2 允许代理管理高性能计算工作流具有明确的、有范围的权限。Anthropic 的 MCP 作为代码 API 模式从根本上改变了代理行为从被动的工具调用者转变为主动的代码编写实体。这种转变将令牌开销减少了 98.7%从 150,000 个令牌减少到 2,000 个。Vercel 的集成进一步巩固了这一轨迹将 MCP 服务器定位为持久代理的主要部署表面。通过引入 fingerprintTools 和 detectToolDrift 等安全原语Vercel 正在定义代理在生产环境中执行代码的操作标准。这些实现的同时出现标志着一个转变MCP 不再只是一个连接器它是代理系统的通用接口层。基础设施架构师的主要担忧是锁定发生位置的转变。在代理开发的早期开发者担心协议级锁定。今天协议是开放的但生态系统正在硬化。价值正在迁移到专门的安全原语、工作流范围的凭据和专有的技能库中。这些组件定义了代理在特定环境中实际能做什么的边界。这创造了一种新的围墙花园形式。为 CIQ 计算环境优化的代理使用其特定的工作流范围凭据不能简单地放入 Vercel 管理的部署表面。虽然协议相同但操作上下文——安全策略、工具漂移检测和特定的代码编写模式——越来越绑定到基础设施提供商。我们正在用一种形式的供应商依赖换取另一种。通过将安全和工作流逻辑直接嵌入 MCP 服务器实现基础设施提供商正在创建代理高度高效但越来越不移动的生态系统。对于技术领导者来说挑战是在利用这些专业生态系统的同时保持架构灵活性。目标应该是构建能够协商这些边界的代理而不是永久束缚在单一提供商的安全和部署原语上的代理。随着 Agentic AI Foundation 继续监督协议行业必须对实现层发生的分歧保持警惕。协议可能是通用的但代理正在变得越来越适应它们所处的环境。对于正在构建 MCP 服务器的开发者现在是时候开始在暂存环境中测试新的无状态核心了。官方合规套件涵盖了新的行为协议检查器可以固定到 2026-07-28 来测试你的服务器。对于新服务器直接从 2026-07-28 开始从一开始就无状态使用显式标识符不依赖 Roots、Sampling 或 MCP Logging。这次更新为 MCP 提供了它预期会长期成长的基础设施一个在普通 HTTP 基础设施上无状态运行的协议。一个扩展框架其中 Tasks 和 MCP Apps 等能力可以在自己的时间线上发布。以及一个生命周期策略让实现者可以基于 2026-07-28 构建知道他们发布的东西将继续工作。无状态核心、标准化扩展和强化授权将帮助开发者以更低摩擦、更一致的终端用户体验将更多应用程序带到 Claude。让我们深入看看这些变化具体如何影响开发者的工作流程。首先无状态协议让水平扩展变得前所未有的简单。以前你需要在负载均衡器上配置粘性会话或者维护一个共享的会话存储。现在任何服务器实例都能处理任何请求你可以直接使用标准的轮询负载均衡。这对于云原生部署来说是一个巨大的胜利因为你不再需要特殊的会话管理基础设施。其次显式句柄模式让状态管理变得透明和可预测。以前会话状态隐藏在传输层调试起来非常困难。现在状态作为显式参数在请求之间传递你可以清楚地看到数据如何流动。这种模式也更容易测试因为你可以模拟不同的状态场景而不需要复杂的会话设置。第三MRTR 模式让交互式工具调用变得更加可靠。以前服务器推送请求需要保持长连接这在无服务器环境中是不可能的。现在服务器可以返回需要输入的状态客户端可以在准备好后重试。这使得复杂的多步骤工作流可以在完全无状态的架构中实现。第四MCP Apps 为 AI 客户端带来了丰富的交互体验。以前工具只能返回文本用户需要在多个应用程序之间切换。现在服务器可以直接在 AI 客户端中渲染表单、图表和仪表板。这大大提升了用户体验也让开发更复杂的工具变得更加可行。第五Tasks 扩展解决了长时间运行操作的痛点。以前长时间运行的任务会阻塞连接或者需要复杂的轮询机制。现在服务器可以返回任务句柄客户端可以随时检查状态。任务甚至可以在客户端断开连接后继续运行实现了真正的异步处理。第六授权强化让企业级部署更加安全。以前 OAuth 支持相对基础企业集成需要很多变通方案。现在与 OAuth 2.0 和 OIDC 的深度集成加上 EMA 扩展让企业可以无缝对接现有身份系统。颁发者验证的强制要求关闭了整个类别的安全漏洞。第七正式的废弃策略给了开发者可预测的迁移时间表。以前协议变更可能突然破坏现有实现。现在任何被废弃的功能都有至少 12 个月的缓冲期。这让开发者可以有计划地进行迁移而不是被动地应对变更。第八缓存增强让性能优化变得更加精细。以前客户端不知道如何缓存工具列表每次都重新请求。现在服务器明确指定缓存时间和范围客户端可以做出智能的缓存决策。工具列表的确定性顺序也意味着 LLM 提示缓存可以跨调用保持稳定。第九头部路由让基础设施可以更智能地处理 MCP 流量。以前网关需要解析 JSON 体才能知道请求是什么操作。现在操作信息直接在 HTTP 头部网关可以快速路由和计量。这也让 WAF 可以基于操作类型进行更精细的安全控制。第十扩展框架让协议可以持续演进而不破坏现有实现。以前新功能必须进入核心协议增加了复杂性。现在新功能可以作为独立扩展发布有自己独立的版本和生命周期。这让 MCP 可以快速创新同时保持核心协议的稳定。这些变化共同构成了 MCP 协议的成熟化。从最初作为连接 AI 代理和工具的简单协议到现在成为企业级代理基础设施的标准。MCP 的发展轨迹反映了整个 AI 代理生态系统的成熟。对于开发者来说现在是拥抱这些变化的最佳时机。无状态协议让部署更简单扩展让功能更丰富授权让企业更安心。那些早期采用新协议的开发者将获得显著的竞争优势。他们的代理将能够更容易地扩展到大规模部署提供更好的用户体验。并且能够无缝集成到企业现有的安全基础设施中。MCP 2026-07-28 不仅仅是一次协议更新它是 AI 代理基础设施新时代的开始。一个无状态、可扩展、安全、可扩展的未来。一个让开发者可以专注于构建有价值的代理而不是纠结于基础设施复杂性的未来。现在就开始你的迁移之旅吧未来已经到来。让我们通过一个实际的代码示例来看看如何实现无状态 MCP 服务器。首先你需要安装最新的 MCP SDK它已经支持 2026-07-28 规范。typescript import { McpServer } from modelcontextprotocol/sdk/server/mcp.js; import { StdioServerTransport } from modelcontextprotocol/sdk/server/stdio.js; const server new McpServer({ name: stateless-example, version: 1.0.0 }); // 定义一个需要状态的工具 server.tool(create-basket, {}, async () { const basketId generateUniqueId(); // 将 basket 存储在数据库或缓存中 await saveBasket(basketId, { items: [] }); return { content: [{ type: text, text: Basket created: ${basketId} }] }; }); server.tool(add-to-basket, { basketId: { type: string, required: true }, item: { type: string, required: true } }, async ({ basketId, item }) { // 从存储中获取 basket const basket await getBasket(basketId); basket.items.push(item); await saveBasket(basketId, basket); return { content: [{ type: text, text: Added ${item} to basket ${basketId} }] }; }); // 启动无状态服务器 const transport new StdioServerTransport(); await server.connect(transport); 这个例子展示了显式句柄模式的工作原理。create-basket 工具返回一个 basketId客户端需要在后续调用中传递这个 ID。服务器不需要维护任何会话状态所有状态都存储在外部存储中。对于 MRTR 模式下面是一个需要用户确认的工具示例typescript server.tool(delete-file, { path: { type: string, required: true } }, async ({ path }) { // 检查文件是否存在 const exists await checkFileExists(path); if (!exists) { return { content: [{ type: text, text: File not found: ${path} }] }; } // 返回需要确认的状态 return { resultType: input_required, inputRequests: [{ type: elicitation, message: Are you sure you want to delete ${path}?, options: [Yes, No] }], requestState: { path, action: delete } }; }); // 处理用户确认后的重试 server.tool(confirm-delete, { confirmed: { type: boolean, required: true }, requestState: { type: object, required: true } }, async ({ confirmed, requestState }) { if (confirmed) { await deleteFile(requestState.path); return { content: [{ type: text, text: Deleted ${requestState.path} }] }; } return { content: [{ type: text, text: Deletion cancelled }] }; }); 这个模式让工具可以在执行前请求用户确认而不需要保持长连接。对于企业级部署下面是如何配置 EMA 扩展的示例typescript server.configureAuth({ type: ema, idp: { issuer: https://idp.company.com, clientId: mcp-server-client, scopes: [openid, profile, mcp:tools] }, policies: [ { effect: allow, principals: [group:mcp-users], actions: [tools/call], resources: [*] } ] }); 这个配置让企业可以通过现有的身份提供商管理 MCP 服务器访问。用户通过组成员身份继承权限无需单独配置每个用户。这些代码示例展示了 MCP 2026-07-28 规范的实际应用。无状态架构不仅简化了部署还提高了可靠性和可扩展性。显式句柄模式让状态管理变得透明和可预测。MRTR 模式让复杂的交互式工作流成为可能。企业级授权让 MCP 可以安全地集成到现有企业基础设施中。现在你已经了解了 MCP 2026-07-28 的核心变化和实际应用。是时候开始规划你的迁移策略了。首先评估你的现有 MCP 服务器对会话的依赖程度。然后逐步迁移到无状态架构利用显式句柄管理必要的状态。测试新的 MRTR 模式来增强你的工具交互能力。配置企业级授权以满足安全合规要求。最后利用扩展框架来添加新的功能如 MCP Apps 和 Tasks。MCP 的未来是无状态、可扩展和安全的。拥抱这些变化你的 AI 代理将能够在任何规模上可靠地运行。无论是在开发者的笔记本电脑上还是在企业级的生产环境中。MCP 2026-07-28 为这个未来奠定了坚实的基础。