新版MCP转向无状态架构

过去一年半，模型上下文协议（Model Context Protocol，MCP）已经成为 AI 智能体与外部服务交互的通用标准。

但对 MCP 的主要批评之一，是该协议要求客户端与服务器之间保持有状态连接。这源于 MCP 的早期设计及其首个 STDIO 传输方式，后者面向本地应用而设计。当 MCP Server 转向远程部署时，它沿用了在本地运行良好的有状态连接模型，并将其移植到 Web 基础设施之上。构建一个行为规范的 MCP Server，意味着需要管理请求到粘性会话的路由、维持流连接、重放消息，以及承担通常比传统 Web 服务器更多的开销与复杂性。现在，这一切都将改变。

最新的 MCP 2026-07-28 规范已于上周发布，同时更新的还有 TypeScript、Python、Go 和 C# SDK。MCP 如今已经成为一个完全无状态的协议。规范、交互模型和 SDK 均已重写，以充分利用这一新协议并简化使用方式。这意味着 MCP 服务器现在只需运行在一个 Worker 中，无须任何有状态基础设施；更少的组件也为客户带来了更简单的运维和更低的成本。

在 Cloudflare，我们与 MCP 的渊源可以追溯到它诞生之初。2025 年 3 月，我们发布了 McpAgent 原语，用于通过 Cloudflare Agents SDK 构建 MCP 服务器。两个月后，我们举办了一场 MCP Demo Day，展示了 Asana、Atlassian、Block、Intercom、Linear、PayPal、Sentry、Stripe 和 Webflow 等客户推出的 MCP Server，以及 13 个针对 Cloudflare 特定产品的 MCP 服务器。一年前，我们又发布了 MCP Server Portals，帮助企业在组织内部安全地采用 MCP。

Cloudflare Durable Objects 凭借其独特定位，成为托管这些新应用的最佳选择。它是一种有状态服务器，将计算、持久化事务存储（通过嵌入式 SQLite）和实时协调能力结合在一起。它可以按需扩容，在未使用时进入休眠，并维持 MCP 在 AI 智能体与人类交互中所需的有状态连接。

McpAgent 与 Workers OAuth Provider 软件包相结合，是托管远程 MCP 服务器的最佳方案。然而，我们逐渐意识到，在保留所有已经广受欢迎的能力的同时，MCP 还可以变得更简单、更高效，也更容易托管。

MCP 2026-07-28 规范的此次发布，凝聚了整个 MCP 团队和各 SDK 维护者数月的工作。在本文中，我们将概述对开发者最重要的协议变更，分享已在生产环境中运行该版本的客户反馈，并说明如何开始使用新规范进行构建。

早期的 MCP 传输以一次 initialize 和 initialized 交换开始，由此启动一个会话。服务器可以分配一个 Mcp-Session-Id 标头，之后的每个请求都必须找到与该会话关联的状态。实践中，这意味着自动扩缩容基础设施必须保留活跃会话，部署时必须等待这些会话结束或将其迁移，而活跃实例一旦丢失，就可能迫使客户端重新连接，甚至导致会话中断。Serverless 平台虽然能够运行 MCP 服务器，但必须额外为协议会话提供协调机制，而绝大多数交互其实根本不需要这种会话。

新协议从核心请求路径中移除了强制握手、Mcp-Session-Id 标头和协议会话。每个请求都会携带自身所需的协议版本、客户端身份和客户端能力。客户端如果想在发出后续请求之前检查服务器，可以调用 server/discover，但这一步是可选的。

这个看似简单的细节改变了 MCP 服务器的部署方式。请求到达服务器后，可以调用工具、提示词或资源，然后直接返回结果。服务器无须存储任何协议会话。这消除了 MCP 很大一部分复杂性，同时保留了人们期望它具备的全部功能，使 MCP 服务器更容易部署、扩展和长期维护。

因此，新规范也不再需要 McpAgent。当应用本身需要状态时，Durable Objects 依然是合适的原语，但 MCP 自身已不再要求通过 Durable Object 来使用该协议。服务器可以在 Cloudflare Workers 这类按请求划定作用域的基础设施上实现更快速的扩缩容。

Cloudflare 的 Agents SDK 从第一天起就支持新规范。在规范最终定稿之前，客户和合作伙伴已经在 Cloudflare 上使用了候选版本，这让我们确信，从 McpAgent 迁移到新的 createMcpHandler（见下文）这一过程能够应对生产流量。

无需开放流即可完成信息征询

MCP 服务器有时需要获取更多信息，才能完成请求。例如，部署工具在发布到生产环境之前可能需要审批；设计工具可能需要用户选择颜色；计费工具可能需要在退款前进行确认。MCP 将这种交互称为信息征询（elicitation）。

此前，由服务器发起的请求（例如 elicitation/create）依赖于开放的流连接。部署这类服务器时，必须在流连接的复杂性、成本和请求超时之间进行权衡。

新协议通过多轮往返请求（Multi Round-Trip Requests，MRTR）重新设计了这一流程。服务器可以返回一个 input_required 结果，描述它所需要的信息。客户端收集答案后，携带该输入重试操作。随后，原始操作即可完成，而双方都无须在这些请求之间保留传输会话。

这项变更与原有的信息征询实现方式并不兼容。不过，它在运维层面要简单得多。我们相信，这将使更多开发者能够利用这一能力，构建功能丰富的 AI 智能体应用。

HTTP 基础设施现在能够理解 MCP

MCP 请求是通过 HTTP 发送的 JSON-RPC 消息，但此前有关请求的信息仅存在于 JSON 正文中。网关必须解析正文，才能知道某个请求是在调用 tools/list、调用工具，还是读取资源。

新规范要求 Streamable HTTP 请求携带 Mcp-Method 和 Mcp-Name 标头。例如，一次工具调用可能如下所示：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": { "q": "otters" }
  }
}

现在，网关、速率限制器或 Web 应用防火墙可以直接根据标头作出决策，无须解析任意 JSON。运维人员可以为不同的方法应用不同的规则，也可以使用他们已在其他场景中采用的相同 HTTP 原语，记录工具级别的指标。

规范还为 tools/list、prompts/list、resources/list 和 resources/read 的返回结果增加了 ttlMs 和 cacheScope 提示。工具目录会以确定性的顺序排列，使客户端能够复用这些目录，同时在重新连接时保持上游提示词缓存的稳定性。

授权机制持续演进

新规范还进一步收紧了 MCP 授权机制。当服务器和客户端之间已经存在关系时，MCP 现在优先使用预注册客户端；动态注册则优先使用客户端 ID 元数据文档（Client ID Metadata Documents，CIMD），并将动态客户端注册（Dynamic Client Registration，DCR）作为后备方案。DCR 已不建议用于新的实现，并计划在 2027 年夏季之后移除。

该规范还采用了 RFC 9207 的签发者标识机制。授权服务器会声明 authorization_response_iss_parameter_supported: true，并在成功的授权响应中包含 iss。客户端会将其与启动授权流程前发现的签发者进行比较。这可以防止来自某个签发者的授权响应被误认为来自另一个签发者。

还有一些不太显眼的变更，弥补了生产部署中的缺口。MCP 客户端现在会在授权请求和令牌请求中，将规范化服务器 URI 作为 RFC 8707 resource 发送。令牌必须针对该受众签发，也只能由该受众接受。Workers OAuth Provider 已为 Workers 上的 MCP 服务器实现了所有这些要求。只需像下面这样封装处理函数：

import { OAuthProvider } from "@cloudflare/workers-oauth-provider";

export default new OAuthProvider({
  apiRoute: "/mcp",
  apiHandler: mcpHandler,
  defaultHandler: authorizationHandler,
  authorizeEndpoint: "/authorize",
  tokenEndpoint: "/oauth/token",
  clientIdMetadataDocumentEnabled: true,
  resourceMetadata: {
    resource: "https://mcp.example.com/mcp",
    authorization_servers: ["https://mcp.example.com"],
    scopes_supported: ["mcp:read"],
  },
});

日渐成熟的标准需要生命周期机制

技术变更只是此次发布的一部分。MCP 2026-07-28 还引入了正式的功能生命周期。

功能分为 Active（活跃）、Deprecated（已弃用）或 Removed（已移除）三类。已弃用的功能必须至少保留 12 个月，之后才能移除。本次发布将 Roots、Sampling、Logging、Dynamic Client Registration 以及旧版 HTTP+SSE 传输标记为已弃用，但现有实现拥有明确的迁移窗口。

这项政策为团队提供了规划升级所需的最低时间保障，使其不必被迫应对突如其来的功能移除。同时，它也为核心协议的稳定留出了空间。

新想法可以通过新的扩展框架更快推进，而不必立即成为核心协议的一部分。MCP Apps 和 Enterprise-Managed Authorization 已经成为扩展，而 Tasks 也已迁移至扩展框架，为可靠的长时间运行工作提供了实现路径。实现者可以在需要时采用这些能力。

配备新 SDK 的新版 MCP

2025 年 11 月，我们在 Agents SDK 中引入了 createMcpHandler，它基于 MCP TypeScript SDK 中一种实验性的无状态模式。借助该模式，仅使用工具、提示词和资源的 MCP 服务器可以部署到 Cloudflare Worker，从而降低复杂性和成本，并简化部署。

我们很高兴看到 createMcpHandler 随此次发布正式进入官方 MCP TypeScript SDK！

2026 年初，我们还与 MCP 维护者合作，将 MCP TypeScript SDK 从 Node.js 重新构建到 Web Standards 之上，帮助改善其与 Bun、Deno 和 Cloudflare Workers 等其他 JavaScript 运行时的互操作性。我们为 TypeScript SDK 贡献了打包、运行时 shim 和拆分包能力，在缩小部署体积的同时，也让整个生态系统从中受益。

客户可以迁移到新规范，同时保持与旧版规范的向后兼容性。/mcp 端点既接受新协议，也接受来自 2025 Streamable HTTP 客户端的无状态请求，因此大多数客户端无需更改配置即可重新连接。

例如，今年 2 月，我们使用这种非官方的无状态模式和名字十分上口的 WebStandardsStreamableHTTPServerTransport，发布了覆盖整个 Cloudflare API 的 Code Mode MCP Server。此后，它已经扩展到每秒处理数千个请求，并完成了数十亿次工具调用。

下面是一个使用官方 SDK 和 Cloudflare Agents SDK 构建的最小服务器示例：

import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";
import { z } from "zod";

function createServer() {
  const server = new McpServer({
    name: "hello-server",
    version: "1.0.0",
  });

server.registerTool(
    "hello",
    {
      description: "Return a greeting",
      inputSchema: { name: z.string().optional() },
    },
    async ({ name }) => ({
      content: [
        {
          type: "text",
          text: `Hello, ${name ?? "World"}!`,
        },
      ],
    }),
  );

return server;
}

export default {
  fetch(request, env, ctx) {
    return createMcpHandler(createServer)(request, env, ctx);
  },
}

真正依赖旧版协议会话、服务器到客户端请求或独立流的服务器，需要采取更审慎的迁移方式。它们可以在现有有状态会话路由旁运行一个严格的无状态路由，逐步迁移功能，等待活跃会话自然结束，然后在弃用期内移除旧版路径。我们的 MCP SDK v2 迁移指南详细介绍了这一过程。对于 MCP 客户端，迁移过程甚至更简单：只需升级 agents 的版本，一切就能正常工作。

createMcpHandler API 最初诞生于 Agents SDK，并将继续保留在其中。我们也会继续封装上游处理程序，提供专注于 Worker 的接口。与较底层的 MCP TypeScript SDK 相比，该接口具有实用的默认配置和更丰富的交互模式。

下一代 MCP 已经投入生产

Sentry 联合创始人兼首席产品官 David Cramer 一直积极谈论 MCP 的潜力，以及其早期版本中有待改进之处。根据他的早期实际使用经验，最新的 MCP 规范兑现了这份潜力，同时也回应了最初的批评。

“我们基于 Cloudflare 的 SDK 构建了 Sentry 的 MCP。我们非常喜欢它，”Cramer 告诉我们，“我们甚至在 7-28 规范最终定稿前就将这个新版本投入了生产环境，而且生产系统没有崩溃。对此我们也非常满意。新规范清理了认证和工具方面的一堆乱象，这正是我想要的。只有当底层管道不再占据故事的全部时，智能体才真正开始变得有用。”

Linear 构建了一款快速、现代的问题跟踪和项目管理工具。他们采用了 MCP，让智能体能够以简单、安全的方式访问 Linear 数据。

“MCP 清楚地说明了开放标准为什么如此重要，”Linear 工程负责人 Tom Moor 表示，“最新一版规范有了显著改进，让 MCP 服务器的托管变得更简单、更可靠，同时还增加了亟需的功能。我仍然认为 MCP 的价值被严重低估了——我们基于这一标准构建一次服务器，它就能与用户想要使用的任何 AI 客户端协同工作。Linear 一贯的立场是，无论你在哪里需要 Linear 数据，都应该能够访问它；共享规范让这件事成为可能，而无需构建数百个集成。”

Anthropic 创建了 MCP，并将其捐赠给 Agentic AI Foundation。对于最初发起这一协议的团队来说，新规范既体现了 MCP 已经取得的进展，也体现了如今社区在推动其发展方面承担的更大责任。

“我们将 MCP 捐赠给 Agentic AI Foundation，是为了让它成为服务于整个生态系统的开放、厂商中立的基础设施。如今，MCP 已经成为智能体软件的基础。它是应用程序用于连接人们日常依赖的工具和数据的底层，并且这是该协议自发布以来最重大的进步。客户端只需投入极少的工程工作，就能获得显著的性能提升。

安全方面采用了保护互联网其他部分的同一套成熟标准。来自整个社区的维护者和贡献者，结合企业级规模下的真实生产经验，共同促成了这一切。我们迫不及待地想看到开发者基于 MCP 构建出怎样的产品。”MCP 联合创建者、首席维护者兼 Anthropic 技术团队成员 David Soria Parra 表示。

新的 MCP 规范现已在 Cloudflare 上同时面向客户端和服务器开放。你可以在 Cloudflare Worker 中运行无状态 MCP 服务器，使用 Workers OAuth Provider 保护它，并连接到 AI 智能体中的 MCP 客户端。当应用程序确实需要协调状态时，可以使用 Cloudflare Durable Objects；在用户迁移期间，还可以通过同一路由同时为新版和旧版无状态客户端提供服务。

安装最新的 Agents SDK 和 MCP TypeScript server SDK，按照迁移指南操作，或者从 createMcpHandler 文档开始。你也可以连接到 Cloudflare 的 MCP 服务器，它们已经支持新规范。

MCP 不再需要有状态基础设施，就能完成实用的交互式工作。服务器可以作为普通的 HTTP 工作负载运行在 Workers 上，靠近用户，并利用开发者在 Web 其他部分所使用的可扩展性、安全性和可观测性基础能力。