2026 年 7 月 28 日MCP 发布第 5 版规范官方将其定性为该协议问世以来规模最大、最系统性的一次颠覆式修订核心变化是从双向有状态连接全面转向无状态核心。本次更新正式废除了 initialize/initialized 握手流程彻底移除 Mcp-Session-Id 请求头每个请求变为完全自包含协议版本、客户端身份与能力通过 _meta 字段随请求送出。这标志着 Agent 工具层接入标准从有状态连接迈入无状态请求/响应的代际跃迁MCP 服务器从此可以直接部署在 Serverless 与边缘计算环境任何一笔请求都能落在轮询式负载均衡器后面的任何一台实例上不再依赖粘性会话与共享存储。MCP 近期月 SDK 下载量超过 4 亿次是今年 4 倍的增长Claude 的连接器目录已列出超过 950 个 MCP 服务器官方同时引入版本化扩展框架并强化了对生产环境 OAuth 2.0 与 OIDC 部署的适配。旧版 MCP 依赖会话绑定客户端必须先完成握手拿到会话 ID请求必须路由到同一台服务器实例横向扩展需要粘性会话和共享存储支持实例重启后会话恢复也是棘手问题。新版彻底移除协议层会话任何请求都能落在负载均衡器后的任意实例上MCP 流量重新变回普通的无状态 HTTP 负载。配套的 Mcp-Method 与 Mcp-Name 标头让网关与 WAF 无需解析 JSON 内容即可路由和计费标头与内容不一致时服务器回传 JSON-RPC 错误码 -32001 与 HTTP 400。Netlify 方面的评价是2026-07-28 规范中的无状态核心让 MCP 成为一等 HTTP 工作负载无需再绕开玩笑管理客户希望 Netlify 上的 MCP 像平台其他部分一样简单新规范从核心层面解锁了这一点。Zoom 方面也认为新规范让基于标准 HTTP 基础设施部署和扩展 MCP 服务器变得容易得多用户可以更快更可靠地在日常依赖的 AI 工作流中获得 Zoom 的会议智能。对于长期被会话管理困扰的平台团队而言这次改版的现实意义远超一次普通的版本迭代它把 MCP 从难以运维的有状态服务拉回了标准 HTTP 的舒适区。Anthropic 在公告中指出无状态核心让服务器可以部署在 Serverless 与边缘基础设施上简化了为 Claude 构建 MCP 服务器并在采用率增长时扩展使用的体验。Intuit 表示无状态协议核心与扩展框架让技术人员和客户能够以企业级规模构建和连接 Agent 体验继续为数以亿计的消费者和企业提供可信的金融智能体验。Block 的观点更直接2026-07-28 规范中的无状态核心降低了他们需要管理的复杂度可以更快地以更大规模向客户交付更多功能。这些来自一线企业的反馈共同指向一个判断无状态不是一次功能取舍而是 MCP 从演示阶段走向生产基础设施的必经之路。一、无状态核心MCP 2026-07-28 架构改版全貌MCP 2026-07-28 规范于 2026 年 7 月 28 日正式发布官方将其定性为该协议问世以来规模最大、最系统性的一次颠覆式修订。MCP 由 Anthropic 于 2024 年 11 月底推出目的是统一大语言模型与外部数据源和工具之间的通信方式2026-07-28 版是其第 5 版规范此前主流版本为 2025-11-25。新版本与旧版本的核心差异可以概括为四点协议状态从有状态变为完全无状态握手机制从必须握手变为取消握手新增的 server/discover 允许预先探索但不强制会话管理从依赖 Mcp-Session-Id 请求头变为完全无会话每个请求相互独立完全自包含水平扩展性从必须使用粘性会话变为请求可路由到任意网关或实例。这四点差异共同构成了本次改版的技术骨架。新版本将协议从双向有状态连接全面转向无状态请求/响应模型服务器不再需要维持任何会话状态即可响应请求。每个请求独立自包含协议版本、客户端身份与能力全部通过 _meta 字段随请求送出。MCP 的 _meta 字段保留键包含 io.modelcontextprotocol/protocolVersion、io.modelcontextprotocol/clientInfo、io.modelcontextprotocol/clientCapabilities 等名称格式要求前缀使用反向 DNS 记号第二个标签为 modelcontextprotocol 或 mcp 的前缀保留给 MCP 使用。客户端若想事先探知服务器能力可选选用新增的 server/discover RPC但该调用并不是强制要求。这意味着 MCP 服务器从难以运维的有状态服务变成了标准的 HTTP 函数Serverless 与边缘计算环境成为一等部署目标。同时移除 Mcp-Session-Id 标头协议层不再需要粘性路由和共享会话存储负载均衡器可以对每一笔请求做普通的轮询分发。无状态并不意味着服务器不能有状态官方推荐的模式与 HTTP API 一致在一次工具调用中生成显式句柄模型在后续调用中以普通参数传回该句柄。服务器持有句柄背后的真实状态每次调用时依据授权上下文校验句柄这样状态对模型可见可传递但协议层保持干净的无状态语义。这一设计选择值得注意它没有试图消灭状态而是把状态从协议层下沉到应用层让每一层各自承担最擅长的职责。对于使用 Kubernetes 的团队Service 配置中的 sessionAffinity 可以直接设为 None这一行小小的改动背后是整个运维模型的简化。二、JSON-RPC 2.0无状态架构的消息基石MCP 所有客户端与服务器之间的消息必须遵循 JSON-RPC 2.0 规范这是协议通信的基石该规范本身就是一个无状态且轻量级的远程过程调用协议。MCP 选择它正是看中了它与无状态架构的天然契合JSON-RPC 2.0 的定义非常严格请求必须包含字符串或整数 IDID 不得为 null且不得在同一会话中重复使用响应必须包含与请求相同的 ID 以建立关联通知则不需要响应。请求对象必须包含 jsonrpc、method、params 三个字段响应对象必须包含 jsonrpc、id 与 result 或 error 之一。这套消息形状在 MCP 的各种传输方式上保持一致是无状态请求-响应对能够落地的语法前提也是任何 HTTP 中间件都能识别和处理 MCP 流量的基础。JSON-RPC 2.0 定义了请求、响应和通知三种消息类型每一种在 MCP 的会话中都承担明确角色。请求由客户端发给服务器等待一个带相同 ID 的响应响应由服务器返回给客户端携带结果或错误通知则是单向消息不需要对端回复。tools/list、tools/call、resources/read、prompts/get 这些核心操作全部以 JSON-RPC 请求的形式表达method 字段决定操作类型params 字段携带具体参数。这种统一的消息形状让任何 HTTP 基础设施都能对 MCP 流量做出标准化的处理决策。错误响应的错误码必须是整数标准 JSON-RPC 错误码之外还定义了 MCP 特有的扩展码例如 -32001 表示 HeaderMismatch用于标头与正文不一致的场景。// JSON-RPC 2.0 请求示例 { jsonrpc: 2.0, method: tools/call, params: { name: searchFlights, arguments: { origin: PEK, destination: SHA, date: 2026-10-01 } }, id: 1 } // JSON-RPC 2.0 响应示例 { jsonrpc: 2.0, result: { content: [ { type: text, text: 找到 3 个航班... } ] }, id: 1 }无状态架构下每个请求独立自包含任何服务器实例都能处理工具目录响应还带上 ttlMs 与 cacheScope 缓存元数据。SEP-2549 可缓存列表结果让 tools/list、prompts/list、resources/list、resources/templates/list、resources/read 与 server/discover 的结果携带这两个字段客户端可据此缓存共享中间层可依据 cacheScope 决定响应是否可缓存。官方同时建议服务器以确定性顺序返回工具列表以便序列化输出保持稳定从而提升下游 LLM 提示缓存的命中率这是一个看似微小却影响显著的工程细节。规范还对 JSON Schema 的使用做出明确规定默认方言为 2020-12实现必须至少支持该方言并对不支持的方言优雅报错组合关键字与 $defs 虽能表达丰富语义但验证成本高昂实现应当施加合理的边界如最大 schema 深度或单次验证时间预算防止恶意 schema 成为验证器的拒绝服务向量。三、三大原语Tools、Resources 与 Prompts 的控制层级MCP 服务器提供三大核心原语Tools、Resources 和 Prompts各自对应不同的控制层级这一设计在 2026 版本中保持不变并继续作为协议的能力基础。Tools 由模型控制是可执行函数允许模型执行操作或检索信息采用 JSON Schema 定义输入输出。Resources 由应用控制提供结构化数据或内容作为模型上下文例如文件内容、git 历史或数据库 schema。Prompts 由用户控制是预定义模板或指令典型例子包括斜杠命令与菜单选项。三层控制结构确保了不同角色的合理分工模型自主决定何时调用工具应用决定何时把资源塞进上下文用户决定何时启用某个提示模板这种分层避免了把一切能力都塞进工具列表所带来的语义混乱。Tools 是模型控制的主动能力每个工具定义一个具体操作与类型化的输入输出模型根据上下文请求工具执行。MCP 使用 JSON Schema 校验工具输入工具调用可能需要用户授权后才能执行确保用户对模型行为保持控制。协议层面 tools/list 返回所有可用工具及其 schematools/call 执行某个具体工具并返回结果。一个典型的工具定义包含 name、description 与 inputSchema 三个字段例如 name 为 searchFlightsdescription 为搜索可用航班inputSchema 声明 origin、destination、date 三个必填字符串字段。旅行预订场景中航班搜索、日历占位、邮件通知三个工具可以被模型自动串联调用。工具的 schema 同时是客户端渲染参数表单与服务器校验入参的唯一契约因此 schema 的准确度直接决定了整个 Agent 流程的可靠性。Resources 是应用控制的被动数据源提供只读信息作为上下文例如文件内容、数据库 schema 或 API 文档。每个资源有唯一的 URI如 file:///path/to/document.md并声明自身的 MIME 类型以便正确处理内容。资源支持两种发现模式直接资源是固定 URI 指向特定数据资源模板是带参数的动态 URI如 travel://activities/{city}/{category}。Prompts 由用户控制是预构建的指令模板告诉模型如何配合特定工具与资源工作典型例子包括规划假期、总结会议、起草邮件。三类原语共同构成了 Agent 与外部世界交互的完整语法Tools 管动作Resources 管上下文Prompts 管交互入口这种分层设计让协议在扩展时不必反复改动核心结构。四、Agent 工具层接入标准的演进从粘性会话到无状态请求旧版 MCP 依赖会话绑定客户端必须先完成握手拿到会话 ID请求必须路由到同一台服务器实例横向扩展需要粘性会话和共享存储支持。每个服务器返回带 Mcp-Session-Id 标头的响应客户端后续请求必须带上这个 ID负载均衡器需要依赖这个 ID 把请求路由回同一实例或者所有实例共享一份会话存储。这一模型在单机演示阶段问题不大但一进入生产环境就立刻变成运维负担实例重启、扩缩容、跨区部署都会牵动整个会话生命周期。自动扩缩基础设施必须保留会话部署时必须排空或迁移会话而负载均衡并不现实因为客户端会被固定到持有其会话的那个实例上。2026-07-28 版本彻底移除协议层会话任何请求都能落在负载均衡器后的任意实例上MCP 流量重新变回普通的无状态 HTTP 负载。没有 Mcp-Session-Id没有粘性路由没有共享会话存储经典的横向扩展模型成为正确且足够的部署形态。这一改动对平台团队意味着容量规划从依赖会话亲和的复杂模型简化到请求速率与并发连接两个维度扩容缩容成为基础设施层面的常规操作。若网关或代理此前依赖 Mcp-Session-Id 做遥测关联、粘性路由或授权绑定需要设计替代方案通常回退到已认证主体或服务器签发的句柄。若上游 MCP 服务器是无状态的粘性路由应当直接移除。Multi Round-Trip Requests 取代长连接SEP-2322 让服务器通过 InputRequiredResult 返回 input_required 结果与 requestState客户端收集答案后携带 requestState 重试原请求。服务器返回的 resultType 为 inputRequiredinputRequests 是一张由服务器命名的映射值是既有的 CreateMessageRequest、ElicitRequest 或 ListRootsRequest 形状requestState 是不透明的服务器编码状态SEP 推荐的做法是服务器把所有恢复所需状态编码进这个字符串把重试当作全新请求处理。客户端把答案放进 inputResponses连同原参数与回显的 requestState 重送原请求任何实例都能接管这次重试因为一切所需数据都在载荷里。这一模式明确是破坏性变更取代了旧版服务器发起请求的全部流程需要真正跨调用持久化的工具则应当迁移到 Tasks 扩展。五、无状态架构的技术优势与实际应用场景无状态架构使 MCP 服务器可直接部署在 Serverless 与边缘计算环境例如 AWS Lambda 与 Cloudflare Workers无需粘性路由和共享状态存储。对于处理数百万并发查询的平台而言从传输层解耦状态是满足可扩展性硬性要求的关键一步。企业可以在无需改动既有基础设施的前提下把 MCP 服务器当成普通 HTTP 服务部署扩缩容、灰度发布、蓝绿部署、跨区多活这些成熟实践直接适用。运维团队不再需要为会话亲和性维护额外一层路由与存储成本与复杂度同时下降。Stacklok 与 Linux Foundation AAIF 于 2026 年 7 月联合调查 100 名美英企业高级软件工程师41% 的受访者称 MCP 已进入生产但 86% 的使用仍是实验或本地开发仅 5% 处于受治理的企业级生产环境49% 将安全与合规列为首要挑战34% 提到治理。这组数据说明协议层的简化只是第一步组织层面的采纳仍有很长的路。配套的 Mcp-Method 与 Mcp-Name 标头让网关与 WAF 无需解析 JSON 内容即可路由和计费标头与内容不一致时服务器回传 JSON-RPC 错误码 -32001 与 HTTP 400。SEP-2243 HTTP 标准化要求每个 Streamable HTTP POST 携带 Mcp-Method对于 tools/call、resources/read、prompts/get 还要携带 Mcp-Name工具参数可通过 x-mcp-header 注解镜像到 Mcp-Param-{Name} 标头例如 Spanner 的 execute_sql 工具上的 region 参数变成 Mcp-Param-Region: us-west1。这种设计让边缘层在不解析请求体的前提下就能完成路由、限流、计费与策略判断降低处理开销的同时保持协议一致性。工具目录响应的 ttlMs 与 cacheScope 元数据让 CDN 可以像缓存普通 HTTP 响应一样缓存工具列表进一步降低源站负载。授权方面向企业 IdP 靠拢授权服务器应依 RFC 9207 回传 iss 参数客户端必须在兑换授权码前验证该参数堵住授权服务器混淆漏洞。新规范强化了对生产环境 OAuth 2.0 与 OIDC 部署的适配MCP 服务器无需采用变通方案可连接 Entra 或 Okta 等企业身份系统。SEP-2577 正式弃用 roots、sampling 和 logging 三项功能SDK 为向后兼容继续暴露对应类型但新服务器不应依赖它们。Sampling 的迁移方向是服务器直接调用 LLM 提供商 APIRoots 的迁移方向是改用普通工具参数或资源 URILogging 改用标准 stderr 日志。无状态化也把安全边界从协议层转移到了每个构建者身上每个 MCP 服务器都必须独立处理认证、授权与审计日志不能再依赖会话状态作为安全上下文。六、MCP 生态现状与未来趋势MCP 近期月 SDK 下载量超过 4 亿次是今年 4 倍的增长Claude 的连接器目录已列出超过 950 个 MCP 服务器被数百万人日常使用。生态的参与方已经从早期的少数实现扩展到 Figma、Intuit、Netlify、Zoom 等多家企业级平台Figma 方面表示其无状态架构可以随使用量增长而扩展借助 MCP Apps、Tasks 与企业托管授权设计到代码的流程可以更紧密地连接在一个工作流里。Anthropic 同时为目录中的连接器提供了可观测性仪表板开发者可以追踪采用率、诊断错误与延迟并按产品面拆解使用情况MCP 隧道的研究预览则让团队可以在不暴露公网的前提下把内网 MCP 服务器接入 Claude。扩展框架正式成形MCP Apps 与 Tasks 作为首批官方扩展在版本化框架下发布为核心协议之外的交互界面与长时间任务提供独立演进路径。MCP Apps 让服务器可以随工具结果一起提供一个小型沙箱界面宿主在侧边渲染用户可以直接在对话里看到连接器在做什么并与之交互无需切换标签页。Tasks 处理长时间运行的工作工具返回一张票据而不是占着连接直到作业完成客户端稍后再取结果批量导出、仓库扫描、跨系统联邦查询这类慢操作终于有了标准形态。企业托管授权让管理员通过身份提供者为整个组织配置 MCP 连接器管理员授权一次用户通过既有的 IdP 组继承访问权限首次登录即完成连接。这套组合让核心协议保持精简同时把创新留给可选的版本化能力。MCP 的治理结构也在同步演进2025 年 12 月 Anthropic 将 MCP 捐赠给 Linux FoundationOpenAI、Google、Microsoft 等成为联合发起方MCP 从此不再是单一厂商的协议而成为行业基础设施。官方路线图把优先级放在可扩展性、治理、企业就绪与生态系统健康上企业就绪这一项被刻意留得较为开放因为维护者希望由正在经历企业部署挑战的实践者来定义这部分工作。已经明确的痛点包括审计追踪、认证与身份、网关行为与配置可移植性大部分企业就绪工作预计会以扩展形式落地而非改动核心规范专门的 Enterprise Working Group 尚未成立官方明确邀请企业基础设施实践者来主导。MCP 2026-07-28 的无状态核心改版从根本上解决了生产环境横向扩展的运营负担让 MCP 服务器从难以运维的有状态服务变成了标准的 HTTP 函数也让 Serverless 与边缘部署从理论可行变为工程现实。从 JSON-RPC 2.0 消息格式到三大原语的控制层级协议在保持简洁的同时实现了代际跃迁每一个设计决策都指向同一个目标让 Agent 工具层接入变得像调用普通 Web API 一样简单让平台团队用既有的 HTTP 基础设施就能承接 AI 流量。随着扩展框架的成熟和 SDK 生态的完善MCP 正成为 Agent 工具层接入的事实标准而 2026-07-28 版本无疑是这条演进路径上最关键的一块里程碑接下来需要观察的是企业治理能力能否跟上协议层已经完成的简化。