浙江
用过 MCP 的都知道，以前的 MCP 是个典型的有状态协议：客户端连上服务器，先走一遍 initialize 握手，服务器给你发个会话 ID，后面每个请求都得带着 Mcp-Session-Id 头，服务器凭这个 ID 去查"这哥们之前干到哪了"。
这套设计小规模跑着没啥毛病，但一上规模就露馅。三个硬伤摆在那：一是会话亲和性把负载均衡绑死了，请求必须路由到持有会话的那台实例，扩缩容就是噩梦；二是实例一挂，会话跟着蒸发，客户端只能从头握手重来；三是水平扩容有天花板，有状态服务加机器牵涉状态分片、再均衡、一致性维护一堆分布式难题。
所以 MCP 这次重构的思路很直接：删。删掉 initialize 握手，删掉 Mcp-Session-Id，要求每个请求自带完整上下文。服务端收到任何请求，只凭请求体本身就能处理完——任何一个实例，处理任何一个请求，不用查任何会话表。说白了，就是把二十年前 Web 从有状态 CGI 走向 RESTful 无状态的那套剧本，在 Agent 世界里重演了一遍。
收益是立竿见影的：MCP 服务正式跨入"云原生"行列，可以跑在任意数量的实例后面，用最普通的轮询负载均衡，享受 Serverless 弹性伸缩。实例故障不再是会话级事故，只是负载均衡器的一次健康检查剔除。这轮重构也因此被称作 Agent 基础设施的"Kubernetes 时刻"。
但架构圈有句老话：状态不会消失，只会转移。删掉 Session 的那一刻，"状态管理"这份责任没有蒸发，而是整体下沉了——从协议层沉到了应用层和云平台层。拆开看，是三份责任：
第一份，会话记忆持久化。无状态时代，每个请求都是"失忆"的，Agent 记得什么，得靠外部系统供给。这意味着你的系统里必须多一个基础设施组件——记忆持久化层。学术界已经有人在搞"记忆路由"，比如 Router-Mem，让 Agent"够用就停"，别把整个记忆库倒进每个请求的上下文窗口，推理时间能降 25-27%。
第二份，幂等性与重复执行治理。这是最容易被低估、后果却最严重的一份。无状态架构和重试机制天生一对：请求无状态，失败换个实例重发最便宜。但重试会放大副作用——Agent 调支付工具扣款，响应在网络里丢了，客户端超时重试，第二次扣款发生。有状态时代服务器能认出"这活我干过了"，无状态时代它看到的两个请求一模一样、同样合法。标准解法是幂等键，但 Agent 的重试往往是自主决策循环发起的，可能换个参数又调一次，这种"语义重复"连幂等键都难抓住。
第三份，上下文重建成本。无状态要求每请求自带完整上下文，Token 消耗结构性上升。一个 50 步的 Agent 任务，后期每一步都要拖着前面 49 步的完整历史进场，总 Token 消耗近似随步数平方级增长。对冲手段无非三条：上下文压缩摘要、前缀缓存复用、结构化状态外移，生产里基本都是组合拳。
责任下沉的地方，就是生意生长的地方。云厂商货架上已经摆出几件新商品：Session-as-a-Service（托管式 Agent 记忆服务，Agent 时代的 ElastiCache）、Agent 网关（幂等、熔断、对账）、Agent 目录（注册、发现、身份、计费）。对金融客户来说，Agent 网关甚至是合规采购项——当 Agent 开始操作真实资金，"任何一笔操作不会因重试而执行两次"就不再是技术选型，而是风控硬要求。
对架构师来说，这轮重构最该记住的一句话：协议删掉的状态，就是你要么自建、要么采购的基础设施。区别在于，这一次你提前知道了剧本。MCP 管工具、A2A 管协作的分层格局正在固化，选型时别纠结"MCP 还是 A2A"——它们是栈的不同层，不是竞品。
你项目里开始用无状态 MCP 了吗？还是仍在观望？评论区聊聊。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
