告别「握手」MCP 2026-07-28 如何让 AI Agent 真正走向企业级部署一、MCP 从哪里来又走到了哪里二、一次工具调用为什么要先「握手」三、2026-07-28把状态从协议核心中拿出去四、企业基础设施为什么在意这件事五、不只是无状态一个更轻、更可治理的 MCP六、影响面七、结语从连接协议走向基础设施协议一、MCP 从哪里来又走到了哪里2024 年底Anthropic 发布了 Model Context ProtocolMCP。它解决的是一个很具体的问题大模型很强但每次让它查数据库、读文档、调 API都得单独写一套胶水代码。能不能像 USB-C 一样做一个通用的「AI 接口」不到两年MCP 走过了几个重要节点2024-11-05MCP 第一个版本发布。核心逻辑很简单——把工具、数据和提示模板标准化模型通过统一的 JSON-RPC 协议就能调用。那时候大家关心的是「能不能连上」。2025-03-26Streamable HTTP 传输层替代了早期的 HTTPSSE 方案。远程部署不再需要维护一个常开的 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 传输下流程是三步客户端发一个initialize请求告诉服务端「我支持的协议版本是 2025-11-25我有哪些能力」。服务端回一个Mcp-Session-Id再通知客户端「初始化完成」。客户端带着这个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_idAgent 后续查询和操作都带着这个 ID。状态还在只是协议不再替你「偷偷」记着了。官方博客里把这一点讲得很明白把状态从传输层的元数据里搬出来变成模型可见的显式参数反而让模型能够跨工具编排这些标识符——这比藏在 session 里的隐形状态要有用得多。四、企业基础设施为什么在意这件事拆掉握手和会话的直接后果是 MCP 突然变得「基础设施友好」了。回到那个采购 Agent 的场景。在旧版里如果采购服务部署了三台实例网关必须保证search和后续的create_request落在同一台实例上——因为它们共享一个会话。负载均衡器得配粘性路由监控要追踪会话亲和性扩缩容时还得处理旧实例上未终结的会话迁移。在新版里search打到实例 Acreate_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 RequestsMRTR。服务端有时需要在处理请求的中途向客户端问一个问题——比如「要删除这三个文件确认吗」。旧版依赖保持 SSE 连接打开来实现这个交互新版改成了服务端先返回一个InputRequiredResultresultType: 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 APILogging 用 stderrstdio 模式或 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 Candidate2026 年 5 月 21 日锁定撰写。协议最终内容、SDK 支持节奏和迁移情况仍可能变化。来源Model Context Protocol Draft Specification (2026-07-28)The 2026-07-28 MCP Specification Release Candidate — Official BlogMCP Specification Changelog (Draft)Model Context Protocol Specification (2025-11-25)MCP GitHub Repository