技术分享2026年9月4日

从有状态到无状态：MCP 这次升级，改变了什么？

一次不只是“功能更新”，而是协议底层思路转向的改版 如果你最近一直在看 Agent、工具调用、AI IDE、企业知识库接入这些方向，MCP 这个名字大概率已经不陌生了。 MCP，全称 Model Context Protocol，本质上是一个开放协议，用来解决一个非常具体的问题：大模型到底怎么标准地...

#MCP

一次不只是“功能更新”，而是协议底层思路转向的改版

如果你最近一直在看 Agent、工具调用、AI IDE、企业知识库接入这些方向，MCP 这个名字大概率已经不陌生了。

MCP，全称 Model Context Protocol，本质上是一个开放协议，用来解决一个非常具体的问题：大模型到底怎么标准地连接外部工具、数据和上下文。

这件事听起来像工程细节，但它其实决定了 Agent 时代能不能真的落地。

因为大模型自己会说话，不代表它天然知道你的文件在哪里、数据库怎么查、内部系统怎么调、企业流程怎么走。没有标准协议，每接一个工具都要重新做一次定制开发，生态就很难长大。

MCP 想做的，就是像 USB-C 统一设备接口、HTTP 统一网页访问那样，把“AI 应用怎么接外部世界”这件事标准化。

所以，MCP 的每一次大版本变化，都不只是协议爱好者关心的事。它往往意味着：AI 应用接入层，正在往更成熟、更工程化的方向走。

2026 年 7 月 28 日这一版 MCP 规范，就是这样一次变化。

它不是简单加了几个字段、补了几个方法，而是对协议底层思路做了一次很明显的调整：从有状态连接，转向无状态请求；从把很多事情藏在会话里，转向让每个请求显式说清楚自己是谁、会什么、要什么。

一句话概括：

MCP 正在从“适合实验的工具协议”，变成“更适合生产环境的基础设施协议”。

一、先讲清楚：MCP 到底是干什么的

先把概念讲明白。

MCP 里有三个核心角色：

  • Host：真正的大模型应用，比如 AI IDE、聊天应用、Agent 平台
  • Client：Host 内部的连接器
  • Server：外部工具和数据提供方，比如文件系统、数据库、浏览器、企业系统

Server 通常提供三类能力：

1. Resources

给模型看的上下文和数据。

比如一份文档、一个数据库表、一段网页内容、某个业务对象的信息。

2. Prompts

给模型用的提示词模板和工作流模板。

比如“总结这份财报”“检查这段代码”“生成客服回复”等可复用操作方式。

3. Tools

给模型调用的函数和动作。

比如查询库存、创建工单、读取文件、运行脚本、调用内部 API。

你可以这样记：

Resources 是“给模型看的东西”； Prompts 是“教模型怎么做事的模板”； Tools 是“模型真正能执行的动作”。

所以，MCP 的本质不是“让模型更聪明”，而是让模型更容易接入世界。

这也是为什么它会越来越重要。

二、这次变化的核心：MCP 从“有状态”走向“无状态”

这次 2026-07-28 版规范，最重要的变化，不在表层功能，而在底层假设。

用一句话说：

MCP 不再把协议建立在“先建立一条长期连接，再围绕这条连接维持状态”上，而是转向“每个请求都尽量自包含、自说明、可独立处理”。

这听起来很技术，但可以用一个类比来理解。

过去的 MCP，更像“先拉一条专线，再开始工作”：

先握手； 再初始化； 再维持会话； 很多事情依赖这条连接本身。

现在的 MCP，更像“每次打电话都要把身份、意图和能力说清楚”：

不再默认有一条长期专线； 不再把关键状态藏在连接层； 每个请求都尽量自己说清楚自己是谁、支持什么、需要什么。

这次 changelog 里最关键的几条变化，基本都在围绕这件事展开：

  • 移除了协议级 session 和 Mcp-Session-Id
  • 移除了 initialize / notifications/initialized 握手
  • 每个请求都通过 _meta 携带协议版本和 client capabilities
  • 新增 server/discover
  • 用 subscriptions/listen 替代原来的订阅设计
  • 移除了 ping、logging/setLevel、notifications/roots/list_changed
  • tasks 从核心协议移到扩展
  • 引入 MRTR，也就是多轮请求模式
  • 移除了 SSE stream resumability 和 message redelivery

这些术语看起来有点密，但核心意思并不复杂：

MCP 在把自己从“连接协议”改成“请求协议”。

也就是说，它不再假设世界里天然存在一条稳定、长久、可依赖的连接，而是假设每一次请求都应该尽量独立、清楚、可组合。

这是非常大的思路变化。

三、为什么要做这样的调整：不是技术洁癖，而是现实压力

这类改动，往往不是“为了优雅而优雅”，而是因为生产环境真的会出问题。

1. 为了更适合真实生产环境

有状态协议在实验室里很好用。

你起一个 server，再连一个 client，握手成功，然后持续通信，体验很顺。

但一旦进入真实生产环境，问题就来了：

  • 服务重启怎么办？
  • 多实例部署怎么办？
  • 中间有代理层怎么办？
  • 断线之后怎么恢复？
  • 请求怎么重试？
  • 负载均衡怎么做？

如果协议层强依赖 session 和长期连接，这些问题都会变得很麻烦。

而无状态请求天然更适合现代分布式系统。

它更容易被代理、缓存、重试、审计，也更容易接入企业现有的网关和基础设施。

所以这次改动，首先是在为“更大规模、更严肃的使用场景”让路。

2. 为了把能力边界说得更清楚

以前，MCP 里很多关键信息依赖握手和连接状态。

这在简单场景里没问题，但一旦系统复杂，就会带来麻烦：

  • 你到底支持哪个协议版本？
  • 这个 client 支持哪些能力？
  • 这次请求该不该走某个扩展？
  • 出错时是协议不兼容，还是状态丢了？

现在改成每个请求都显式携带协议版本和 client capabilities，好处很直接：

边界更清楚； 排错更容易； 兼容性更可控。

这对标准协议来说非常重要。

因为标准最怕的，不是功能少，而是边界模糊。

3. 为了让核心协议更克制

这次还有一个很重要的变化：tasks 被移出了核心协议，改成扩展。

这件事很值得关注。

它说明 MCP 设计者已经意识到，一个协议如果想长期发展，核心不能无限膨胀。

核心协议最好只做最稳定、最通用、最少争议的部分； 更复杂、更实验性的能力，放到扩展里去演化。

这其实是一种非常典型的“标准化成熟路径”。

就像很多基础协议一样，真正活得久的，往往不是一开始什么都包，而是核心足够窄，扩展足够清楚。

所以 tasks 移出核心，不是削弱 MCP，反而是让它更像一个能长期演化的协议。

4. 为了适应 Agent 时代更复杂的多轮交互

这次引入的 MRTR（Multi Round-Trip Requests） 也很关键。

它背后对应的是一个很现实的问题：

很多 AI 任务，不是一次请求、一次响应就能结束的。

比如：

模型想调用一个工具，但服务器发现还缺参数； 任务执行到一半，需要用户补充确认； 服务器需要先向 client 要更多上下文，才能继续处理。

这类场景，如果协议只支持“一问一答”，就会很别扭。

MRTR 的价值就在于，它把这种“中间还要再要信息”的过程，变成了更结构化、更明确的协议模式。

这说明 MCP 已经不满足于支持简单工具调用，而是在为更复杂的 Agent 工作流打基础。

四、这次更新里，最值得普通读者记住的 3 个变化

如果你不想陷入细节，可以只记住这三件事。

1. 从 session 到 stateless

以前是“先建立连接，再围绕连接工作”； 现在是“每个请求自己说清楚”。

这会直接影响 MCP 在真实系统里的部署方式。

2. 从核心大包到核心 + 扩展

以前很多功能都往核心协议里塞； 现在开始把核心收窄，把更复杂的能力放到扩展里。

这意味着 MCP 在变得更像一个长期标准。

3. 从单轮调用到多轮协作

以前更像一次请求一次响应； 现在更重视多轮请求、补充输入、复杂交互。

这意味着 MCP 更适合 Agent，而不仅仅是工具调用。

五、这对开发者和企业意味着什么

这次改动，不只是协议作者自己的事。它会直接影响开发者和企业怎么使用 MCP。

对开发者

以前写 MCP server，很多人可能会下意识地把它当成一个“长连接服务”来写。

但以后，开发思路可能会更像写现代 Web API：

  • 请求更显式
  • 状态更外置
  • 扩展更清楚
  • 错误处理更标准化

这对生态来说其实是好事。

因为越是像标准 API，越容易学习、接入和复用。

对企业

对企业来说，这次变化也很重要。

因为无状态、显式、可扩展的协议，更容易接入现有基础设施：

  • API 网关
  • 权限系统
  • 审计系统
  • 日志系统
  • 私有部署环境
  • 混合云架构

这意味着 MCP 更容易从“开发者玩具”变成“企业集成方案”。

特别是当企业想把内部工具、知识库、数据系统暴露给多个 AI 应用时，协议是否工程化，会直接决定能不能大规模推广。

对 Agent 生态

对 Agent 生态来说，这次变化说明 MCP 正在往“工具协议基础设施”的方向走。

它不再只是让 demo 跑起来，而是开始考虑：

  • 多轮协作
  • 版本协商
  • 扩展治理
  • 状态外置
  • 企业接入

这些事听起来不如“模型又变强了”那么性感，但它们才是真正决定 Agent 能不能规模化的底层条件。

六、MCP 的意义，不在于它完美，而在于它开始像基础设施

很多人看协议更新，容易只盯着“加了什么、删了什么”。

但这一次，MCP 真正值得关注的，不是某个字段，也不是某个方法名，而是它背后透出的方向感。

它开始表现出一种基础设施协议的自觉：

  • 核心更克制
  • 状态更显式
  • 扩展更清楚
  • 更面向生产环境

这说明 MCP 已经不只是“让模型连工具”的实验方案，而是在往“AI 应用接入层标准”迈进。

如果 Agent 时代真的到来，那么这类协议的重要性，未必会输给模型本身。

因为模型决定“会不会想”，而协议决定“能不能做事”。

而 MCP 这次升级，显然是在认真解决后者。

参考来源

  • Model Context Protocol Specification, 2026-07-28, Key Changes
  • Model Context Protocol Specification, 2026-07-28, Overview
  • Model Context Protocol GitHub Repository
返回文章列表