Skip to main content
最终流程
字段值
SEP1850
标题基于 PR 的 SEP 工作流
状态最终
类型流程
创建日期2025-11-20
接受日期2025-11-28, 8 票赞成，0 票反对，0 票缺席，根据 Discord 投票结果。
作者Nick Cooper (@nickcoai), David Soria Parra (@davidsp)
赞助人David Soria Parra (@davidsp)
PR#1850

​
摘要

本 SEP 正式化了基于拉取请求（PR）的 SEP 工作流，将提案作为 markdown 文件存储在 Model Context Protocol 规范仓库的 seps/ 目录中。该工作流根据拉取请求编号分配 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 编号后：修正提交以将文件重命名为 {PR 编号}-{slug}.md 并更新头部（SEP-{PR 编号} 和 PR: #{PR 编号}）
  5. 等待赞助人分配：一旦赞助人同意，他们将分配自己并将状态更新为 草案

​
3. 赞助人职责

赞助人是核心维护者或维护者，负责在审查过程中支持 SEP。赞助人的职责包括：
  • 审查提案并提供建设性反馈
  • 请求更改基于社区意见
  • 管理状态转换通过：
    • 确保 SEP markdown 文件中的 状态 字段准确
    • 应用匹配的 PR 标签以保持与文件状态同步
    • 通过 PR 评论沟通状态更改
  • 启动正式审查当 SEP 准备就绪时（从 草案 移动到 审查中）
  • 提交给核心维护者确保 SEP 在核心维护者会议上展示，并且作者和赞助人出席。
  • 确保质量标准在推进提案之前得到满足
  • 跟踪实现进度，并确保在 最终 状态之前完成参考实现

​
4. 审查流程

状态进展遵循：草案 → 审查中 → 已接受 → 最终 其他终端状态：已拒绝, 已撤回, 已取代, 休眠 休眠状态：如果 SEP 在六个月内没有找到赞助人，核心维护者可以关闭 PR 并将 SEP 标记为 休眠。 参考实现必须通过链接的拉取请求或 issues 进行跟踪，并且在将 SEP 标记为 最终 之前必须完成。

​
5. 文档

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

​
6. SEP 文件结构

每个 SEP 必须包括： 
# SEP-{编号}: {标题}

- **状态**: 草案 | 审查中 | 已接受 | 已拒绝 | 已撤回 | 最终 | 已取代 | 休眠
- **类型**: 标准轨道 | 信息类 | 流程
- **创建日期**: YYYY-MM-DD
- **作者**: 姓名 <email> (@github 用户名)
- **赞助人**: @github 用户名 (或 "无" 如果正在寻找赞助人)
- **PR**: https://github.com/modelcontextprotocol/specification/pull/{编号}

## 摘要

## 动机

## 规范

## 理由

## 向后兼容性

## 安全影响

## 参考实现

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

为了提高可发现性和过滤：
  • 赞助人必须应用与 SEP 状态匹配的 PR 标签（草案, 审查中, 已接受, 最终, 等）
  • markdown 状态 字段和 PR 标签都应保持同步
  • markdown 文件作为规范记录（与提案一起版本化）
  • PR 标签支持按状态轻松过滤和搜索 SEP
  • 只有赞助人应修改状态字段和标签；作者应通过其赞助人请求更改

​
8. 遗留考虑

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

​
理由

​
为什么基于文件？

将 SEP 存储为文件可使权威规范与代码一起版本化，镜像了 PEPs（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 投票中以 8 票赞成、0 票反对和 0 票缺席的结果被 MCP 核心维护者一致接受。