跳到主要内容
已定稿流程
字段取值
SEP 编号1850
标题基于 PR 的 SEP 工作流
状态已定稿
类型流程
创建日期2025-11-20
已接受2025-11-28，根据 Discord 投票：8 票赞成，0 票反对，0 票缺席。
作者Nick Cooper (@nickcoai), David Soria Parra (@davidsp)
赞助人David Soria Parra (@davidsp)
PR#1850

​
摘要

本 SEP 正式确立了基于拉取请求 (Pull Request) 的 SEP 工作流。该工作流将提案作为 Markdown 文件存储在模型上下文协议规范仓库的 seps/ 目录中。工作流从 PR 编号分配 SEP 编号，在 Git 中维护版本历史，并取代了之前基于 GitHub Issues 的流程。这确立了基于文件的方法作为撰写、评审和接受 SEP 的规范方式。

​
动机

基于 Issue 的 SEP 流程带来了多项挑战：
  • 内容分散：提案内容散布在 GitHub issues、链接文档和拉取请求中，导致评审和归档困难。
  • 协作困难：在 issue 正文中维护长篇规范使得迭代编辑和多贡献者协作变得更加困难。
  • 版本控制有限：GitHub issues 无法提供与 Git 管理文件同等的版本控制能力。
  • 状态管理不明：该流程缺乏追踪状态转换及确保不同事实来源之间一致性的明确机制。
基于文件的工作流通过以下方式解决这些问题：
  • 将每份 SEP 与规范本身一起置于版本控制之下
  • 提供 Git 内置的评审工具、历史记录和可搜索性
  • 将 SEP 编号与拉取请求链接，消除手动记录的需要
  • 将所有讨论汇总在拉取请求线程中
  • 结合 PR 标签与文件状态，提高可发现性

​
规范

​
1. 规范位置

  • 每个 SEP 都保存在规范仓库的 seps/{NUMBER}-{slug}.md 中
  • SEP 编号始终是引入该 SEP 文件的拉取请求编号
  • seps/ 目录作为所有 SEP 的唯一事实来源

​
2. 作者工作流

  1. 起草提案：在 seps/0000-{slug}.md 中起草，使用 0000 作为占位编号
  2. 提交拉取请求：包含 SEP 草案及任何支持材料
  3. 请求担保人：从维护者列表中寻找；可以标记来自 MAINTAINERS.md 的潜在担保人
  4. 获知 PR 编号后：修正提交 (amend) 以将文件重命名为 {PR-number}-{slug}.md，并更新文件头（SEP-{PR-number} 和 PR: #{PR-number}）
  5. 等待担保人指派：一旦担保人同意，他们将指派自己并将状态更新为 Draft (草案)

​
3. 担保人职责

担保人 (Sponsor) 是指在评审过程中支持 SEP 的核心维护者或维护者。担保人的职责包括：
  • 评审提案并提供建设性反馈
  • 根据社区意见要求进行更改
  • 管理状态转换，通过：
    • 确保 SEP Markdown 文件中的 Status 字段准确无误
    • 添加匹配的 PR 标签，使其与文件状态保持同步
    • 通过 PR 评论沟通状态变更
  • 在 SEP 准备就绪时启动正式评审（从 Draft 转为 In-Review）
  • 上报给核心维护者：确保 SEP 在核心维护者会议上提交，且作者和担保人出席
  • 在推进提案前确保达到质量标准
  • 追踪实现进度，并确保在进入 Final (最终) 状态前完成参考实现

​
4. 评审流程

状态演进遵循：Draft (草案) → In-Review (评审中) → Accepted (已接受) → Final (最终) 其他终态：Rejected (已拒绝)、Withdrawn (已撤回)、Superseded (已取代)、Dormant (休止) 休止状态：如果 SEP 在六个月内未找到担保人，核心维护者可以关闭 PR 并将该 SEP 标记为 dormant。 参考实现必须通过链接的拉取请求或 issue 进行追踪，且必须在将 SEP 标记为 Final 之前完成。

​
5. 文档

  • docs/community/sep-guidelines.mdx 作为面向贡献者的说明文档
  • seps/README.md 提供关于格式、命名、担保人职责和接受标准的简明参考
  • 两份文档都必须反映此工作流并保持同步

​
6. SEP 文件结构

每个 SEP 必须包含 
# SEP-{NUMBER}: {Title}

- **Status**: Draft | In-Review | Accepted | Rejected | Withdrawn | Final | Superseded | Dormant
- **Type**: Standards Track | Informational | Process
- **Created**: YYYY-MM-DD
- **Author(s)**: Name <email> (@github-username)
- **Sponsor**: @github-username (or "None" if seeking sponsor)
- **PR**: https://github.com/modelcontextprotocol/specification/pull/{NUMBER}

## Abstract

## Motivation

## Specification

## Rationale

## Backward Compatibility

## Security Implications

## Reference Implementation

​
7. 通过 PR 标签进行状态管理

为了提高可发现性和过滤效率
  • 担保人必须添加与 SEP 状态匹配的 PR 标签（draft、in-review、accepted、final 等）
  • Markdown Status 字段和 PR 标签应保持同步
  • Markdown 文件作为权威记录（随提案版本化）
  • PR 标签便于按状态快速过滤和搜索 SEP
  • 只有担保人应修改状态字段和标签；作者应通过其担保人申请更改

​
8. 遗留问题考虑

  • 贡献者可以有选择地开启 GitHub Issue 进行早期讨论，但权威的 SEP 文本存在于 seps/ 中
  • 一旦存在拉取请求，Issue 应链接到相关文件
  • SEP 编号衍生自 PR 编号，而非 Issue 编号

​
基本原理

​
为什么采用基于文件的方式？

将 SEP 作为文件存储可使权威规范与代码同步版本化，这借鉴了 PEP（Python 增强提案）和其他标准组织使用的成功流程。这种方法：
  • 通过 Git 提供内置版本控制
  • 支持标准的代码评审工作流
  • 维护所有更改的清晰历史记录
  • 支持多贡献者协作
  • 自然地与规范仓库集成

​
为什么使用 PR 编号？

使用拉取请求编号：
  • 消除了手动编号带来的竞争条件
  • 在提案与讨论之间建立自然的溯源关系
  • 防止编号冲突
  • 简化贡献流程
  • 为评审维护单一的讨论线程

​
为什么使用 PR 标签？

在文件状态之外增加 PR 标签：
  • 无需打开文件即可按状态快速过滤 SEP
  • 在 PR 列表中提供 SEP 状态的即时可见性
  • 支持 GitHub 的搜索和过滤功能
  • 补充了权威的 Markdown 状态字段
  • 减轻维护者管理多个 SEP 的压力

​
将其设为主要流程

同时维护两个重叠的规范流程会带来背离风险并使贡献者感到困惑。确立基于文件的方法作为主要手段：
  • 减少新贡献者的认知负荷
  • 确保 SEP 库的一致性
  • 简化担保人的维护工作
  • 符合行业最佳实践

​
向后兼容性

  • 现有的基于 Issue 的 SEP 仍然有效，无需迁移
  • 历史 GitHub Issue 链接将继续有效
  • 未来的 SEP 应引用 seps/ 中的新文件位置
  • 维护者可以选择将历史 SEP 补录到 seps/ 中以供归档

​
安全影响

除了拉取请求的标准代码评审流程外，没有新的安全性考虑。

​
参考实现

  • 本拉取请求 (#1850) 在 seps/README.md 和 docs/community/sep-guidelines.mdx 中都实现了规范说明
  • 流程已更新以反映基于 PR 的工作流以及通过标签进行的状态管理
  • 本 SEP 文档本身即作为新格式的示例

​
投票

本 SEP 已于 2025 年 12 月 28 日星期五在 Discord 投票中获得 MCP 核心维护者一致通过（8 票赞成，0 票反对，0 票缺席）。