MCP Stateless：从协议连接到 Agent 能力平台

无状态并不意味着 Agent 没有记忆、任务不能持续、工具不能处理有状态业务。它只改变状态的表达方式：从隐含的连接与 Session，转成请求元数据、显式状态引用、任务资源和领域系统记录。这个差别决定了系统能否使用普通 HTTP 基础设施，也决定了故障后能否知道究竟丢了什么。

这不是把状态问题推给别的组件，而是让每种状态回到有明确所有者、生命周期和恢复语义的层。

2026-07-28 版本究竟移除了什么

旧版 Streamable HTTP 要求 initialize/initialized 握手。服务端返回 Mcp-Session-Id，客户端在后来请求中持续携带；多副本部署要么使用粘性路由，把同一会话固定在实例上，要么建立共享 Session Store。实例故障时，客户端还要重新握手、恢复能力协商和流状态。协议生命周期因此与部署拓扑紧密耦合。

2026-07-28 删除了握手和 Mcp-Session-Id。每个 JSON-RPC 请求单独通过 HTTP POST 发送，协议版本、客户端身份与客户端能力进入每请求 _meta；客户端可选择调用 server/discover 获取服务端版本与能力，也可以直接调用具体方法，遇到不支持版本再依据标准错误协商。任意请求可以落到任意健康实例，普通 round-robin 负载均衡即可工作。

Streamable HTTP 还要求把 method 与工具或资源名称镜像到 Mcp-Method、Mcp-Name 请求头。Gateway、WAF、限流器和观测系统由此可以在解析 JSON Body 前完成路由和策略匹配。服务端必须校验 Header 与 Body 一致，否则应拒绝请求，避免网关依据一个值放行、后端却执行另一个值的分歧攻击。

过去需要服务端主动请求客户端输入的流程，改由 Multi Round-Trip Requests 表达。工具若需要用户确认或模型采样，可返回 input_required、待回答请求与 requestState；客户端收集结果后重新提交原调用。状态被显式装入响应和重试请求，另一个实例也能接手。长任务则由 Tasks 扩展提供可轮询的耐久句柄，而不是依赖一条长连接维持存在感。

代价同样明确：版本、能力和客户端信息需要随请求重复传输；应用要设计显式状态引用；旧客户端与旧服务仍需双栈或降级；如果开发者把完整业务状态都塞进不透明 Handle，又缺少过期、授权和审计，无状态只会把隐藏状态从内存移到另一个黑盒。

状态应该重新落到哪些层

协议层负责请求如何表达和交换，不应承担任务事实。Agent Runtime 保存目标、计划、预算、审批、制品、重试和恢复点；MCP Gateway 保存身份到策略的映射、路由配置、工具目录和可观测数据；工具服务执行业务操作；数据库、工单或云控制面仍是领域事实源。

跨调用状态最好以显式引用传递。例如导入任务返回 job_id，下一次查询携带该 ID；数据库事务返回有权限绑定和过期时间的事务句柄；需要人工确认的删除操作返回不可变动作摘要，确认后携带摘要哈希继续。引用必须绑定主体、租户、作用域、版本和 TTL，并防止被另一个用户或另一个工具重放。

这也让恢复语义更清楚。协议请求超时不等于业务动作未发生；客户端要通过幂等键或任务状态查询确认结果，而不是盲目重试。对纯读取可以自动重试，对幂等写入复用同一键，对可补偿动作记录补偿步骤，对不可逆操作要求执行前确认。无状态协议消除了连接级歧义，却不会自动解决分布式系统的 exactly-once 难题。

记忆也不应放进 MCP Session。长期偏好与历史知识属于 Agent 记忆系统，必须可检索、可删除、可审计；短期工具状态由明确句柄表示；服务端缓存属于性能优化，丢失后应能从事实源重建。把这三类状态混在一个 Session 里，扩容、权限撤销和故障恢复都会变得含糊。

Gateway 为什么从可选代理变成能力控制面

云端 MCP 的另一个规模问题是工具目录。论文《MCP Gateway》测量了“把全部 Tool Schema 内联给模型”的上限：单个云服务类别就可能有 921 个工具；120 个 VPC 工具可消耗超过 166k Token，Qwen3-MAX 在 120 个工具时端到端延迟超过 100 秒、180 个时超过 200 秒；工具增加还使拒绝调用比例从 8% 升到 19%。模型上下文即使达到百万 Token，也要同时容纳用户问题、历史与推理，不能把目录当成免费空间。

该 Gateway 把 OpenAPI 3.0/3.1 操作在挂载时编译成 MCP 工具，以独立适配层处理 OpenAPI↔MCP 数据映射和不同 MCP Transport；在线链路保持确定性，缺失语义的规范只在离线阶段由模型补充。实现运行于阿里云 L7 基础设施，协议与路由部分约 8K 行 Go，转换模块约 6K 行 WebAssembly，已在五个区域运行八个月，覆盖 315 个云产品、约一万级 OpenAPI 操作。

工具发现不让另一个 LLM 再读一遍全目录，而由 Gateway 暴露标准 Tool Search 工具。离线为工具名称与描述建立 Dense 向量索引和 BM25 Sparse 索引；在线分别检索、Outer Join，再用 Reciprocal Rank Fusion 合并 Top-K。Dense 擅长意图改写，BM25 保留资源 ID、参数名和云产品缩写等精确词法信号，两者互补。

在 3,616 个生产工具上，Hybrid 的 Recall@15 为 98.2%，高于 Dense-only RAG-MCP 的 83.1%、在 ToolBench 微调的 ToolLLM 的 78.6% 和 BM25 的 67.7%；最终工具选择准确率为 81.6%，对应对比为 72.1% 与 70.6%。从 372 个工具全部暴露改为 Top-15，平均工具选择时间由 55.7 秒降到 6.2 秒，缩短 8.9 倍；Token 从 505.86k 降到 21.22k，减少 23.8 倍；P95 从 60.0 秒降到 12.4 秒。检索本身在百级到万级工具规模内保持约 202–243 毫秒。

这些结果证明 Gateway 可以承担确定性检索与治理，却也揭示边界。ToolLLM 在训练过的 ToolBench 上接近满召回，迁到云目录后显著下降，说明目录语义持续变化时固定微调难以维护；ID-only 查询缺少语义，向量检索容易失败，需要领域规则、依赖图或缓存补足；Top-15 有约 2% 目标遗漏，一旦真实工具不在候选集，最强模型也无法选择正确。

旧的有状态部署经验仍然有迁移价值

《MCP Gateway》研究的是旧版会话模型，因此设计了中心 Session Metadata Store，把前端 Session、后端 Session 与 Routing Hash 映射起来；长连接跨 Gateway 实例时再用 Pub/Sub 把请求或响应送回持有 SSE 通道的实例。这一整套复杂性正好构成 2026-07-28 无状态改造的反证：连接级状态会迫使基础设施知道会话归属。

新协议下，这部分可以显著简化，但论文的其他经验仍然成立。Gateway 仍要做旧协议桥接、身份建立、后端凭证映射、工具级访问控制、OpenAPI 转换、目录检索和流量观测。无状态解决的是副本亲和与隐藏握手状态，并没有消除治理需求。

生产测量也能帮助判断控制面预算。典型少于 20 字段的 API 转换 P50 低于 35 微秒，100 字段时 P50 为 143 微秒；生成 1,334 个工具的 16.7MB 规范离线耗时 2.75 秒。旧有状态模式里 Session 管理占 Gateway 主要每请求成本，而无状态路径更轻。系统在扩容时响应时间约 7 毫秒保持稳定，说明把策略与转换放进数据面并不必然带来高延迟，但实现必须避免在在线路径调用不确定的 LLM。

从“连上工具”到“运营能力平台”

无状态 MCP 的生产落地可以用一次请求的责任链检查：Runtime 生成带身份与追踪上下文的动作；Gateway 根据 Mcp-Method、Mcp-Name、主体和租户完成鉴权、限流与路由；Tool Search 只返回允许发现且与意图相关的工具；工具调用携带幂等键和显式状态引用；领域系统写入事实；结果与副作用回到任务事件日志。

目录、执行与权限应分离。用户“能发现某工具”不等于“能调用”，能调用也不等于能访问任意资源；敏感参数仍需资源级策略。工具 Schema 更新要有版本和缓存 TTL，旧客户端通过版本协商或兼容层降级；追踪要贯穿 Host、Gateway、MCP Server 与下游系统，才能把一次 Agent 失败定位到选错工具、参数错误、权限拒绝还是后端故障。

还要为双栈迁移做现实规划。新客户端可以先 server/discover，不支持 2026-07-28 时回退到 2025 系列握手；服务端可同时保留旧 Session 路径和新无状态路径，按协议版本隔离。迁移完成前，应分别观测会话粘连失败率、版本降级率、Header/Body 不一致拒绝、Tool Search 漏召回和显式状态句柄错误。

MCP Stateless 的核心不是删掉一个 Session Header，而是把隐含系统行为变成显式契约。连接可以无状态，任务必须耐久；服务可以任意扩容，权限必须逐请求成立；工具可以成千上万，模型每次只应看到相关且获准的子集。做到这三点，MCP 才从“模型调用工具的适配协议”成长为可运营的 Agent 能力平台。