12.2 SEP 协议改进流程
🎯 学习目标：看懂 MCP 的治理机制，知道一条协议变更从想法到落地要经过什么 ⏱️ 预计时间：30 分钟 📊 难度等级：⭐⭐⭐（偏流程，代码很少）
📌 一句话结论：MCP 的每一次重要变更背后都有一份 SEP（Specification Enhancement Proposal，规范改进提案）。你在 11.1 协议版本演进 里看到的
SEP-2575、SEP-2243这类编号，指的就是它们。理解 SEP，你才能判断一项变更"是定了还是还在讨论"。
🤔 SEP 是什么
SEP 是 MCP 社区用来提出协议变更、收集意见、并记录设计决策的主要机制。
- 它是一份 markdown 设计文档，托管在规范仓库的
seps/目录 - 它要给出简洁的技术规范（这个特性到底怎么定义）和动机（为什么现有规范不够）
- SEP 作者负责在社区里建立共识，并记录反对意见——不是压掉，而是写下来
撰写前建议先读 MCP 设计原则，它说明了指导协议演进的核心价值与取舍。
✅ 什么时候该写 SEP
SEP 流程是给"足够重大、需要社区广泛讨论 + 正式设计文档 + 历史记录"的变更准备的。小改动直接提 GitHub PR 更合适。
该写 SEP：
| 情形 | 例子 |
|---|---|
| 新特性或协议变更 | 新增/修改/移除 API 方法、消息格式变化、互操作标准 |
| 破坏性变更 | 任何不向后兼容的改动 |
| 治理或流程变更 | 修改决策方式、贡献指南 |
| 复杂或有争议的话题 | 存在多个合理方案、容易引发争论 |
不该写 SEP（走普通 PR）：
- Bug 修复与错别字订正
- 文档澄清
- 给既有特性补示例
- 不改变行为的次要 schema 修正
💡 拿不准？先到 Discord 问问，别一上来就闷头写大文档。
📚 SEP 的四种类型
| 类型 | 含义 |
|---|---|
| Standards Track | 描述 MCP 的新特性或实现，或核心规范之外支持的互操作标准 |
| Informational | 描述设计问题、或提供指南/信息，不提出新特性 |
| Process | 描述 MCP 的某个流程，或提出流程变更（本文档本身就是 Process SEP） |
| Extensions Track | 描述一个扩展。评审与通过流程和 Standards Track 相同，但标明它是扩展而非核心协议新增，见 12.3 官方扩展体系 |
🔄 SEP 生命周期
状态含义
| 状态 | 含义 |
|---|---|
draft | 已有赞助人，正在非正式评审 |
in-review | 准备进入核心维护者正式评审 |
accepted | 已批准，等待实现与一致性测试 |
rejected | 被核心维护者否决 |
withdrawn | 作者主动撤回 |
final | 实现与一致性测试均已完成 |
superseded | 被更新的 SEP 取代 |
dormant | 6 个月内未找到赞助人；可复活 |
⚠️
dormant≠rejected。休眠只是"没找到赞助人"，想法本身可能依然成立。如果情况变化（社区有了新兴趣、出现新用例），可以找到赞助人并重开 PR 复活它。
🪜 提案的九个步骤
- 起草：以 markdown 文件形式写，命名为
0000-your-feature-title.md（0000是占位符） - 提 PR：把 SEP 文件加到规范仓库的
seps/目录 - 更新编号：PR 建好后，用 PR 编号重命名文件（PR #1850 →
1850-your-feature-title.md），并同步更新头部 - 找赞助人：从维护者名单里 @ 一位与你提案领域相关的核心维护者/维护者（只 @ 1–2 位，别群发）
- 赞助人认领：赞助人同意后把自己指派到 PR，并把状态改成
draft - 非正式评审：赞助人审阅、可能要求修改，讨论在 PR 评论里进行
- 正式评审：就绪后赞助人把状态改为
in-review，进入核心维护者正式评审（每两周一次会议） - 裁决：可能
accepted、rejected，或退回修改，由赞助人更新状态 - 定稿：通过后需完成参考实现，且对可观测协议行为的 Standards Track SEP 还须合并一致性测试；作者把规范变更（schema、规范文本、changelog 条目）加入 PR。SDK 实现不是必需项。完成赞助人把状态改为
final，PR 可合并
提高通过率的三个诀窍
- 先在相关工作组/兴趣组（WG/IG）的 Discord 频道讨论——这是打磨提案、建立早期支持最有效的一招
- 没有对口组，就去 GitHub Discussions 或
#general起个话题；如果反响热烈，值得先建一个新的 IG/WG - 对齐核心维护者的优先级与设计原则——优先级一般体现在项目路线图里；不在当前优先级、或与设计原则冲突的提案，大概率会拖很久
🧑💼 赞助人（Sponsor）的角色
赞助人是一位为核心维护者或维护者，负责推动 SEP 走完评审：
- 审阅提案、给出建设性反馈
- 依据社区意见要求修改
- 更新 SEP 状态（作者应通过赞助人请求状态变更，而不是自己改状态字段）
- 在就绪时启动正式评审
- 在核心维护者会议上介绍并讨论提案
💡 状态以 markdown 文件的
Status字段为规范记录，PR 标签便于筛选检索，两者要同步。
📏 通过标准与原型要求
SEP 通过需满足：有原型实现 + 对生态有明确收益 + 社区支持与共识。
合格的原型：
- 官方 SDK 里的可运行实现（分支/fork 即可）
- 演示关键机制的独立 PoC
- 展示目标行为的集成测试
- 实现了该特性的参考服务器或客户端
不合格：
- ❌ 只有伪代码
- ❌ 没有代码的设计文档
- ❌ "相信我，能跑"——评审者要看得到
原型不必生产可用，它的作用是证明可行、提前暴露边界问题。
🧪 一致性测试要求（Conformance）
对引入或修改可观测协议行为的 Standards Track SEP，必须先在 一致性测试仓库 合并一个一致性场景，SEP 才能到达 final。
需要提交：
- 一个带 SEP 编号标签的一致性场景，针对一致性仓库的 draft spec 版本标签
- 一个结构化的可追溯文件
sep-NNNN.yaml，把 SEP 规范章节里每一条 MUST/MUST NOT 和 SHOULD/SHOULD NOT 映射到某个检查 ID，或记录为"有据可依的排除项"（若属框架缺口则附跟踪 issue） - 该场景能针对 SEP 的参考实现通过
豁免： Process 与 Informational SEP；无可观测协议行为的 Standards Track SEP（文档澄清、不参与校验的 schema 注解、实现加固建议）。
💡 在 SEP 起草阶段（正式评审前）就写一致性场景是受鼓励但非强制的——它常能提前暴露规范措辞里的歧义，此时改最便宜。
📄 SEP 文档的八个部分
| 部分 | 作用 |
|---|---|
| 1. Preamble | 标题、作者与联系方式、状态、类型、PR 编号 |
| 2. Abstract | 约 200 词，说明要解决的技术问题 |
| 3. Motivation | 为什么现有规范不够——动机不足可能被直接否决 |
| 4. Specification | 语法与语义的技术规范，细到足以支撑多方互操作实现 |
| 5. Rationale | 为什么这样设计、考虑过哪些替代方案、相关工作总结 |
| 6. Backward Compatibility | 所有引入不兼容的 SEP 必须描述不兼容点、严重程度与应对 |
| 7. Reference Implementation | 到达 Final 前必须完成，但不必在通过前完成 |
| 8. Security Implications | 必须显式记录相关安全问题 |
❌ 被否决之后
否决不等于永久出局。你可以：
- 正面回应反馈——针对具体顾虑修改后重提
- 讨论否决理由——去 Discord 问清楚
- 提交竞争性 SEP——有时换个方案更好
- 等时机成熟——社区需求会变，今天被拒的可能明天被欢迎
另外：已到达 final 的 SEP 是历史记录，不再更新。若规范其后又变了，以当前规范为准。
💡 怎么用 SEP 读懂 changelog
回到 11.1 协议版本演进，你会看到很多带编号的变更。对照思路是：
| 你看到的 | 它告诉你 |
|---|---|
| 出现在某版本 changelog 里 | 该 SEP 已 accepted 并随版本发布，可以按此实现 |
只在 seps/ 目录里、状态 draft/in-review | 还在讨论，别急着按它写生产代码 |
出现在 draft 版规范里 | 下一版的候选，随时可能变 |
状态 dormant | 想法搁置，尚未成定论 |
举几个 2026-07-28 相关的例子：SEP-2575（无状态 MCP）、SEP-2243（HTTP 标准化，引入 Mcp-* 头）、SEP-2549（结果缓存 ttlMs/cacheScope）、SEP-2577（Roots/Sampling/Logging 废弃）、SEP-2663（Tasks 转为扩展）。