模型上下文协议已经达到了一个重要的基础设施里程碑：其 2026 年 7 月 28 日修订版使协议迈向无状态核心。 对于构建代理系统、工具服务器、IDE 集成或多模型编排层的团队来说，这不是表面上的规范更新。 它改变了有关会话、初始化、扩展、兼容性和治理的假设。
MCP 候选版本将 7 月 28 日的规范描述为添加无状态协议核心、扩展框架、任务、MCP 应用程序、授权强化和正式弃用策略。 MCP 官方博客还警告称，该版本包含重大更改。 GitHub 运营着最引人注目的 MCP 服务器实现之一，在最终版本发布之前表示，其 MCP 服务器已经支持新规范，并于 7 月 28 日将该协议描述为“无状态”。
实际意义很简单：MCP 的形状不再像一个会话密集型本地集成层，而更像是一个用于远程工具访问的互联网规模协议。 这很重要，因为代理系统不再局限于桌面开发工具。 它们越来越多地在云服务、CI 系统、客户支持工作流程、问题跟踪器和企业自动化平台内运行。
MCP 发生了变化
主要变化是转向无状态协议核心。 GitHub 的变更日志称，新核心删除了会话并进行初始化，目的是使远程 MCP 部署更容易扩展。 这是一个重大的架构转变。 有状态协议可以很好地适用于本地工具和受控环境，但它们使水平扩展、无服务器执行、故障转移、边缘部署和负载平衡变得复杂。
无状态核心使实施者可以更自由地在普通 Web 基础设施后面运行 MCP 服务器。 请求可以跨实例分发，而无需在特定后端保留长期会话。 对于大型组织来说，这可以降低运营复杂性。 对于较小的团队来说，它可能会使托管的 MCP 服务器更容易使用托管计算而不是自定义的长期运行的基础设施进行部署。
根据候选版本材料，更广泛的 2026-07-28 版本还引入了扩展框架和任务。 这些新增内容表明 MCP 正在变得更加模块化，并且对于长期运行的工作更加明确。 MCP 应用程序和授权强化指向同一方向：该协议正在从早期的生态系统粘合层成熟到更正式的代理与工具交互层。
这种成熟的成本是兼容性工作。 MCP 博客将该版本描述为具有重大更改的版本，围绕该修订版发布的 TypeScript 和 C# SDK 材料重点关注迁移支持和无状态概念。 任何操作 MCP 服务器、在 IDE 扩展中嵌入 MCP 或通过内部基础设施路由代理调用的团队都应将修订视为工程事件，而不是后台标准更新。
为什么无状态 MCP 对开发人员和操作人员很重要
代理工具存在一个与普通 API 扩展不同的扩展问题。 单个用户请求可以触发许多工具调用、模型转换、重试、文件读取、搜索查询和批准步骤。 当工具协议假定持久会话时，生产操作员必须在这些交互中保留状态或围绕协议构建解决方法。
通过从核心中删除会话，MCP 可以更好地适应代理工作负载突发、分布式和异步的环境。 当请求可以独立处理时，无服务器功能、边缘工作人员、Kubernetes 部署和多区域系统都会受益。 这并没有消除代理应用程序的状态；它将状态移动到应用程序数据库、任务队列、身份系统或显式工作流层中，而不是将其嵌入到协议核心中。
对于开发人员来说，这一变化最终应该使远程工具服务器更易于使用。 对于平台团队来说，它可以简化可观察性和容量规划。 操作员可以专注于请求级跟踪、工具调用延迟、授权决策和错误模式，而不是调试不透明的会话关联行为。
还有一个治理角度。 随着 MCP 在编码助理和企业代理中变得越来越普遍，公司将需要有关代理可以调用哪些工具、可以访问哪些数据以及允许哪些用户或服务调用它们的策略。 因此，新修订版中的授权强化并非偶然。它反映了一个现实，即工具访问现在已成为安全边界，而不仅仅是开发人员的便利。
受影响的人群
最直接受影响的群体是 MCP 服务器维护人员、SDK 用户、代理平台团队以及将内部工具暴露给 AI 代理的组织。 如果服务器依赖于会话行为或旧的初始化流程，则需要根据新规范进行测试。 如果应用程序支持多个 MCP 版本，则可能需要版本协商、兼容性层或分阶段迁移计划。
IDE 和开发人员工具供应商也在范围内。 MCP 越来越多地与编码代理、自定义代理和模型管理功能一起出现。 无状态协议核心使这些产品能够更轻松地可靠地调用远程工具，但前提是它们的集成符合规范。
使用代理自动化的企业即使从未阅读过 MCP 规范，也应该注意。 该更改可能会影响连接到存储库、票务系统、数据库、内部知识库或部署工具的代理的可靠性。 在迁移窗口期间，可能的故障模式不仅仅是明显的中断。 它们可能包括缺少工具功能、更改身份验证行为，或者由于工具服务器不再按预期运行而采取不同路径的代理。
对于 Model Gate 等 AI API 网关，这种连接是实用的。 统一的 AI API 越来越靠近模型路由、API 密钥管理、使用分析和团队 API 治理。 当代理系统在普通模型调用旁边添加 MCP 工具调用时，网关和可观察层将需要考虑工作流程的双方：使用了哪个模型、调用了哪些工具、它们的成本、谁授权了它们以及发生故障的位置。
迁移优先级和开放性问题
第一个迁移优先级是兼容性测试。 团队应清点 MCP 客户端和服务器，识别会话依赖性或初始化行为，并根据 2026-07-28 SDK 或可用的一致性材料进行测试。 生产系统应该分阶段进行升级，特别是当代理执行具有副作用的操作（例如创建拉取请求、修改问题、查询客户数据或执行部署工作流程）时。
第二个优先事项是可观察性。 无状态基础设施可以更容易扩展，但分布式代理系统仍然需要关联 ID、跟踪捕获、请求日志和策略事件。 如果没有这些，团队可能会用会话复杂性来换取调试复杂性。 使用情况分析应区分模型调用和工具调用，尤其是当代理工作流程被计费、速率限制或由团队审核时。
第三个优先事项是授权审核。 如果新规范强化了授权语义，那么实施者不应简单地将旧的访问假设移植到新版本中。 他们应该重新检查令牌范围、用户委托、服务帐户、审核日志和拒绝行为。 默认情况下，工具访问权限应为最低权限，特别是对于远程 MCP 部署。
在组织做出不可逆转的设计决策之前，一些细节仍然值得检查。 本文可用的研究包括候选版本、规范页面、SDK 迁移材料和 GitHub 的实施说明。 在内部标准或客户文档中引用确切的协议要求之前，应直接审查 2026-07-28 规范的最终规范性措辞。
即使有这样的警告，方向也是明确的。 MCP 正在成为一种更加面向生产的代理基础设施协议。 无状态核心应该使远程部署更容易扩展，但它也迫使生态系统清除早期实现中的假设。 对于使用代理进行构建的团队来说，这种协议更改值得冲刺票，而不仅仅是书签。