MCP的发展：制作团队在新规范下需做好哪些准备
2026-07-28版本的任务上下文协议修订如何改变扩展性、任务处理、授权机制及缓存功能，以及如何分阶段安全地迁移现有服务器。
来源: **MCP Grows Up: Six Changes Production Teams Need to Plan For**
一次远超版本更新的重大修订
根据该项目的发布公告，Model Context Protocol在2026年7月28日发布以来迎来了最大规模的修订。此次更新取消了协议会话机制，规范了扩展功能，增加了持久异步处理能力，加强了授权管理，并为实现者提供了明确的废弃策略。候选版本自5月21日起就已冻结，这为SDK维护者、客户端开发者和服务器运营商提供了大约十周的时间来测试这些新设计。
综合来看，最终完成的文档实现了无状态核心架构、多轮请求处理、基于标题的路由机制、可缓存的结果查询与列表功能、扩展框架、任务管理、MCP应用支持、更严格的授权机制，以及一套可靠的特性逐步废弃流程。
“无状态MCP”听起来是个不错的标题，但实际上变更内容远不止于此。还有几项重要的变动隐藏在背后。结果对象新增了resultType字段，HTTP GET流已被移除。subscriptions/listen取代了旧式的订阅方式。通过Last-Event-ID，SSE流不再支持断点续传。列表和资源结果必须包含缓存提示信息。工具架构可以使用完整的JSON Schema 2020-12规范。最后，当资源缺失时，现在会返回标准的JSON-RPC错误码-32602，而之前是-32002。
如果认为这只是“升级依赖后重新部署”那么简单，那就大错特错了。这实际上是一次架构层面的迁移。
1. 无状态协议并不等同于应用无状态
早期的版本通过 initialize/initialized 的握手流程来建立上下文。对于远程 HTTP 服务器，服务器还会提供一个 Mcp-Session-Id，客户端在后续请求中会重复发送该标识。这样就能将客户端与某个服务器会话关联起来，而在实际部署中，负载均衡器通常会采用粘性路由机制，或搭配共享会话存储，或是同时使用这两种方式。
在 2026-07-28 版本中，这种握手流程以及协议会话都将消失。每个请求都会在 _meta 字段中包含其协议版本、客户端功能以及可选的客户端身份信息。服务器必须实现 server/discover 功能，不过客户端无需在每次操作前都调用它。客户端可以选择直接发送自己偏好的协议版本，如果收到 UnsupportedProtocolVersionError 错误，则再尝试重新发送。
通过 Streamable HTTP，当前请求会携带如下元数据：
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
相同的版本、方法和名称也会出现在 JSON-RPC 的请求体中。请求体具有权威性，服务器必须拒绝任何头部信息与请求体不一致的情况。这样就能防止在服务器正在处理另一项操作时，网关却批准或路由当前操作。
“无状态”并不意味着“不存储任何数据”
该规范并未取消应用程序状态的存在，只是不再要求隐藏它。当服务器需要保持多次调用之间的连续性时，应生成一个域标识，例如 workspace_id、browser_id、basket_id、analysis_run_id 或 deployment_id。客户端或模型随后可在后续调用中将其作为普通参数传入：
create_workspace()
→ { "workspace_id": "ws_7f3..." }
add_file(workspace_id="ws_7f3...", ...)
→ ...
run_analysis(workspace_id="ws_7f3...")
→ ...
这种方式比隐藏传输状态更为简洁，但会给应用程序带来新的职责，需要处理所有权检查、租户隔离、过期处理、保留规则、授权问题，以及防范猜测攻击和重放攻击。持久化的工作流可能仍需要数据库或分布式缓存，而长期运行的任务按定义就需要可靠的存储机制。基础设施可以是无状态的，而产品本身仍需保持状态。
2. 无状态设计真正能带来优势的场景
简单的水平扩展
当请求自带完整上下文时，服务器可以部署在标准的轮询负载均衡器之后。在 Kubernetes 中，通常使用普通的 Deployment 和 Service 即可，无需添加会话亲和性注解，也不需要专门用于管理 MCP 会话的 StatefulSet。自动扩缩容的优势尤为明显：新生成的容器在开始处理请求前无需重新建立协议会话，而在滚动部署过程中被替换的容器也不会导致客户端陷入无效会话。
不过有一个需要注意的地方：如果应用程序需要处理任务，那么这些任务对象仍需存储在外部持久化存储中，以便在进程或容器丢失时依然能够保留。
网关处的路由与策略
由于 Mcp-Method 和 Mcp-Name 是普通请求头，网关无需解析 JSON 正文即可进行路由、计费及策略执行。在支持为 tools/list、昂贵的搜索工具、部署工具以及任何可能造成破坏的功能设置独立配额的多租户服务中：
tools/list → high request allowance
tools/call + search → standard allowance
tools/call + deploy_prod → lower rate limit and stronger policy
resources/read → data-volume quota
网关绝不应将clientInfo视为判断调用者的依据。该字段为自声明字段，仅用于显示、调试和日志记录。租户身份需通过经过验证的令牌或其他可信来源来确定。
缓存
对resources/read、resources/templates/list、resources/list、prompts/list、tools/list以及server/discover的响应都会包含两个新字段：ttlMs和cacheScope。前者表示数据新鲜度提示，而非轮询间隔；后者则说明结果是对公还是私有的。任何因用户、租户、范围或授权不同而有所差异的内容都不得视为共享的公共数据，且变更通知可能会使本应保持新鲜的状态的结果失效。
缓存可以减少重复的工具目录请求，并稳定模型提示输入。错误选择的作用范围还会引发新的正确性及隐私问题。
可观测性
规范文档说明了通过 _meta 键 traceparent、tracestate 和 baggage 来传播 W3C Trace Context。主机、MCP 客户端、网关、服务器以及下游服务借此能够以统一方式关联整个执行路径中的工具调用。Trace Context 有助于实现关联，但它并非授权机制，也不具备完整性保障功能，敏感数据、令牌、原始提示及个人信息都不应放入 baggage 中。
3. 扩展功能成为一级概念
现在的每个扩展都拥有唯一的标识符、协商规则、指定的维护者、独立的代码仓库以及自身的发布周期。客户端会在每次请求发送的能力信息中声明其所支持的扩展，而服务器则通过 server/discover 功能公布自身的扩展列表。只有当双方都支持某项扩展时，它才会生效；如果对方不支持，实现方案就必须恢复到核心功能，或返回相应的错误信息。
这对协议的演进而言是一大进步，因为各种功能不再需要等待完整的核心版本发布。同时这也形成了一个兼容性矩阵。服务器无法假设所有主机都支持 Tasks、MCP Apps、企业级管理授权功能或任何未来的扩展，因此生产代码需要明确的回退机制：
- 那些支持任务功能的工具，还会为不声明任务功能的客户端提供同步路径，否则会返回明确的“不支持该功能”的错误信息。
- 由MCP应用支持的工具在主机无法渲染其界面时，仍能返回有用的结构化或文本格式内容。
- 企业级授权仅在组织政策允许的情况下才会启用。
- 特定于扩展的字段绝不会发送给未协商这些字段的客户端。
扩展功能降低了与核心规范的耦合度，同时也增加了生态系统碎片化的风险。
4. 任务功能让长时间运行的工具更具稳定性
任务会从实验性核心模块移至正式的扩展模块 io.modelcontextprotocol/tasks 中。如果客户端声明支持任务功能，服务器就可以用任务处理标识符来代替最终结果来响应普通操作。随后客户端可通过 tasks/get 读取当前状态，使用 tasks/update 提供所需输入，再通过 tasks/cancel 请求取消任务。
任务的状态会依次变为 working、input_required、completed、failed 和 cancelled。服务器在返回任务处理标识符之前必须先将该任务持久化存储。取消操作属于协作式处理，因此即使收到了确认请求，也不保证相关操作会立即停止。
天然的候选方案包括测试套件、构建流水线、代码生成、云部署、数据导入、文档处理、需要人工审批的步骤、批处理作业以及某些外部作业API的封装层。实际上得到的并非真正的异步执行，而是具备恢复能力：客户端可以中断后重新启动，并使用相同的任务ID继续轮询。
生产环境服务器必须添加的功能
任务处理需要的远不止一个后台线程：
- 持久化的任务存储库
- 每次调用
tasks/get、tasks/update或tasks/cancel时都进行授权检查 - 所有权与租户隔离
- 状态转换的验证
- 结果与错误的保留
- 生存时间限制的强制执行与清理
- 轮询频率的限制
- 取消操作的传播
应将任务ID视为资源标识符，而非机密信息。仅持有该ID绝不足以授权任何操作。
5. 多次往返请求替代服务器主动发起的请求
无状态服务器无法依赖持久的双向连接来随时向客户端提问。此时就需要多次往返请求（MRTR）来发挥作用。当服务器需要确认、获取信息、采样或其他由客户端提供的输入时，它会返回InputRequiredResult。客户端收集这些输入后，使用inputResponses以及可选的requestState重新尝试原始操作。
以一种具有破坏性的工具为例：
delete_resources(resource_ids=[...])
服务器不会在现有流上发起反向请求，而是直接回复：
input_required:
"Confirm deletion of 53 resources"
客户端收到确认后再次发起原始调用。由于重试是独立进行的，因此该机制在不同实例间均可使用，但这也意味着服务器必须为重试场景做好设计。
生产环境MRTR的规则
- 在获取所有必需的输入之前，不得执行不可逆的操作。
- 确保重试操作具有幂等性。
- 将
requestState与特定操作及发起该操作的客户端绑定。 - 使过期的请求状态失效。
- 拒绝那些涉及服务器从未请求或已接收过的键值的响应。
- 限制允许的重试次数，防止形成无限循环。
- 每次重试时都需重新授权该操作。
- 切勿假设重试会落在同一个实例上。
在流程较为敏感的场景中，应将requestState设置为不可见的随机标识符，实际数据保存在服务器上；或者设置为一个包含消息认证码的值，以便在数据被篡改时能够被发现。
6. MCP应用改变的是产品本身，而不仅仅是协议
MCP应用允许服务器将某个工具与交互式HTML界面关联起来。兼容的宿主环境会在沙箱化的iframe中渲染该界面。应用通过postMessage以JSON-RPC格式与宿主通信，而宿主则负责控制应用能够使用哪些功能与工具。这样一来，表单、控制面板、确认对话框、媒体播放器、部署配置工具、分类筛选界面以及那些难以用文本表达的界面元素都能得以实现。
对于初创公司而言，这能够改变最小可行产品的经济模型：无需先构建独立的应用外壳和集成层，即可实现交互式对话式工作流程。不过，前端开发工作并未消失。团队仍需负责界面设计、状态管理、CSP配置、沙箱内的代码运行、输入验证、主机功能协商、安全工具调用处理、跨客户端的兼容性测试，以及为不支持该应用的主机提供备用方案。由于应用只是可选扩展，不同主机的支持程度各异，因此即便无法显示视图，服务器也应返回有意义的结构化内容。
7. 权限管理愈发严格且复杂
根据HTTP授权规则，受保护的MCP服务器充当OAuth资源服务器的角色，而MCP客户端则扮演OAuth客户端的角色。该规范借鉴了OAuth 2.1及相关标准中的部分内容。服务器必须发布受保护资源元数据以便客户端能够找到它们，同时支持OAuth和OpenID Connect两种授权服务器元数据格式。PKCE是强制要求的，授权请求和令牌请求中也需要包含资源标识符，且发行方验证更为严格。主要规则如下：
- 客户端需发送一个名为
resource的参数，指定目标MCP服务器。 - 服务器需验证所收到的令牌确实是为其指定的受众生成的。
- 授权服务器应包含
iss字段，客户端在兑换授权码之前会先检查该字段中的发行方信息。
Authorization请求头中，绝不能放在查询字符串中。S256算法。资源标识符用于限制令牌的适用对象，不应将其描述为加密令牌绑定机制。
企业身份是另一回事
核心MCP授权涵盖了标准的用户委托式OAuth流程。集中式的企业访问策略则来自可选的企业管理授权扩展功能，该功能允许企业的身份提供商管控对MCP服务器的访问，涵盖用户加入、退出、条件访问以及规则执行等环节。客户端、服务器的授权系统以及企业身份环境都必须支持这一功能。从安全审查的角度来看，其架构结构如下：
Core authorization
OAuth flow
issuer validation
resource/audience validation
scopes and step-up
Protected Resource Metadata
Optional enterprise extension
corporate IdP policy
SSO
centralized approval and revocation
identity-assertion exchange
该规范明确了架构，但并未让OAuth的操作变得更简单。获取客户端元数据会带来SSRF和信任策略方面的问题。令牌及刷新凭证需要安全存储。多发行方部署则需要独立的注册流程和令牌状态管理。元数据、重定向URI、作用域以及标准资源标识符都必须保持一致。
8. 真正的废弃政策
现有功能分为三种状态：活跃、已废弃和已移除。一个核心功能通常至少需要处于已废弃状态12个月才能被移除，而且废弃过程需要有文档化的迁移路径，并在中央注册表中登记。实际移除时间可能会晚于最早预定日期。对于存在紧急安全风险的情况，有快速处理途径，但即便如此通常也需要至少90天时间。
较旧的传输方式HTTP+SSE有独立的过渡规则，因此可能比其他已被废弃的功能更早被移除。仍在使用该方式的机构应首先计划迁移到Streamable HTTP。还需注意，12个月的规则仅适用于协议功能；SDK API则拥有独立的支持策略和时间表，可能会有所不同。
在实际应用中的体现
企业内部工具
设想有一家公司通过MCP发布内部知识、Jira、Confluence内容、服务目录及操作手册。在旧模式下，远程部署可能需要依赖会话绑定，以确保同一员工始终连接到同一个实例。而到了2026-07-28，MCP架构可以由一组无状态容器构成，这些容器位于普通的Kubernetes服务及负载均衡器之后：
MCP host
↓
API gateway / authorization
↓
Stateless MCP Deployment
├─ Knowledge connector
├─ Jira connector
├─ Confluence connector
└─ Service catalog connector
↓
OpenTelemetry backend
日常授权可遵循核心OAuth机制，而当需要集中式的身份提供商策略时，则会启用企业级管理授权扩展功能。实际支持该扩展功能的客户端数量是主要的限制因素。
多租户SaaS
假设某开发工具供应商将MCP作为付费API提供给成百上千的租户使用。无状态特性支持简单的多区域路由，网关可以依据Mcp-Method和Mcp-Name进行流量计量，租户身份从经过验证的授权信息中获取，而非客户端发送的任何名称或请求头。合理的实现方式应是按租户划分处理逻辑和任务，将特定于租户的目录标记为cacheScope: "private"，对比每个请求头与请求体内容，对资源消耗较大的工具设置独立的限流规则，禁止跨租户查询任务，并将授权决策逻辑置于本地进程内存之外。不再存在基于会话的路由机制；租户隔离仍需由你负责实现。
AI编程助手
编码服务器可以将run_tests、build_project、generate_patch或deploy_preview作为任务提供出来。它会立即返回任务ID，将工作加入队列，这样代理就可以继续读取代码或处理其他问题。客户端按照服务器建议的间隔进行轮询，当某个破坏性操作需要审批时，任务状态会变为input_required，此时客户端需通过tasks/update进行响应。这样做的好处是即便编辑器重启或网络中断也能保持正常运行。但代价则是需要一个完善的任务系统：稳定的队列、工作进程租约、存储的结果、取消功能、隔离的工作空间以及数据保留策略。
医疗保健与金融服务
资源标识符与受众验证机制可降低为某个MCP服务器生成的令牌在另一服务器被重复使用的风险，而发行方验证则能减少OAuth混淆攻击的可能性。W3C追踪上下文功能允许追踪请求在MCP路径及其背后服务中的流转过程。这些机制共同为安全与合规团队提供了更清晰的管控手段，但并不能完全解决合规问题。应用内部仍需具备授权机制、不可篡改的审计事件记录、数据保留与删除规则、数据分类机制、同意处理流程、密钥管理机制、管理访问日志、事件处理流程以及最少的追踪数据。追踪功能有助于诊断问题，但不应成为唯一的审计记录。
一家专注于AI的初创公司
设想一个小型团队正在开发一个基础设施辅助工具。通过MCP应用，它可以实现部署计划表单、成本估算仪表板、审批对话界面、发布监控功能以及回滚控制功能。主机负责提供对话上下文，服务器则提供工具和UI资源，而应用则通过主机控制的桥梁来调用这些工具。起初可能不需要独立的仪表板产品，但API设计、授权机制、UI测试、无障碍性、CSP规则以及兼容性回退方案依然必不可少。
新规范带来的复杂性
状态虽被转移，但并未消失。连接状态变成了明确的域状态，这一架构改进要求人们必须仔细设计状态的处理方式、存储机制、有效期、所有权以及重试机制。
升级SDK与采用新协议是两项独立的工作。在候选版本发布时，SDK维护者就建议各团队将SDK的主版本升级与新传输协议的启用分开进行，这一建议至今仍然有效。以TypeScript v2 SDK为例：它将原来的单个包拆分为独立的服务器端和客户端包，仅以ESM格式提供，可在Node.js 20+、Bun和Deno上运行，通过符合标准模式的库进行验证，并包含用于处理常见v1版本变更的代码修改模块。Python v2同样经历了大规模重构，其中包括将FastMCP重命名为MCPServer。在v2版本发布后，TypeScript v1至少还会获得六个月的漏洞修复和安全更新，而Python v1则将继续得到关键漏洞修复和安全补丁。应当采取谨慎的工作顺序：
- 在支持的情况下，升级 SDK 同时保持原有的协议行为。
- 修复应用层 API 的变更问题。
- 添加对多个时代协议的兼容支持。
- 使用真实客户端和流量进行验证。
- 逐步启用现代的无状态行为。
- 只有在观察客户端采用情况后才能停止对旧版本的支持。
扩展功能会导致能力碎片化。 工具无法假设 Tasks 或 MCP Apps 在所有地方都存在，因此产品团队需要制定兼容性矩阵并提供备用用户体验。
重试机制可能引发正确性问题。 现在的重试场景包括 MRTR、协议版本协商、HTTP 响应流丢失、授权升级、Tasks 轮询以及订阅重新连接等。因此，任何具有副作用的操作都需要有明确的幂等性设计。
OAuth的互操作性有所提升，但要求依然严格。该规范将OAuth 2.1及客户端ID元数据文档视为草案，因此实现者必须同时遵循MCP的变更以及相关基础标准。
缓存机制引发了隐私问题。将依赖授权的响应标记为公开状态，可能会导致某个用户或租户的目录被其他用户看到。采用保守的默认设置更为合适：除非对所有调用者而言结果完全一致，否则应使用私有权限范围。
总体评估
MCP 2026-07-28使该协议更接近现代网页的运作方式：独立的请求、明确的版本标识、常规的HTTP路由、真正的缓存语义、分布式追踪，以及标准化的授权机制和可独立发展的可选功能。其真正的好处并非没有状态，而是没有隐藏的协议状态。
扩展规模、跨区域路由、故障恢复、设置网关策略以及系统监控都变得容易多了。而随之显现的则是那些曾被掩盖的工作会话状态：应用程序处理逻辑、幂等性、持久性任务、扩展方案备用、授权元数据、缓存隐私性以及重试机制的运作方式。
如果您正在运行现有的生产服务器，应分阶段进行迁移并同时支持旧版本与新版本。将 SDK 升级与传输协议更新视为两个独立的步骤，消除对连接的预设假设，将长期运行的任务存储在明确的存储机制中，测试授权与重试功能，只有在实际客户端采用情况得到验证后才能逐步废弃旧有功能。对于全新的服务器来说则更为简单：从无状态请求处理程序和明确的状态管理开始，使用 Streamable HTTP 及当前的授权机制，加入 OpenTelemetry，确保缓存行为的确定性，并从第一天起就规划后续扩展方案。
虽然该协议的运行变得更加简单，但仅适用于那些能够明确界定应用程序状态、安全边界及故障处理方式的团队。
相关阅读
- 实用指南：MCP 2026——该协议的发展历程及生产环境中的应用 — 为采用该模式的团队提供的实用指南详细操作指南，涵盖合同、检查项以及可直接使用的代码模板。
- 开发者优先安装的十款MCP服务器 — 为AI编程助手精选的按优先级排序的MCP服务器列表，涵盖Context7、GitHub、Postgres及内存相关服务器，附有安装配置及权限设置注意事项。