跳到主要内容什么是 SEP？
SEP 代表规范增强提案 (Specification Enhancement Proposal)。SEP 是一种设计文档，旨在向 MCP 社区提供信息，或描述模型上下文协议及其流程、环境的新功能。SEP 应提供该功能的简明技术规范和基本原理。 我们打算将 SEP 作为提议重大新功能、收集社区对某一问题的意见以及记录 MCP 设计决策的主要机制。SEP 作者负责在社区内建立共识并记录不同意见。 SEP 以 markdown 文件的形式维护在规范仓库的 seps/ 目录中。它们的修订历史记录了功能提案的历史过程。什么样的情况符合 SEP 标准？
其目标是将 SEP 流程保留给那些影响重大、需要广泛社区讨论、正式设计文档和决策过程历史记录的变更。对于较小的、更直接的变更，常规的 GitHub pull request 通常更合适。 如果您的变更涉及以下任何内容，请考虑提议 SEP：
- 新功能或协议变更：任何添加、修改或删除模型上下文协议中功能的变更。这包括：
- 添加新的 API 端点或方法。
- 更改现有数据结构或消息的语法或语义。
- 为不同的 MCP 兼容工具之间的互操作性引入新标准。
- 对规范本身的定义、呈现或验证方式进行重大更改。
- 破坏性变更：任何不向后兼容的变更。
- 治理或流程变更：任何改变项目决策或贡献指南的提案（例如本文档本身）。
- 复杂或有争议的话题：如果一项变更可能有多种有效解决方案或引发重大争论，SEP 流程提供了必要的框架，以便在开始实施之前探索替代方案、记录理由并建立社区共识。
SEP 类型
SEP 分为三种类型
- 标准轨道 (Standards Track) SEP 描述了模型上下文协议的新功能或实现。它也可能描述将在核心协议规范之外支持的互操作性标准。
- 信息性 (Informational) SEP 描述了模型上下文协议的设计问题，或向 MCP 社区提供通用指南或信息，但不提出新功能。信息性 SEP 并不一定代表 MCP 社区的共识或建议。
- 流程 (Process) SEP 描述了围绕 MCP 的流程，或提议对流程进行更改（或提议一个事件）。流程 SEP 类似于标准轨道 SEP，但适用于 MCP 协议本身以外的领域。
提交 SEP
SEP 流程始于一个针对模型上下文协议的新想法。强烈建议单个 SEP 仅包含一个关键提案或新想法。小的增强或补丁通常不需要 SEP，可以通过向 MCP 仓库提交 pull request 直接注入到 MCP 开发工作流中。SEP 越集中，往往越容易成功。 每个 SEP 必须有一个 SEP 作者 —— 该作者负责使用下文描述的样式和格式编写 SEP，在适当的论坛中引导讨论，并尝试围绕该想法建立社区共识。SEP 作者应首先尝试确定该想法是否适合作为 SEP。在 MCP 社区论坛（Discord、GitHub Discussions）发布帖子是最好的方式。SEP 工作流
SEP 以 pull request 的形式提交到规范仓库的 seps/ 目录。标准的 SEP 工作流如下：
-
起草您的 SEP，命名为
0000-your-feature-title.md 的 markdown 文件，使用 0000 作为 SEP 编号的占位符。遵循下文所述的 SEP 格式。
-
创建 pull request，将您的 SEP 文件添加到 规范仓库的
seps/ 目录中。
-
更新 SEP 编号：创建 PR 后，修正您的提交，使用 PR 编号重命名文件（例如，PR #1850 变为
1850-your-feature-title.md），并更新 SEP 标题以引用正确的编号。
-
寻找发起人 (Sponsor)：在您的 PR 中标记来自 维护者列表的核心维护者或维护者，请求其发起支持。维护者会定期审查公开提案以决定支持哪一个。
-
发起人指派自己：一旦发起人同意，他们会将自己分配到该 PR，并在 markdown 文件中将 SEP 状态更新为
draft。
-
非正式审查：发起人审查提案，并可能根据社区反馈要求进行修改。讨论在 PR 评论中进行。
-
正式审查：当 SEP 准备就绪时，发起人将状态更新为
in-review。SEP 进入核心维护者团队的正式审查阶段。
-
决议：SEP 可能会被
accepted（接受）、rejected（拒绝）或退回修改。发起人会相应地更新状态。
-
最终确定：一旦被接受，必须完成参考实现。完成后并合并到规范中时，发起人将状态更新为
final。
如果 SEP 在六个月内未找到发起人，核心维护者可能会关闭该 PR 并将 SEP 标记为 dormant（休眠）。
每个 SEP 应包含以下部分
- 前导内容 (Preamble) — 简短的描述性标题、每位作者的姓名和联系信息、当前状态、SEP 类型和 PR 编号。
- 摘要 (Abstract) — 对所处理技术问题的简短描述（约 200 字）。
- 动机 (Motivation) — 动机应清晰地解释为什么现有的协议规范不足以解决该 SEP 所解决的问题。对于想要更改模型上下文协议的 SEP 来说，动机至关重要。缺乏充分动机的 SEP 申请可能会被直接拒绝。
- 规范 (Specification) — 技术规范应描述任何新协议功能的语法和语义。规范应足够详细，以允许竞争性的、互操作的实现。
- 原理 (Rationale) — 原理解释了为什么要做出特定的设计决策。它应描述曾考虑过的替代设计和相关工作。原理应提供社区内达成共识的证据，并讨论在讨论过程中提出的重要反对意见或疑虑。
- 向后兼容性 (Backward Compatibility) — 所有引入向后不兼容性的 SEP 都必须包含一个描述这些不兼容性及其严重程度的部分。SEP 必须解释作者提议如何处理这些不兼容性。
- 参考实现 (Reference Implementation) — 参考实现必须在任何 SEP 状态变为“Final”之前完成，但不需要在 SEP 被接受之前完成。虽然在编写代码之前就规范和原理达成共识的方法很有价值，但在解决许多协议细节讨论时，“大致共识和可运行代码”的原则仍然有用。
- 安全影响 (Security Implications) — 如果与 SEP 相关的安全问题，应明确写出这些问题，以确保 SEP 的审查者知晓。
请参阅 SEP 模板以获取完整的文件结构。
SEP 状态
SEP 可以处于以下状态之一
draft：已有发起人的 SEP 提案，正在进行非正式审查。in-review：准备好接受核心维护者正式审查的 SEP 提案。accepted：核心维护者已接受 SEP，但仍需最终定稿和参考实现。rejected：核心维护者拒绝了 SEP。withdrawn：作者撤回了 SEP。final：SEP 已定稿，参考实现已完成。superseded：SEP 已被较新的 SEP 取代。dormant：未找到发起人并随后被关闭的 SEP。
状态管理
发起人负责更新 SEP 状态。 这确保了状态转换是由具有相应权限和背景的人员进行的。发起人负责：
- 直接在 SEP markdown 文件中更新
Status 字段
- 在 pull request 上应用匹配的标签（例如
draft、in-review、accepted）
markdown 状态字段和 PR 标签应保持同步。markdown 文件作为规范记录（随提案版本化），而 PR 标签便于按状态过滤和搜索 SEP。 作者应通过其发起人请求状态更改，而不是自己修改状态字段或标签。SEP 审查与决议
SEP 由 MCP 核心维护者团队每两周审查一次。 SEP 要被接受，必须满足某些最低标准：
- 演示提案的原型实现
- 对 MCP 生态系统有明显的益处
- 社区支持和共识
一旦 SEP 被接受，必须完成参考实现。当参考实现完成并合并到主源代码库时，状态将更改为“Final”。 SEP 也可以被“拒绝 (Rejected)”或“撤回 (Withdrawn)”。被“撤回”的 SEP 可以在以后重新提交。
发起人是核心维护者或维护者，负责在审查过程中支持该 SEP。发起人的职责包括：
- 审查提案并提供建设性反馈
- 根据社区意见要求进行修改
- 随着提案在工作流中的推进，更新 SEP 状态
- 在 SEP 准备就绪时启动正式审查
- 在核心维护者会议上介绍和讨论提案
- 确保提案符合质量标准
报告 SEP 错误或提交 SEP 更新
您如何报告 bug 或提交 SEP 更新取决于多个因素，例如 SEP 的成熟度、SEP 作者的偏好以及您评论的性质。对于尚未达到 final 状态的 SEP，最好直接在该 SEP 的 pull request 上发表评论。一旦 SEP 最终确定并合并，您可以通过创建修改该 SEP 文件的新 pull request 来提交更新。
转让 SEP 所有权
有时有必要将 SEP 的所有权转让给新的作者。通常，我们希望保留原作者作为转让后 SEP 的共同作者，但这实际上取决于原作者。转让所有权的一个正当理由是原作者不再有时间或兴趣更新它或跟进 SEP 流程，或者已经失联（即无法联系或不回复电子邮件）。转让所有权的一个不正当理由是因为您不同意 SEP 的方向。我们努力围绕 SEP 建立共识，但如果无法达成，您始终可以提交一个具有竞争性的 SEP。
本文档放置于公有领域或采用 CC0-1.0-Universal 许可协议，以两者中更宽松的为准。
