> ## Documentation Index
> Fetch the complete documentation index at: https://mcp-zh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 特性生命周期与弃用政策

> 单个 MCP 规范特性如何在活跃、已弃用和已移除状态之间流转，以及实现者可据以规划的时间线。

本政策为模型上下文协议规范内的单个特性定义了一套生命周期。它定义了三种特性状态（活跃、已弃用、已移除）、在它们之间流转的标准和程序、弃用与移除之间的最短窗口期，以及每次转换所需的文档。

本政策通过 [SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596) 采纳。

## 适用范围

本政策规范 MCP 核心规范的**特性**：协议消息、能力、传输、schema 类型和规范性行为要求。规范文档本身的修订生命周期（草案、当前、最终）在[版本控制指南](/docs/learn/versioning)中定义。

## 特性状态

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

| 状态      | 含义                                                 | 对实现者的预期                       |
| ------- | -------------------------------------------------- | ----------------------------- |
| **活跃**  | 该特性是当前规范修订的一部分。                                    | 按照该特性的规范性要求实现。                |
| **已弃用** | 该特性仍保留在规范中，但已被安排移除。已记录一条迁移路径（见下文）。                 | 新的实现不应采用该特性。既有实现应在最早移除日期之前迁移。 |
| **已移除** | 该特性已从 `draft` 中删除，并将在下一个当前修订中缺席。它在其最后出现的最终修订中仍有记录。 | 面向该下一个当前修订的实现不得依赖该特性。         |

已弃用的特性\*\*可以（MAY）\*\*通过一个取代弃用 SEP、并记录了情况变化的 SEP 恢复为活跃状态。恢复遵循与弃用相同的批准路径。如果该特性后来再次被弃用，则[弃用特性](#弃用一个特性)中的最短弃用窗口期将从新弃用生效的修订起重新计算。

### SDK

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

## 弃用一个特性

在以下情况可以提议弃用某个特性：

* 它已被另一个涵盖相同用例的特性所取代，
* 它带来了无法就地缓解的安全、隐私或互操作性风险，
* 生态遥测数据或 SDK 维护者共识表明，相对于其维护成本，其采用度微乎其微，
* 或核心维护者认为适当的任何其他理由。

弃用是一项规范变更，因此依据 [SEP 指南](/community/sep-guidelines)需要一个 SEP。弃用 SEP 必须：

1. 按名称标识该特性，并链接到其在 `schema.ts` 中的定义（在适用情况下）以及规范正文。
2. 对照上述标准陈述理由。
3. 记录迁移路径，或明确声明无需迁移。如果迁移路径指名了一个替代特性，该特性必须在弃用生效的修订中处于活跃状态；替代特性与弃用可以在同一修订中落地。
4. 指定**最短弃用窗口期**：即该特性在有资格被移除之前必须保持已弃用状态的月数，至少为十二个月。窗口期从该特性首次被标记为已弃用的规范修订发布之日起计算，而非从 SEP 达到最终状态之日起。该特性在窗口期结束当日或之后作为当前修订发布的第一个规范修订中变得有资格移除；该时点即为该特性的**最早移除**。

当弃用 SEP 被接受并达到最终状态时，弃用即被安排。

* 该特性在 `schema.ts` 中的条目会获得一个 `@deprecated` JSDoc 标记，引用弃用 SEP 以及弃用生效的修订。
* 该特性的规范正文会获得一条带有相同信息的弃用通知。
* 该修订的 `changelog.mdx` 会在 "Deprecated" 标题下获得一个条目。"Deprecated" 和 "Removed" 是与既有的 Major/Minor/Other 分组并列的常设变更日志标题。
* 该特性会被添加到[已弃用登记表](#已弃用登记表)，附带其弃用 SEP、其变为已弃用状态的修订、其迁移路径及其最早移除。

当承载这些变更的修订被发布并成为新的当前修订时，该特性即变为已弃用（参见[版本控制指南](/docs/learn/versioning)）。最短弃用窗口期从该次发布开始计算。

## 已弃用登记表

[`docs/specification/draft/deprecated.mdx`](/specification/draft/deprecated) 是一个单一页面，列出了处于已弃用或已移除状态的每一个特性。它是"什么正在被淘汰、到什么时候"这一问题的权威答案，从而使实现者无需从散布在各修订变更日志中的弃用条目重新拼凑出这幅图景。

## Tier 1 SDK 义务

一旦某特性变为已弃用所在的修订作为当前修订发布，Tier 1 SDK：

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

始终未能浮现已弃用特性的 Tier 1 SDK，将受[等级降级流程](/community/sdk-tiers#tier-relegation)约束。

## 移除一个特性

1. 一旦某特性被设定为移除，移除将在最短弃用窗口期结束后，由核心维护者酌情执行。
2. 移除需要记录在 `changelog.mdx` 和[登记表](#已弃用登记表)中。
3. 对原始弃用或移除 SEP 的任何更改都需要一个 SEP，例如延长或缩短时间线（[加速移除](#加速移除)）或将特性恢复为活跃状态（[特性状态](#特性状态)）。

特性可以保持已弃用状态而不被移除，其时间远长于最短弃用窗口期。

## 加速移除

当特性带来活跃的安全风险时，即存在一个已发布安全公告的漏洞，或有记录的在野利用且不存在就地缓解措施，十二个月的下限可以缩短。缩短窗口期需要依据[治理决策流程](/community/governance#decision-process)获得核心维护者批准，并记录在弃用 SEP 中，或在风险于该 SEP 已达最终状态之后才浮现的情况下，记录在一个引用它的简短加速移除 SEP 中。缩短后的窗口期仍必须在特性变为已弃用与其最早移除之间提供至少九十天。

## 角色

| 行动            | 由谁                                                       |
| ------------- | -------------------------------------------------------- |
| 提议弃用、延长或恢复    | 任何贡献者，按照 SEP 流程                                          |
| 担保（Sponsor）   | 一位维护者或核心维护者，按照 SEP 流程                                    |
| 批准弃用 SEP      | 核心维护者，按照[治理决策流程](/community/governance#decision-process) |
| 在发布准备期间决定一次移除 | 核心维护者，按照[治理决策流程](/community/governance#decision-process) |
| 批准延长或恢复 SEP   | 核心维护者，按照[治理决策流程](/community/governance#decision-process) |
| 批准加速移除        | 核心维护者，按照[治理决策流程](/community/governance#decision-process) |

依据[治理角色](/community/governance#roles)定义，首席维护者对上述每一项批准保留否决权。