SEP-2596：规范特性生命周期与弃用政策

社区译文；来源： MCP 29affa6b

摘要

本 SEP 为 Model Context Protocol 规范中的单项特性定义生命周期，该生命周期独立于规范文档本身的修订版生命周期。它引入三种特性状态（Active、Deprecated、Removed）、状态转换的条件和程序、弃用与移除之间的最短窗口，以及每次转换所需的文档。目标是在协议表面被淘汰时，提供 SDK 作者和实现者可以据此规划迁移的可预测时间线。

动机

规范已经移除或表明将要移除多项特性，但每种情况一直都以临时方式处理：

• HTTP+SSE 传输在 Streamable HTTP 向后兼容性指引中被描述为“已弃用”，但没有说明移除日期。
• includeContext 的值 "thisServer" 和 "allServers" 在 sampling/createMessage 与 schema.ts 中被标为“软弃用（soft-deprecated）”，并注明它们“可能会在未来的规范版本中移除”。
• JSON-RPC 批处理在 2025-03-26 修订版中加入，又在紧接着的 2025-06-18 修订版中移除，没有经过弃用期。
• 合并 Resource 与 ResourceTemplate（#1540）以及弃用 roots、sampling 和 logging（SEP-2577）等开放提案都会淘汰现有协议表面，却没有可遵循的流程。

这种不一致会带来代价。实现者无法判断“deprecated”与“soft-deprecated”是否含义不同，也无法判断任一状态在移除前会持续多久。讨论 #2177（询问 SSE 传输究竟何时移除）等社区问题没有可援引的政策。在 NYC 维护者会议上，大型实现方将无限期支持旧协议版本描述为“侵蚀性的技术债务”。稳定性优先于速度这一设计原则指出，“从[规范]中移除几乎不可能”，却没有为确有理由需要移除的情况提供路径。

Core Maintainer 在 2026 年 4 月 1 日会议上达成一致：MCP 需要“正式的版本状态和明确的弃用周期”，并且“方向已达成一致，机制待定”。本 SEP 提出这套机制。

规范

范围

本政策管理 MCP 核心规范的特性：协议消息、capability、传输、schema 类型和规范性行为要求。它不管理 SDK 特有 API、注册表政策或规范文档自身的修订版生命周期（Draft、Current、Final）；后者由版本控制指南定义。

请注意，本文中的“Final”有两种含义：根据版本控制指南，规范的某个_修订版_被后续版本取代时成为 Final；而某个 SEP 的状态按照 SEP 指引推进时也会达到 Final。上下文通常足以区分；若不能，本文会明确写为“SEP 达到 Final”或“Final 修订版”。

特性状态

一项规范特性只会处于以下三种状态之一：

“软弃用（soft-deprecated）”这一术语停止使用。规范中的现有用法按本政策重新归类为 Deprecated（参见过渡）。

从规范中移除某项特性，并不要求 SDK 在仍支持早期修订版的版本中删除该特性；在那些早期修订版中，该特性仍处于 Active 或 Deprecated 状态。具体时间线由 SDK 自己的修订版支持政策决定（参见开放问题）。

可以（MAY）通过一项取代原弃用 SEP、并说明情况为何发生变化的新 SEP，将 Deprecated 特性恢复为 Active。恢复遵循与弃用相同的审批路径。如果该特性后来再次弃用，弃用特性规定的最短弃用窗口将从新一次弃用生效的修订版起重新计算。

弃用特性

至少满足以下一项条件时，可以（MAY）提议弃用某项特性：

• 已有另一项特性取代它并覆盖相同用例。
• 它带来无法原地缓解的安全、隐私或互操作性风险。
• 生态系统遥测或 SDK 维护者共识表明，相对于维护成本，其采用率可以忽略不计。

弃用属于规范变更，因此根据 SEP 指引需要一项 SEP。弃用 SEP 必须（MUST）：

1. 按名称识别该特性，并链接到其在 schema.ts 中的定义（如适用）以及规范正文。
2. 根据上述条件说明理由。
3. 记录迁移路径，或明确说明无需迁移。如果迁移路径指定了替代特性，该替代特性在弃用生效的修订版中必须（MUST）处于 Active 状态；替代特性与弃用可以（MAY）在同一修订版中落地。当记录的替代特性仍只存在于 draft 时，该特性不按本政策进入 Deprecated 状态。
4. 指定最短弃用窗口：该特性在具备移除资格前必须（MUST）保持 Deprecated 状态的月数，且至少为十二个月。该窗口从首次将该特性标为 Deprecated 的规范修订版发布之日起计算，而不是从 SEP 达到 Final 之日起计算。窗口期满后，在当日或之后首个作为 Current 发布的规范修订版中，该特性具备移除资格；这一时间点即该特性的最早移除时间。

弃用 SEP 达到 Final 时，弃用进入计划：以下变更会落入规范草案（schema/draft/ 和 docs/specification/draft/）。承载这些变更的修订版按照版本控制指南作为 Current 发布时，该特性变为 Deprecated，最短弃用窗口也从该次发布起计算。将计时起点锚定到修订版发布，意味着同一修订版中弃用的所有特性具有同一个最早移除时间，不会因为各自 SEP 的落地日期不同而分别计算日期。

• 该特性在 schema.ts 中的条目会增加 @deprecated JSDoc 标签，引用弃用 SEP 以及弃用生效的修订版。
• 该特性的规范正文会增加包含相同信息的弃用通知。
• 该修订版的 changelog.mdx 会在“Deprecated”标题下增加一个条目。本 SEP 将“Deprecated”和“Removed”作为固定的变更日志标题，与现有 Major/Minor/Other 分组并列。
• 该特性会加入已弃用注册表，其中记录其弃用 SEP、进入 Deprecated 状态的修订版、迁移路径和最早移除时间。

已弃用注册表

docs/specification/draft/deprecated.mdx 是一个单页，列出当前处于 Deprecated 状态的所有特性。它是回答“哪些内容即将退出、何时退出”的统一入口，实现者不必从分散在各修订版变更日志中的弃用条目重建全貌。每一行记录特性、弃用 SEP、进入 Deprecated 状态的修订版、已记录的迁移路径和最早移除时间。弃用时增加一行；移除时将该行移至同一页面的 Removed 部分，并链接到变更日志条目，因此该页面也充当历史记录。注册表本身不具有规范效力；它是一个派生视图，与各特性的弃用通知和变更日志条目保持一致，后两者才是规范性记录。

Tier 1 SDK 义务

特性生命周期的有效程度，取决于实现能否向使用方呈现这些信息。上述规范制品记录某项特性已进入 Deprecated；Tier 1 SDK（定义见 SEP-1730）将这一记录传递给实现者，否则他们可能只能在功能因移除而失效时才发现变化。某项特性进入 Deprecated 状态的修订版作为 Current 发布后，Tier 1 SDK：

• 必须（MUST）在其下一个版本中使用对应语言的原生机制，将相应 API 表面标为弃用（例如 Java 中的 @Deprecated、.NET 中的 [Obsolete]、TypeScript 中的 @deprecated JSDoc、Go 中的 Deprecated: 文档约定），并在机制允许时引用弃用 SEP 和最早移除日期。该标记作用于 SDK API 表面，不取决于使用方所面向的规范修订版；即使使用方仍停留在较早修订版，也有意向其发出这一前瞻信号。
• 当弃用特性被使用时，应该（SHOULD）通过该语言的惯用机制发出运行时警告（例如 Python 的 DeprecationWarning、Node.js 的 process.emitWarning 或可配置 logger）。运行时警告可以触达从不阅读 API 文档的开发者，同时也是一致性测试能够断言的可观测信号。

这些义务是 Tier 1 状态的一致性标准。持续未能呈现 Deprecated 特性的 Tier 1 SDK，将受 SEP-1730 中的 Tier 降级流程约束。

移除特性

1. 某项特性确定移除后，最短弃用窗口期满，Core Maintainer 可在发布准备期间根据治理决策流程自行决定执行移除。移除无需单独的 SEP。移除特性前，Core Maintainer 必须（MUST）确认弃用 SEP 中指定的迁移目标（如有）仍处于 Active 状态。
2. 对弃用或移除所做的任何其他变更都需要 SEP，例如延长或缩短时间线（加速移除），或者将特性恢复为 Active（特性状态）。

请注意，特性可以在超过最短弃用窗口很久之后仍保持 Deprecated 状态，而不被移除。

SDK 将弃用作为 SDK 分级系统的一部分来实现（参见 Tier 1 SDK 义务）；移除不会对 SDK 维护者提出额外要求。

作出移除决定后，该特性会从 schema/draft/schema.ts（如存在）和规范草案正文中删除；该修订版的 changelog.mdx 会在“Removed”标题下增加一个条目，链接到弃用 SEP 以及最后包含该特性的 Final 修订版；该特性在注册表中的行会移至 Removed 部分，并链接到该变更日志条目。

加速移除

当特性带来现实的安全风险时，可以（MAY）缩短十二个月的下限。现实的安全风险是指：存在已发布安全公告或有记录的真实攻击利用，且无法原地缓解的漏洞。缩短窗口需要 Core Maintainer 根据治理决策流程批准，并记录在弃用 SEP 中；如果风险是在该 SEP 已达到 Final 后才出现，则记录在一项引用原 SEP 的简短加速移除 SEP 中。缩短后的窗口仍必须（MUST）在特性进入 Deprecated 与其最早移除之间保留至少九十天。

角色

与所有 Core Maintainer 决策一样，根据治理角色定义，Lead Maintainer 对上述每项批准保留否决权。

过渡

在本政策存在之前，规范已经将两项特性描述为弃用（参见动机）。本 SEP 达到 Final 后，它们会被归类为 Deprecated 并作为初始条目写入注册表；弃用特性中的弃用 SEP 要求不追溯适用。这两项弃用决策都早于本政策；本节使用新术语记录它们，使“deprecated”和“soft-deprecated”从此只表示一个明确定义的含义。

这两项特性公开弃用的时间都已远超十二个月，因此在实践中已经满足最短弃用窗口；若将其计时起点重新锚定到未来的修订版发布，就会重启一个生态系统实际上已经经历过的窗口。因此，每项特性从本 SEP 达到 Final 之日起获得三个月宽限期，期满后具备移除资格；这与加速移除条款为最短允许窗口设定的下限一致。移除仍然遵循移除特性：由 Core Maintainer 在发布准备期间作出决定，不会在宽限期结束时自动发生。

includeContext 是 sampling/createMessage 的参数。SEP-2577弃用整个 Sampling 特性；受影响的两个 includeContext 值跟随该特性的弃用计划，不另设独立的移除计时，并且最迟与 Sampling 同时移除。

这一特殊过渡安排只适用于本 SEP 达到 Final 之日，规范已描述为弃用的特性。此后的每项弃用都完整遵循弃用特性，特殊过渡特性的移除也无例外地遵循移除特性。

本 SEP 达到 Final 时，以下内容会直接落入 draft/，不设单独的实施 Gate：版本控制指南更新为引用本政策；创建 deprecated.mdx 并写入上述两项特性；在 changelog.mdx 中增加“Deprecated”标题及两个条目；每项特性都获得弃用特性所述的 @deprecated schema 注解和正文通知。对于 includeContext，由于字符串字面量联合类型无法表达针对单个值的 @deprecated 标签，注解会加在整个属性上；HTTP+SSE 传输没有 schema.ts 类型，因此只在传输正文中标注。

理由

为什么采用独立于规范修订版的状态模型？

版本控制指南已经为规范_修订版_定义了 Draft、Current 和 Final。这些状态描述整份文档的编辑成熟度，并不能说明 Current 修订版中的某条消息或某个字段是否即将退出。Kubernetes 弃用政策、Node.js 弃用周期以及 RFC 8996 等 IETF 实践（该 RFC 在 TLS 协议族中弃用 TLS 1.0 和 1.1）都出于这一原因，在发布版本控制之外另行维护特性级弃用规则。

为什么弃用需要 SEP，而移除不需要？

需要社区评审的判断是淘汰某项特性的决定和迁移路径的选择；这些内容由弃用 SEP 承载。该 SEP 达到 Final 后，项目已经承诺移除并确定最早日期，因此按计划执行该决定不会增加新的判断，再为移除编写第二项 SEP 只会增加流程本身。维护者仍须在发布准备期间作出明确的移除决定，并执行移除特性中的确认；这与 SEP-1730 的分级晋升程序一致，晋升由维护者决定，而不是在计时器到期时自动发生。SEP 保留给确实会改变既定结果的情况：延长窗口、恢复特性，或因安全风险缩短下限。这样既遵循 SEP 指引中协议表面变更值得使用 SEP 的原则，又不要求用 SEP 重复批准已经作出的变更。

为什么是十二个月？

NYC 维护者会议曾提出“一年支持期加一年弃用期”的模型，也记录了考虑到 agentic 领域的快速发展，不愿承诺更长窗口的意见。同一场讨论指出，即便这种模型也可能给 SDK 维护者造成负担；本 SEP 保留十二个月下限，因为移除是允许执行而非自动执行（移除特性），所以特性会按生态系统需要持续保持 Deprecated，不会迫使 SDK 与日历赛跑。从修订版发布而不是 SEP 日期开始计算，使窗口可观测：SDK 作者和实现者本来就通过同一个时间点跟踪修订版本身。由于弃用只在其修订版发布时生效，同一修订版中引入的替代特性会在十二个月窗口内得到验证；无需为此要求它提前出现在更早的修订版中。该窗口至少跨越同一会议讨论的两个六个月发布周期：一个周期供 SDK 维护者发布迁移支持，另一个周期供下游采用。Core Maintainer 可以让特性在 Deprecated 状态停留更久；十二个月只是下限。

与 SEP-1400（语义化版本控制）的关系

SEP-1400提议用语义化版本控制取代基于日期的修订版标识符。两项提案回答不同问题：SEP-1400 规定如何为修订版编号，本 SEP 规定如何淘汰修订版中的特性。本 SEP 从修订版的_发布_而不是修订版的_标识符_开始计算移除窗口，因此不依赖标识符方案；无论修订版使用日期还是语义化版本号，它都同样适用。

共识

NYC 维护者会议（2026 年 3 月 31 日）达成了方向共识，2026 年 4 月 1 日 Core Maintainer 会议随后确认，并记录“正式的版本状态和 SDK 弃用周期（方向已达成一致，机制待定）”。社区需求可见于讨论 #2177（询问 SSE 何时移除）和讨论 #1980（要求终止一项已超出其原定用途的向后兼容性要求）。

向后兼容性

本 SEP 引入一套流程，不改变协议行为。过渡一节为两项已经非正式弃用的特性赋予 Deprecated 状态和最早移除时间。此前两者都没有明确的移除日期，因此将时间线具体化（对于生态系统已拥有超过一年迁移时间的特性，设置三个月宽限期）不会缩短实现者此前获得的任何承诺。

安全影响

未发现安全影响。这是一项治理变更，不引入新的协议表面、传输、认证流程或信任边界。明确的弃用路径具有间接安全收益：如果某项特性日后被发现不安全，项目将拥有可预测的机制来将其淘汰；这正是加速移除条款的用途。

参考实现

本 SEP 定义流程，不提供参考实现。将本政策应用于两项现有非正式弃用的规范修改已在过渡中说明，并在本 SEP 达到 Final 时直接落入 draft/。

开放问题

• 规范修订版支持窗口。 NYC 会议还讨论了 Tier 1 SDK 必须支持某个规范_修订版_多久（这与修订版中的某项特性不同）。该政策应写入 SEP-1730 的修正案，但它决定了本政策的弃用窗口在实践中是否可观测。如果 Tier 1 SDK 只支持最新修订版，在两次发布之间更新 SDK 的使用方可能从弃用前的版本直接升级到移除后的版本，从未看到 Tier 1 SDK 义务规定的 Deprecated 标记。要求 Tier 1 SDK 支持一个滚动窗口内所有曾作为 Current 发布的修订版，并使该窗口至少等于十二个月弃用下限，便可补上这一缺口。SEP-1730 修正案应与本 SEP 同步推进。
• “采用率可以忽略不计”条件的遥测来源。 本政策允许基于采用情况弃用特性，但项目目前没有共享遥测。在建立共享遥测之前，这项条件依赖 SDK 维护者的证明。
• 特性成熟度分级。 本 SEP 对每项 Active 特性统一采用十二个月下限。Kubernetes 弃用政策使用 alpha/beta/GA 分级，对成熟度较低的特性设置更短窗口；若采用这种方式，动机所述的 JSON-RPC 批处理回退便不需要经历一整年弃用期。MCP 是否应采用窗口更短或为零的 Experimental 层级，留给后续 SEP 决定。
• 线协议级弃用信号。 Tier 1 SDK 义务将弃用警告放入官方 SDK；不使用官方 SDK 且不阅读变更日志的实现者，在移除前仍收不到警告。线协议级信号（例如响应中的 _meta 弃用字段，类似 Kubernetes 的 Warning header）可以补上这一缺口，但它属于 Standards Track 变更，不在本 Process SEP 的范围内。