功能生命周期与弃用政策

各个 MCP 规范功能如何经历 Active、Deprecated 和 Removed 状态，以及实现者可据此规划的时间线。

本政策定义了 Model Context Protocol 规范中各个功能的生命周期。它定义了三种功能状态（Active、Deprecated、Removed）、在它们之间迁移的标准与流程、弃用与移除之间的最短窗口期，以及每次转换所需的文档。

本政策经由 SEP-2596 采纳。

范围

本政策管辖 MCP 核心规范的功能：协议消息、能力、传输、schema 类型以及规范性行为要求。规范文档本身的修订版生命周期（Draft、Current、Final）定义于版本管理指南。

功能状态

一个规范功能恰好处于以下三种状态之一：

State	Meaning	Implementer expectation
Active	The feature is part of the Current specification revision.	Implement per the feature's normative requirements.
Deprecated	The feature remains in the specification but is scheduled for removal. A migration path is documented (see below).	New implementations should not adopt the feature. Existing implementations should migrate before the earliest removal date.
Removed	The feature has been deleted from `draft` and will be absent from the next Current revision. It remains documented in the Final revision it last appeared in.	Implementations targeting that next Current revision must not depend on the feature.

被弃用的功能 MAY（可以）通过一个 SEP 恢复为 Active，该 SEP 需取代弃用它的 SEP 并记录情况的变化。恢复遵循与弃用相同的审批路径。如果该功能之后再次被弃用，弃用一个功能中的最短弃用窗口期将从新的弃用生效所在修订版起重新计算。

SDK

从规范中移除并不强制 SDK 从发布版本中删除该功能。该时间线由 SDK 自身的修订版支持政策管辖。

弃用一个功能

在以下情况下，可以提议弃用一个功能：

它已被另一个覆盖相同用例的功能所取代，
它带来了无法就地缓解的安全、隐私或互操作性风险，
生态系统遥测数据或 SDK 维护者共识表明，相对于其维护成本，其采用率可忽略不计，
或核心维护者认为适当的任何其他原因。

弃用属于规范变更，因此需要依据 SEP 指南提交 SEP。弃用 SEP 必须：

按名称标识该功能，并链接到其在 schema.ts 中的定义（如适用）以及规范正文。
依据上述标准陈述理由。
记录迁移路径，或明确说明无需迁移。如果迁移路径指定了替代功能，该功能必须在弃用生效所在的修订版中处于 Active 状态；替代与弃用可以落在同一修订版中。
指定最短弃用窗口期：该功能在被允许移除之前必须保持 Deprecated 状态的月数，至少为十二个月。窗口期从该功能首次被标记为 Deprecated 的规范修订版发布之日起计算，而非从 SEP 达到 Final 之日起计算。该功能在窗口期届满之时或之后作为 Current 发布的第一个规范修订版中即具备移除资格；该时间点即该功能的最早移除时间。

当弃用 SEP 被接受并达到 Final 时，弃用即被排定。

该功能在 schema.ts 中的条目会获得一个 @deprecated JSDoc 标签，引用该弃用 SEP 以及弃用生效所在的修订版。
该功能的规范正文会获得一条包含相同信息的弃用通知。
该修订版的 changelog.mdx 会在 "Deprecated" 标题下获得一个条目。"Deprecated" 和 "Removed" 是与现有 Major/Minor/Other 分组并列的常设 changelog 标题。
该功能会被添加到弃用注册表，并附上其弃用 SEP、其变为 Deprecated 所在的修订版、其迁移路径以及其最早移除时间。

当承载这些变更的修订版发布并成为新的 Current 修订版时，该功能即变为 Deprecated（参见版本管理指南）。最短弃用窗口期自该发布之日起计算。

弃用注册表

docs/specification/draft/deprecated.mdx 是一个单页文档，列出所有处于 Deprecated 或 Removed 状态的功能。它是"哪些功能即将退出，以及何时退出"的权威答案，使实现者无需从散布于各修订版 changelog 中的弃用条目里重建这一图景。

Tier 1 SDK 义务

一旦某功能变为 Deprecated 所在的修订版作为 Current 发布，Tier 1 SDK：

必须在其下一个发布版本中，使用该语言的原生机制（例如 Java 中的 @Deprecated、.NET 中的 [Obsolete]、TypeScript 中的 @deprecated JSDoc、Go 中的 Deprecated: 文档约定）将相应的 API 表面标记为已弃用，并在该机制允许的情况下引用弃用 SEP 及最早移除日期。
应使用该语言的惯用机制（例如 Python 的 DeprecationWarning、Node.js 的 process.emitWarning，或可配置的日志记录器）在已弃用功能被使用时发出运行时警告。

若某 Tier 1 SDK 持续未能呈现某个 Deprecated 功能，则须接受 Tier Relegation Process。

移除功能

一旦某功能被设定为移除，移除将在最短弃用窗口期满后，由 Core Maintainers 酌情执行。
该移除需记录在 changelog.mdx 和注册表中。
对原始弃用或移除 SEP 的任何更改都需要一份 SEP，例如延长或缩短时间线（快速移除）或将功能恢复为 Active （功能状态）。

功能可以保持 Deprecated 状态而不被移除，其时间可以远长于最短弃用窗口。

快速移除

当功能构成活跃安全风险时，即存在已发布安全公告的漏洞，或有记录的、无就地缓解措施的野外利用，十二个月的下限可以缩短。缩短窗口需要依据治理决策流程获得 Core Maintainer 批准，并记录在弃用 SEP 中；或者，若该风险在该 SEP 已为 Final 之后才出现，则记录在一份引用它的简短快速移除 SEP 中。缩短后的窗口仍须在该功能变为 Deprecated 与其最早移除之间提供至少九十天。

角色

操作	谁
提议弃用、延长或恢复	任何贡献者，依据 SEP 流程
发起	一名 Maintainer 或 Core Maintainer，依据 SEP 流程
批准弃用 SEP	Core Maintainers，依据治理决策流程
在发布准备期间决定移除	Core Maintainers，依据治理决策流程
批准延长或恢复 SEP	Core Maintainers，依据治理决策流程
批准快速移除	Core Maintainers，依据治理决策流程

依据治理角色定义，Lead Maintainers 对上述每一项批准保留否决权。