MCP 2026-07-28 无状态协议怎么做安全迁移：Resource Indicators、Issuer 校验与任务状态

把 MCP 服务从单机 demo 放到多副本网关后，最先暴露的通常不是工具逻辑，而是“请求到底依赖哪一台实例”的旧会话假设。2026-07-28 规范候选版把传输层会话拿掉，让每次请求携带必要的协议和客户端信息；但无状态不等于无安全状态，授权受众、签发者和长任务结果仍然要有明确边界。

先划清两种状态：传输状态可以拿掉，业务状态不能凭空消失

旧的 Streamable HTTP 交互需要初始化并返回 Mcp-Session-Id，后续请求依赖这段会话。多副本部署时，请求被路由到另一台实例就可能出现 400 Session Not Found；为了绕过它，团队往往再引入粘性路由或共享会话存储。

新模型把协议版本、客户端信息和能力放进每次请求的 _meta，让任意健康实例都能完成一次独立调用。这个变化解决的是传输层路由和扩缩容问题。用户确认、支付、批量同步这类业务任务仍有生命周期，必须由任务存储、过期策略和权限检查承接，不能误读成“服务完全没有状态”。

请求格式变化：头部是路由证据，正文仍是业务事实

2026-07-28 规范候选版为 Streamable HTTP 请求增加了几个可被网关直接读取的字段：Mcp-Protocol-Version 表示协议版本，Mcp-Method 表示 JSON-RPC 方法，Mcp-Name 表示具体工具、提示词或资源名。它们应与请求体中的含义一致，代理就不需要深度解析整个 JSON 才能做基础路由和审计。

POST /mcp HTTP/1.1
Mcp-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {"q": "otters"},
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {"name": "demo", "version": "1.0"}
    }
  }
}

迁移时先做最小一致性校验：头部缺失、方法不一致、工具名不一致都进入拒绝分支；只有通过校验的请求才进入工具授权。不要为了“兼容旧客户端”而静默接受冲突值，否则日志里看到的调用对象可能和实际执行对象不同。

授权边界：Resource Indicators 解决的是“令牌给谁用”

当一个客户端同时访问多个 MCP 服务时，只验证令牌有效并不够。令牌如果没有明确目标，代理或服务可能把发给 A 服务的凭据带到 B 服务，这就是典型的混淆代理边界。规范候选版引入 RFC 8707 Resource Indicators，让客户端明确指定令牌的目标资源；RFC 9207 的 iss 校验则帮助客户端确认授权响应来自预期签发者。

这两项检查关注点不同：iss 回答“是谁签发了这次授权响应”，resource 回答“令牌允许交给哪个服务”。接入时可以把它们放进同一张审计记录，避免只记一条“OAuth 成功”。

长任务不要再绑住 HTTP 连接：taskId 需要权限和过期时间

数据库备份、CRM 同步或外部系统处理可能持续几十秒。新任务扩展允许服务立即返回 taskId，客户端再用 tasks/get 或 tasks/update 查询进度。这个设计让连接可以释放，也让负载均衡不必把后续请求送回原实例。

工程上至少要为任务记录四个字段：创建者主体、目标工具、状态版本和过期时间。任务完成后结果也应按主体授权；仅凭猜测出的 taskId 不应读取结果。若任务需要用户确认，恢复请求里的 requestState 要校验完整性和有效期，不能当成永不过期的业务凭据。

灰度迁移怎么验收：先验证边界，再扩大流量

1. 在测试环境同时保留旧客户端和候选版客户端，记录每次请求的协议版本、头部三元组和最终实例。
2. 把服务部署到至少两个实例，关闭粘性路由，连续调用同一工具，确认请求跨实例仍能完成。
3. 人为制造头部与 JSON-RPC 冲突，确认网关拒绝并产生可检索审计事件。
4. 使用错误的 iss 或不匹配的 resource 做负向测试，确认不会进入工具执行阶段。
5. 启动一个长任务后重启原实例，再从另一实例查询；检查主体、状态版本、过期时间和结果权限。

这里别急着把“多副本能跑通”当成迁移完成。真正的验收结果应同时包含成功路径、拒绝路径和实例故障后的恢复路径；三者缺一，安全边界仍可能只停留在 demo 状态。

常见问题：无状态迁移最容易误判的几个点

移除 Mcp-Session-Id 后，还需要 Redis 吗？

传输层会话可以不再依赖 Redis，但长任务、幂等键、撤销记录和审计事件仍可能需要共享存储。是否使用 Redis 取决于业务状态，而不是 MCP 是否无状态。

Resource Indicators 能代替权限系统吗？

不能。它约束令牌的目标资源，仍要结合工具级授权、主体权限、输入校验和审计。目标正确不代表调用者一定有权执行该工具。

候选版规范可以直接切生产吗？

不建议直接把候选版当作生产兼容保证。先在灰度环境验证客户端 SDK、网关、鉴权服务和任务存储的组合，再按回滚开关扩大范围。

为什么头部和 JSON 都要记录？

头部便于网关路由和限流，正文承载完整调用语义。两者同时记录并核对，才能在代理改写或客户端异常时还原真实调用对象。

收尾检查

MCP 2026-07-28 的核心价值不只是“去掉一个会话 ID”，而是把路由、授权和长任务边界拆开。迁移完成的标志，是任意实例都能处理合法请求，同时错误发行者、错误受众、冲突头部和越权任务都会在进入工具前被拦住。按这四类负向用例做完灰度验收，再谈扩缩容收益才稳妥。