7月28日，MCP（Model Context Protocol）发布了自诞生以来最大规模的一次架构更新。
听起来像是一个协议的工程细节更新，不值得大惊小怪？恰恰相反。这次更新的核心变化——从有状态协议转向无状态协议——可能会从根本上改变AI Agent基础设施的架构走向。取消initialize握手、取消Mcp-Session-Id，每次请求自带完整上下文……这个配方是不是很熟悉？没错，HTTP就是这么做的。
MCP为什么要"去状态化"？
要理解这个变化的意义，得先从MCP之前的设计说起。
MCP 1.0是一个有状态的会话协议——就像早期的FTP或Telnet，客户端和服务端之间要先建立Session，通过initialize握手协商能力，然后所有交互都在这个Session的上下文中进行。服务端需要维护每个客户端的会话状态：连接了哪些工具、上次调用了什么、上下文变量是什么……这种设计在简单场景下没问题，但一到大规模部署就出问题。
什么问题？首先是水平扩展难。因为服务端要维护会话状态，请求必须 sticky 到同一台服务器，不能随便负载均衡。流量上来了想加机器？没那么简单，得处理会话迁移、状态同步、分布式一致性这些麻烦事。
然后是容错能力差。服务端重启了怎么办？Session没了，整个连接就得重连、重新握手、重新加载工具。客户端网络抖动了怎么办？同样的，Session断了就得重来。对于长时运行的Agent来说，这是不可接受的——你不想做一个一小时的任务，因为网络抖了一下就全废了。
还有部署灵活性差。有状态协议很难做CDN式的边缘部署、很难做serverless、很难做请求级的路由和调度。而这些恰恰是云服务最擅长的东西。
无状态化的真正赢家是谁
转向无状态协议之后，这些问题迎刃而解。每个请求自带完整上下文，服务端不需要记住任何东西——来请求就处理，处理完就忘掉。想加机器？随便加，负载均衡器随便分发，反正哪台机器处理都一样。服务端挂了？客户端换一台机器重发请求就行，不会丢失进度。
这和Web的发展史如出一辙——从有状态的CGI会话到无状态的HTTP REST API，Web服务才真正实现了全球化、规模化、高可用的部署。MCP走的是同一条路。
那么谁是最大的受益者？云厂商。因为状态管理这门生意，从协议层让渡出去之后，必然会在上层以服务的形式重新出现——而且会以云服务的方式出现。你想做MCP的Session管理？云厂商给你做；你想做MCP的边缘部署？云厂商给你做；你想做MCP的自动扩展和负载均衡？云厂商给你做。协议层越简单、越无状态，上层云服务的想象空间就越大。
"MCP取消了Session，也把状态这门生意让给了云厂商。就像HTTP越简单，AWS越赚钱——这个剧本我们看过一遍了。"—— 一位云原生架构师的判断
对于Agent开发者来说，这也是个好消息。协议越简单、越标准化，集成的成本就越低，生态繁荣的速度就越快。你不用再担心MCP服务端的状态管理、水平扩展这些基础设施问题——云厂商会帮你搞定，你只需要专注于业务逻辑和工具实现。
当然，MCP的无状态化才刚起步，很多细节还在迭代，生态还需要时间适应。但方向已经很清晰了：MCP正在从"一个聪明的协议设计"变成"Agent时代的HTTP"——简单、无状态、可扩展、全球部署。当这个基础设施足够成熟，Agent的大规模落地才真正成为可能。
明天见。
On July 28, MCP (Model Context Protocol) released its largest architectural update since its inception.
Sounds like a niche engineering detail of a protocol, not worth making a fuss about? On the contrary. The core change in this update — shifting from a stateful protocol to a stateless one — could fundamentally reshape the architecture of AI Agent infrastructure. Removing the initialize handshake, removing the Mcp-Session-Id, every request carrying full context… doesn't that formula sound familiar? Exactly — that's how HTTP works.
Why Is MCP "Going Stateless"?
To understand the significance of this change, you have to start with MCP's previous design.
MCP 1.0 was a stateful session protocol — like early FTP or Telnet, the client and server first established a Session, negotiated capabilities through an initialize handshake, then all interactions happened within the context of that session. The server had to maintain session state for every client: which tools were connected, what was last called, what context variables were set… This design works fine for simple scenarios, but breaks down at scale.
What breaks? First, horizontal scaling is hard. Because the server maintains session state, requests have to be sticky-routed to the same server — you can't just load-balance freely. Want to add more machines when traffic spikes? It's not that simple. You have to handle session migration, state synchronization, distributed consistency — the whole messy package.
Then there's poor fault tolerance. What happens when the server restarts? The Session is gone, the whole connection has to reconnect, re-handshake, reload tools. What if the client's network flickers? Same thing — Session breaks, you start over. For long-running agents, this is unacceptable — you don't want a one-hour task to get completely wasted because the network stuttered for a second.
And then there's poor deployment flexibility. Stateful protocols are hard to deploy in CDN-style edge locations, hard to make serverless, hard to do request-level routing and scheduling. And these are exactly the things cloud services excel at.
Who Are the Real Winners of Statelessness?
After shifting to a stateless protocol, these problems melt away. Every request carries its full context; the server doesn't need to remember anything — a request comes in, it gets processed, and the server forgets about it. Want to add more machines? Add as many as you want. The load balancer can distribute requests freely — it doesn't matter which machine handles it. A server goes down? The client just resends the request to a different one, no progress lost.
This mirrors the history of the Web exactly — it was only after moving from stateful CGI sessions to stateless HTTP REST APIs that web services truly achieved global, massive, highly-available deployment. MCP is walking the same path.
So who benefits the most? Cloud providers. Because the business of state management, once ceded from the protocol layer, will inevitably reappear at a higher layer in the form of services — and in the form of cloud services. Want MCP session management? Cloud providers will do it for you. Want MCP edge deployment? Cloud providers will do it for you. Want MCP auto-scaling and load balancing? Cloud providers will do it for you. The simpler and more stateless the protocol layer, the more room there is for cloud services on top.
"MCP removed Sessions — and handed the state management business to cloud providers. The simpler HTTP became, the more money AWS made — we've seen this movie before."— A Cloud-Native Architect's Take
For agent developers, this is also good news. The simpler and more standardized the protocol, the lower the integration cost and the faster the ecosystem prospers. You no longer have to worry about infrastructure issues like MCP server state management and horizontal scaling — cloud providers will handle it for you. You just focus on business logic and tool implementation.
Of course, MCP statelessness is just getting started. Many details are still iterating, and the ecosystem needs time to adapt. But the direction is clear: MCP is evolving from "a clever protocol design" to "the HTTP of the agent era" — simple, stateless, scalable, globally deployable. When this infrastructure matures enough, large-scale agent deployment truly becomes possible.
See you tomorrow.
MCP取消了Session，也把状态这门生意让给了云厂商。就像HTTP越简单，AWS越赚钱——这个剧本我们看过一遍了。
—— 一位云原生架构师
MCP removed Sessions — and handed the state management business to cloud providers. The simpler HTTP became, the more money AWS made — we've seen this movie before.
— A Cloud-Native Architect
MCP · Model Context Protocol · stateless protocol · Agent protocol · Agent infrastructure · cloud services · HTTP moment · horizontal scaling
Sources · 信源 Sources
本文基于 Dawn Vision 认知引擎处理的 8 个源信号生成，经编辑部人工审核。素材来源：MCP官方规范、今日头条、博客园技术分析。
Generated by the Dawn Vision cognitive engine processing 8 source signals, with human editorial review. Sources: MCP Official Spec, Toutiao, Blog Garden Tech Analysis.
