MCP 终于无状态了，但状态并没有消失，只是被「甩」给了应用

MCP 终于无状态了，但状态并没有消失，只是被“甩”给了应用 — infoq.cn · 13 小时前 · 🤖 AI / ML

MCP 协议长期依赖有状态的会话连接，这给服务端的横向扩展、负载均衡与断线恢复带来了额外约束，文章讨论的正是它向无状态形态演进之后究竟改变了什么。新形态下协议层不再强绑定会话，服务端不必为每个客户端维护一份持续存活的上下文，请求本身需要携带完成一次调用所需的全部信息，从而可以被任意实例处理。直接收益是部署方式更自由：粘性会话与会话亲和路由不再是必需品，扩容、缩容、滚动发布和按需拉起实例都变得更简单，也更契合无服务器与边缘节点的运行环境。但作者强调，状态并没有被消灭，只是从协议层转移到了应用层——对话历史、工具调用结果、鉴权上下文与中间产物由谁来保存，需要客户端或业务系统自己决定，常见做法是借助外部缓存、数据库或对象存储来承载。随之而来的代价包括请求体积变大、上下文重复传输带来的带宽与延迟开销，以及应用侧必须自行处理并发写入、过期清理与多副本一致性等问题。作者的结论是：无状态化确实降低了协议与服务端自身的复杂度，却把复杂度平移给了应用，是否值得取决于具体场景在可扩展性与实现成本之间的权衡。

核心信息

协议层去会话化是这次变化的核心：服务端不再为每个客户端维持长期存活的会话上下文，任何实例都能处理任意一条请求，粘性会话与会话亲和路由因此不再是必需品。直接结果是水平扩容、滚动发布、灰度切换与按需拉起实例的门槛明显降低，也更契合无服务器与边缘节点的部署形态；对运维而言，节点随时消失或重启不再意味着会话中断，故障恢复从「找回那台机器」变成了「把请求发给下一台」。
状态并没有消失，而是被明确移交到应用层：对话历史、工具调用结果、鉴权凭据、中间产物等仍需有人保存，通常落到外部缓存、数据库或对象存储里。应用必须自己定义读写的时机、生命周期与并发策略，包括何时写入、何时裁剪、何时失效；如果照搬过去把状态放在进程内存里的写法，多副本部署下会立刻出现上下文丢失或前后不一致的问题。
代价集中在传输与实现两端：请求需要自带完整上下文，报文体积随之变大，重复传输带来额外的带宽与序列化开销，成本会随交互轮次增长而不是停留在服务端内存里。应用侧还要自行处理并发写入、过期清理、多副本一致性以及重放去重等问题，复杂度并没有被消除，只是从协议层换到了业务代码里，需要额外的中间件或存储组件来兜底。
是否采用无状态形态取决于场景：短连接、高并发、弹性伸缩诉求强的调用链更划算，可以按请求任意调度；而强交互、长流程、上下文体量大的场景仍需评估重复传输的代价，常见的折中做法是用会话标识配合服务端缓存，或者对上下文做压缩与增量传递。选型时应把带宽成本、存储成本与工程复杂度一并纳入比较，而不是只看服务端是否好扩。

💡 为什么值得读: 想搞清楚无状态化到底省了谁的事、又把麻烦塞给了谁，这篇把责任转移的账算得比发布会清楚得多。

✍️ 小编看法: 小编看法：无状态这件事，表面上是一次协议层的瘦身，实际上是一次责任的重新划分。过去协议替应用背了一部分包袱，现在这份包袱被明确退回给使用方，好处是服务端可以像普通 Web 服务一样被随意调度，坏处是很多团队会在第一次上线时低估应用侧要补的功课。最容易被忽略的是成本结构的变化：请求体变大意味着同样的业务量要付出更多带宽和序列化开销，如果上下文里塞着完整的历史记录，费用会随交互轮次线性上涨，而不是像以前那样只在服务端内存里滚雪球。另一个隐蔽的坑是多副本下的写入竞争，过去单会话单实例天然串行，现在同一个用户的两条请求可能落到不同机器，谁后写谁覆盖的问题会立刻暴露。对做基础设施的团队来说，这反而是机会：状态存储、上下文压缩、幂等重放、请求去重这些中间件会变成刚需，谁能把这些能力做成开箱即用的组件，谁就能吃到这波迁移红利。接下来值得观察三点：一是社区会不会形成事实上的状态存储约定，二是主流客户端是否内置上下文裁剪与压缩，三是网关层会不会出现专门针对这类协议的无状态路由与缓存产品。协议变简单从来不代表系统变简单，它只是把难题挪到了更难被看见的地方。

🏷️ MCP, state management, AI agents, protocol