MCP 无状态化升级解析：会话移除、MRTR、请求头路由与云原生 Agent Server

MCP 升级的重点不是字段变化，而是从有状态会话转向更适合扩容、鉴权和路由的 Agent 基础设施。

导语

MCP 的一次协议升级，不一定会像模型发布那样刷屏。

但如果你在做 Agent、工具调用、企业集成或者 MCP Server，这类“地基层”的变化反而更值得看。因为它改的不是某个工具字段，而是 MCP 在生产环境里如何扩容、鉴权、路由、交互和演进。

2026-07-28 版本的重点可以用一句话概括：MCP 正在从一套偏会话式的双向协议，转向更适合云原生部署的无状态基础设施。

这背后有几个关键动作：

图：MCP 从会话绑定转向可横向扩展的无状态基础设施

· MCP Server 从有状态转向无状态。
· initialize / initialized 握手和 Mcp-Session-Id 会话机制被移除。
· 多轮往返请求 MRTR 接管“中途需要用户输入”的场景。
· 请求头路由、列表缓存、订阅机制开始补齐规模化能力。
· MCP Apps、Tasks、企业托管鉴权、观测看板等扩展进入框架化阶段。
· 鉴权体系向 OAuth 2.0 / OIDC 生产标准靠拢。

真正值得关心的，不是“协议又多了几个概念”，而是 MCP 为什么必须做这次架构调整。

有状态协议卡住了 MCP Server 的扩容

早期 MCP 的设计更像一条持续连接：客户端和服务端先通过 initialize / initialized 完成握手，协商协议版本和能力集；后续请求挂在同一个会话上，通过 Mcp-Session-Id 维持上下文；服务端还可以反向向客户端发起请求，例如要求用户确认、发起采样等。

这套机制在小规模、单实例、开发者本地场景里能跑起来。但进入生产环境后，它会带来几个很典型的后端问题：

生产问题	有状态 MCP 的代价
负载均衡	同一会话必须落到同一实例，需要 sticky routing
横向扩容	会话状态要共享，通常要引入 Redis 等外部存储
网关治理	限流、鉴权、路由需要解析 JSON 请求体，不能只看请求头
双向通信	Server 到 Client 的反向请求让链路更复杂，也更难穿透网关和边界

这些问题不是实现细节，而是决定 MCP Server 能不能像普通 HTTP 服务一样被网关托管、弹性扩容、按需部署。

新版本的核心取向很明确：把传输层里的隐式状态拿掉，让每个请求尽量自描述。

这个变化会把一部分状态管理责任推向 MCP Client，也就是 Agent 一侧。它并不是单纯甩锅。Agent 本来就需要管理任务上下文、工具结果、用户偏好和中间状态，把状态显式放到 Agent 可见的位置，反而更符合 Agent 执行任务的方式。

黑盒会话对模型不可见。显式 handle 对模型可见，可以在多次工具调用之间被传递、解释和检查。这一点很关键。

握手和会话被移除后，请求必须自己说清楚

移除会话之后，握手也就不再适合继续做强依赖。

旧流程里，客户端先握手，再进入绑定会话的调用阶段。新流程把协议版本、客户端身份、客户端能力等信息放到每个请求的 _meta 字段里。服务器不需要记住上一次握手结果，也不需要根据 Mcp-Session-Id 找回会话上下文。

如果客户端想提前知道服务端支持什么，可以调用可选的 server/discover。但它不再是所有调用的前置动作。

这会直接改善网关和服务端的部署模型：请求不必粘在同一台机器上，服务端实例可以更容易横向扩展，serverless 或弹性伸缩也更现实。

当然，无状态不等于业务不能有状态。差别在于，状态不再藏在传输会话里，而是通过显式 handle、工具参数、外部存储或客户端上下文来表达。

MRTR 接管“中途要问人”的场景

去掉双向会话后，一个问题会马上出现：如果工具执行到一半需要用户确认，或者缺少一个必填参数，服务端不能再沿着常驻连接反向问客户端，那应该怎么办？

新版本引入了 MRTR，Multi Round-Trip Requests，多轮往返请求。

它的思路并不复杂：服务端不再反向发起请求，而是在当前调用的响应里声明 resultType: "input_required"，并附上需要补充的问题。客户端收集用户输入后，再带着 inputResponses 重新发起原始调用。最终结果仍然由服务端返回。

这比“服务端反向找客户端”更适合 HTTP、网关和无状态部署。所有交互都变成客户端发起的请求，链路方向更单一，权限边界也更清楚。

订阅机制解决的是另一类问题。客户端可以通过 subscribe 声明自己关心的资源或事件，服务端在内容变化时推送通知，客户端也可以随时 unsubscribe。这让“持续关注某类变化”不必依赖一条会话连接。

维度	旧版	新版
通信隐喻	一通不能轻易挂断的电话	可按需订阅的事件频道
连接模式	持久、有状态	按需请求、按需订阅
会话管理	依赖 Session-Id	通过请求自描述、订阅和显式 handle 组织状态
扩展方式	改协议本体	核心协议 + 扩展框架
兼容性	原有会话模型	与旧版不兼容，需要适配

这个设计取舍很清楚：牺牲一部分旧协议的连续会话便利性，换取服务端规模化、网关治理和企业部署的确定性。

三个旧能力进入迁移倒计时

这次升级还给三个能力设置了 12 个月弃用窗口：

弃用功能	替代方向
Roots	使用工具参数传递
Sampling	直接使用 Provider API
Logging	使用 stderr 或 OpenTelemetry

这说明 MCP 在收缩核心协议的职责边界。

Roots 这类上下文入口更适合显式变成工具参数；Sampling 不再需要 MCP Server 反向调用客户端模型能力，直接走 Provider API 更清楚；Logging 则交给 stderr 或 OpenTelemetry 这类成熟观测体系，避免协议自己再造一套日志机制。

对开发者来说，这不是“字段改名”级别的调整，而是要重新检查 Server 的状态模型、工具参数设计、日志接入和模型调用路径。

请求头路由和缓存，让网关终于能正常工作

无状态之后，MCP 又补了几块生产环境里很实用的能力。

第一是请求头路由。Mcp-Method 和 Mcp-Name 放到 HTTP 请求头后，网关做限流、鉴权、审计和路由时，不必解析 JSON 请求体。对企业网关来说，这个变化很实际：治理能力可以前置，成本更低，规则也更稳定。

第二是列表结果缓存。tools/list、prompts/list、resources/list、resources/read 等接口返回 ttlMs 和 cacheScope 后，客户端可以按服务端建议缓存结果，减少重复拉取。工具、提示词、资源列表这类数据并不总是每次都变，缓存能降低延迟，也能减轻 Server 压力。

第三是错误码对齐 JSON-RPC。比如“资源未找到”从 MCP 自定义的 -32002 调整为 JSON-RPC 标准里的 -32602。这类改动看起来小，但对 SDK、网关、日志分析和错误处理很有意义。标准化的错误码，会减少生态里各自解释的成本。

扩展框架开始接住更大的 Agent 生态

协议核心收缩的同时，扩展能力在变多。

MCP Apps 被纳入扩展框架，说明 Agent 不会长期停留在纯文本返回。一个重要方向是让 Agent 返回可交互界面。A2UI 更偏声明式 UI 蓝图，不执行代码；MCP Apps 更偏在沙箱里运行 Web 应用。两条路线目前还没到最终收敛阶段，但方向已经很清楚：Agent 需要把结果变成可操作界面，而不只是生成一段解释。

企业托管鉴权也是同一条生产化路线。用户可以通过身份提供商和组权限自动继承访问权，首次登录就完成连接，尽量做到终端用户零操作接入。这对企业内 MCP Server 很关键，因为真实组织里权限不是一个 token 能讲清楚的，它涉及身份、部门、角色、资源边界和审计。

观测看板则补齐运行侧反馈。MCP Server 的性能、采用率、错误诊断都需要进入可观测体系。没有这些数据，开发者很难判断工具是没人用、用得慢、经常失败，还是被某类 Agent 误用。

换句话说，MCP 正在从“让工具能被 Agent 调用”，走向“让工具能在企业和大规模 Agent 系统里稳定运行”。

这次升级的真正信号

MCP 早期解决的是连接问题：让模型和外部工具之间有一套共同接口。

现在它开始解决基础设施问题：服务怎么扩容，网关怎么治理，状态怎么显式传递，用户输入怎么补齐，企业鉴权怎么接入，运行质量怎么观测，扩展能力怎么不污染核心协议。

这就是这次升级最值得关注的地方。它不是一次单纯的协议清理，而是 MCP 从开发者友好的工具协议，向生产级 Agent 基础设施靠拢。

短期看，开发者需要适配不兼容变更，尤其是会话、Roots、Sampling、Logging 和反向请求相关逻辑。长期看，无状态、请求自描述、显式 handle、MRTR、订阅、请求头治理和标准观测，会让 MCP Server 更像现代云服务，也更容易承接大规模 Agent 调用。

Agent 应用要真正落地，靠的不只是更聪明的模型，还要有能被部署、治理、观测和扩展的协议底座。MCP 这次改动，正是在补这块底座。

AI小老六