行业动态

Model Context Protocol（MCP）在2026年7月28日发布新一版正式规范。这是 MCP自推出以来幅度最大的一次升级，核心目标是让 AI Agent与工具、数据源和远程服务之间的连接方式更适合大规模生产部署。新版不仅把协议核心改为无状态架构，还引入 Extensions扩展框架、Tasks长任务能力、MCP Apps、企业级授权机制以及正式的弃用策略。

MCP最初由 Anthropic推动，后来逐步发展为开放协议。它解决的问题，是让 Claude等 AI应用不必为每一个外部工具单独设计一套连接方式，而是通过统一规范发现工具、读取资源并执行操作。随着 MCP Server从本地开发环境进入云端和企业系统，原有会话机制在负载均衡、横向扩容和身份管理上的限制也越来越明显，这正是本次升级重点处理的问题。

协议核心转向无状态

新版 MCP最大的变化，是移除协议层会话以及 Mcp-Session-Id，并取消原有 initialize握手。客户端的请求需要携带服务器处理所需的信息，远程 MCP Server不再依赖某个固定实例保存会话状态。

MCP 官方架构示意图

这一调整直接改变了远程服务的部署方式。过去，MCP Server往往需要粘性会话、共享会话存储，或者额外的网关逻辑来保证后续请求回到同一个实例；现在，请求可以交给任意可用节点处理，普通轮询负载均衡、容器集群和 Serverless环境都更容易承载 MCP服务。需要跨请求保留业务状态的应用，仍然可以通过显式状态句柄传递信息，但状态不再由协议会话隐式维护。

无状态化也让 MCP更接近成熟的 HTTP工作负载。服务可以更容易地做横向扩容、故障转移、缓存、路由和观测，平台团队不必再围绕协议会话设计专门的基础设施。对于准备把 MCP Server从内部测试推向生产环境的团队，这项变化比单纯新增几个接口更重要。

Extensions成为正式扩展机制

2026-07-28规范把 Extensions提升为一等能力。协议核心负责保持稳定和精简，更多面向应用层的功能则通过扩展独立演进，避免所有新需求都直接堆进基础协议。

首批重点能力包括 MCP Apps和 Tasks。MCP Apps允许服务器向客户端提供可交互界面，使工具调用结果不再局限于纯文本或结构化数据；Tasks则面向需要较长时间完成的工作，让客户端能够启动、跟踪并获取异步任务结果。对于代码分析、数据处理、内容生成和企业工作流等场景，这类能力可以减少开发者自行设计轮询、回调和状态同步机制的成本。

授权体系更贴近企业部署

新版规范继续强化授权设计，使 MCP更接近 OAuth 2.0和 OpenID Connect的成熟部署方式。企业托管授权机制允许组织统一管理 MCP Server的身份与访问关系，降低用户重复登录和重复授权的负担，也方便安全团队实施权限控制、审计和合规策略。

这意味着 MCP正从面向个人开发者的工具连接协议，逐步走向企业级 Agent基础设施。对大型组织而言，真正影响采用速度的往往不是工具数量，而是身份系统能否接入、权限能否统一配置，以及服务调用能否被追踪和治理。新版规范正在补齐这些关键环节。

兼容性和迁移需要谨慎处理

此次更新包含破坏性变化。仍依赖 initialize、Mcp-Session-Id或旧版连接生命周期的客户端和服务器，不能在不修改代码的情况下直接切换。官方 TypeScript、Python、C# 等 SDK会按各自节奏采用新规范，旧版协议在一段时间内仍可能继续存在，因此客户端和服务器需要通过版本协商处理兼容问题。

开发团队在迁移前应重点检查三类逻辑：一是是否把业务状态绑定在 Session ID上，二是是否依赖服务器主动发起的旧式交互方式，三是网关、鉴权和监控系统是否读取旧版请求头。对于已经稳定运行的生产服务，先在测试环境验证 SDK和客户端兼容性，再逐步切换，比直接全量升级更稳妥。

MCP从连接标准走向 Agent基础设施

这次升级的意义不只是“协议变得更简单”。无状态核心降低了远程 MCP Server的部署门槛，Extensions为交互界面和长任务提供了统一演进空间，企业授权机制则让组织能够更安全地管理大规模工具连接。三者结合后，MCP的定位正在从开发工具之间的连接层，进一步扩展为 Agent系统的通用基础设施。

对于普通开发者，本地 stdio模式的使用体验未必会立刻发生明显变化；但对云平台、企业软件和需要部署大量远程 MCP Server的团队而言，新规范会显著改变架构选择。接下来真正值得观察的，是主流 AI客户端、开发工具和云服务采用2026-07-28规范的速度，以及新版 SDK在实际生产环境中的兼容表现。