SEP 指南

社区译文；来源： MCP 80041ab0

什么是 SEP？

SEP 是 Specification Enhancement Proposal（规范增强提案）的缩写。SEP 是向 MCP 社区提供信息，或描述 Model Context Protocol 及其流程新功能的设计文档。SEP 应提供简洁的功能技术规范及其理由。

SEP 是提出重大新功能、收集社区对某个问题的意见以及记录 MCP 设计决策的主要机制。SEP 作者负责在社区内建立共识，并记录反对意见。

起草 SEP 时，作者应阅读 MCP 设计原则，其中说明指导协议演进的核心价值和取舍。

SEP 以 markdown 文件形式维护在规范仓库的 seps/ 目录中。其修订历史构成功能提案的历史记录。

何时编写 SEP

SEP 流程仅用于重要到需要广泛社区讨论、正式设计文档和历史记录的变更。对于较小变更，普通 GitHub pull request 通常更合适。

变更涉及以下内容时，应编写 SEP：

新功能或协议变更：添加、修改或移除协议功能（新 API 方法、消息格式变更、互操作标准）
破坏性变更：任何不向后兼容的变更
治理或流程变更：改变决策方式或贡献指南
复杂或有争议的主题：可能存在多种有效方案或引发重大争论的变更

以下情况跳过 SEP 流程：

错误修复和拼写修正
文档澄清
为现有功能添加示例
不改变行为的小型 schema 修复

不确定时，请在开始重大工作前到 Discord 询问。

SEP 类型

SEP 分为四类：

Standards Track：描述 Model Context Protocol 的新功能或实现，或者核心规范之外支持的互操作标准。
Informational：描述设计问题，或在不提出新功能的情况下为社区提供指南/信息。
Process：描述围绕 MCP 的流程，或提出流程变更（例如本文）。
Extensions Track：描述协议扩展。它遵循与 Standards Track SEP 相同的评审和接受流程，但表明提案针对扩展而非协议新增内容。扩展生命周期参见创建扩展。

SEP 工作流

  flowchart TD
    Idea["Idea"]
    AwaitingSponsor{"Awaiting Sponsor<br/>(up to 6 months)"}
    Draft["Draft"]
    Dormant["Dormant<br/>(no sponsor)"]
    Withdrawn["Withdrawn<br/>(by author)"]
    InReview["In-Review"]
    Decision{"Core Maintainers decide"}
    Accepted["Accepted"]
    Rejected["Rejected"]
    Final["Final"]

    Idea -->|"Submit PR with SEP file"| AwaitingSponsor
    AwaitingSponsor --> Draft
    AwaitingSponsor --> Dormant
    AwaitingSponsor --> Withdrawn
    Draft -->|"Sponsor reviews"| InReview
    InReview --> Decision
    Decision --> Accepted
    Decision --> Rejected
    Accepted -->|"Reference implementation +<br/>conformance test complete"| Final

分步流程

**必须先讨论。**SEP 作者在创建 SEP pull request 前，必须与相关工作组或兴趣组在 Discord 中讨论想法，且 PR 描述必须链接到该讨论（Discord thread、WG/IG 会议记录或 GitHub Discussion）。没有关联前置讨论的 SEP 不会被接受。如果不存在相关小组，请改在 GitHub Discussions或 Discord 的 #general 频道发起讨论。如果获得足够兴趣，可以考虑创建新的 IG 或 WG。寻找发起人和 Facilitator 所需的投入，是判断想法是否获得足够支持的良好信号。

为提高 SEP 被接受的机会，请检查它是否符合 Core Maintainer 的优先事项和设计原则。优先事项通常体现在项目路线图中。超出当前优先事项或与设计原则冲突的提案，更可能在评审中面临延迟或额外阻力。

与相关小组讨论：将想法带到对应的工作组或兴趣组，并在那里完善。保留讨论链接（Discord thread、会议记录或 GitHub Discussion），以便加入 PR 描述。
起草 SEP：将 SEP 编写为名为 0000-your-feature-title.md 的 markdown 文件，并使用 0000 作为占位符。遵循下文的 SEP 格式。
创建 pull request：在规范仓库的 seps/ 目录中添加 SEP 文件。该仓库只接受 collaborator 创建的 pull request。
更新 SEP 编号：创建 PR 后，使用 PR 编号重命名文件（例如 PR #1850 对应 1850-your-feature-title.md），并更新 SEP 头部。
寻找发起人：从维护者列表中提及 Core Maintainer 或 Maintainer，选择负责提案相关领域的人。提示：
- 提及 1-2 名相关维护者，不要提及所有人
- 在相关 Discord 频道分享 PR
- 如果 2 周后没有响应，请在 #general 中询问
发起人指派自己：发起人同意后，将自己指派到 PR，并将 SEP 状态更新为 draft。
非正式评审：发起人评审提案并可能要求修改。讨论在 PR 评论中进行。
正式评审：准备就绪后，发起人将状态更新为 in-review。在此之前，发起人确认已完成小组讨论，且 PR 描述中包含链接。SEP 进入 Core Maintainer 正式评审（每两周开会）。
决定：SEP 可以变为 accepted、rejected，或退回修订。发起人更新状态。
最终确定：SEP 被接受后，必须完成参考实现。对于具有可观察协议行为的 Standards Track SEP，还必须合并一致性测试。作者在 SEP 的 pull request 中加入规范变更（schema 变更、规范文本和变更日志条目）。SEP 变为 final 不要求完成 SDK 实现。完成这些工作后，发起人将状态更新为 final，SEP 的 PR 即可合并。已合并 SEP 会发布到 SEP 索引，每个 SEP 都可以按编号通过 modelcontextprotocol.io/seps/<number> 访问（例如 /seps/1850）。

SEP 状态

状态	含义
`draft`	已有发起人，正在进行非正式评审
`in-review`	已准备好接受 Core Maintainer 正式评审
`accepted`	已获批准，等待实现和一致性测试
`rejected`	被 Core Maintainer 拒绝
`withdrawn`	作者撤回提案
`final`	已完成实现和一致性测试
`superseded`	已被较新的 SEP 取代
`dormant`	6 个月内未找到发起人；可以恢复

重要区别：dormant 不等同于 rejected。Dormant SEP 只是没有找到发起人，想法本身仍可能有效。如果情况发生变化（出现新的社区兴趣或新用例），可以通过找到发起人并重新打开 PR 来恢复 dormant SEP。

SEP 格式

每个 SEP 应包含以下部分：

1. 前言

简短的描述性标题、作者姓名/联系信息、当前状态、SEP 类型和 PR 编号。

2. 摘要

对所处理技术问题的简短说明（约 200 字）。

3. 动机

说明现有协议规范为何不足。这一点至关重要；动机不充分的 SEP 可能被直接拒绝。

4. 规范

描述新功能语法和语义的技术规范。内容必须足够详细，使彼此竞争的实现能够互操作。

5. 理由

说明为何作出特定设计决定、考虑过哪些替代设计及相关工作。应提供社区共识的证据，并回应讨论中提出的反对意见。

6. 向后兼容性

所有引入向后不兼容的 SEP 都必须说明这些不兼容、严重程度和处理方式。

7. 参考实现

必须在 SEP 达到“Final”状态前完成，但在接受前无需完成。

8. 安全影响

应明确记录与 SEP 有关的任何安全问题。

完整文件结构参见 SEP 模板。

原型要求

SEP 被接受前，需要“一个展示提案的原型实现”。以下内容符合要求：

可接受的原型：

某个官方 SDK 中可运行的实现（分支/fork）
展示关键机制的独立概念验证
展示所提行为的集成测试
实现该功能的参考服务器或客户端

原型应当：

证明核心功能按描述工作
表明 API 设计实用且符合使用习惯
揭示边界情况或实现难题
可由评审者运行（包含设置说明）

以下内容不充分：

只有伪代码
没有代码的设计文档
“请相信它能工作”：评审者需要实际查看

原型不需要达到生产就绪水平，其目的是证明可行性并尽早暴露问题。

发起人角色

发起人是推动 SEP 完成评审流程的 Core Maintainer 或 Maintainer。其职责包括：

评审提案并提供建设性反馈
根据社区意见要求修改
随提案推进更新 SEP 状态
SEP 准备就绪时发起正式评审
在 Core Maintainer 会议中介绍并讨论提案
确保提案符合质量标准

作者应通过发起人请求状态变更，而不是自行修改状态字段。

状态管理

**发起人负责更新 SEP 状态。**这确保状态转换由具备相应权限和背景的人适当地执行。

发起人：

直接更新 SEP markdown 文件中的 Status 字段（如果无权访问源仓库，则与作者协作设置正确状态）
为 pull request 应用匹配标签（例如 draft、in-review、accepted）

markdown 状态字段和 PR 标签应保持同步。markdown 文件是经版本控制的规范记录，PR 标签则便于筛选和搜索。

SEP 评审与决定

MCP Core Maintainer 团队每两周评审一次 SEP。

SEP 必须满足以下标准才能被接受：

有展示提案的原型实现
对 MCP 生态系统有明确益处
获得社区支持和共识

SEP 被接受后，作者在 SEP 的 pull request 中加入规范变更（schema 变更、规范文本和变更日志条目）。必须完成参考实现及所有必需的一致性测试，但不要求完成 SDK 实现。工作完成后，状态变为“Final”，PR 即可合并。

一致性测试要求

对于引入或修改可观察协议行为的 Standards Track SEP，必须先将一致性场景合并到一致性仓库，SEP 才能达到 Final 状态。

必需内容：

使用 SEP 编号标记的一致性场景，目标为一致性仓库的 draft spec-version 标签
结构化追溯文件（sep-NNNN.yaml），将 SEP Specification 部分中的每个 MUST/MUST NOT 和 SHOULD/SHOULD NOT 映射到检查 ID 或有记录的排除项（如果属于框架缺口，还要附跟踪 issue）
场景针对 SEP 参考实现运行通过

豁免范围：

Process 和 Informational SEP
没有可观察协议行为的 Standards Track SEP（文档澄清、不执行验证的 schema 注解、实现加固建议）

职责分工：

发起人确保编写一致性场景，并验证追溯文件覆盖 SEP 中的每个 MUST/MUST NOT 和 SHOULD/SHOULD NOT
一致性仓库维护者评审场景 PR 的技术正确性
测试作者可以是任何人：SEP 作者、SDK 维护者或社区贡献者

我们鼓励在 SEP 起草期间（Core Maintainer 评审之前）编写一致性场景，但不强制要求，因为这通常能尽早发现规范性语言中的歧义，此时修复成本更低。

完整规范（包括追溯文件格式和争议流程）参见 SEP-2484。

被拒绝之后

拒绝并非永久结果。你可以：

处理反馈：如果有人提出具体顾虑，解决后重新提交
讨论拒绝原因：在 Discord 中询问以理解理由
提交竞争性 SEP：有时不同方法会更有效
等待合适时机：社区需求会变化；今天被拒绝的内容未来可能受到欢迎

报告 SEP 错误或更新

对于尚未达到 final 状态的 SEP，请直接在该 SEP 的 pull request 中评论。

Final SEP 作为被接受设计的历史记录保留，最终确定后不再更新。如果 SEP 达到 Final 后规范发生变化，应以当前规范为准。每个 Final SEP 页面都会显示相应通知。

转移 SEP 所有权

有时需要将 SEP 所有权转移给新作者。通常我们希望保留原作者作为共同作者，但最终由原作者决定。

适合转移所有权的理由：

原作者不再有时间或兴趣
无法联系原作者

不适合的理由：

你不同意其方向（应改为提交竞争性 SEP）

版权

本文档置于公有领域或采用 CC0-1.0-Universal 许可证，以限制更少者为准。

Security 兴趣组章程 Server Card 工作组章程