SEP-3392：扩展生命周期

社区译文；来源： MCP 84d84572

摘要

本 SEP 为 MCP 扩展定义了一套成熟度生命周期。扩展从 Experimental 起步，可以进入 Beta，然后要么以扩展形态成为 Stable，要么被晋升进核心规范。存放扩展规范的目录表明其阶段（specification/experimental/、specification/beta/、specification/stable/）。因此一个 ext-<area> 仓库可以容纳处于不同阶段的扩展，且阶段变化不需要重命名仓库。阶段决定了允许哪些协议变更、由谁批准，以及实现者可以期待何种稳定性。

Experimental 和 Beta 扩展只需扩展维护者批准即可迭代，且可以进行破坏性变更。进入 Beta 与进入 Stable 各需要一份扩展跟踪 SEP。Stable 扩展只随新的核心协议修订发布而变更。晋升进核心规范需要标准跟踪 SEP。

本 SEP 更新了 SEP-2133 定义的扩展生命周期，不改变扩展的协商方式。

动机

SEP-2133 定义了两类扩展：位于 experimental-ext- 仓库、无稳定性承诺的实验性扩展，以及通过扩展跟踪 SEP 毕业、位于 ext- 仓库的官方扩展。它没有成熟度的概念，由此产生两个问题。

官方扩展不带稳定性信号。 扩展跟踪 SEP 是唯一的关卡，而扩展一旦成为官方，SEP-2133 允许其维护者随时变更它，无需核心维护者评审。实现者无从判断一份官方扩展是已经定型，还是仍在返工。各扩展用各自未定义的措辞表达成熟度：ext-auth 使用 specification/stable/ 和 specification/draft/，ext-tasks 把它的 schema 快照标注为 “Stable” 和 “Development”，ext-skills 发布 specification/stable/。

官方扩展的变更时点未定义。 SEP-2133 允许扩展维护者自行选择时机变更官方扩展，并要求每次破坏性变更使用新标识符。实现者需要行为可能变化的可预期时点。协议本身已经提供了这样的时点，因为每个请求都声明协议修订，而 SEP-2663 已经按协议修订定义扩展行为。

SEP-2596 把"特性成熟度分级"留作开放问题，并指向 Kubernetes 的 alpha/beta/GA 模型。本 SEP 就扩展回答了这个问题。

规范

阶段

以上位置是 ext-<area> 仓库内部的路径。参见仓库与目录。

  flowchart LR
    Exp["Experimental<br/>specification/experimental/"]
    Beta["Beta<br/>specification/beta/"]
    Stable["Stable<br/>specification/stable/"]
    Core["核心规范<br/>（扩展已归档）"]

    Exp -->|"扩展跟踪 SEP"| Beta
    Beta -->|"扩展跟踪 SEP"| Stable
    Beta -->|"标准跟踪 SEP"| Core
    Stable -->|"标准跟踪 SEP"| Core

扩展 必须不（MUST NOT） 跳过 Beta，除非核心维护者以记录在案的表决豁免该要求。本 SEP 定稿时已是官方扩展的扩展，在过渡一节中分类。

角色

扩展维护者是该扩展仓库的维护者，列入仓库的 MAINTAINERS.md，正如 ext-tasks 已经做的那样。按照 SEP-2133 对仓库维护者的规定，扩展维护者由核心维护者任命，通常是对应工作组的负责人，或对应兴趣组的主持人。每个扩展 必须（MUST） 至少有一名扩展维护者。

“扩展维护者批准"指由至少一名非作者的扩展维护者批准的 pull request。扩展维护者 应该（SHOULD） 通过对应的工作组或兴趣组协调变更，遵循其决策流程。

核心维护者对每个扩展保留 SEP-2133 赋予他们的权力，包括修改、弃用、归档或移除它的能力。按照治理角色，Lead Maintainer 对本 SEP 中的每项核心维护者决定保留否决权。

仓库与目录

官方扩展位于 ext-<area> 仓库中，仓库 可以（MAY） 按 SEP-2133 允许的方式归组相关扩展。同一仓库中的扩展 可以（MAY） 处于不同阶段。仓库名不含阶段信息，阶段变化时也不改名。

在仓库内部，阶段由存放扩展规范的目录表示。例如（扩展名为示意）：

ext-tasks/
  specification/
    experimental/
      partial-results.md
    beta/
      steering.md
    stable/
      tasks/
        2026-07-28/
        draft/
    archived/

• 每个扩展的规范 必须（MUST） 位于 specification/<stage>/<name>，其中 <stage> 为 experimental、beta 或 stable，<name> 是一个文件或目录。一个扩展 必须不（MUST NOT） 同时出现在多个阶段目录下。
• 阶段目录 必须（MUST） 与扩展的阶段一致，并且是阶段唯一的必备标记。<name> 之下的布局由扩展维护者决定，但 Stable 对修订的要求除外。
• 阶段变更是从一个阶段目录移到另一个阶段目录，或移入 specification/archived/。由扩展维护者发起 pull request 执行移动，并在有要求时链接对应的 SEP，由一名核心维护者批准。这是扩展仓库中唯一需要核心维护者批准的变更。
• 扩展维护者 可以（MAY） 仅凭扩展维护者批准，在 specification/experimental/ 下新增扩展。
• GitHub 不对移动后的路径做重定向。扩展维护者负责更新因移动而失效的链接。
• Schema、SDK 软件包、示例和其他支撑文件 可以（MAY） 位于仓库的其他位置。当它们属于某一个扩展时，应该（SHOULD） 标明所属扩展。
• specification/archived/ 存放已晋升进 Core 或已终止的扩展。参见 Core 与终止扩展。

实验性仓库。 SEP-2133 定义的 experimental-ext-<name> 仓库保持不变。任意维护者 可以（MAY） 创建一个。其中的一切都是 Experimental，因此不需要阶段目录。实验性仓库中的扩展要进入 Beta，需移入某个 ext-<area> 仓库的 specification/beta/ 下。该仓库可以是该领域已有的仓库，也可以是核心维护者新建的仓库。核心维护者 可以（MAY） 通过重命名实验性仓库来创建它，正如他们为 ext-tasks 和 ext-skills 所做的。

以下要求适用于所有阶段：

• 按照 SEP-2133 的要求，每个扩展 必须（MUST） 保持与某个工作组或兴趣组的关联。
• SEP-2133 的许可、贡献者许可授权、商标和反垄断条款适用。
• 每个扩展 必须（MUST） 连同其当前阶段列在 MCP 网站的扩展页面上；Beta 扩展还要列出其预期去向。

SDK 保留 SEP-2133 给予它们的自主权。扩展在每个阶段都保持默认禁用，需要开发者明确选择启用。

Experimental

Experimental 扩展是一个原型。扩展维护者 可以（MAY） 在既有的 ext-<area> 仓库的 specification/experimental/ 下添加一个，任意维护者 可以（MAY） 创建 experimental-ext-<name> 仓库。两者都可以发生在 SEP 起草之前或之后。

• 扩展维护者 可以（MAY） 合并任何变更，包括破坏性变更，无需通知、弃期或核心维护者评审。
• 实现者 必须不（MUST NOT） 期待扩展的两个修订之间兼容。他们 应该（SHOULD） 固定到某个 tag 或 commit。

核心维护者保留随时归档 Experimental 扩展或实验性仓库的能力。

Beta

Beta 扩展是核心维护者愿意让实现者尝试的扩展。目标是真实使用：实现者发现需要改变什么，设计随之迭代。

进入。 由扩展维护者或工作组按照 SEP-2133 与 SEP 指南提交一份扩展跟踪 SEP。它按标准跟踪 SEP 的方式评审，且 SEP-2133 已要求它标识工作组与扩展维护者，并在某个官方 SDK 中有参考实现。SEP 被接受后，扩展移入 specification/beta/<name>，具体见仓库与目录。

预期去向。 Beta SEP 应该（SHOULD） 说明该扩展意在成为 Stable 还是被晋升进 Core。去向是给实现者的信号，不是承诺。扩展维护者 可以（MAY） 在 Beta 期间改变它，由把扩展移出 Beta 的那份 SEP 最终决定。预期去向的改变 应该（SHOULD） 像破坏性变更一样公告。

迭代。 进入之后，扩展维护者批准变更，无需进一步的核心维护者评审。

• 扩展 应该（SHOULD） 优先做增量变更，例如新增可选字段或能力标志，而非破坏性变更。
• 破坏性变更允许，但 应该（SHOULD） 少见并 应该（SHOULD） 成批。
• 每次破坏性变更 必须（MUST） 记入变更日志，并注明引入它的修订。
• 扩展维护者 应该（SHOULD） 在合并破坏性变更前，在工作组或兴趣组渠道公告。
• 扩展维护者 应该（SHOULD） 维护一份已知实现及所获反馈的公开清单。这份清单是进入下一阶段的证据。

退出。 Beta 扩展进入 Stable 或 Core，或被归档。

Stable

Stable 扩展是已发布、持续维护、位于核心规范之外的 MCP 生态组成部分。

进入。 由扩展维护者或工作组提交第二份扩展跟踪 SEP。它遵循与标准跟踪 SEP 相同的评审和接受流程。该 SEP 必须（MUST）：

• 链接 Beta SEP 和扩展的位置，并通过已知实现清单表明该扩展已被真实使用。
• 展示两个相互独立的实现，至少一个客户端侧、一个服务器侧，且二者可互操作。
• 附带一个满足 SEP-2484 对标准跟踪 SEP 要求的一致性场景，除非该扩展没有可观察的协议行为。本 SEP 把 SEP-2484 的要求扩展到把扩展推进到 Stable 的扩展跟踪 SEP。

SEP 达到 Final 后，扩展移入 specification/stable/<name>，扩展维护者发布第一个 Stable 修订。

修订。 Stable 扩展以核心协议修订为键发布修订，例如在 specification/stable/<name>/draft/ 目录旁边放置 specification/stable/<name>/2026-07-28/ 快照。

• 已发布的修订不可变。
• 扩展 只可以（MAY） 在新的核心协议修订作为 Current 发布之时或之后，随新修订一起变更。拟议的变更累积在 draft/ 中，在生效前对实现者可见。
• 发布新修订只需扩展维护者批准。核心维护者不评审。
• 不改变任何实现所受要求的编辑性修正 可以（MAY） 随时作用于已发布的修订。

兼容性。 见标识符与兼容性。

退出。 Stable 扩展可以被晋升进 Core 或被弃用。

Core

属于核心协议的扩展由标准跟踪 SEP 晋升，与其他标准跟踪 SEP 一样评审。提案 可以（MAY） 来自 Beta 扩展或 Stable 扩展。该 SEP 必须（MUST） 引用扩展的仓库和位置。

该特性在某个具体的核心协议修订 R（例如 2027-01-01）中成为核心协议的一部分。R 发布后，以下规则适用：

• R 或更高。 对声明 R 或更高版本的请求，该特性是核心行为。无论是否声明了该扩展标识符它都适用，因此以 R 或更高版本响应的服务器不需要声明该扩展，也不需要用它响应。
• 早于 R。 对声明更早修订的请求，按该扩展最终修订的定义适用。仍支持更早修订的客户端 应该（SHOULD） 继续声明该扩展标识符，让尚未支持 R 的服务器可以回退到扩展行为。
• 何时停止。 当某一方不再支持任何早于 R 的修订时，停止声明该扩展。没有单独的日落期。
• 差异。 核心行为 可以（MAY） 与扩展不同。SEP 必须（MUST） 定义差异，使每个协议修订只有一个确定的行为。

SEP 达到 Final 后，规范文本进入核心 draft。扩展保持当前阶段，直到 R 作为 Current 发布。随后扩展移入 specification/archived/<name>，顶部放置指向核心规范章节和该 SEP 的说明。归档副本保留扩展的最终修订，它仍是对更早协议修订的定义。从那时起，任何变更都是核心规范变更。同一仓库中的其他扩展不受影响。

终止扩展

• 撤回或长期不活跃。 扩展维护者 可以（MAY） 撤回 Experimental 或 Beta 扩展，随后它移入 specification/archived/。对于六个月内既无合并变更、也无工作组或兴趣组活动的 Experimental 或 Beta 扩展，核心维护者 可以（MAY） 将其归档。
• 弃用。 Stable 扩展通过一份扩展跟踪 SEP 弃用，须满足 SEP-2596 对核心特性规定的要求、最短窗口和 Tier 1 SDK 义务。弃用期间它仍位于 specification/stable/ 下，移除时移入 specification/archived/。

被归档的扩展保留其名称、标识符和历史，顶部放置说明归档原因的提示。当仓库中的每个扩展都被归档时，核心维护者归档该仓库；experimental-ext-<name> 仓库则作为整体归档。

标识符与兼容性

本节取代 SEP-2133 中每次破坏性变更 必须（MUST） 使用新标识符的规则。

• 扩展的标识符在创建时固定，不随阶段变化而改变。
• Experimental 与 Beta。 扩展 应该（SHOULD） 优先做增量变更，例如在设置对象中新增可选字段或能力标志，而非破坏性变更。破坏性变更保留同一标识符，标识符在修订之间不携带兼容性承诺。做出破坏性变更的扩展 应该（SHOULD） 在其设置对象中新增或递增 revision 字符串，让对端能检测到不匹配。缺少 revision 表示初始修订。收到未知 revision 的一方 不应该（SHOULD NOT） 启用该扩展。
• Stable。 破坏性变更只出现在以核心协议修订为键的新修订中。对一对通信方而言，扩展的行为就是为其协商的协议修订定义的行为。一个修订 必须不（MUST NOT） 改变已为更早协议修订定义的行为。不需要新标识符。只有当旧行为与新行为必须在同一协议修订下共存时，才使用新标识符。
• 扩展规范 必须（MUST） 说明它的每个修订各适用于哪些协议修订。
• 所有阶段的实现者 应该（SHOULD） 按 SEP-2133 的要求，把从对端收到的扩展数据视为不可信。

过渡

本 SEP 达到 Final 时：

• docs/extensions/overview.mdx 与 docs/community/sep-guidelines.mdx 中的扩展跟踪描述会更新为与本 SEP 一致。
• 扩展页面列出每个扩展及其阶段。
• 既有仓库中的扩展按下表分类。仓库不重命名。每个 ext- 仓库的扩展维护者把其规范移入所示阶段目录，由一名核心维护者批准该移动。

• 被分类的扩展不需要新的 SEP。它们既有的 SEP（包括 ext-server-card 的 SEP-2127）即算作所分阶段的 SEP，且它们保留标识符和线上行为。既有 SEP 未声明预期去向，因此每个 Beta 扩展的扩展维护者在扩展页面上记录一个去向。
• 被分类为 Stable 的扩展自 Final 起遵循修订规则。它们的下一个修订以下一个核心协议修订为键，已发布的规范保留其内容。
• 今天直接位于 specification/ 下的带日期快照和 draft/ 目录（如 ext-apps 和 ext-tasks 中）移入扩展自己的目录，例如 specification/beta/tasks/2026-07-28/。
• ext-auth 继续承载多个扩展，每个都分类为 Stable。它今天的 specification/stable/ 和 specification/draft/ 目录存放的是不同的扩展。两个扩展都移入 specification/stable/，各自获得自己的 draft/ 目录。
• ext-skills 今天发布 specification/stable/，其中 “stable” 指已发布的修订。其规范移入 specification/beta/。
• 承载多个 Experimental 扩展的 experimental-ext- 仓库（如 experimental-ext-tool-annotations）不变。其中请求进入 Beta 的扩展移入某个 ext-<area> 仓库，其余保持不变。

理由

为什么把阶段放进目录而不是仓库名？ 本 SEP 的早期草案使用仓库名（experimental-ext-<name>、beta-ext-<name>、ext-<name>）。那样每个仓库只能有一个阶段，但一个领域往往同时有多个阶段的工作。Tasks 与 Events 工作组计划在稳定当前 Tasks 扩展的同时，让 steering 和中间结果在旁边孵化（agents-wg#29），而 ext-auth 已经把一个扩展放在 specification/stable/ 下、另一个放在 specification/draft/ 下。若阶段进入仓库名，这两处各需第二个仓库，各有自己的维护者文件、issue 和软件包。目录让它们共用一个。这也避免了重命名——GitHub 会为重命名做重定向，但每次阶段变化都会破坏软件包名和模块路径。

目录在每个指向规范的链接中仍然可见，这是 README 横幅或 front-matter 标签做不到的。代价有二。GitHub 不对移动后的路径做重定向，因此指向默认分支上旧路径的链接会断。指向 tag 或 commit 的链接不会断，MCP 网站上的扩展页面是稳定入口。移动也只需要写权限，而重命名需要管理员权限。因此本 SEP 要求由一名核心维护者批准移动。

为什么 Beta 需要 SEP，而 Beta 内的迭代不需要？ Beta 是项目的名字第一次为扩展背书的阶段，因此要经过 SEP-2133 已为官方扩展要求的完整评审。之后的迭代遵循 SEP-2133 的思路：把每次变更都交给核心维护者评审，会让扩展卡在一个本就以月计的流程上。

为什么 Stable 需要第二份 SEP？ Stable 是比 Beta 更强的承诺：行为在一个协议修订内固定。第二次评审让核心维护者在做出承诺前，检验来自 Beta 的证据（真实使用、独立实现和一致性）。

为什么 Stable 扩展只能随核心协议修订变更？ 实现者需要行为变化的已知日期。由于每个请求都声明其协议修订，把扩展修订绑定到核心修订，让变更有生效的落点，而不破坏更早修订上的对端。这也与现行实践一致：ext-tasks 按核心修订快照其 schema，ext-skills 把它的稳定规范固定在 2026-07-28。

为什么 Stable 之前必须有 Beta？ Beta 的目的，是在项目押注一个设计之前获得真实使用。Stable 的证据在 Beta 期间更容易收集，而若证据暴露问题，Beta 扩展的修改成本很低。核心维护者仍可以豁免该要求。

为什么 Beta 扩展要声明预期去向？ Beta 的两个出口设定的预期不同。走向 Core 的扩展之后由核心协议修订定义，其标识符将不再被声明；走向 Stable 的扩展则一直是扩展。实现者决定对 Beta 扩展的采纳深度时，需要知道会走向哪边。去向不具约束力，因为 Beta 的存在正是为了收集决定它的证据。

为什么晋升进 Core 后扩展仍被声明？ 协议修订按请求协商，客户端无法预知服务器是否支持 R。声明该扩展让同一个客户端能同时与 R 两侧的服务器协作，而当双方都在 R 上时，核心行为无需协商。

考虑过的替代方案。

• 把阶段放进仓库名（experimental-ext-<name>、beta-ext-<name>、ext-<name>）。 它把仓库限制在一个阶段，多个阶段并行的领域需要多个仓库，且每次阶段变化都要重命名仓库。见第一问。
• 扩展在前、阶段在后，例如 tasks/beta/spec.md。 它让扩展的路径前缀在各阶段间固定，但读者无法按阶段一览全部扩展，阶段也埋在每条链接的更深处。
• 用核心维护者表决代替 SEP 进入 Beta。 更轻量，但它为官方扩展制造了第二条没有成文的批准路径，且不留设计书面记录。
• 给 Experimental 和 Beta 扩展独立的标识符，例如 io.modelcontextprotocol.experimental/<name>。 它让阶段在线上可见，但每次阶段变化都迫使实现者改代码和标识符。revision 设置以更低成本提供大部分收益。
• 要求每次 Stable 破坏性变更使用新标识符（SEP-2133 原文）。 它让新旧行为无限期共存，迫使两者都被实现。把行为绑定到协商的协议修订，复用了协议已有的机制。

先行实践。 Kubernetes 让特性经历 alpha、beta 和 GA 阶段，各有不同的稳定性承诺和弃用窗口，SEP-2596 已引用。OpenTelemetry Collector 组件带有 development、alpha、beta 和 stable 稳定性级别。Node.js 的 Stability Index 把 API 标记为 experimental 或 stable 等级别。

向后兼容性

本 SEP 只变更流程，不改变任何线上消息。

• 它以上述规则取代 SEP-2133 的标识符规则及创建、迭代和晋升步骤。
• 仓库不重命名，因此仓库 URL、软件包名和模块路径不变。
• 既有 Experimental 仓库不变。
• ext-skills、ext-tasks 和 ext-server-card 分类为 Beta。它们的标识符和线上行为不变。其规范移入 specification/beta/，这会断开默认分支上指向旧路径的链接。
• ext-apps 和 ext-auth 分类为 Stable，其规范移入 specification/stable/。自 Final 起，对它们已发布规范的变更须等待核心协议修订。

安全影响

Experimental 和 Beta 扩展不经核心维护者评审即迭代，因此一个不安全的设计可能在具备安全专业知识的人读到之前就被实现。控制措施有：

• 扩展在每个阶段都保持默认禁用，实现者需明确选择启用。
• 进入 Beta 需要一份扩展跟踪 SEP，包括其中的安全影响一节；进入 Stable 需要第二次完整 SEP 评审。
• 扩展只能通过由一名核心维护者批准的 pull request 进入 specification/beta/ 或 specification/stable/，因此扩展无法展示一个没有 SEP 授予的阶段。
• Stable 变更只随核心协议修订生效，且事前在 draft/ 中可见。
• 核心维护者保留在任何阶段归档扩展的权力，例如在漏洞被报告时。

允许同一标识符在 Experimental 和 Beta 阶段做破坏性变更，意味着针对不同修订构建的两个实现可以协商该扩展，然后误解彼此的数据。实现 必须（MUST） 校验扩展数据（SEP-2133），而 revision 设置（在存在时）让对端可以拒绝它不认识的修订。

参考实现

这是一份 Process SEP，没有协议实现。达到 Final 时，它落地过渡一节列出的文档变更和目录移动。