MCP 走向无状态，开发者追问：这不就又变回 API 了吗？

作者 ｜ Steef-Jan Wiggers

译者 ｜ 田橙

MCP 2026-07-28 规范 取消了协议会话。迄今为止，相关报道将此描述为可扩展性方面的一项进步，事实也的确如此。但同一版本还新增了两个必需的 HTTP 标头，而借助这些标头，网关无需打开请求正文，就能对智能体流量进行路由、限流和计量。

早期传输以 initialize 和 initialized 交互开始，由此建立会话，并通过 Mcp-Session-Id 标头跟踪会话。此后的每个请求都必须找到与该会话关联的状态。自动扩缩基础设施必须保留会话，部署时必须排空或迁移会话，而负载均衡并不现实，因为客户端会被固定到持有其会话的那个实例上。

新协议从核心请求路径中移除了握手、会话标头和协议会话。每个请求都携带其所需的协议版本、客户端身份和能力。任何请求都可以落到任意实例上。

受到较少关注的是请求本身发生了什么变化。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 指出，该规范甚至更进一步：可以将工具参数复制到标头中，以实现自定义路由。

使用新标头、通过网关控制进行 MCP 请求路由

迄今为止，智能体治理一直从另一个方向发展。Cloudflare 的 智能体追踪 和 Azure API Management 的 AI Gateway 层 都位于协议之上，作为独立的控制层存在。此次发布将元数据放入传输层，使基础设施团队已经在运行的系统能够读取它。

Elicitation 被拆开了。服务器发起的请求过去需要保持一个开放流。现在，它们使用多轮往返请求：服务器返回 input_required，客户端收集答案，然后重试调用。审批由一条保持连接变成两个请求，部署起来更简单，但这意味着等待人工响应的过程不再位于单次调用内部。

授权机制也随之收紧：动态客户端注册已被弃用，并计划在 2027 年夏季之后移除；采用 RFC 9207 进行颁发者标识；客户端将规范服务器 URI 作为 RFC 8707 resource 发送，以确保令牌只会被该受众接受。

Hacker News 上的社区反应出现了尖锐分歧，而分歧并不在于无状态是否是一项改进，而在于这项改进揭示了什么。

对于其中一派而言，此次发布证实，该协议从一开始就不应该是有状态的。正如评论者 drdexebtjl 所说：

事后看来，有状态 MCP 显然是错误的。这实际上使 MCP 变成了另一个 REST API 端点，也让你可以使用已经为 REST API 搭建好的同一套基础设施（例如负载均衡器、API 网关、渐进式发布等）。

评论者 pjmlp 将其描述为业界不断重复吸取的一项教训，并回顾了从 Sun RPC 得出的相同结论：无状态服务器永远更好，只有在无法避免时才使用有状态服务器。评论者 luciana1u 说得更加直白：

我们发明了一种有状态协议，发现状态难以扩展，于是剥离了状态，最终得到的结果是“发一个 POST 请求就行”。REST 阵营已经得意地等待这一刻 20 年了。

评论者 bloppe 从结构层面提出了这一观点，将 MCP 描述为一个类似 REST 的 API，加上一份 OpenAPI 已经能够提供的同类规范，再加上运行框架层面的授权，并认为只有第三项是真正的新事物。

辩护者并没有否认这种相似性，而是不同意由此得出的结论。评论者 lexicality 指出，MCP 实际上就是 JSON-RPC，真正被发明出来的是一套模型已经接受训练并能够使用的约定。评论者 vidarh 最简洁地概括了这一观点：

MCP 带来的核心优势在于，它是一项获得 AI 提供商认可的标准，正因为如此，人们有强烈的动力真正去实现它。

实现者从另一个方向得出了类似结论。Sentry 联合创始人兼首席产品官 David Cramer 此前曾公开撰文称 MCP 还不够好。他告诉 Cloudflare，此次发布理顺了身份验证和工具的处理方式：

只有当底层管道不再占据整个故事时，智能体才真正变得有用。

另一条并行讨论提出了一个问题：智能体是否根本不需要协议，只需要通过 shell 访问普通 CLI 工具。评论者 firasd 反驳说，CLI 立场假设使用者是一名开发者，正在笔记本电脑上操作，并且在编码运行框架中打开了 shell；但这只描述了一小部分使用场景，大多数使用场景来自手机应用、网页聊天和嵌入式组件。

MCP 的采用情况不存在争议：Anthropic 报告称，MCP SDK 的月下载量已超过 4 亿次，今年增长了三倍。至于这种采用能否惠及单个服务器，则是另一个问题。r/AI_Agents 上的一篇咨询公司帖子 称，他们在审计一位客户的服务器时发现，该服务器三个月内记录了 61 次工具调用，其中 58 次来自客户自己的工程师；帖子认为，团队把“智能体能够访问”当成了“智能体愿意访问”。作者披露，MCP 工作在其咨询收入中占据很大比例，并得出了一个与此次发布相呼应的结论：

资金正在流向网关、注册中心和身份验证层，而不是服务器本身。

对于已经在生产环境中运行 MCP 的团队而言，迁移确实需要付出工作。依赖协议会话、服务器到客户端请求或独立流的服务器，可以在现有有状态会话路由旁边运行一条无状态路由，将功能迁移过去，排空活动会话，并在弃用窗口期内移除旧路径。规范以及更新后的 TypeScript、Python、Go 和 C# SDK 现已提供。

原文连接：

https://www.infoq.com/news/2026/08/mcp-stateless-gateway/

声明：本文为 InfoQ 翻译，未经许可禁止转载。