模型上下文协议（MCP）迎来史上最大更新：彻底走向无状态与安全重构
紫喵API服务 的 AI API 使用建议
紫喵API服务 面向需要 OpenAI 兼容接口、Claude/Gemini/GPT 多模型切换、包月额度管理和图像模型调用的用户。阅读本文后，可以结合本站的模型清单、独立使用文档和个人面板，把教程内容直接落到实际调用流程中。
引言
在人工智能代理（AI Agent）和代码助手快速发展的今天，如何让语言模型安全、高效地连接外部数据库、API和工具？由 Anthropic 于 2024 年底发起的 模型上下文协议（Model Context Protocol，简称 MCP） 给出了答案。
短短不到两年的时间，MCP 已经从一个单一厂商的开源构想，迅速成长为整个 AI 行业的连接标准。根据安全机构的统计，目前已有超过 10,000 个公共 MCP 服务器处于运行状态，SDK 的月下载量更是突破了 9700 万次。OpenAI、Google、Microsoft 和 AWS 等科技巨头均已将其深度集成至各自的 Agent 技术栈中。
然而，快速野蛮生长也带来了不可忽视的架构瓶颈与安全隐患。2026年7月28日，MCP 迎来了其历史上最大的一次规格重构（2026-07-28 规范）。这次更新不仅彻底将协议核心“无状态化”，更开启了为期 12 个月的旧版本废弃倒计时。本文将深度解析此次 MCP 更新的核心变化、对开发者带来的破坏性影响，以及安全层面的全面洗牌。
一、彻底摆脱“状态”的枷锁：MCP 走向 stateless
在早期的版本中，MCP 的设计是**有状态（Stateful）**的。当客户端连接到 MCP 服务器时，必须通过一个 initialize（初始化）握手建立连接，并获得一个 Mcp-Session-Id（会话ID）。此后的所有交互都需要携带这个会话ID来确保通信在同一个会话上下文中。
这在开发者本地电脑（例如通过 stdio 连接 Claude Desktop）运行时非常完美。然而，当企业试图将 MCP 部署到云端以服务海量用户时，问题接踵而至。
图：当 MCP 服务器走向云端多节点部署时，传统的会话机制对负载均衡带来了极大的挑战。
在云原生环境中，这意味着成千上万个容器实例必须共享会话状态，或者依赖极为复杂的粘性会话（Sticky Sessions）路由。
2026-07-28 规格的核心解法：
- 取消握手与会话 ID：彻底移除
initialize/initialized握手步骤以及Mcp-Session-Id头信息。 - 请求自包含：通过引入全新的
Mcp-Method和Mcp-Name请求头，客户端每次发送的请求都携带其版本、标识及能力声明。 - 无缝水平扩展：任何请求都可以打到服务器的任意实例上。服务器从此可以使用最基础的轮询负载均衡器（Round-robin Load Balancer）进行扩容，无需同步会话状态，极大地降低了云端托管的复杂度和基建成本。
二、痛并快乐着：本次更新破坏了什么？
无状态化并非免费的午餐，它对现有的自研 MCP 生态带来了巨大的破坏性影响。如果你的团队目前正运行着基于旧版（如 2025-11-25 规范）构建的生产级 MCP 服务，以下几点需要特别注意：
1. 会话级状态失效
任何依赖会话 ID 缓存数据、上下文或流式进度的服务器代码都将失效。开发者必须将这些状态转化为显式的句柄（Handles），并作为工具参数（Tool Arguments）在请求之间传递——即让状态在网络上传输，而非保存在服务器中。
2. 任务（Tasks）机制全面改版
Tasks 任务管理已从协议核心移出，并重构为独立扩展。
- 以前通过会话绑定的任务对象，现在改由服务器颁发任务句柄（Task Handle）。
- 客户端通过
tasks/get、tasks/update和tasks/cancel驱动异步任务。 - 由于失去了会话边界，
tasks/list（列出所有任务）功能已被彻底删除。
3. 三大核心功能的废弃（12个月过渡期）
新版本规范建立了规范的生命周期管理（Active -> Deprecated -> Removed），以下功能已被标记为“Deprecated（废弃）”，将在最少 12 个月后彻底移除：
- Roots（根目录映射）：不再由客户端告知服务器哪些本地路径可用，转为通过显式的工具参数或资源 URI（Resource URIs）传递。
- Sampling（客户端采样）：废除服务器请求客户端模型生成补全的混乱设定，建议服务器端直接调用大模型 API。
- Logging（协议日志）：移除冗余的协议级日志，推荐开发者直接使用
stderr、stdio或标准的 OpenTelemetry 链路追踪。
三、安全洗牌：从“默认信任”到 OAuth 2.1 规范化
随着 MCP 步入企业级应用，其安全隐患也暴露无遗。安全机构 Practical DevSecOps 的扫描指出，多达 30% 至 82% 的公开 MCP 服务器存在安全漏洞。由于一个被攻破的 MCP 服务器可能会被用作跳板，进而窃取 AI Agent 有权访问的其他内部工具，NSA 和 CISA 甚至在 2026 年 6 月联合发布了 MCP 安全设计指南。
为了应对这一危机，2026-07-28 规范重点加强了授权机制。通过六项规格增强提案（SEPs），MCP 正式将服务器定位为 OAuth 2.1 资源服务器：
- Protected Resource Metadata (RFC 9728)：要求服务器暴露
.well-known/oauth-protected-resource端点，以便客户端能够自动发现正确的授权服务器，防范配置劫持。 - Resource Indicators (RFC 8707)：显式声明令牌（Token）的适用范围，防止恶意服务器重用其他服务器的令牌（“混淆代理”攻击）。
- Issuer Verification (RFC 9207)：强制客户端验证授权响应的发行方，杜绝多授权服务环境下的“混淆”攻击。
此外，新版本推出了 MCP Apps (SEP-1865) 作为首个官方扩展。它允许服务器向客户端输出基于沙箱 iframe 的 HTML 交互界面。为了防止 stored-XSS（存储型跨站脚本）攻击，所有的 UI 交互被强制要求与底层工具调用共享同一条 JSON-RPC 信道及 OAuth 2.1 授权路径。
四、开发者迁移指南与应对策略
随着 2026-07-28 规范在 7 月 28 日正式定稿，为期 12 个月的兼容窗口正式开启。在此期间，旧版客户端与新版服务器（或反之）的直接通信可能会受阻。
以下是针对不同角色的应对策略：
| 改造项 | 影响范围 | 建议行动 | 紧迫度 |
|---|---|---|---|
| 无状态化改造 | 服务端/客户端 | 移除 Mcp-Session-Id 依赖，将业务状态改造为通过工具参数显式传递。 |
🚨 极高（割接前需完成） |
| 请求头适配 | 客户端/集成商 | 确保客户端发出的每个请求都带上 Mcp-Method 和 Mcp-Name 请求头。 |
🚨 极高 |
| OAuth 2.1 升级 | 运维与服务端 | 结束无授权运行状态，配置 .well-known 元数据端点。 |
⚠️ 高 |
| 废弃项迁移 | 服务端开发 | 逐步将 Roots、Sampling 和 Logging 替换为显式参数、直连 LLM API 和 OpenTelemetry。 |
📅 中（12个月内完成） |
总结：走向成熟的 AI 基础设施
从零散的“玩具协议”到由 Linux Foundation 旗下基金会托管、各大巨头鼎力支持的无状态网络标准，MCP 在过去 20 个月里完成了惊人的蜕变。
2026-07-28 规格的发布，标志着 MCP 开始正视企业在云端大规模部署时的成本与安全痛点。虽然迁移的过程充满了接口重构的“阵痛”，但无状态化带来的低成本扩展性，以及 OAuth 2.1 带来的安全防线，都将成为下一代 AI Agent 生态坚实的基石。建议工程团队在这一周内完成资产盘点，尽早规划迁移路径。