模型上下文协议重大转向:取消会话、走向无状态,开发者追问——这不就又变回 API 了吗?
7 月 28 日,MCP 规范正式取消协议会话,转向无状态设计。新增两个 HTTP 标头使网关无需解析请求正文即可路由、限流和计量。社区反应尖锐分歧:有开发者认为"这不就又变回 REST API 了吗",也有开发者指出MCP 的真正价值在于成为 AI 提供商认可的标准。
7 月 28 日,MCP 规范正式取消协议会话,转向无状态设计。新增两个 HTTP 标头使网关无需解析请求正文即可路由、限流和计量。社区反应尖锐分歧:有开发者认为"这不就又变回 REST API 了吗",也有开发者指出MCP 的真正价值在于成为 AI 提供商认可的标准。
Mcp-Session-Id 标头,每个请求独立携带协议版本、身份和能力,可落到任意实例。Mcp-Method 和 Mcp-Name 使网关无需解析 JSON 正文即可按方法或工具路由、限流和计量——基础设施团队可直接用现有系统管理。早期 MCP 传输以 initialize 和 initialized 交互开始,建立会话后通过 Mcp-Session-Id 标头跟踪。每个请求都必须找到与该会话关联的状态。自动扩缩基础设施必须保留会话,部署时必须排空或迁移会话,负载均衡也不现实——客户端被固定到持有其会话的实例上。
新协议从核心请求路径中移除了握手、会话标头和协议会话。每个请求都携带其所需的协议版本、客户端身份和能力。任何请求都可以落到任意实例上。
但数据只是故事的一部分。
需要 initialize 握手建立会话;Mcp-Session-Id 跟踪状态;客户端固定到实例;自动扩缩需排空或迁移会话;负载均衡困难。
无需握手,无会话标头;每个请求自带版本、身份和能力;任意请求可落到任意实例;基础设施可直接使用标准 HTTP 机制。
注:无状态并不等于"没有上下文"——上下文仍可通过其他机制传递,但协议层不再负责维护会话状态。
MCP 的采用规模不存在争议。Anthropic 报告称 MCP SDK 月下载量已超过 4 亿次,今年增长了三倍。但规模之下,真实的使用情况可能没有那么乐观。
注:SDK 下载量反映的是生态热度,不代表实际生产环境中的工具调用活跃度。
一个诚实的注脚:
受到较少关注的是请求本身发生了什么变化。MCP 消息是 HTTP 上的 JSON-RPC,此前有关请求的信息只存在于 JSON 正文中。网关必须解析正文,才能知道请求是在列出工具、调用工具,还是读取资源。
现在,Streamable HTTP 请求必须包含两个标头:Mcp-Method 和 Mcp-Name。工具调用到达时的形式为 Mcp-Method: tools/call 和 Mcp-Name: search,后面是 JSON-RPC 负载。
Cloudflare 的 Matt Carey 详细说明了这样做的好处:网关、速率限制器或 WAF 可以读取这些标头,并按方法或工具采取措施,使用的正是它们已经应用于其他所有 API 的那些基本机制。评论者 evalstate 指出,该规范甚至更进一步——可以将工具参数复制到标头中,以实现自定义路由。
注:这一变化将元数据放入传输层,使基础设施团队已经在运行的系统能够直接读取和管理智能体流量,无需额外控制层。
Hacker News 上的社区反应出现了尖锐分歧,而分歧并不在于无状态是否是一项改进,而在于这项改进揭示了什么。
两种立场,一个核心问题:
注:立场强度基于社区讨论中的声量估算,不代表精确统计。三种立场并非互斥,许多开发者同时持有多个观点。
批评者的核心论据:"我们发明了一种有状态协议,发现状态难以扩展,于是剥离了状态,最终得到的结果是'发一个 POST 请求就行'。REST 阵营已经得意地等待这一刻 20 年了。"—— 评论者 luciana1u
辩护者的核心回应:"MCP 带来的核心优势在于,它是一项获得 AI 提供商认可的标准,正因为如此,人们有强烈的动力真正去实现它。"—— 评论者 vidarh
Sentry 联合创始人 David Cramer 从实现者角度给出了更务实的判断:"只有当底层管道不再占据整个故事时,智能体才真正变得有用。" 此次发布理顺了身份验证和工具的处理方式,让基础设施层回归其应有的位置。
另一条并行讨论:智能体是否根本不需要协议?
评论者 firasd 反驳了"直接用 CLI 工具"的立场,指出 CLI 假设使用者是一名开发者且正在笔记本电脑上操作,但这只描述了一小部分使用场景——大多数使用场景来自手机应用、网页聊天和嵌入式组件。协议层的标准化恰恰是让智能体走出开发者终端的必要条件。
注:授权机制也随之收紧——动态客户端注册已被弃用(计划 2027 年夏季后移除),采用 RFC 9207 进行颁发者标识,客户端将规范服务器 URI 作为 RFC 8707 resource 发送,确保令牌只被该受众接受。
MCP 的无状态化转型本质上是一次"诚实"的修正:承认早期设计中的有状态假设过于理想化,现实世界的智能体部署需要的是能直接插入现有基础设施的标准化接口。这场争议的真正价值不在于"变回 API"的嘲讽,而在于揭示了一个事实——智能体协议正在从学术实验走向工程落地,而工程化的代价就是放弃一些纯粹性,换取可部署、可运维、可规模化的能力。
对于已经在生产环境中运行 MCP 的团队,迁移需要付出工作。规范以及更新后的 TypeScript、Python、Go 和 C# SDK 现已提供。依赖协议会话、服务器到客户端请求或独立流的服务器,可以在现有有状态会话路由旁边运行一条无状态路由,逐步迁移。
MCP 规范 · 2026-07-28 版 · 已发布