如果你用 Claude 连过 Gmail、日历或者公司内部数据库,你其实已经在用一个叫 MCP 的协议——只是你完全感觉不到它的存在。7月28日,这个协议会发布一版新的候选规范,改动听起来很技术:服务器怎么记住"你是谁"。但对那些正在给 AI Agent 搭基础设施的人来说,这块石头压了大半年,终于要松一松。

MCP 是什么,卡点在哪

MCP,全称 Model Context Protocol,是 AI 模型连接外部世界的通用接口——日历、数据库、Gmail、Slack、Salesforce,都靠它接进模型。它是这一轮 Agent 热潮里最不起眼、也最基础的一块管道。

旧机制里,客户端第一次连上服务器,双方握手,服务器发一个 Session ID,后面每次请求都带着这个 ID,证明"我们还是同一段对话"。这套逻辑在单台服务器上没毛病,一旦上规模就出问题:企业级部署背后往往是一个负载均衡器,把请求随机分发到几十台、甚至跨地区的服务器上。服务器之间默认互不通气,谁也不知道别的机器发出去的 Session ID 是什么。结果是每家公司都得额外搭一套跨机共享的会话存储,和负载均衡器的设计初衷对着干。

Session 处理:旧机制 vs 新方案 旧:服务器要记住你 客户端 负载均衡 服务器A 服务器B 服务器C 共享 Session 存储(必须同步) 服务器之间必须跨机同步 Session ID 新:服务器不认状态 客户端 负载均衡 服务器A 服务器B 服务器C 请求自带信息,谁接都一样 类似普通网站早已验证的无状态架构,理论上更容易横向扩展 官方候选规范,预计 2026年7月28日 发布

这不是纸上谈兵的小麻烦。今年 Agent 相关的热度很高,但真正把 MCP 服务器大规模铺开、做成一方产品的公司并不多,Session ID 这道坎是原因之一。

谁会先受益,谁的话不能全信

新版本的思路很朴素:服务器端不再强求记住会话状态,改成更接近普通网站的处理方式——请求自己带够信息,谁接都能处理。理论上,这能让 MCP 服务器更容易横向扩展、更容易维护,规模化的运行成本也该更低。

这套逻辑不是 MCP 独创。HTTP 本身就是无状态协议,今天几乎所有网站的水平扩展能力都建立在这个假设上。MCP 现在补的,是十几年前 Web 架构就走过的路。

无状态改造:三个时间点 2026年5月 无状态规范候选版公开 2026年6月 Arcade 融资6000万美元 行业信号,非协议本身 7月28日 新版本正式发布

真正会先感受到变化的,是搭建企业级 MCP 接入层的服务商和平台方,以及要把 Agent 接进内部系统的技术团队。普通用户这边,大概率什么都感觉不到——你的 Claude 该怎么用还怎么用。

值得多说一句:这次把改动讲得最清楚的,是一家两年历史、六月刚融了6000万美元的创业公司 Arcade,他们的生意就是帮 Agent 在真实企业里落地执行。他们的解读值得参考,但终究是一家利益相关方的说法,不能当成协议效果的独立验证。

  • 提醒.协议层面的松绑,解决不了 Agent 本身的可靠性、权限治理和执行安全问题,这些坎还在原地。

我的判断

王安石有句诗,"看似寻常最奇崛,成如容易却艰辛"。这次更新放进模型发布的叙事里,寒酸得不值一提——没有新能力,没有更聪明的推理,普通用户连感知都没有。但基础设施的进度,从来不按模型训练的速度走,它按标准委员会磨嘴皮子的速度走。

协议慢一拍,不代表方向错,只代表台子还没搭稳

这次更新说明的是,MCP 生态终于开始补一门早该补的课:怎么让一个协议在几十台机器、跨地区负载均衡的真实生产环境里不别扭地跑起来。这是把规模化的门槛往后推了一步,不是把门槛拆掉。模型可以一路狂飙,但 Agent 能不能真正嵌进企业系统,取决于这类不起眼的管道工程有没有跟上——这次,它总算往前挪了一步。