MCP 2026-07-28 要改成无状态：AI 工具网关该检查什么

如果你的团队已经让 Claude、Cursor、IDE、内部 Agent 或自动化流程连接 MCP Server，接下来要关注的不只是“又多了一个协议版本”。MCP 官方已经发布 2026-07-28 版本候选稿，并明确这是一次带有 breaking changes 的大版本调整：协议核心转向无状态，initialize 握手和协议级 session 被移除，Streamable HTTP 请求要携带更明确的元数据和路由头，授权规范也更贴近 OAuth 2.1、OpenID Connect 和企业身份系统。

这件事对使用者的影响很具体：以前为了让远程 MCP Server 稳定运行，团队可能需要 sticky session、共享 session store，甚至在网关层解析请求体来判断调用了哪个工具。新的无状态模型把更多信息放进每次请求，让 MCP 流量更容易被负载均衡、缓存、限流、审计和追踪。但前提是，客户端、MCP Server 和中间网关都真的按新规范处理请求。

换句话说，MCP 的这次变化不是单纯的 SDK 升级，而是 AI 工具网关和统一调用层的一次迁移检查。

无状态改变了网关的工作方式

在旧的 Streamable HTTP 设计里，客户端需要先建立会话，后续请求再携带 Mcp-Session-Id。这让多实例部署变得麻烦：负载均衡器要把同一个会话固定到同一个实例，服务端常常还要维护共享 session 状态。

2026-07-28 的核心变化，是把每次请求变成更完整的 HTTP 调用。协议版本、客户端信息、能力信息会随请求进入 _meta；请求头里会带上 MCP-Protocol-Version、Mcp-Method，以及在工具、资源或 prompt 调用中使用的 Mcp-Name。这样网关可以直接基于请求头做路由、限流、日志和策略判断，而不用先读取 JSON-RPC body。

这对生产环境是好事，但也会暴露隐藏依赖。凡是仍然依赖 Mcp-Session-Id 的服务、插件、负载均衡规则、审计字段或指标维度，都需要重新检查。无状态协议不等于业务不再需要状态，而是要求业务状态显式存在于工具参数、任务句柄或资源 URI 里，而不是藏在传输层 session 里。

迁移前先查四个风险点

第一，查路由规则。新的请求头让 MCP 流量更容易被网关识别，但只有在客户端和服务端都按规范发送、校验这些头时才成立。网关应该记录 MCP-Protocol-Version、Mcp-Method 和 Mcp-Name，并能区分 tools/call、resources/read、prompts/get 等不同操作。高风险工具不应该和普通只读工具使用同一套限流和授权策略。

第二，查状态依赖。把服务扩到多个实例后，任何“只有粘到同一实例才正常”的行为都要被找出来。常见问题包括：工具调用结果依赖内存里的临时 session、长任务进度依赖连接上下文、缓存键里混入旧 session id、日志只记录连接而不记录工具名。更稳的做法是让服务端返回明确的任务句柄、资源 id 或业务对象 id，并要求后续调用把这些 id 作为普通参数传回。

第三，查授权边界。MCP draft authorization 规范要求 HTTP transport 下的授权和 OAuth 体系对齐，包含 Protected Resource Metadata、Resource Indicators、issuer 校验、scope 选择和 step-up 授权等内容。团队不应该把上游系统 token 直接透传给 MCP Server，也不应该让所有工具共享同一个大权限访问令牌。更合理的模式是：网关或授权层先确认调用者身份、目标 MCP Server、工具范围和资源范围，再下发面向目标资源的短期权限。

第四，查 SSRF 和外联策略。MCP 安全最佳实践特别提醒，OAuth metadata discovery、授权服务器地址、token endpoint、redirect 链路都可能成为 SSRF 入口。服务端 MCP 客户端应限制访问私有网段、云 metadata 地址、localhost 服务和非预期跳转；生产环境也应优先使用 HTTPS，并通过出站代理或网络策略记录异常访问。

企业授权会改变 MCP 的接入方式

MCP 官方在 6 月稳定了 Enterprise-Managed Authorization 扩展。它要解决的问题很现实：如果每个员工都要为每个 MCP Server 单独点一次 OAuth，同意流程会很快变成部署阻力，安全团队也难以用统一策略管理访问范围。EMA 让组织可以通过身份提供方集中发放 MCP Server 访问权限，用户登录后继承所在团队、角色和条件访问策略。

这说明 MCP 正在从“个人工具连接协议”走向“企业工具访问层”。当 MCP Server 连接到代码仓库、工单、数据库、设计系统、内部搜索或云服务时，团队更关心的不是某个工具能不能连上，而是谁能调用、能调用哪些工具、能访问哪些资源、调用是否可审计、权限是否可撤销。

AI 工具网关在这里的价值会更明显：它可以把模型 API、MCP Server、内部 API 和身份系统之间的边界收敛到一个更可控的位置。对开发者来说，Agent 仍然是熟悉的工具；对团队来说，路由、授权、预算、日志和审计不再散落在每个客户端里。

一个实用的 MCP Gateway 检查清单

如果你已经部署远程 MCP Server，可以按下面的顺序检查。

检查项	需要确认的问题
协议版本	客户端和服务端是否能显式处理 `2026-07-28`，并对旧版本做兼容或拒绝策略
请求头	网关是否记录并校验 `MCP-Protocol-Version`、`Mcp-Method`、`Mcp-Name`
会话依赖	是否还依赖 `Mcp-Session-Id`、sticky session、共享 session store 或连接级状态
多实例部署	任意请求是否可以落到任意实例；长任务是否改用任务句柄或显式状态
工具权限	是否能按工具名、用户、团队、环境、资源范围设置允许、拒绝、限流和审计
OAuth 元数据	是否实现 Protected Resource Metadata、Resource Indicators 和 issuer 校验
Token 边界	是否避免上游 token 直接透传；是否使用面向目标 MCP Server 的短期权限
SSRF 防护	metadata discovery、redirect、token endpoint 是否经过网络出口和私网拦截
可观测性	是否把工具名、资源名、调用者、模型、trace、延迟、错误和重试关联起来
缓存策略	`tools/list`、资源列表或只读结果是否有清晰的 TTL 和用户范围

这张表的重点不是“把所有能力一次做完”，而是避免 MCP 流量在进入生产后变成新的盲区。很多团队已经有 API Gateway、模型网关或统一调用层；现在需要判断的是，MCP 流量是否也应该进入同一套治理面，而不是继续让每个 Agent 客户端各自处理授权和日志。

对模型路由和成本治理也有影响

MCP 看起来是在解决工具连接问题，但它会间接放大模型调用和成本治理问题。一个 Agent 调用工具前，可能先让模型判断任务、读取资源、整理参数、执行工具、解释结果，再决定下一步。工具越多，链路越长，模型调用越容易变成不可预测的任务流。

无状态 MCP 让工具调用更容易被网关识别，也给成本和质量控制提供了更清晰的入口。例如，团队可以按工具类型设置模型策略：普通查询走低成本模型，高风险写入先用强模型复核；内部搜索失败时切换备用模型或备用工具；某个 MCP Server 报错率升高时，减少自动重试并触发告警。前提是网关层能看到工具名、请求链路、调用者、模型和 token 成本。

这也是为什么 MCP 迁移不应该只交给某个客户端或某个 Server 维护者。它跨过了身份、网络、模型、工具、日志和预算。越早把 MCP 放进统一的调用控制层，后面接入更多工具和模型时，越不容易失控。

结语

MCP 2026-07-28 的无状态改造，让远程 MCP Server 更适合放进普通 HTTP 基础设施里：更容易负载均衡，更容易被网关路由，更容易缓存和追踪，也更容易和 OAuth 体系对齐。但这次变化同样会淘汰很多隐性的旧假设，比如传输层 session、单实例状态、粗粒度 token、只按服务限流、不按工具审计。

对已经在生产或准生产环境使用 MCP 的团队来说，现在最值得做的是迁移检查：哪些地方还依赖 session，哪些工具需要更细授权，哪些请求应该进入网关日志，哪些出站访问必须限制，哪些模型调用需要和工具链路关联。等到工具数量、Agent 数量和调用量一起上升后，再补这些控制点会更难。

MCP 正在变成 AI 应用访问外部世界的关键协议。协议越成熟，团队越应该用成熟的 API 治理方式来管理它。