告别「握手」：MCP 2026-07-28 如何让 AI Agent 真正走向企业级部署

一、MCP 从哪里来，又走到了哪里

2024 年底，Anthropic 发布了 Model Context Protocol（MCP）。它解决的是一个很具体的问题：大模型很强，但每次让它查数据库、读文档、调 API，都得单独写一套胶水代码。能不能像 USB-C 一样，做一个通用的「AI 接口」？

不到两年，MCP 走过了几个重要节点：

• 2024-11-05：MCP 第一个版本发布。核心逻辑很简单——把工具、数据和提示模板标准化，模型通过统一的 JSON-RPC 协议就能调用。那时候大家关心的是「能不能连上」。
• 2025-03-26：Streamable HTTP 传输层替代了早期的 HTTP+SSE 方案。远程部署不再需要维护一个常开的 SSE 长连接，服务器终于可以用普通的 HTTP 端点和客户端通信了。
• 2025-06-18 到 2025-11-25：授权框架、结构化工具输出、elicitation（向用户反问补充信息）、实验性 Tasks，以及扩展机制的雏形陆续落地。协议不再只是一个「连接器」，生产环境的需求开始主导它的演进方向。

到这，问题已经变了。不是「能不能连上」，而是「能不能撑住规模」。

早期的 MCP 有一个隐含假设：一次交互就是一个会话。客户端先跟服务端「握手」——交换协议版本和能力清单，服务端颁发一个会话 ID，后续所有请求都得带着这个 ID，也必须回到同一台服务器上。这在本地跑一个工具的时候完全没问题。但要把它部署到几百个实例的企业集群里，麻烦就来了：负载均衡器得识别会话并做粘性路由，挂掉一个实例就会丢一批会话状态，中间件得理解 MCP 专有的消息生命周期。

2026 年 7 月 28 日即将正式发布的这一版（目前仍处于发布候选（RC）阶段）做了一件看起来「减法」的事：它把这套握手和会话机制从协议里拆掉了。

二、一次工具调用，为什么要先「握手」

先看看旧版 MCP 在远程模式下是怎么工作的。

假设你的 Agent 想调一个搜索工具tools/call。在 2025-11-25 版本的 Streamable HTTP 传输下，流程是三步：

1. 客户端发一个initialize请求，告诉服务端「我支持的协议版本是 2025-11-25，我有哪些能力」。
2. 服务端回一个Mcp-Session-Id，再通知客户端「初始化完成」。
3. 客户端带着这个Mcp-Session-Id，发实际的tools/call请求。

客户端 服务端 │ │ │──── initialize ───────────→│ │←─── Mcp-Session-Id ────────│ │──── initialized ──────────→│ │ │ │──── tools/call ───────────→│ （携带 Session ID） │←─── result ────────────────│

这个Mcp-Session-Id是协议级的会话标识。它的存在意味着：每一次交互都绑定在一个隐式的「连接生命线」上。负载均衡器必须把同一个 Session ID 的请求路由到同一台服务器——也就是粘性路由。如果你水平扩展了十个实例，挂掉一个，那这台实例上所有进行中的会话就没了。

在本地跑 stdio 模式时，进程本身就是这个「会话」，没有人会注意到这个问题。但当你把 Agent 部署到企业环境——多实例、自动扩缩容、网关统一路由和审计——这个设计就开始咬人了。你得专门维护一个共享的会话存储，得让网关理解 MCP 的消息语义，得处理会话迁移和恢复。基础设施在为协议「让路」，而不是反过来。

三、2026-07-28：把状态从协议核心中拿出去

2026-07-28 版本做的事，一句话概括：每个请求自己说明自己是谁，不再需要事先握手。

具体来说，initialize和notifications/initialized被移除了。Mcp-Session-Id和协议级 session 也一并移除。取而代之的是，每个请求在_meta字段里携带三样信息：

• io.modelcontextprotocol/protocolVersion：我用的是哪个协议版本
• io.modelcontextprotocol/clientInfo：我是哪个客户端
• io.modelcontextprotocol/clientCapabilities：我具备哪些能力

任何一个请求都是自包含的。服务端的任何实例都能独立处理它，不需要先去查「这家伙之前跟我握手了吗」。

新版调用流程变成一步：

客户端 服务端（任意实例） │ │ │──── tools/call ───────────→│ （自带 _meta：版本、身份、能力） │←─── result ────────────────│

客户端也可以在发实际请求之前先调server/discover，问清楚服务端支持哪些版本和能力。但这不是必须的——直接发也行，如果版本不匹配，服务端会返回一个UnsupportedProtocolVersionError，列出它支持的版本，你换一个重试就好。

这里有一个容易混淆的地方，值得特别说清楚：协议无状态不等于业务无状态。

举个例子。假设你在做一个企业采购 Agent。你让它「搜索三家云服务供应商、创建一个采购申请、等审批通过后下单」。在旧版 MCP 里，创建采购申请这个动作可能依赖会话上下文——服务端在握手阶段记住了你的身份、部门和预算上限。在新版里，这些信息不再由协议管理，但你的业务可以自己管理。采购申请创建后，服务端返回一个request_id，Agent 后续查询和操作都带着这个 ID。状态还在，只是协议不再替你「偷偷」记着了。

官方博客里把这一点讲得很明白：把状态从传输层的元数据里搬出来，变成模型可见的显式参数，反而让模型能够跨工具编排这些标识符——这比藏在 session 里的隐形状态要有用得多。

四、企业基础设施为什么在意这件事

拆掉握手和会话的直接后果，是 MCP 突然变得「基础设施友好」了。

回到那个采购 Agent 的场景。在旧版里，如果采购服务部署了三台实例，网关必须保证search和后续的create_request落在同一台实例上——因为它们共享一个会话。负载均衡器得配粘性路由，监控要追踪会话亲和性，扩缩容时还得处理旧实例上未终结的会话迁移。

在新版里，search打到实例 A，create_request打到实例 B，完全没问题。你可以用最普通的轮询负载均衡，不需要共享存储，不需要网关理解 MCP 的会话语义。

三个具体改进让这件事更好落地：

可路由。Streamable HTTP 传输现在要求携带Mcp-Method和Mcp-Name头。网关或限流器不用解析 JSON 报文就能知道「这是一个tools/call，目标是search」，路由、限流、审计都可以在 HTTP 层完成。

可缓存。tools/list、resources/list这类查询结果现在带ttlMs和cacheScope字段。客户端和中间代理可以直接按 HTTP 缓存语义处理，不用反复轮询。配合subscriptions/listen的变更通知——列表变了服务端会推送——缓存和实时性可以兼得。

可追踪。W3C Trace Context 传播被写进了规范，traceparent、tracestate、baggage这些字段通过_meta传递。一条追踪链路可以从宿主应用穿过客户端 SDK、MCP 服务端、再到服务端调的下游系统，在 OpenTelemetry 后端拼成一颗完整的调用树。这对排障、性能分析和审计的价值不言自明。

还需要提一句 Multi Round-Trip Requests（MRTR）。服务端有时需要在处理请求的中途向客户端问一个问题——比如「要删除这三个文件，确认吗？」。旧版依赖保持 SSE 连接打开来实现这个交互，新版改成了服务端先返回一个InputRequiredResult（resultType: "input_required"），把问题、选项和状态一并打包；客户端收集好答案后，带着inputResponses重发原请求。任何一个服务端实例都可以接住这个重发，因为它需要的全部上下文都在请求体里。

五、不只是无状态：一个更轻、更可治理的 MCP

无状态化是这次升级的主线，但 2026-07-28 不止于此。

Extensions 成为一等公民。之前 MCP 也有扩展的概念，但没有正式的机制。现在扩展有了反域名标识符（如io.modelcontextprotocol/tasks）、独立的代码仓库、自己的版本节奏，和从 SEP 提案到发布的完整流程。核心协议不必为每一个新场景膨胀——像 Tasks 和 MCP Apps 这种能力就可以作为扩展独立演进。

Tasks 从核心协议搬到了扩展里。之前在 2025-11-25 中的实验性 Tasks API 在真实使用中暴露了不少设计问题，团队决定把它重构成一个扩展：用tasks/get轮询替代阻塞等待，用tasks/update支持中途输入，tasks/list因为无法在无会话模型下安全做权限隔离而被移除。采购审批这种耗时几小时的流程，Agent 创建任务后拿到一个句柄，后续查询和取消都通过句柄进行——不需要协议替你保持连接。

MCP Apps 让工具长出界面。服务端可以返回沙盒化的 HTML 界面，宿主在对话中内嵌渲染。比如采购 Agent 的审批环节，服务端直接返回一个审批表单，而不是一串 JSON 字段让宿主自行拼 UI。更重要的是，界面触发的每一个操作都走同样的 JSON-RPC 协议路径，审计和权限控制是通的。

授权更贴近企业实践。六个 SEP 加固了授权规范：客户端必须验证 OAuth 响应中的iss参数（防混入攻击）、动态注册时声明application_type（避免桌面客户端被误认为 Web 应用）、凭证绑定到颁发它的授权服务器、以及 refresh token 的标准用法。

工具的 JSON Schema 从子集升级到完整 2020-12。inputSchema和outputSchema现在支持oneOf、anyOf、allOf、$ref和条件逻辑。一个采购审批工具的输入可以精确描述为「供应商名称（必填）+ 预算上限（数字，必须大于 0）+ 审批备注（可选，但若金额超过 10 万则变成必填）」。这种表达能力对生成准确工具调用的 LLM 至关重要。

Roots、Sampling 和 Logging 被标记弃用。这三个功能在至少 12 个月后才会移除，方向已经明确：Roots 的替代方案是直接通过工具参数传目录路径；Sampling 建议直接调 LLM Provider API；Logging 用 stderr（stdio 模式）或 OpenTelemetry（结构化可观测）。

正式弃用策略被写入了治理框架。每个特性有 Active → Deprecated → Removed 三态生命周期，弃用窗口不少于 12 个月。2026-07-28 这种级别的 breaking change 不会成为常态。

六、影响面

升级从来不是免费的。

2026-07-28 是 MCP 自发布以来最大的一次不兼容修订（breaking revision）。如果你是 MCP 客户端、服务端或 SDK 的实现与维护者，下面这些是绕不开的：

• 检查对旧握手的依赖。如果实现假设了initialize→Mcp-Session-Id→initialized的生命周期，需要改为在每个请求上携带_meta。
• 重构 session 范围的业务状态。如果之前的业务逻辑依赖协议级 session 来识别对话或用户，需要改为显式标识符。
• 更新粘性路由的假设。负载均衡配置可以简化，但也意味着原来依赖同一实例处理连续请求的隐含设计要重新检查。
• 等待 SDK 更新。Tier 1 SDK 被要求在 7 月 28 日前完成适配，具体节奏取决于各 SDK 维护者。
• 单独评估弃用能力的替代方案。使用了旧版 server-to-client 请求（Sampling、Roots、单独 Logging 通道）的实现需要对照替代方案逐项验证。

对于最终使用者来说，界面不会有变化。你还是对 Agent 说一句「帮我查一下上次的采购单状态」，它应该照样能查。

协议本身也不会自动解决高可用架构的设计和运维、组织级的身份与权限配置、审计日志的存储与分析、数据治理策略的制定，以及 GPU 和 API 调用成本的优化。MCP 这次升级清除的，是一组阻碍规模化部署的协议级结构障碍。它让基础设施团队可以按处理普通 HTTP 服务的方式来处理 MCP 服务——这是规模化的一项基础条件，而不是充分条件。

七、结语：从连接协议走向基础设施协议

MCP 2026-07-28 没有替企业解决部署问题。它做的是另一件事：不再让协议本身把部署变得更难。

回到最开头。MCP 最初的目标是解决连接问题——模型和工具之间缺一口标准的「对话语言」。两年过去，连接还是核心，但规模变了。当 Agent 开始在组织里承载实际的业务调用，不再是 demo 里的一次性查天气，而是每天几万次采购查询、审批流转、数据检索时，「能不能部署」就成了和「能不能连接」同等重要的问题。

对于最终使用者，界面可能没有变化。它本来也不应该变——好的基础设施升级是透明的。对于必须拆握手、找 session 依赖、做兼容测试的 MCP 实现者，这条路不轻松。但对于相信 Agent 能在企业里真正干活的人，路确确实实变宽了一些。

本文基于 MCP 2026-07-28 发布候选（Release Candidate，2026 年 5 月 21 日锁定）撰写。协议最终内容、SDK 支持节奏和迁移情况仍可能变化。

来源：

• Model Context Protocol Draft Specification (2026-07-28)
• The 2026-07-28 MCP Specification Release Candidate — Official Blog
• MCP Specification Changelog (Draft)
• Model Context Protocol Specification (2025-11-25)
• MCP GitHub Repository