MCP 无状态服务如何避免把业务会话塞回连接：句柄关联与请求级扩展设计

MCP 2026-07-28 的核心变化，可以先用一句话概括：协议层不再替应用保管会话，但应用仍然可以有状态。迁移时最容易犯的错，是把 Mcp-Session-Id 删除后，顺手把购物篮、浏览器实例、草稿或授权上下文也丢掉。正确做法是把业务状态显式化，再让每次 HTTP 请求都携带足够的关联信息。

先把协议状态和业务状态拆开

官方发布说明把 2026-07-28 描述为无状态协议核心：initialize/initialized 握手和 Mcp-Session-Id 被移除，客户端信息与能力改为随请求传递。这样做的直接收益是请求可以落到任意实例，不再强依赖粘性负载均衡或共享协议会话表。

但订单、购物篮、浏览器标签、长任务和用户授权仍是应用数据。把它们列成业务对象，保存到数据库或专门的状态服务，并给对象分配可鉴权、可过期的句柄。实例内只保留短暂的计算中间值，避免进程重启或轮询换节点后无法恢复。

用显式句柄恢复跨调用关联

显式句柄的关键不是把旧会话 ID 改个名字，而是让它成为工具参数的一部分。例如创建购物篮后返回 basket_id，下一次调用明确传回：

{
  "name": "add_item",
  "arguments": {
    "basket_id": "bsk_7f2a",
    "sku": "book-17",
    "quantity": 1
  }
}

服务端收到后要做四件事：校验句柄属于当前主体；检查过期和撤销状态；以句柄作为幂等和并发控制的一部分；再读取共享业务存储。句柄可以由模型在多个工具间传递，这比隐藏在传输层的状态更容易审计，但也意味着不要把敏感信息直接编码进去。

让网关按请求元数据路由

无状态请求应尽量自包含。发布说明给出的方向是使用 Mcp-Method 和 Mcp-Name 头部，让负载均衡器、网关和限流器按操作路由，而不必先解析 JSON-RPC body。网关仍应比较头部和 body 的 method/name；不一致就拒绝，避免路由到错误处理器。

迁移检查可以很简单：先关闭 sticky session，再让两台实例做 round-robin；如果任何一次调用仍依赖上一台实例的内存，就说明业务状态没有完成显式化。中间需要用户输入时，也应把请求状态放入可验证的 payload，让重试请求可以落到任意实例。

按 ttlMs 和 cacheScope 设计缓存

列表和资源读取结果可以携带 ttlMs 与 cacheScope。前者告诉客户端结果能新鲜多久，后者说明结果是否能跨用户共享。缓存键至少要考虑操作名、资源身份、授权主体或租户边界；把 basket_id 直接当成公共缓存键，可能让同一用户的业务数据进入共享缓存。

把 traceparent 贯穿调用链

没有长连接，不代表不能追踪。MCP 规范说明在 _meta 中传递 W3C Trace Context 的键名，宿主、客户端 SDK、MCP 服务和下游服务即可把一次工具调用串成 span 树。注意职责边界：显式句柄回答“操作哪个业务对象”，traceparent 回答“这次请求经过哪里”，两者不能互换。

最后按五项结果验收：任意实例可处理自包含请求；业务句柄可鉴权且可过期；网关能按操作路由；缓存范围和 TTL 可解释；OpenTelemetry 后端能还原调用链。做到这五点，协议会话移除才真正转化为可横向扩展的工程收益。

相关问题

问：无状态后还需要 Redis 吗？
需要时仍然可以用。Redis、数据库或其他状态服务保存的是业务对象，不是 MCP 协议会话；关键是通过显式句柄访问，并定义生命周期。

问：能不能用 traceparent 作为业务对象 ID？
不建议。traceparent 随调用变化且服务于观测，业务句柄应稳定、可鉴权、可撤销，两者分开才能正确重试和审计。

资料依据：MCP 官方 2026-07-28 规范说明、MCP 官方传输文档。