• 状态（Status）: Final
• 类型（Type）: Process
• 创建（Created）: 2025-11-20
• 接受（Accepted）: 2025-11-28，Discord 投票 8 赞成、0 反对、0 缺席。
• 作者（Author(s)）: Nick Cooper (@nickcoai), David Soria Parra (@davidsp)
• 担保人（Sponsor）: David Soria Parra (@davidsp)
• PR: https://github.com/modelcontextprotocol/specification/pull/1850

​

摘要

​

动机

• 内容分散：提案内容散布在 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 及任何支撑材料
3. 从维护者列表请求担保人；从 MAINTAINERS.md 标记潜在担保人
4. 在得知 PR 编号后，修订提交，将文件重命名为 {PR-number}-{slug}.md 并更新头部（SEP-{PR-number} 和 PR: #{PR-number}）
5. 等待担保人指派：一旦担保人同意，他们将自我指派并将状态更新为 Draft

​

3. 担保人职责

• 评审提案并提供建设性反馈
• 基于社区意见请求修改
• 管理状态转换，方式是：
  • 确保 SEP markdown 文件中的 Status 字段准确
  • 应用匹配的 PR 标签，使其与文件状态保持同步
  • 通过 PR 评论沟通状态变化
• 在 SEP 就绪时发起正式评审（从 Draft 转为 In-Review）
• 提交给核心维护者，确保该 SEP 在核心维护者会议上呈现，且作者和担保人到场。
• 在推进提案之前确保满足质量标准
• 跟踪实现进度，并确保参考实现在 Final 状态之前完成

​

4. 评审流程

​

5. 文档

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

​

6. 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 编号

​

理由

​

为何基于文件？

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

​

为何使用 PR 编号？

• 消除手动编号的竞态条件
• 在提案与讨论之间创造天然的可追溯性
• 防止编号冲突
• 简化贡献流程
• 为评审维护单一的讨论话题

​

为何使用 PR 标签？

• 无需打开文件即可按状态快速过滤 SEP
• 在 PR 列表中即时呈现 SEP 状态
• 支持 GitHub 的搜索和过滤能力
• 补充规范的 markdown 状态字段
• 减少维护者管理多个 SEP 的摩擦

​

将其确立为主要流程

• 减少新贡献者的认知负担
• 确保 SEP 文集的一致性
• 简化担保人的维护
• 与行业最佳实践一致

​

向后兼容性

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

​

安全影响

​

参考实现

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

​

投票