AI TECH DEEP DIVE · 2026.08.16

MCP 不再依赖会话

Agent 工具协议进入无状态时代

Model Context Protocol 在 2026-07-28 版本中完成了一次关键转向：核心协议从依赖长会话的双向连接，改为每个请求都能自我描述的无状态模式。新请求携带协议版本、客户端信息与能力，可以被普通负载均衡器分发到任意服务实例。

这不是一次简单的 API 改名，而是 MCP 服务扩容、路由、缓存、授权和故障恢复方式的重构。对正在把 Agent 工具链从本地演示推向生产的团队，结论很直接：协议更容易水平扩展了，但应用状态、安全边界与可观测性必须重新设计。

久

SECTION 01

从“建立会话”改成“请求自带身份”

上一代 Streamable HTTP 的典型路径是：客户端先发送 initialize，服务器返回能力和可选的会话 ID，客户端再发送初始化通知，之后的请求都带着该会话标识。如果一次 Agent 任务跨越多个工具调用，服务器需要记住这个连接上下文。

2026-07-28 规范取消了这个协议层握手。客户端可以先调用 server/discover 了解版本和能力，也可以直接发送第一个业务请求。每个请求都在 _meta.io.modelcontextprotocol/* 中携带版本、客户端信息和能力。任何符合规范的实例都可以单独验证并处理请求。

这个变化把“我们正在进行哪一段对话”从协议层拿走了。但它没有消灭应用状态：工作流进度、长任务结果、用户权限、审批记录和重试边界仍需要存储，只是不再依赖某台 MCP 服务器的内存会话。

SECTION 02

无状态解决的是扩容与故障恢复

当服务端必须保留会话时，网关往往需要粘性路由，或者后端需要一个共享会话存储。某个实例重启后，原有连接还需要恢复或重建。这些机制在本地一个客户端时很轻，到多租户、多区域和弹性容器环境中就会迅速变成维护成本。

新模式让请求可以经过普通轮询负载均衡，其中某个实例失效不会自动破坏下一次调用。对云平台来说，这意味着更容易做无服务器化部署、水平扩容和跨区域切换。对开发者来说，它减少了协议层恢复逻辑，但并不代表工具调用可以随意重试。

像“查询文档”这样的读操作可以通过请求 ID 和幂等键安全重试；“发送消息”、“提交审批”、“执行付款”等写操作仍需要业务幂等、状态查询与人工确认。无状态协议解决了服务分发，没有替你解决副作用。

SECTION 03

服务器不再主动发请求，多轮任务换了表达方式

旧协议里，服务器可以通过持续连接向客户端发起 sampling 或 elicitation 类请求。这种模式适合长连接，却给无状态 HTTP、网关和无服务器环境带来了反向通道问题。

新规范用 Multi Round-Trip Requests（MRTR）重新表达这些交互。服务器在当前响应中返回下一轮所需的信息，客户端处理后再发一个新请求。对用户征求、模型采样和需要多步确认的工具流程来说，这保留了多轮语义，同时避免服务器主动打开新的 JSON-RPC 请求。

代价是延迟和取消语义需要重新测试。一次原来在长连接上完成的交互，现在可能包含多个完整的 HTTP 往返。如果客户端断线，服务端也需要知道哪个步骤可以重做，哪个步骤必须读取既有结果。

SECTION 04

路由、缓存和授权开始进入标准基础设施

2026-07-28 版本让方法名和工具名可以镜像到 HTTP 头，网关可以直接按请求类型做路由、限流和授权，而不需要解析完整业务消息。对平台团队而言，这让 MCP 请求更接近普通服务 API：可以复用网关策略、跨区域路由、WAF 规则和审计管道。

列表类响应新增缓存提示和确定性顺序。这个细节对 Agent 很重要：工具目录如果每次排序不同，即使内容没变，上游 prompt 缓存也可能失效。稳定排序与缓存提示可以降低重复 token 和计算消耗。

授权部分同时加入 RFC 9207 发行者验证，并从动态客户端注册转向客户端元数据文档。这些更新能改善身份混淆和网关配置，但不能证明某个工具值得信任。工具的权限、参数验证、输出过滤与副作用确认，仍需要在应用层实现。

SECTION 05

迁移不能只改一个版本号

官方 TypeScript SDK 的迁移文档提醒，即使已经使用 v2 包，也不会默认在线上传输 2026-07-28 字节；客户端需要显式选择自动协商或锁定新版本。这个设计避免了新 SDK 上线后突然与旧服务器失配。

Go SDK 的发布说明也保留了对 2025-11-25 和更早版本的向后兼容，客户端与服务器会协商双方支持的最高版本。这意味着生产迁移的安全路径应是双栈而不是切换日：先升级 SDK 和可观测性，再开启协商，最后逐步提高新版本流量。

需要重点处理的不兼容面包括：

将服务端内存会话转换为应用状态或请求状态。

为客户端增加版本协商和降级测试。

把服务器主动请求改写为 MRTR 流程。

重新检查取消、超时、重试与幂等边界。

更新 OAuth 发行者验证与客户端元数据。

验证工具列表顺序和缓存键在各实例间一致。

SECTION 06

团队现在可以做的六项检查

第一，列出当前 MCP 服务的所有会话状态，区分哪些是协议状态，哪些是必须保留的业务状态。第二，检查客户端与服务器 SDK 是否真正支持 2026-07-28，不要只看包的大版本。

第三，用“新客户端—旧服务器”、“旧客户端—新服务器”和“双方都新”三组组合做协商测试。第四，给每个有副作用的工具定义幂等键、结果查询和人工确认点。

第五，在网关、服务和工具层传递同一请求标识，保证可以追踪一次 Agent 任务跨越多次无状态调用的完整链路。第六，先用一小部分无风险读工具开启新协议，再扩展到写操作和长任务。

SECTION 07

无状态不等于无上下文，也不等于更安全

这次发布解决的是协议层会话与部署拓扑的耦合，并没有取消 Agent 的任务上下文。相反，应用需要更清楚地决定上下文放在哪里：是客户端内存、工作流数据库、任务扩展，还是业务系统。

它也没有自动解决工具提示注入、越权、敏感输出和错误重试。请求自带元数据可以让身份验证更明确，但如果工具本身获得了过大权限，无状态只会让这个工具更容易被大规模调用。

因此，更稳妥的判断是：MCP 2026-07-28 把 Agent 工具协议带进了标准云基础设施的运行模型。它降低了水平扩展和故障恢复的门槛，但同时把应用状态、幂等、授权和观测性的设计责任更清楚地交还给了开发团队。

AI研客专注记