SEP-1850：基于 PR 的 SEP 工作流

社区译文；来源： MCP 29affa6b

摘要

本 SEP 正式确立基于 pull request 的 SEP 工作流，将提案以 Markdown 文件形式存储在 Model Context Protocol 规范仓库的 seps/ 目录中。该工作流使用 pull request 编号作为 SEP 编号，在 Git 中维护版本历史，并取代此前基于 GitHub Issues 的流程。这使基于文件的方式成为编写、评审和接受 SEP 的规范方式。

动机

基于 issue 的 SEP 流程带来了若干问题：

• 内容分散：提案内容散落在 GitHub issue、链接文档和 pull request 中，难以评审和归档。
• 协作困难：在 issue 正文中维护长篇规范，使迭代编辑和多贡献者协作更加困难。
• 版本控制有限：GitHub issue 不具备 Git 所管理文件的同等版本控制能力。
• 状态管理不清晰：该流程缺乏明确机制来跟踪状态转换，并确保不同真相源之间保持一致。

基于文件的工作流通过以下方式解决这些问题：

• 将每份 SEP 与规范本身一起纳入版本控制
• 提供 Git 内置的评审工具、历史记录和搜索能力
• 将 SEP 编号关联到 pull request，消除人工编号管理
• 将所有讨论集中呈现在 pull request 线程中
• 结合使用 PR 标签与文件状态，提高可发现性

规范

1. 规范位置

• 每份 SEP 都位于规范仓库的 seps/{NUMBER}-{slug}.md
• SEP 编号始终是引入该 SEP 文件的 pull request 编号
• seps/ 目录是所有 SEP 的唯一真相源

2. 作者工作流

1. 起草提案：在 seps/0000-{slug}.md 中起草，并使用 0000 作为临时编号
2. 开启 pull request：提交包含 SEP 草案和任何支持材料的 pull request
3. 请求赞助人：从 Maintainers 列表中请求赞助人；在 MAINTAINERS.md 中标记潜在赞助人
4. 获知 PR 编号后：修改提交，将文件重命名为 {PR-number}-{slug}.md，并更新文件头（SEP-{PR-number} 和 PR: #{PR-number}）
5. 等待赞助人指派：赞助人同意后，会将自己指派给该 PR，并把状态更新为 Draft

3. 赞助人职责

赞助人是负责推动 SEP 完成评审流程的 Core Maintainer 或 Maintainer。赞助人的职责包括：

• 评审提案并提供建设性反馈
• 根据社区意见请求更改
• 通过以下方式管理状态转换：
  • 确保 SEP Markdown 文件中的 Status 字段准确
  • 应用匹配的 PR 标签，使其与文件状态保持同步
  • 通过 PR 评论传达状态变更
• 在 SEP 准备就绪时启动正式评审（从 Draft 转为 In-Review）
• 提交 Core Maintainers 审议，确保 SEP 在 Core Maintainer 会议上提出，并由作者和赞助人出席
• 在推进提案前，确保满足质量标准
• 跟踪实现进度，并确保参考实现在进入 Final 状态前完成

4. 评审流程

状态按以下顺序推进：Draft → In-Review → Accepted → Final

其他终止状态：Rejected、Withdrawn、Superseded、Dormant

Dormant 状态：如果一份 SEP 在六个月内未找到赞助人，Core Maintainers 可以关闭该 PR，并将 SEP 标记为 dormant。

参考实现必须通过关联的 pull request 或 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/
• pull request 存在后，issue 应链接到相关文件
• SEP 编号来自 PR 编号，而不是 issue 编号

理由

为什么基于文件？

将 SEP 存储为文件，可以让权威规范与代码一起进行版本管理，这与 PEP（Python Enhancement Proposals）和其他标准组织采用的成功流程一致。此方式能够：

• 通过 Git 提供内置版本控制
• 使用标准代码评审工作流
• 保留所有变更的清晰历史记录
• 支持多贡献者协作
• 与规范仓库自然集成

为什么使用 PR 编号？

使用 pull request 编号可以：

• 消除人工编号产生的竞态条件
• 在提案与讨论之间建立自然的可追溯关系
• 防止编号冲突
• 简化贡献流程
• 保留单一讨论线程用于评审

为什么使用 PR 标签？

在文件状态之外添加 PR 标签可以：

• 无需打开文件即可按状态快速筛选 SEP
• 在 PR 列表中立即显示 SEP 状态
• 支持 GitHub 的搜索和筛选能力
• 补充规范的 Markdown 状态字段
• 降低维护者管理多份 SEP 时的操作成本

将此流程设为主要流程

同时维护两个相互重叠的规范流程，会带来内容分歧风险并使贡献者困惑。将基于文件的方式确立为主要方法可以：

• 降低新贡献者的认知负担
• 确保 SEP 集合的一致性
• 简化赞助人的维护工作
• 与业界最佳实践保持一致

向后兼容性

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

安全影响

除 pull request 的标准代码评审流程外，没有新的安全考量。

参考实现

• 本 pull request（#1850）在 seps/README.md 和 docs/community/sep-guidelines.mdx 中实现了规范说明
• 该流程已更新为基于 PR 的工作流，并通过标签管理状态
• 本 SEP 文档本身就是新格式的一个示例

投票

本 SEP 于 2025 年 12 月 28 日星期五在 Discord 投票中，以 8 票赞成、0 票反对、0 票缺席的结果，获得 MCP Core Maintainers 一致接受。