1. 从有状态到无状态2026年这次MCP更新到底在解决什么问题1.1 旧协议里的“隐式状态”是哪里来的MCP模型上下文协议前几年的实现本质上走的还是“长连接 会话上下文”的老路。客户端和服务器建立连接之后先做一次 initialize 握手服务器生成一个 session id后续所有工具调用、资源读取、提示词拉取都靠这个 session id 绑定到同一份服务端状态上。这个状态里装着什么通常是当前对话上下文、已经打开的资源句柄、分页游标、临时权限标记甚至还有服务器主动推送的订阅关系。这套设计在单体应用时代没什么大问题因为服务器就一台进程内存里的状态是天然的共享变量。可一旦把 MCP 接入到真实的 Agent 生产环境问题立刻暴露出来。我在维护模拟项目X的时候第一版就是照着旧规范搭的客户端连上一个工具服务用一个全局 session 变量记住“这个会话属于哪个用户”“调过哪些工具”“上次读到资源的第几页”。调试单个连接时很舒服前后端 log 串得起来一切都在掌握中。问题出现在压测和灰度扩容那一刻。因为我们有三台网关节点做负载均衡客户端每发起一次新请求负载均衡器可能把连接分到不同节点上session id 虽然没变但节点上的内存状态对不上。你在这个节点上完成了鉴权下个请求打到另一个节点那边一脸茫然。最后只能让负载均衡器开启粘性会话按 session id 哈希到固定节点时间一长节点之间负载严重不均某台机器扛不住其他机器闲着。1.2 “状态”成了分布式扩展的隐形敌人很多人觉得无状态只是“省内存”其实不然。状态真正的成本是分布式下的协调成本。粘性会话只是缓解了路由问题并没有解决状态一致性问题。模拟项目X后来加了 Redis 保存 session 快照每次操作后回写总算解决了跨节点读不到状态的问题。但代价是每次工具调用至少要多两次网络往返一次从 Redis 读状态一次回写。在高并发下Redis 的连接数和序列化开销又成了瓶颈。更麻烦的是服务端主动推送的订阅通知很难恢复。客户端断线重连后必须重新拉取一整套资源列表才能知道哪些文件发生了变更。新协议在2026年做 Stateless 化改造本质上是把“状态到底放在哪里”这个问题从协议层决策变成了应用层决策。协议不再保证帮你记住任何东西客户端每次请求都必须带上完整的上下文包括但不限于用户身份、权限范围、会话摘要、资源快照、调用链追踪标识。服务器完成处理后立刻“失忆”下一次请求来了从头解析。这种设计看起来像是开倒车——像极了早年 REST 接口要不停传 token 的笨办法。但它解决了一个非常现实的问题让 MCP 服务可以像普通 Web 服务一样水平扩展、滚动升级、随时重启而不必担心连接断开导致整个会话不可恢复。1.3 新规范的目标让每一次请求都可独立重放Stateless 架构最核心的价值是“可重放性”。一次工具调用如果失败了客户端拿着同样的请求体重试就行不会因为服务器端状态不一致而得到不同的结果。这在旧协议里几乎不可能做到因为同一把“尺子”在不同节点上可能量出不同长度。举个例子旧协议里客户端发起read_resource请求里只需要传资源 uri服务器端从 session 里读权限配置决定这次读取是否允许。如果权限配置在 A 节点上是“可读”在 B 节点上因为缓存未更新变成了“不可读”同一个请求就会出现两个结果。新协议要求客户端在请求里直接携带一份压缩过的权限快照服务器只负责校验签名和时效不再从内部状态里“猜”用户是谁。这件事的意义在于AI Agent 的工作流可以变得更加健壮。Agent 在调用工具、获取文件、写入数据库的过程中任何一个环节失败了都能带着原始参数重试。这在过去是奢望一次长会话里第 5 步发生了超时第 1 步到第 4 步的“进程内积累”全部丢失整个 Agent 任务只能从头开始。所以我认为这次更新的核心不是某个 API 变了、某个字段改了那么简单而是整个协议的定位从“连接协议”变成了“消息协议”。它不再关心你和服务器之间维持一条什么样的通道只关心每条消息是否自包含、可解析、可验证。2. Stateless架构在协议层的具体改法请求怎么传、资源怎么认2.1 从长会话到单次请求的上下文注入新规范里最直观的变化是取消了一锤定音的initialize会话建立流程。旧协议客户端连上之后先发 initialize服务器返回协议版本和服务器能力然后两者之间保持一个长连接。新协议把这套动作拆掉了客户端不需要先“打招呼”直接发第一个正式请求就行。所有原本初始化阶段协商的参数比如协议版本、能力声明、认证信息全部以请求头或元数据字段的形式随每个请求一起发送。具体到 JSON-RPC 2.0 风格的封装里每个请求的 params 对象下都会有一个保留字段context里面装的是当前会话的摘要、用户的身份断言、调用的工具列表、已经获取的资源快照的哈希。服务端拿到 context 后进行校验如果上下文过期或不完整返回一个标准错误码要求客户端补充信息后重试。刚开始我总觉得这种设计很啰嗦一条工具调用可能因为上下文太大而要分片传输网络开销比旧协议高不少。但仔细想想这是“用带宽换可用性”。旧协议里状态存服务端内存成本小但不可扩展新协议把状态放到请求里成本转移到了网络但任何中间件都能无差别处理流转比如消息队列、事件总线、Serverless 函数全都可以直接接住一个请求并做出反应而不用关心它是哪个会话的一部分。2.2 认证与授权方式也随状态一起外置了旧协议因为存在长会话鉴权通常做成连接级别握手时一次性认证之后所有请求默认通过。新协议废除了这个隐式信任每一次请求都要做完整的认证和授权。这意味着 token、签名、证书信息必须放在每个请求里而不是“连接已经建立”这个前提里。从工程上看这其实是把安全模型对齐到了传统的 HTTP API。你可以在服务器前面挂一个通用网关统一校验 JSON Web Token 或者 mTLS 证书全部由中间件完成不用在业务代码里关心“这个会话之前是不是验证过”。对运维来说这省了太多事。原来为了维持长连接里的认证状态需要每台节点同步会话缓存session 失效清理策略也要小心设计现在只需要在 API 网关上做一次标准校验后面的负载均衡、限流、审计都顺了。有一点容易被忽略授权也不能再依赖“登录时拉取的一锤子权限列表”。新规范建议客户端在请求里携带权限声明服务端可以根据声明的资源范围、操作类型、有效期做细粒度判断。这跟传统的 OAuth2 的 scope 思想很像但更激进——它要求权限信息本身也是“无状态可验证”的最好是用短时效签名或结构化 token而不是查数据库看用户角色。2.3 资源访问模型从“打开后读取”变成“声明式获取”旧协议的资源访问是个有状态的过程。客户端先list_resources拿到目录再open_resource打开某个资源随后通过一个连接保持的“打开状态”来分页读取内容。这个打开状态放在服务器内存里和 session 绑定服务器关闭连接就等于关闭了所有资源。新协议去掉了open_resource这一步。客户端直接发read_resource请求参数里包含完整的资源 URI、读取范围和期望的返回格式。服务器只根据请求本身判断是否需要鉴权、是否有权限、返回多大内容。没有“当前打开了多少个资源”这种全局计数也就没有资源句柄泄漏、未关闭连接导致的内存膨胀问题。这个改动让资源读取能更好地接入对象存储这类无状态后端。模拟项目X里有一个文件检索服务原来用旧协议时每个会话打开一个文件底层映射到本地文件句柄一台机器只能同时服务几十个活跃会话迁移到新协议后一个请求直接拉对象存储里的文件切片随手就把文件句柄释掉并发能力呈数量级提升。2.4 与既有 REST/HTTP 工具链的融合Stateless 化带来一个侧面红利MCP 终于能和主流基建完美融合了。原来很多团队抱怨 MCP 调试难因为它是私有格式的长连接wireshark 抓包看不懂kubectl 滚动更新会把所有连接掐断监控指标也难以暴露“每个会话在干什么”。现在协议变成了无状态的消息流就是普通 HTTP 请求你可以直接复用 API 网关、熔断器、限流插件、可观测性中间件。我实测下来最舒服的一点是日志分析。之前排查问题要翻 session 生命周期日志和工具调用日志两张表还得靠 session id 做 join现在每一条请求都是一个完整的事件带了 trace id、user id、resource uri直接进日志系统就能做全链路追踪。对中小团队来说这意味着不用再为了一个 AI 工具协议专门养一套定制化基础设施复用公司现成的 Web 服务监控体系就行。3. 迁移到Stateless架构的完整踩坑记录以模拟项目X为例3.1 我们为什么要从旧版MCP迁到新版模拟项目X是一个内部 Agent 工具编排网关最初基于旧版 MCP 实现给前端聊天机器人提供搜索、文档读取、任务创建三类工具。上线三个月后最难受的不是功能问题而是扩容问题。每次压测到每秒 500 个工具调用时负责维持会话状态的节点 CPU 先到 90%内存占用也一路飙高。我们试过调大实例规格、加 Redis 缓存但始终觉得不优雅。2026年新规范草案出来以后我决定拿模拟项目X做第一个吃螃蟹的试点。迁移周期大概六周实际写代码只用了两周剩下四周全在处理各种隐含假设。旧协议时代很多“因为连接还在所以理所当然”的东西迁移时全冒出来了。3.2 迁移过程中遇到的四个典型坑坑一上下文透传字段设计不合理。一开始我把context设计成一个大 JSON里面有 user_id、chat_id、tool_call_history结果一个请求有时能到 200KB。日志系统直接被撑爆网关频繁触发请求体大小限制。后来改成引用式传法真正的大段落比如工具调用历史放到一个临时对象存储里请求里只带一个 brief summary 和一个对象引用服务器按需拉取。这个设计很像 HTTP 缓存里的 ETag但更灵活适合跨服务传递。坑二旧的 Server-Sent Events 推送逻辑需要移除。旧协议支持服务器主动向客户端推送通知比如“资源已更新”“进度有变化”。新协议为了无状态把这种长连接推送整个砍掉了改成客户端轮询或者用 webhook 回调。模拟项目X里有一个“长任务执行”场景旧代码依赖 SSE 流式返回进度。迁移时我先做了个临时方案客户端每 3 秒拉一次任务状态接口等新协议正式支持回调后再换成 webhook。这里提醒大家流式响应并不是被取消了而是改为通过普通的 HTTP 流式响应来传递关键是不能占用额外的长连接。坑三大资源快照重复传输导致带宽升高。无状态请求要求携带资源快照但有些文件动不动几十 MB。把整个文件塞到 context 里显然不现实我用的是“快照摘要 按需拉取”的策略。请求里只带文件哈希和修改时间服务器检查哈希与缓存一致就直接用缓存不一致才返回RESOURCE_CHANGED错误让客户端重新上传或定向拉取。这种方式在 90% 场景下都能命中省掉大量带宽。坑四鉴权中间件顺序问题。迁移到无状态后权限校验迁移到 API 网关层。但有些服务为了兼容多协议既支持旧客户端又支持新客户端导致网关做一次鉴权业务层又做一次两边规则还不一样出现了线上偶尔 401 的诡异现象。后面统一收敛成网关层唯一鉴权业务层只检查上下文里的权限声明是否有效问题才消除。3.3 兼容层与双协议共存方案这次迁移我不想“一刀切”因为现网还有几十个旧客户端没来得及改造。我的做法是加了一个兼容层网关同时监听旧协议端口和新协议端口。旧端口进来的请求先经过一个转换器把旧 session 流程自动映射为新协议的无状态请求。转换器会在 Redis 里暂存一份旧会话对应的上下文快照用新协议格式封装后转发给下游业务服务。这样做的核心价值在于业务服务可以先完成无状态化改造而客户端适配可以慢慢推。等到所有客户端都升级完再把旧端口挂掉整个过程对业务几乎无损。我还整理了一张新旧调用差异对照表方便团队理解和后续排障。能力旧协议有状态新协议Stateless建立会话需要 initialize 握手不需要直接发请求认证方式连接级一次性认证每请求携带 token/签名上下文存储服务端 session 内存客户端请求内携带资源读取先 open 再 read直接 read_resource服务端推送长连接 SSE轮询或外部 webhook水平扩展需要粘性会话天然支持普通负载均衡断线重试恢复困难同一请求可重放3.4 实测数据延迟、吞吐和稳定性对比迁移完成后我做了三轮对比压测。旧协议基线是迁移前代码新协议是新代码压测工具是同一个模拟流量脚本模拟 1000 个并发用户每个用户连续发起 20 个工具调用。结果比较让我意外在平均延迟基本持平的情况下P99 延迟明显下降。旧协议的 P99 是 240ms新协议是 160ms。原因不难理解旧协议高峰时段所有请求都在抢同一批 session 锁Redis 读写和内存竞争拉长了尾部延迟新协议没有全局状态请求天然并行尾部延迟自然被压缩。吞吐方面更有说服力。旧协议单节点最多扛住 400 QPS新协议在第一轮压测里直接跑到了 800 QPSCPU 还有 30% 余量。连接数上旧协议是 1000 个长连接新协议是短连接瞬时并发连接只有旧协议的十分之一。对云上部署来说这还意味着按连接数的计费成本也随之下降。不过稳定性测试也暴露了另一个问题大上下文请求体如果超过网关限制会被直接拦截而旧协议不会出现这种情况。我后来在客户端侧加了一个请求体压缩功能context 字段统一用 gzip 压缩后再传输压缩率大约 70%问题迎刃而解。4. Stateless对Agent框架与工具生态的连锁反应4.1 Agent编排逻辑从“记住会话”转向“组装请求”这次协议更新对 Agent 框架的影响可能比对工具服务商的影响更深。以前 Agent 框架的核心逻辑是“管理会话”创建会话、延展会话、恢复会话、读取会话中的工具调用记录。现在框架层不再需要那么重的会话管理器反而要把精力花在“如何高效组装上下文”上。组装上下文不是简单地把数据拼在一起。Agent 每执行一个步骤都要把当前的目标、历史消息摘要、可用的工具列表、相关资源片段、权限声明整合成一个足够小的请求体。这个操作其实是在“提纯”。我见过一个粗糙的早期实现为了图省事把整个对话历史全塞进 context结果请求体膨胀到 5MB服务端处理慢得离谱。后来加入了“语义摘要 关键片段保留”的策略只把最近三轮对话的完整文本和更早历史的摘要放进 context请求体立刻降到几十 KB效果还更好了。这种变化对 Agent 的规划能力也是一种解放。旧协议里Agent 切换工具、改变目标时经常要清理旧状态无状态请求意味着每一步都是从第一性原理出发重新审视这个请求需要什么信息上下文会被强制地精简和重写。很多开发者担心 token 成本上升但我的实测是去掉冗余状态后模型理解上下文反而更准确有效 token 的比例高了总成本未必增加。4.2 工具服务商需要重新设计服务端对工具服务商来说Stateless 架构带来的是开发范式的转变。过去写一个 MCP 工具服务器框架自带 session 管理你把工具函数注册好就行现在框架不管状态了你需要自己决定哪些信息放进请求里、哪些信息放在数据库里哪些允许客户端直接传。这里最典型的是“用户偏好设置”这类数据。旧协议里服务器可以悄悄保存用户偏好在连接生命周期内直接调出来用新协议要求客户端显式传偏好不愿意传服务器就不处理。这个看似繁琐的改动长期来看其实是好事多租户系统的数据隔离变得更清楚了不存在服务器端“猜用户”导致的越权风险。另一个要改的是工具“进度”和“任务”类接口。以前可以在服务端开一个后台线程跑任务然后通过 SSE 推送给客户端现在要么接口同步等待完成要么让客户端轮询。我建议服务商统一采用“任务即资源”的模式创建任务接口立即返回一个 task 资源 URI客户端再通过 read_resource 轮询任务状态。这种模式语义特别清晰也天然符合无状态请求模型。4.3 MCP客户端宿主应用的适配要点客户端侧需要承担更多的上下文管理责任这也是很多人吐槽的点。以前连上服务器就完事现在你得认真设计 context 的生命周期。我的建议是客户端内部维护一个“会话状态存储层”但它的位置不在网络层而在应用层。每次发请求前从存储层读出上下文组装到请求里每次收到响应后更新存储层中的摘要。需要特别注意的是上下文无限增长的问题。如果不做控制聊天记录和资源片段会越积越多。我目前用的是“滑动窗口 摘要降级”策略完整保存最近 N 条消息N 条之前的历史每隔一段时间做一次摘要压缩。这个策略在旧协议里也会用到但旧协议没有强迫你这么做所以很多项目偷懒省掉了新协议逼着你做反而让长期运行的 Agent 更加稳定不会因为上下文爆炸而翻车。客户端还要处理一种新情况请求被服务端以CONTEXT_EXPIRED拒绝。这意味着你携带的上下文太老了服务端已经认为它不可信。合理方式是客户端自动触发一次快照刷新从本地会话存储重新组装最新上下文再重试一次。这个机制跟 JWT 过期刷新逻辑很像习惯了就好。5. 我对这次更新的几点判断与实操建议5.1 Stateless 不等于“没有状态”而是“状态归属清晰化”很多刚接触新规范的人会有个误解无状态服务器就不能有任何内部存储如果要存用户数据就得推到外部数据库。这个理解太极端。Stateless 真正要求的是“每个请求自包含任意节点处理结果一致”并不禁止服务器使用数据库、缓存或者对象存储。反而我认为这次协议更新是在逼着开发者把状态分门别类哪些是会话级临时状态不需要跨请求保留哪些是业务持久状态必须入数据库哪些是客户端状态应该交给客户端保存。清晰划分之后系统的扩展边界一下子明朗了。模拟项目X迁移完后我们的 Redis 里只存“上下文快照引用”和“短签名令牌”不存业务数据整条链路的观测性和可维护性都提高了一个档次。5.2 想省事的话先做协议网关而不是直接改业务如果你们团队正好在评估要不要跟进新协议我的建议是初期别大规模重写所有业务服务。先搭一个协议网关对外暴露新旧两套接口内部统一走 Stateless 的新调用模型。网关负责把旧请求翻译成新格式把旧 session 状态转成临时的上下文快照这样业务代码可以先保持不动后续迭代中逐步替换内部实现。这种做法最大的好处是低风险。你可以先把新协议跑在一个边缘服务上验证压测数据再决定要不要全面推广。网关层本身也不复杂一个普通的 HTTP 中间件团队两周能搞定但换来的是整个迁移过程可控。我们当时是在第四周才完成业务核心链路改造网关在第六周才完全移除整个过程没有发生过一次线上事故。5.3 我下一步会试的三个方向可观测性、上下文压缩、细粒度权限基于这次迁移的实际体验我接下来准备在三个方向继续投入。第一个方向是全面接入请求级别的 trace id。无状态请求天然适合链路追踪每个请求就是一条完整链路我可以把模型调用、工具调用、数据库访问串在一起做性能剖析。第二个方向是尝试更激进的上下文压缩算法比如层级摘要和向量召回混合目标是让 context 体积再降一半但保留关键信息不丢失。第三个方向是细粒度权限签名把之前的一次性 broad scope 换成按资源、按操作、按 TTL 签发的短期权限 token让每个请求最多只能碰它该碰的一小块数据。这三个方向都需要和团队一起验证但可以肯定的是Stateless 化给了我们更大的操作空间很多以前被 session 框架限制的设计现在都能拿出来了。不管你是 Agent 开发者、工具服务商还是只在内部系统里用 MCP 的工程团队这次协议变化都值得花时间重新审视一遍自己的架构。无状态不是银弹但它带来的“清晰边界”和“可重放性”确实是当下复杂 AI 系统里最需要的东西。