什么是 SEP？
SEP 代表“规范增强提案”（Specification Enhancement Proposal）。SEP 是一份设计文档，旨在为 MCP 社区提供信息，或描述模型上下文协议及其流程的新功能。SEP 应提供该功能的简明技术规范及其背后的基本原理。 SEP 是提议重大新功能、收集社区对某议题的意见，以及记录 MCP 设计决策的主要机制。SEP 作者负责在社区内建立共识并记录不同意见。 在撰写 SEP 时，作者应查阅 MCP 设计原则，该原则概述了引导协议发展的核心价值观和权衡取舍。 SEP 以 Markdown 文件形式维护在规范仓库的seps/ 目录中。其修订历史记录了功能提案的演变过程。何时编写 SEP
SEP 流程仅适用于那些重大到需要广泛的社区讨论、正式设计文档和历史记录的变更。对于较小的改动，普通的 GitHub 拉取请求 (Pull Request) 通常更为合适。 如果您的改动涉及以下内容，请编写 SEP：- 新功能或协议变更 - 添加、修改或删除协议中的功能（新的 API 方法、消息格式变更、互操作性标准）
- 破坏性变更 - 任何不向后兼容的更改
- 治理或流程变更 - 更改决策制定或贡献指南
- 复杂或有争议的话题 - 可能有多种有效解决方案或会引发重大辩论的变更
- 错误修复和错别字更正
- 文档澄清
- 为现有功能添加示例
- 不改变行为的微小架构修复
SEP 类型
SEP 有四种类型- 标准轨道 (Standards Track) - 描述模型上下文协议的新功能或实现，或者核心规范之外支持的互操作性标准。
- 信息类 (Informational) - 描述设计问题或为社区提供指南/信息，而不提议新功能。
- 流程类 (Process) - 描述围绕 MCP 的流程或提议流程变更（如本文档）。
- 扩展轨道 (Extensions Track) - 描述协议扩展。遵循与标准轨道 SEP 相同的审查和验收流程，但表明该提案针对的是扩展而非协议本身。有关扩展的生命周期，请参阅 创建扩展。
SEP 工作流程
分步流程
提高 SEP 被接受概率的方法
- 首先在 Discord 中与相关的工作组或兴趣小组讨论您的想法。 这是完善提案并建立早期支持的最有效方法。
- 如果没有相关小组，请在 GitHub Discussions 或 Discord 的
#general频道中发起对话。 如果有足够的兴趣，也许值得 创建一个新的 IG 或 WG —— 寻找发起人和推动者所付出的努力，是判断该想法是否有足够吸引力的一个良好信号，这也远比冷不丁地提交一份草案要好。 - 检查是否符合核心维护者的优先级和设计原则。 优先级通常反映在 项目路线图中。超出当前优先级或与设计原则冲突的提案，在审查过程中更有可能面临延误或额外的阻力。
-
撰写您的 SEP，将其命名为
0000-your-feature-title.md（以0000作为占位符）。请遵循下方的 SEP 格式。 -
创建拉取请求，将您的 SEP 文件添加到规范仓库的
seps/目录中。 -
更新 SEP 编号：创建 PR 后，根据 PR 编号重命名文件（例如，PR #1850 变为
1850-your-feature-title.md）并更新 SEP 标题。 -
寻找发起人 (Sponsor)：在维护者列表中标记一名核心维护者或维护者。选择领域与您的提案相关的人。小贴士：
- 标记 1-2 位相关维护者，不要标记所有人
- 在相关 Discord 频道分享您的 PR
- 如果 2 周后没有回应，请在
#general中询问
-
发起人自行指派：当发起人同意后，他们会自行指派到该 PR，并将 SEP 状态更新为
draft（草案）。 - 非正式审查：发起人审查提案并可能请求更改。讨论在 PR 评论中进行。
-
正式审查：准备就绪后，发起人将状态更新为
in-review（审查中）。SEP 进入核心维护者的正式审查阶段（每两周开会一次）。 -
决议：SEP 可能被
accepted（接受）、rejected（拒绝）或退回修改。发起人会更新状态。 -
定稿：一旦被接受，必须完成参考实现。对于具有可观察协议行为的标准轨道 SEP，还必须合并一个一致性测试。完成后并整合到规范中，发起人将状态更新为
final（最终）。
SEP 状态
| 状态 | 含义 |
|---|---|
draft (草案) | 已有发起人，正在进行非正式审查 |
in-review (审查中) | 准备进行核心维护者的正式审查 |
accepted (已接受) | 已批准，等待实现 + 一致性测试 |
rejected (已拒绝) | 被核心维护者拒绝 |
withdrawn (已撤回) | 作者撤回了提案 |
final (最终) | 已完成实现和一致性测试 |
superseded (已取代) | 已被更新的 SEP 取代 |
dormant (休眠) | 6 个月内未找到发起人；可以重新激活 |
dormant（休眠）与 rejected（拒绝）不同。休眠的 SEP 只是没有找到发起人 —— 该想法可能仍然有效。如果情况发生变化（新的社区兴趣、新的用例），休眠的 SEP 可以通过寻找发起人并重新开启 PR 来重新激活。
SEP 格式
每个 SEP 应包含以下部分1. 序言
简短的描述性标题、作者姓名/联系方式、当前状态、SEP 类型和 PR 编号。2. 摘要
简短（约 200 字）的描述，说明所处理的技术问题。3. 动机
为什么现有的协议规范是不够的。这一点至关重要 —— 缺乏充分动机的 SEP 可能会被直接拒绝。4. 规范
描述新功能语法和语义的技术规范。必须详细到足以让竞争性、可互操作的实现者参考。5. 基本原理
为什么做出特定的设计决策、考虑过的替代方案以及相关工作。应提供社区共识的证据，并解决讨论中提出的异议。6. 向后兼容性
所有引入向后不兼容性的 SEP 必须描述这些不兼容性、其严重程度以及处理方法。7. 参考实现
必须在 SEP 达到“最终”状态前完成，但在接受前无需完全完成。8. 安全影响
任何与 SEP 相关的安全问题应予以明确记录。 有关完整文件结构，请参阅 SEP 模板。原型要求
在 SEP 被接受之前，您需要“一个证明该提案的原型实现”。以下是符合要求的原型： 可接受的原型：- 在官方 SDK 之一中的工作实现（作为分支/分叉）
- 证明关键机制的独立概念验证 (PoC)
- 展示所提议行为的集成测试
- 实现该功能的参考服务器或客户端
- 证明核心功能如描述般运作
- 展示 API 设计是实用且符合人体工程学的
- 揭示任何边缘情况或实现挑战
- 可供审查者运行（包含设置说明）
- 仅有伪代码
- 没有代码的设计文档
- “相信我，它能用” —— 审查者需要亲眼看到
发起人（Sponsor）角色
发起人是指导 SEP 完成审查过程的核心维护者或维护者。发起人的职责包括：- 审查提案并提供建设性反馈
- 根据社区反馈请求更改
- 随着提案进展更新 SEP 状态
- 在 SEP 准备就绪时启动正式审查
- 在核心维护者会议上介绍并讨论提案
- 确保提案符合质量标准
状态管理
发起人负责更新 SEP 状态。 这确保了状态转换由具有相应权限和背景的人员适当地进行。 发起人：- 直接在 SEP Markdown 文件中更新
Status字段（或者，如果他们没有权限，则与作者协作设置正确的状态） - 将匹配的标签应用到拉取请求（例如，
draft,in-review,accepted）
SEP 审查与决议
SEP 由 MCP 核心维护者团队每两周审查一次。 SEP 若要被接受，必须满足以下标准：- 有证明该提案的原型实现
- 对 MCP 生态系统有明确的益处
- 有社区支持和共识
一致性测试要求
对于引入或修改可观察协议行为的标准轨道 SEP，必须在 SEP 达到Final 状态前，将一致性场景合并到 一致性仓库中。 要求：- 一个标记有 SEP 编号的一致性场景，指向一致性仓库的草稿规范版本标签
- 一个结构化的可追溯性文件 (
sep-NNNN.yaml)，将 SEP 规范部分中的每个 MUST/MUST NOT 和 SHOULD/SHOULD NOT 映射到检查 ID 或记录的排除项（如果是框架缺失，则需要跟踪工单） - 该场景能够通过 SEP 的参考实现测试
- 流程类和信息类 SEP
- 没有可观察协议行为的标准轨道 SEP（文档澄清、非校验性的架构注释、实现加固建议）
- 发起人确保编写一致性场景，并核实可追溯性文件涵盖了 SEP 中的每一个 MUST/MUST NOT 和 SHOULD/SHOULD NOT
- 一致性仓库维护者审查场景 PR 的技术正确性
- 测试作者可以是任何人：SEP 作者、SDK 维护者、社区贡献者
拒绝后的处理
被拒绝并非永久。您可以：- 解决反馈 - 如果提出了具体担忧，解决它们并重新提交
- 讨论拒绝原因 - 在 Discord 中询问以了解原因
- 提交竞争性 SEP - 有时不同的方法效果更好
- 等待时机 - 社区需求在演变；今天被拒绝的可能稍后会被欢迎
报告 SEP 错误或更新
对于尚未达到final 状态的 SEP，直接在 SEP 的拉取请求上发表评论。一旦 SEP 定稿并合并，通过创建新的拉取请求修改 SEP 文件来提交更新。
转移 SEP 所有权
偶尔需要将 SEP 的所有权转让给新作者。通常，我们希望保留原作者作为共同作者，但这取决于原作者的意愿。 转让所有权的合理理由：- 原作者不再有时间或兴趣
- 原作者失联
- 您不同意其方向（请改为提交竞争性 SEP）