SEP 指南

本文档描述了如何提交 SEP（Specification Enhancement Proposal，规范增强提案）来提议对 Model Context Protocol 的变更。

什么是 SEP？

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

我们打算将 SEP 作为提议主要新功能、收集社区对问题的意见以及记录已进入 MCP 的设计决策的主要机制。SEP 作者负责在社区内建立共识并记录不同意见。

SEP 作为 markdown 文件维护在规范存储库的 seps/ 目录 中。它们的修订历史作为功能提案的历史记录。

什么内容符合 SEP？

目标是将 SEP 流程保留给需要广泛社区讨论、正式设计文档和决策制定过程历史记录的实质性变更。对于较小、更直接的变更，常规的 GitHub 拉取请求通常更合适。

如果您的变更涉及以下任何内容，请考虑提出 SEP：

  • 新功能或协议变更：任何添加、修改或删除 Model Context Protocol 中功能的变更。这包括：
    • 添加新的 API 端点或方法。
    • 更改现有数据结构或消息的语法或语义。
    • 引入不同 MCP 兼容工具之间互操作性的新标准。
    • 对规范本身的定义、呈现或验证方式进行重大更改。
  • 破坏性变更：任何不向后兼容的变更。
  • 治理或流程变更：任何改变项目决策或贡献指南的提案（如本文档本身）。
  • 复杂或有争议的主题：如果变更可能有多个有效的解决方案或产生重大辩论，SEP 流程提供了必要的框架来探索替代方案、记录理由并在实施开始前建立社区共识。

SEP 类型

有三种 SEP：

  1. 标准跟踪 SEP 描述 Model Context Protocol 的新功能或实现。它还可以描述将在核心协议规范之外支持的互操作性标准。
  2. 信息性 SEP 描述 Model Context Protocol 设计问题，或向 MCP 社区提供一般指南或信息，但不提议新功能。信息性 SEP 不一定代表 MCP 社区的共识或建议。
  3. 流程 SEP 描述围绕 MCP 的流程，或提议对流程的变更（或流程中的事件）。流程 SEP 类似于标准跟踪 SEP，但适用于 MCP 协议本身以外的领域。

提交 SEP

SEP 流程始于 Model Context Protocol 的新想法。强烈建议单个 SEP 包含单个关键提案或新想法。小型增强或补丁通常不需要 SEP，可以通过向 MCP 存储库提交拉取请求注入到 MCP 开发工作流中。SEP 越集中，它往往越成功。

每个 SEP 都必须有一个 SEP 作者——某人使用下面描述的样式和格式编写 SEP，在适当的论坛中引导讨论，并尝试围绕该想法建立社区共识。SEP 作者应该首先尝试确定该想法是否可以作为 SEP。发布到 MCP 社区论坛（Discord、GitHub Discussions）是解决此问题的最佳方式。

SEP 工作流程

SEP 作为拉取请求提交到规范存储库中的 seps/ 目录。标准 SEP 工作流程是：

  1. 起草您的 SEP：作为名为 0000-your-feature-title.md 的 markdown 文件，使用 0000 作为 SEP 编号的占位符。遵循下面描述的 SEP 格式。

  2. 创建拉取请求：将您的 SEP 文件添加到 规范存储库 的 seps/ 目录中。

  3. 更新 SEP 编号：创建 PR 后，修改您的提交以使用 PR 编号重命名文件（例如，PR #1850 变为 1850-your-feature-title.md）并更新 SEP 标题以引用正确的编号。

  4. 寻找赞助者：在您的 PR 中标记维护者列表中的核心维护者或维护者以请求赞助。维护者定期审查开放提案以确定赞助哪些提案。

  5. 赞助者分配自己：一旦赞助者同意，他们将分配自己到 PR 并将 SEP 状态更新为 draft。

  6. 非正式审查：赞助者审查提案，并可能根据社区反馈请求更改。讨论在 PR 评论中进行。

  7. 正式审查：当 SEP 准备就绪时，赞助者将状态更新为 in-review。SEP 进入核心维护者团队的正式审查。

  8. 决议：SEP 可以被 accepted、rejected 或返回进行修订。赞助者相应地更新状态。

  9. 最终确定：一旦被接受，必须完成参考实现。完成后并纳入规范时，赞助者将状态更新为 final。

如果 SEP 在六个月内未找到赞助者，核心维护者可能会关闭 PR 并将 SEP 标记为 dormant。

SEP 格式

每个 SEP 应该包含以下部分：

  1. 前言——简短的描述性标题、每个作者的姓名和联系信息、当前状态、SEP 类型和 PR 编号。
  2. 摘要——正在解决的技术问题的简短（约 200 字）描述。
  3. 动机——动机应该清楚地解释为什么现有的协议规范不足以解决 SEP 解决的问题。对于想要更改 Model Context Protocol 的 SEP，动机至关重要。没有足够动机的 SEP 提交可能会被直接拒绝。
  4. 规范——技术规范应该描述任何新协议功能的语法和语义。规范应该足够详细，以允许竞争的、可互操作的实施。
  5. 理由——理由解释为什么做出特定的设计决策。它应该描述考虑的替代设计和相关工作。理由应该提供社区共识的证据，并讨论在讨论期间提出的重大反对意见或担忧。
  6. 向后兼容性——所有引入向后不兼容性的 SEP 都必须包括描述这些不兼容性及其严重性的部分。SEP 必须解释作者建议如何处理这些不兼容性。
  7. 参考实现——参考实现必须在任何 SEP 被赋予"Final"状态之前完成，但在 SEP 被接受之前不必完成。虽然在编写代码之前就规范和理由达成共识的方法是有价值的，但在解决许多协议细节的讨论时，“粗略共识和运行代码"的原则仍然是有用的。
  8. 安全影响——如果存在与 SEP 相关的安全问题，应该明确写出这些问题，以确保 SEP 的审查者意识到这些问题。

有关完整的文件结构，请参阅 SEP 模板。

SEP 状态

SEP 可以处于以下状态之一：

  • draft：具有赞助者的 SEP 提案，正在接受非正式审查。
  • in-review：SEP 提案已准备好由核心维护者进行正式审查。
  • accepted：SEP 已被核心维护者接受，但仍需要最终措辞和参考实现。
  • rejected：SEP 已被核心维护者拒绝。
  • withdrawn：SEP 已被作者撤回。
  • final：SEP 已最终确定，参考实现已完成。
  • superseded：SEP 已被较新的 SEP 替代。
  • dormant：未找到赞助者并随后关闭的 SEP。

状态管理

**赞助者负责更新 SEP 状态。**这确保状态转换由具有适当权限和上下文的人做出。赞助者：

  1. 直接在 SEP markdown 文件中更新 Status 字段
  2. 为拉取请求应用匹配的标签（例如，draft、in-review、accepted）

markdown 状态字段和 PR 标签应该保持同步。markdown 文件作为规范记录（随提案版本化），而 PR 标签使按状态过滤和搜索 SEP 变得容易。

作者应该通过他们的赞助者请求状态更改，而不是自己修改状态字段或标签。

SEP 审查和决议

SEP 由 MCP 核心维护者团队每两周审查一次。

要使 SEP 被接受，它必须满足某些最低标准：

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

一旦 SEP 被接受，必须完成参考实现。当参考实现完成并合并到主源代码存储库时，状态将更改为"Final”。

SEP 也可以被"拒绝"或"撤回"。被"撤回"的 SEP 可以在以后重新提交。

赞助者角色

赞助者是通过审查流程支持 SEP 的核心维护者或维护者。赞助者的职责包括：

  • 审查提案并提供建设性反馈
  • 根据社区输入请求更改
  • 更新 SEP 状态随着提案在工作流程中进展
  • 在 SEP 准备就绪时启动正式审查
  • 在核心维护者会议上展示和讨论提案
  • 确保提案符合质量标准

报告 SEP 错误或提交 SEP 更新

如何报告错误或提交 SEP 更新取决于几个因素，例如 SEP 的成熟度、SEP 作者的偏好以及您的评论的性质。对于尚未达到 final 状态的 SEP，最好直接在 SEP 的拉取请求中发表评论。一旦 SEP 最终确定并合并，您可以通过创建修改 SEP 文件的新拉取请求来提交更新。

转移 SEP 所有权

偶尔有必要将 SEP 的所有权转移给新的 SEP 作者。一般来说，我们希望保留原始作者作为转移 SEP 的共同作者，但这实际上取决于原始作者。转移所有权的一个好原因是因为原始作者不再有时间或兴趣更新它或完成 SEP 流程，或者已经从网络上消失（例如，无法联系或不回复电子邮件）。转移所有权的一个坏原因是因为您不同意 SEP 的方向。我们试图围绕 SEP 建立共识，但如果不可能，您总是可以提交竞争的 SEP。

版权

本文档放置在公共领域或根据 CC0-1.0-Universal 许可证，以较宽松者为准。