MCP 2026-07-28 详解：无状态服务器、MCP 应用、任务、企业认证与新代理基础设施

引言

模型上下文协议（Model Context Protocol）迎来了自发布以来最大规模的一次架构修订。

MCP最初被引入时，是作为一种让AI应用将模型与工具、API、数据源、文件及外部系统连接起来的通用方式。在不到两年的时间里，它已从一个由Anthropic主导的集成项目，发展成为一个更广泛的开源协议，拥有自己的治理流程、SDK生态系统、工作组、扩展以及横跨众多AI产品的实现。

2026-07-28修订版聚焦于MCP离开开发者笔记本电脑、进入大型生产环境时出现的问题。

最主要的变更可以概括为：

MCP正在协议层转变为无状态。

这一变更从新的线上格式中移除了协议级的会话和初始化握手，使远程MCP服务器能够更轻松地部署在普通负载均衡器、无服务器基础设施、边缘计算节点和水平扩展架构之后。

但无状态传输只是本次更新的一部分。

该修订版还正式确立了一个扩展框架，重塑了长时间运行的任务，引入了多轮往返请求，增加了可路由的HTTP头和缓存提示，强化了授权机制，扩展了JSON Schema支持，并制定了一项正式的功能弃用策略。

在协议本身之外，MCP生态系统还在增加交互式应用、企业级托管授权、私有网络隧道以及更强大的开发者工具。

正是在这一点上，MCP开始不再像一个便捷的智能体连接器，而更像生产级基础设施。

MCP采用速度迅猛增长

源报告强调了MCP使用量的增长速度。

根据源文章引用的Claude开发者发布公告：

MCP SDK月下载量已超过4亿次。
年度内SDK月使用量大约增长了四倍。
TypeScript和Python SDK的累计下载量均跨越了非常大的里程碑。
已有数百个MCP集成通过Claude的连接器生态可用。

这些7月底的具体数据属于发布公告中的指标，而非核心规范中发布的数字。

Anthropic早前的一份官方公告提供了一个有用的参照点：2026年1月，Anthropic表示MCP已达到每月1亿次下载。

这意味着在7月协议重新设计之前，生态系统已经相当庞大。

因此，本次更新的意义不在于MCP试图在未来某天变得有用，而在于维护者正在围绕已在生产规模上显现的问题重新设计协议。

这些问题包括：

粘性会话。
共享会话存储。
水平扩展。
无服务器部署。
网关路由。
认证复杂性。
长时间运行的智能体操作。
交互式界面。
向后兼容性。
协议演进。

为什么之前的有状态设计成为扩展难题

早期的远程MCP部署可以维持协议级别的会话状态。

客户端通常会初始化一个

建立连接并获得了一个会话标识符。后续请求随后需要保持与该会话的关联。

一个简化的 2025-11-25 流程如下所示：

POST /mcp HTTP/1.1
Content-Type: application/json

{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}

初始化之后，后续的调用可以携带：

Mcp-Session-Id: 1868a90c-3a3f-4f5b

这种方法对许多应用来说是可行的，但它带来了一些基础设施层面的要求。

生产环境部署可能需要：

粘性负载均衡器路由。
共享会话存储。
会话复制。
会话过期逻辑。
故障转移处理。
感知连接的可观测性。
对服务器重启的特殊处理。

MCP 维护者得出的结论是，这些要求与协议本身的耦合过于紧密。

新修订版本移除了这一假设。

MCP 现已在协议层面实现无状态

在 2026-07-28 协议设计中，每个请求都携带服务器解析请求所需的信息。

官方示例如下：

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"
},
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
}

不再有协议级的 Mcp-Session-Id。

不再有强制性的连接会话将请求绑定到单个服务器实例。

任何兼容的服务器实例都可以处理该请求。

图片展示的是MCP 2026-07-28协议设计中的一条请求示例。请求方法为POST，目标路径为/mcp，协议版本为HTTP/1.1，MCP协议版本为2026-07-28，Mcp-Method为tools/call，Mcp-Name为search。请求体内容为JSON格式，包含jsonrpc、id、method、params和_meta等字段，params中name为search，arguments包含q为otters，_meta中包含客户端信息。该图片与上下文紧密相关，直观呈现了新协议设计中请求的结构，体现了MCP协议在协议层去状态化的特点。

这对于云部署来说是一个重大的改进。

远程 MCP 服务器现在可以适配传统的架构：

客户端
↓
API 网关 / 负载均衡器
↓
MCP 服务器实例 A
MCP 服务器实例 B
MCP 服务器实例 C

请求不再因为之前某个请求落在某个实例上，就必须回到该实例。

新线上格式中移除了 `initialize` 握手

无状态重新设计还从 2026-07-28 线上格式中移除了旧的 initialize / initialized 生命周期。

之前初始化期间只传输一次的信息，现在通过元数据随请求一同传输。

当客户端希望提前发现服务器能力时，可以使用新方法 server/discover。

这并不意味着旧客户端会立即停止工作。

当前的 SDK 文档包含对早期协议版本的兼容性行为说明。例如，C# SDK 可以支持新的无状态

在继续与使用 2025-11-25 协议的客户端协商旧版基于会话的行为的同时，路径向前推进。

重要的迁移区别在于：

2026-07-28：
无状态请求模型，无协议会话。

旧版本：
初始化握手和会话感知行为可能仍受支持
通过版本协商和 SDK 兼容路径。

开发者应测试集成的两端，而不是只升级服务器并假设所有客户端都能理解新版本。

无状态协议并不意味着无状态应用

最容易犯的错误之一是将此变更理解为：

MCP 应用不再允许保持状态。

这不是规范的含义。

协议层是无状态的。

应用仍然可以在状态有用的地方维护状态。

假设一个购物工具创建了一个购物篮。

服务器可以返回：

{
"basket_id": "basket_8472"
}

模型可以在后续调用中传入该值：

{
"basket_id": "basket_8472",
"item_id": "item_123"
}

这使应用状态作为普通工具数据可见，而不是将其隐藏在传输元数据中。

同样的模式可以用于浏览器会话、报表任务、购物车、工作流 ID、部署 ID、文档编辑状态和长时间运行的分析任务。

为什么显式句柄可能更好

可见的句柄有几个优势。

模型可以：

在相关工具之间传递它。
推理哪个句柄属于哪个任务。
将其包含在日志中。
在重试后恢复它。
将其交给另一个工作流步骤。

服务器可以：

验证句柄。
使其过期。
将其绑定到用户或租户。
拒绝过期状态。
将实际状态存储在数据库中。

因此，无状态 MCP 将状态管理从传输层转移到显式的应用设计中。

无服务器和水平扩展变得容易得多

源文章强调了无服务器部署，这是新协议最实际的成果之一。

当请求是自包含的，MCP 服务器可以更容易地在以下环境中运行：

AWS Lambda。
Cloudflare Workers。
Vercel。
其他无服务器函数。
容器自动扩缩容平台。
普通无状态 Kubernetes 部署。
边缘环境。

这不意味着每个 MCP 工作负载都能自动在每个无服务器平台上运行。

开发者仍然需要考虑执行时长、流式支持、冷启动、持久化应用状态、密钥、出站网络、长时间运行的任务、文件系统需求和数据库连接。

协议不再强制要求会话架构，这消除了一个主要障碍。

轮询负载均衡成为自然的默认选择

水平扩展的服务器不再需要在协议层将单个客户端绑定到单个实例。

这意味着简单的轮询负载均衡器可以在多个实例之间分发请求。

这改善了：

自动扩缩容。
实例替换。
故障恢复。
滚动部署。
多区域路由。
基础设施简单性。

这也改变了服务器作者在考虑隐藏的内存中状态时的思维方式

状态。

如果某个工具能正常工作，仅仅是因为之前的请求在某个进程内填充了一个字典，那么当下一次请求到达另一个实例时，该实现可能会失败。

一个好的迁移测试是：

如果每次工具调用都落在不同的服务器进程上，同一工作流是否还能继续？

如果答案是否定的，说明服务器包含了一个应用程序状态依赖，这个依赖需要变得显式，或者迁移到持久的共享存储中。

多轮往返请求取代持久的调用中连接

无状态设计仍然需要一种方式让服务器向客户端请求更多信息。

示例包括用户确认、附加参数、引导式提问、模型生成的响应，或与工作区相关的值。

新机制是多轮往返请求（Multi Round-Trip Requests，简称 MRTR）。

工具可以返回一个不完整的结果：

{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "删除3个文件？",
"schema": {
"type": "boolean"
}
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

客户端收集所需的答案。

然后，它使用 inputResponses 和返回的 requestState 重复原始调用。

由于状态在请求流中携带，另一个服务器实例可以处理下一轮。

这比要求长期存在的服务器到客户端连接更符合无状态架构。

基于头部的路由使 MCP 对网关更友好

新的 Streamable HTTP 格式直接将操作元数据添加到 HTTP 头部。

重要的头部包括：

Mcp-Method: tools/call
Mcp-Name: search

这对生产基础设施很重要。

API 网关、Web 应用防火墙、速率限制器或可观测性层无需解析 JSON 主体即可识别操作。

可能的用途包括：

将所有搜索工具路由到同一个池。
对破坏性操作应用更严格的限制。
按工具名称记录延迟。
按方法计量使用量。
在网关处阻止不允许的工具。
创建独立的可靠性策略。

协议规范还要求头部与 JSON-RPC 主体之间保持一致。

服务器应拒绝二者不一致的请求。

列表和读取结果支持缓存感知

MCP 客户端经常请求相对稳定的元数据，例如工具列表、资源、提示词列表和资源读取。

反复获取相同的信息会浪费网络流量和服务器容量。

新修订引入了缓存元数据，例如：

ttlMs
cacheScope

这些值让服务器可以指示结果应保持新鲜的时间长度，以及结果是否可以跨用户或上下文共享。

这与普通的 HTTP 缓存的原理类似。

对于工具密集型的代理，这可以减少重复的元数据加载。

分布式追踪已标准化

该修订还记录了 W3C Trace Context 传播。

诸如：

traceparent
tracestate
baggage

之类的键可以通过 MCP 元数据传播。

这使得单个分布式追踪可以跨越以下链路跟踪工作：

宿主应用程序
→ MCP 客户端
→ MCP 网关
→ MCP 服务器
→ 下游 API
→ 数据库

对于企业级部署，这一点很重要，因为当团队能够看到延迟实际发生在哪里时，慢速工具调用会更容易调试。

扩展成为一级协议特性

该协议也在改变可选功能的演进方式。

当前框架赋予扩展：

反向DNS标识符。
能力协商。
独立版本控制。
专用代码仓库。
委派维护者。
SEP流程中的正式扩展轨道。

这很重要，因为核心协议不需要吸收每一个新想法。

一个功能可以先作为扩展成长成熟，经过验证的能力随后可以更接近核心。

MCP Apps：对话中的交互式UI

最显眼的MCP扩展之一是MCP Apps。

MCP工具传统上返回文本、结构化JSON或资源。

有些任务需要界面。

示例包括仪表板、图表、地图、表单、任务看板、配置面板、设计画布和视频播放器。

MCP Apps允许服务器声明一个UI资源，宿主在沙箱化的iframe中渲染该资源。

图片展示了MCP Apps的交互流程。用户向Agent发送指令“show me analytics”，Agent在聊天中渲染互动应用。应用通过工具调用与MCP Server交互，Server返回工具输入/结果，结果推送到应用。用户与应用交互，应用请求工具调用，Server返回新鲜数据，应用更新至新数据。此图与上下文紧密相关，直观呈现了MCP Apps从用户指令到应用更新的完整交互过程。

简化的流程如下：

工具声明一个UI资源。
模型调用该工具。
宿主在沙箱中加载UI。
工具数据被传入界面。
用户与应用交互。
应用可以通过宿主请求额外的工具调用。
宿主对这些操作保持权限和审计控制。

MCP Apps已被多个兼容宿主支持，包括Claude和其他支持MCP的开发产品。

MCP Apps基本安装

官方扩展包可以通过以下命令安装：

npm install -S @modelcontextprotocol/ext-apps

官方示例代码仓库可以在本地运行：

git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start

这些命令来自官方MCP Apps文档，可能随扩展的演进而变化。

Tasks：不阻塞连接的长时运行工作

Agent工具越来越多地启动无法在一次普通HTTP请求期间完成的工作。

示例包括CI流水线、大型数据处理任务、云部署、长时间研究任务、视频渲染和人工审批流程。

MCP Tasks扩展允许服务器返回一个持久的任务句柄，而不是阻塞等待操作完成。

图片展示了MCP Tasks扩展的流程图。Client端发起tools/call请求，Server返回CreateTaskResult。Client循环调用tasks/get，Server返回Task状态。若Server需用户输入，Client调用tasks/update提交输入，Server返回ack。再次循环调用tasks/get，Server返回Task状态。最终，Server返回Task完成状态及结果，Client循环调用tasks/get。该图与文档中介绍MCP Tasks扩展允许服务器返回持久任务句柄，而非阻塞操作完成，以及任务状态变化等内容相呼应。

该

官方扩展定义的方法包括：

tasks/get
tasks/update
tasks/cancel

任务可以在以下状态之间流转：

working
input_required
completed
cancelled
failed

客户端可以轮询 tasks/get。

如果服务器需要用户输入，任务可以进入 input_required 状态。

客户端可以通过 tasks/update 提交输入。

这种设计在断开连接的情况下也能正常工作，并且不需要一条长期保持的连接。

重要兼容性说明

任务功能在 2025-11-25 核心规范中曾作为实验性功能存在。

新的 Tasks 扩展并非旧 API 的简单重命名副本。

官方 SDK 文档警告说，较新的 Tasks 扩展与早期实验性实现在线上协议上不兼容。

使用旧 Tasks 功能的应用程序应进行迁移，而不能指望自动兼容。

企业托管授权

企业部署面临的授权问题与消费级集成不同。

一家公司可能有数千名员工和数十个已批准的 MCP 服务器。

它不希望每位员工都独立授权每个连接器。

企业托管授权扩展允许组织通过身份提供商集中管理访问控制。

受支持的企业 IdP 模式可能涉及 Microsoft Entra ID、Okta 以及企业 SSO 系统等产品。

组织可以决定哪些员工可以访问哪些 MCP 服务器，以及何时应撤销访问权限。

员工使用其企业身份进行身份验证，而无需为每个 MCP 服务器单独完成 OAuth 审批。

图片展示的是MCP（Microsoft Copilot for Business）界面中“Connectors”下的设置弹窗。弹窗标题为“Enable for organization”，下方列出了多个应用，如Asana、Atlassian、Canva、Figma、Granola等，每个应用右侧都有蓝色的开关按钮，当前均处于开启状态。图片与上下文紧密相关，上下文介绍了MCP的Enterprise-Managed Authorization扩展，允许组织通过身份提供商集中管理访问控制，此图直观呈现了在MCP中启用组织内应用连接器的操作界面，与文档中介绍的组织身份管理相关。

官方 MCP 文档将企业托管授权描述为一个扩展，而非默认对每个客户端都启用的功能。

客户端和组织的身份基础设施都需要支持该扩展。

授权机制正在更广泛地得到加固

核心授权工作还获得了多项安全改进。

RFC 9207 颁发者验证

授权响应可以包含 iss 颁发者参数。

客户端在兑换授权代码之前验证颁发者。

免費版 · 使用 We0 AI

幾分鐘搭建展示站並增長獲客

輸入一句想法，We0 AI 即可生成展示站、頁面與 CMS。發佈上線後並幫你獲取客戶和流量。

用戶註冊贈送一次完整項目生成

適合先體驗一次完整生成流程，快速看到專案初稿。

未命名-1

佈局

填充

圓角

生成中

这有助于防范授权服务器混淆攻击。

客户端凭据与其颁发者保持绑定

注册的客户端凭据不应在无关的授权服务器之间重复使用。

当资源转移到其他颁发者时，客户端应针对该颁发者进行适当的注册。

改进的桌面和 CLI 注册

该修订版澄清了动态客户端注册期间 application_type 的行为。

这有助于避免授权服务器将原生 CLI 或桌面应用程序视为 Web 客户端并拒绝本地重定向 URI 的情况。

CIMD 是

新客户端注册指引

MCP授权项目一直在向客户端ID元数据文档（Client ID Metadata Documents，简称CIMD）方向推进，用于新实现，同时在需要的地方保留DCR兼容性。

实际建议是遵循当前的授权文档，而不是根据较旧的MCP教程来实现客户端注册。

工具的完整JSON Schema 2020-12

工具模式也变得更加富有表现力。

inputSchema和outputSchema支持完整的JSON Schema 2020-12特性。

输入模式可以使用：

oneOf
anyOf
allOf
$ref
$defs
条件语句

输出模式不再局限于单一狭窄的对象形态。

structuredContent可以表示模式支持的任何JSON值。

这使得当API具有联合类型、条件字段、嵌套可复用定义、多种输出形态、数组或标量结果时，MCP工具能够更准确地描述。

Roots、Sampling和Logging已弃用

三个较旧的核心能力已被正式弃用：

功能	推荐方向
Roots	工具参数、资源URI或服务器配置
Sampling	直接集成LLM提供商
Logging	stdio使用`stderr`；结构化可观测性使用OpenTelemetry

弃用并不意味着立即移除。

新的生命周期策略规定，弃用功能在被允许移除之前至少要有十二个月的过渡期。

当前SDK可能继续支持这些能力以保持兼容性。

正式弃用策略改变了MCP升级风险

无状态重新设计包含破坏性变更。

维护者表示，他们不希望这种级别的中断成为常态。

新的功能生命周期定义了以下阶段：

活动（Active）
已弃用（Deprecated）
已移除（Removed）

已弃用的功能在移除前会获得最低支持期限。

扩展也可以与核心分开独立演进。

这为团队提供了更可预测的迁移规划。

MCP隧道解决不同的企业问题

协议修订使得公共远程MCP服务器更易于扩展。

企业通常面临相反的问题：它们根本不想让服务器公开。

Anthropic的MCP隧道功能针对Claude托管代理和支持的Claude平台工作流解决了这一使用场景。

一个轻量级网关运行在企业网络内部，并建立出站连接。

Anthropic将此模式描述为：

无公共MCP端点。
无入站防火墙规则。
无需公共IP。
端到端加密流量。

内部数据库、ERP系统、私有API、知识库和工单系统可以保留在企业网络边界之内。

MCP隧道仍然是Claude的产品功能，而非核心MCP协议要求。

Anthropic目前将其描述为研究预览。

MCP应用与隧道不应混淆

这两个功能都改善了生产环境中的MCP，但它们解决的是不同的问题。

功能	解决的问题
MCP应用	MCP主机内的丰富交互界面
任务	持久化的长时间运行工具操作
企业托管授权	集中式公司

服务器可以使用这些功能中的一个、多个或全部。

现有 MCP 服务器开发者需要改变什么？

如果服务器已经能与旧版 MCP 客户端配合使用，开发者不必立即重写所有内容。

他们应执行结构化迁移。

步骤 1：盘点隐藏的会话依赖

搜索依赖以下内容的代码：

Mcp-Session-Id
内存中的按会话字典
粘性路由
连接本地客户端状态
仅初始化能力存储
服务器实例亲和性

判断每个依赖是协议状态、应用状态、认证状态还是临时执行状态。

将应用状态移至显式句柄或适当的持久化存储中。

步骤 2：测试无状态请求处理

使用支持 2026-07-28 修订版的 SDK 版本。

然后使用多个服务器实例进行测试。

一种有用的测试配置是：

客户端
↓
轮询负载均衡器
↓
服务器 A / 服务器 B / 服务器 C

发送一个多步骤工作流，确认连续请求可以到达不同实例而不会中断任务。

步骤 3：添加显式状态句柄

对于需要状态的工作流，返回一个稳定标识符：

{
"job_id": "job_7f18c9"
}

要求后续调用包含该标识符：

{
"job_id": "job_7f18c9",
"action": "continue"
}

在服务端验证每个句柄。

良好的句柄应具有强熵、租户绑定、授权检查、过期时间、撤销机制和清晰的错误处理。

步骤 4：更新网关规则

如果使用 Streamable HTTP，请利用以下标头：

Mcp-Method
Mcp-Name

添加路由、速率限制、指标、WAF 策略和访问日志。

步骤 5：添加缓存支持

对适当的列表和读取响应，遵循或生成：

ttlMs
cacheScope

不要跨用户共享特定于用户数据的敏感缓存内容。

步骤 6：迁移旧任务

如果应用程序使用了实验性的 2025-11-25 Tasks API，请将其更新为扩展生命周期。

测试：

tasks/get
tasks/update
tasks/cancel

以及 input_required 状态。

步骤 7：审查弃用功能

搜索 Roots、Sampling 和 MCP Logging。

规划向显式工具参数或资源 URI、直接模型提供商调用以及 stderr 或 OpenTelemetry 的迁移。

步骤 8：重新测试授权

验证签发者验证、重定向 URI、客户端注册、刷新令牌、作用域处理以及身份提供者兼容性。

企业部署应评估 EMA 是否适用。

步骤 9：测试旧客户端

向后兼容是生态系统问题，而不仅仅是服务器问题。

维护一个测试矩阵：

客户端	协议修订版	结果
当前客户端	`2026-07-28`	预期无状态路径
旧客户端	`2025-11-25`	兼容性路径
不支持的客户端	旧版本/未知	明确的协商失败

不要静默假设每个

客户端同时进行升级。

第10步：在生产环境前添加可观测性

至少需要测量：

请求数量。
工具名称。
延迟。
错误率。
任务持续时间。
需要输入的频率。
缓存命中率。
认证失败次数。
下游 API 延迟。
追踪 ID。

无状态系统更容易扩展，但分布式系统仍然需要良好的可观测性。

示例：迁移前后对比

迁移前

服务器将报告对象存储在内存中：

sessions[session_id]["report"] = report

下一个工具调用期望到达同一进程。

迁移后

服务器存储持久化状态：

report_id = save_report(report)
return {"report_id": report_id}

下一个工具接收：

{
"report_id": "report_123"
}

任何服务器实例都可以加载该报告。

重要的变化在于架构层面：

隐藏的传输会话状态
→ 显式的应用状态

无状态 MCP 是否意味着更低成本？

有可能，但并非自动实现。

无状态部署可以降低基础设施的复杂性：

无需共享的 MCP 会话存储。
减少粘性路由需求。
更容易实现自动扩展。
更容易进行无服务器部署。
简化故障转移。

缓存还可以减少重复的元数据调用。

然而，应用状态仍然有成本。

如果工作流需要持久化状态，开发者可能仍然需要 Redis、SQL 数据库、对象存储、任务队列或工作流引擎。

新的设计让开发者可以选择存储架构，而不是由协议会话强制指定一种。

MCP 正在成为“AI 领域的 HTTP”吗？

源文章使用了这个类比。

这个类比很有用，但不应该从字面上理解。

HTTP 是基础性的 Web 传输标准，几乎用于所有互联网系统。

MCP 是一种专门化协议，用于将 AI 客户端和代理连接到工具、资源、提示词、接口和外部服务。

这个类比所捕捉到的是发展方向：

一个标准接口。
众多独立的服务器。
众多兼容的客户端。
共享的约定。
能够通用地路由和观测请求的基础设施。

2026-07-28 的重新设计强化了这一类比，因为 MCP 流量现在更自然地适配传统的无状态 HTTP 基础设施。

MCP 是否能达到类似 HTTP 的普及程度仍然是一个未解的问题。

生态系统比 Claude 更广泛

MCP 起源于 Anthropic，但现在作为一个更广泛的开源协议项目进行治理。

该生态系统包括独立维护者、工作组、规范增强提案、多种语言的 SDK、MCP 应用、任务、企业授权扩展、注册表，以及多个 AI 产品中的实现。

例如，MCP 应用是与 MCP 社区的贡献者以及 Anthropic、OpenAI 和 MCP-UI 的参与者共同开发的。

这一点很重要，因为当客户端和服务器都可以不依赖单一供应商来实现协议时，协议的价值会更大。

当前 SDK 格局

官方 MCP 项目维护或认可多种语言的 SDK 实现。

主要仓库包括 TypeScript、Python、Go、C# 以及其他生态系统的 SDK。

2026 年 6 月

候选发布公告特别强调了四个一级 SDK 的测试版支持：

TypeScript。
Python。
Go。
C#。

到 7 月下旬，当前的 SDK 文档已包含 2026-07-28 的行为。

由于 SDK 的采用是独立进行的，请始终查看您所使用的确切语言和版本的发布说明。

更安全的迁移策略

对于生产系统，避免“切换日”式迁移。

更安全的过程是：

升级开发环境。
运行一致性测试。
测试 2026-07-28 客户端。
测试旧版客户端。
在预发布环境中启用无状态部署。
添加多个服务器实例。
强制请求跨实例分发。
测试身份验证。
测试长时间运行的任务。
测试应用程序状态句柄。
监控延迟和错误。
逐步推出。

这一点尤其重要，因为新修订版有意更改了核心生命周期行为。

不应假设的内容

不要假设每台服务器都自动无服务器化

该协议更自然地支持无服务器部署。

您的应用程序可能仍需要数据库、持久化任务执行器、文件存储或较长的执行时间。

不要假设所有状态都会消失

只有协议级会话状态会从新的线上模型中移除。

应用程序状态仍然是应用程序自身的问题。

不要假设 MCP 应用程序能在每个客户端中运行

扩展是协商确定的，主机的支持情况各不相同。

不要假设任务向后兼容

当前的 Tasks 扩展与早期的实验性实现不同。

不要假设弃用意味着失效

Roots、Sampling 和 Logging 在弃用期内仍然可用。

不要假设所有客户端已支持 `2026-07-28`

SDK 和产品的采用进度各不相同。

不要假设“开放协议”意味着“无需安全工作”

MCP 可以执行强大的工具。

授权、用户同意、沙箱化、工具设计、机密管理和审计仍然至关重要。

常见问题

什么是 MCP 2026-07-28？

MCP 2026-07-28 是自推出以来模型上下文协议最大的一次架构修订。其主要变化包括无状态协议核心、移除新线上格式的会话握手、一级扩展、MCP 应用程序、重新设计的 Tasks、MRTR、更强的授权、缓存元数据以及正式的弃用策略。

MCP 现在完全无状态了吗？

2026-07-28 协议层设计为无状态。应用程序仍然可以通过显式句柄、数据库、工作流系统或其他持久化存储来保持状态。

`Mcp-Session-Id` 发生了什么变化？

2026-07-28 线上格式移除了协议级的 Mcp-Session-Id 机制。当前 SDK 在协商旧协议修订版时可能仍支持基于会话的行为以实现向后兼容。

我可以在 AWS Lambda 或 Cloudflare Workers 上部署 MCP 服务器吗？

无状态协议使无服务器和边缘部署变得更加容易，因为请求不再需要协议级会话亲和性。您的服务器仍然需要满足运行时的执行、网络、存储和持续时间限制。

什么是 MCP 应用程序？

MCP 应用程序是一个官方扩展

使工具能够在兼容的 MCP 主机中返回交互式界面，如仪表盘、表单、图表及其他 HTML 体验。该界面在沙箱化的 iframe 中运行，并通过 MCP 主机进行通信。

什么是 MCP 任务？

任务功能允许服务器为长时间运行的工作返回持久的异步任务句柄。客户端可借助 tasks/get 轮询状态，通过 tasks/update 提供所需输入，或使用 tasks/cancel 取消操作。

什么是企业托管授权？

企业托管授权是 MCP 的一个扩展，通过组织的身份提供商实现集中式访问控制。它允许 IT 管理员依据企业身份策略管理 MCP 服务器的访问，而无需每个用户单独授权每台服务器。

我必须立即从旧版 MCP 迁移吗？

未必。SDK 可通过版本协商支持较旧协议修订版，已弃用的功能会获得明确的支持窗口。生产团队仍应开始测试，因为无状态设计改变了围绕会话、长时间运行操作和基础设施的假设。

摘要

MCP 2026-07-28 修订版将协议推向大型 Web 系统中已普遍采用的基础设施模式。请求变得自包含，协议级会话从新的线上格式中消失，网关路由变得更加容易，普通的水平扩展不再需要粘性 MCP 会话。

与此同时，生态系统也在向上发展。MCP 应用增加了交互式 UI，任务支持持久化异步工作，企业托管授权集中了企业访问权限，MCP 隧道为 Claude 平台用户提供了访问内部私有服务器的路径。

迁移并非简单地"删除会话 ID"。团队需要识别隐藏的状态依赖，将应用状态迁移到显式句柄或持久化存储中，测试 MRTR 和任务，更新授权，保持与旧客户端的兼容性，并添加适当的可观测性。

最重要的变化是架构层面的：MCP 正从面向连接的智能体集成模式，转向无状态、可扩展的协议，从而更自然地适配现代云基础设施。