SEP-2484：Standards Track SEP 达到 Final 状态前必须具备一致性测试

社区译文；来源： MCP 29affa6b

摘要

本 SEP 在 Standards Track SEP 的 Accepted → Final 转换中增加一项一致性测试要求。会改变可观察协议行为的 Standards Track SEP 在标为 Final 前，覆盖其规范性要求的一致性场景必须合并到 conformance 仓库，并附带结构化的可追溯文件，将每项 MUST/MUST NOT 和 SHOULD/SHOULD NOT 映射到一项检查或有记录的排除项。这样可以让一致性套件随规范演进保持同步，为 SDK 维护者提供可执行的实现目标，并使 SEP-1730 中的等级百分比真正衡量规范覆盖率。Process 和 Informational SEP 不受此要求约束；不包含可观察协议行为的 Standards Track SEP 也不受约束。

动机

规范与实现之间的差距

MCP 规范以英语编写。SDK 维护者将这些英语文本转化为代码，每次转化都可能产生偏差。SEP-1730（SDK 分级）已经依赖一致性测试（Tier 1 要求通过率为 100%，Tier 2 要求为 80%），但没有机制保证测试套件与规范同步。当一项 SEP 达到 Final 时，SDK 维护者根据文字描述实现，并只能寄希望于自己的解释与其他 SDK 相同。一致性测试可能稍后才出现，甚至根本不会出现；而测试出现时，有时会揭示两个“符合规范”的 SDK 实际行为不一致。

为什么现有的参考实现要求还不够

参考实现证明该特性能够构建出来：它代表一种有效解释。一致性测试定义每个实现都必须做到什么：它把规范性要求转化为可执行断言。TypeScript 参考实现几乎无法告诉 Rust 维护者其代码是否正确；一致性测试则能给出明确答案，而当它无法给出答案时，这种分歧会暴露规范本身的歧义。

让一致性套件持续有效

一致性套件是 SEP-1730 等级百分比所使用的标尺。如果它落后于规范，一个 SDK 即使缺少重要规范特性，也可能被判定为“100% compliant”。把测试与 SEP 生命周期绑定会形成强制机制：测试套件与规范以完全相同的速度增长。

规范

范围

此要求仅适用于引入或修改可观察协议行为的 Standards Track SEP：符合规范的对等方能够通过检查线上的消息、传输层可观察副作用（HTTP 状态码、header、连接生命周期、OAuth 重定向），或本地传输中的进程级可观察副作用（stdio 流内容、退出码）检测到的行为。

以下情况不受此要求约束：

• Process SEP（治理、工作流、社区结构）
• Informational SEP（不具规范效力的指引和最佳实践）
• 不包含可观察协议行为的 Standards Track SEP，例如：
  • 仅以文档澄清既有行为
  • 不改变验证或运行时行为的 schema annotation
  • 描述实现加固、而非线级要求的安全建议

一致性套件本身不限于官方 SDK。任何实现（官方 SDK、社区 SDK 或自定义部署）都可以运行该套件并报告符合度百分比。

要求

适用范围内的 Standards Track SEP 要从 Accepted 转为 Final，必须满足：

1. 一个一致性场景已合并到 conformance 仓库，使用 SEP 编号作为标签，并以 conformance 仓库为即将发布版本设置的 draft 规范版本标签为目标。
2. 场景附带一个可追溯文件。详见下文。
3. 该场景通过 SEP 参考实现的测试。

该规范版本发布时，场景的规范版本标签会作为正常发布流程的一部分，从 draft 标签更新为带日期的版本。conformance harness 和被测 SDK 都必须将 draft 标签识别为可协商的协议版本，才能实际执行这些新要求。

可追溯文件

可追溯文件是 conformance 仓库中的结构化文件（sep-NNNN.yaml）。它把 SEP“规范”一节中的每项规范性要求映射到执行该要求的检查，或者记录该要求被排除的原因：

sep: 1234
spec_url: https://modelcontextprotocol.io/specification/draft/section#anchor
requirements:
  - check: sep-1234-foo-present
    text: "MUST include `foo` in the response"
  - check: sep-1234-bar-absent
    text: "MUST NOT send `bar` before initialization"
  - check: sep-1234-qux-present
    text: "SHOULD include `qux` when available"
  - check: sep-1234-baz-rejected
    text: "MUST reject requests with invalid `baz`"

  - text: "MUST retry on 503"
    excluded: "Requires fault injection; not currently supported by framework"
    issue: https://github.com/modelcontextprotocol/conformance/issues/N
  - text: "MUST be rendered in a monospace font"
    excluded: "Client rendering; not observable at the protocol level"

结构化数据使工具能够把检查失败链接回相应的规范章节，也使 conformance CLI 能够按 SEP 报告覆盖率。

排除分为两类。框架缺口（行为可观察，但框架目前无法表达）应该链接一个跟踪 issue。协议层不可观察（要求约束客户端渲染、实现内部或类似事项）只需要填写 excluded 原因。如果某项 SEP 的所有要求都属于第二类，则它不受此要求约束，完全不需要场景。

发起人负责验证可追溯文件完整：SEP“规范”一节中的每一项 MUST、MUST NOT、SHOULD 和 SHOULD NOT（以及 RFC 2119 中的同义词：SHALL、REQUIRED、RECOMMENDED）都有一行记录。针对 SHOULD 级要求的检查报告警告而不是失败。MAY 要求不需要记录。发起人不评审测试代码；测试代码由 conformance 仓库按正常 PR 流程评审。哪些内容属于规范性要求，由发起人判断。

谁来编写测试

发起人负责确保有人编写一致性场景。场景使用 TypeScript 编写；不熟悉 conformance 仓库的贡献者应从其 CONTRIBUTING 指南开始。实践中，SEP 作者往往最适合完成这项工作，因为编写测试会暴露规范性语言中的歧义，而在 SEP 达到 Final 前修复这些歧义的成本低于之后再修复。

规范正文具有权威性

一致性测试从规范正文派生，并且从属于规范正文。当测试与规范不一致时，以规范为准，测试属于 bug。

一致性测试争议

如果实现者认为已合并的一致性测试与规范矛盾，应在 conformance 仓库中创建 issue，并引用具体的规范正文。conformance 维护者添加 disputed 标签后，该测试即视为存在争议；争议测试在解决前不影响 SEP-1730 的等级评估。

大多数争议通过正常 issue 分类流程解决：修复测试、澄清规范，或说明理由后关闭争议。如果分歧属于根本性问题（提出争议的一方与 conformance 维护者无法就规范含义达成一致），任一方都可以单方面升级给 Core Maintainers 裁决；但更希望双方共同升级，因为目标是消除歧义，而不是在争论中取胜。如果场景 PR 因非技术原因受阻，发起人也可以使用相同的升级路径。

测试稳定性与分级

SEP-1730 的等级评估针对一个固定的一致性发布版本运行，而不是针对 conformance 仓库的最新提交运行。SEP 达到 Final 后新增到其场景中的检查（无论是额外的边界情况，还是覆盖此前排除的要求）会进入 conformance 仓库的 main 分支，但只有下一轮等级评估采用更新的一致性版本时，才会影响等级百分比。

这意味着 SDK 维护者在两轮等级评估之间拥有稳定目标，同时一致性套件可以持续演进，不会意外导致等级状态回退。

发起人职责

SEP-1850 要求发起人在把 SEP 标为 Final 前跟踪参考实现进展。本 SEP 扩展了该职责：对于适用范围内的 Standards Track SEP，发起人还要确认使用 SEP 编号标记的一致性场景已经合并，并附有完整的可追溯文件；如果属于例外，则确认 SEP 中已经记录该例外。

与 SEP-1730（SDK 分级）的关系

本 SEP 在不改变 SEP-1730 等级定义或阈值的前提下强化其基础。等级评估使用固定的一致性发布版本，因此新增检查不会追溯影响等级状态。争议测试在解决前不计入等级百分比。

覆盖既有规范行为（不关联新 SEP）的场景贡献仍然受到欢迎，并且不要求附带可追溯文件。

与 SEP-1627（一致性测试）的关系

本 SEP 接受 conformance 仓库作为一致性测试的规范存放位置，并正式确定它在 SEP 生命周期中的作用，因此取代 SEP-1627。SEP-1627 的 golden trace 方案没有被继承；场景与检查模型用语言中立的 fixture 换取运行时表达能力。SEP-1627 的协议调试器构想仍然是有价值的未来工作。

理由

为什么限制 Final 而不是 Accepted？

如果限制 Accepted，就必须在 Core Maintainers 同意该特性应纳入规范之前编写测试，这会把精力浪费在最终被拒绝的 SEP 上。

不过，在 SEP 起草_期间_编写一致性测试通常很有价值：它会迫使 MUST/MUST NOT 语言足够精确，并暴露正文略过的边界情况。尤其对于包含复杂行为要求的 SEP，鼓励作者在 Core Maintainer 评审前起草一致性场景。这不是必需条件，因为小型 SEP 可能不值得为此预先投入，而被拒绝 SEP 的测试也会成为无效工作。

限制 Final 会把硬性要求放在参考实现要求已经所在的位置：SEP 已经达成共识，剩余工作是实现。

为什么需要可追溯文件？

如果不定义覆盖标准，每项 SEP 都会重新争论“有一致性测试”的含义：一项检查是否足够，还是必须覆盖每个 MUST？可追溯文件使覆盖范围可以审计：每项规范性陈述都有一行记录，每一行要么对应检查，要么对应有记录的排除项。“足够”因此变成“文件完整”。

该文件也让缺口清晰可见。一项 SEP 如果有十项 MUST，却有八项被排除，就是一个信号：要么该 SEP 确实难以测试（跟踪 issue 会说明原因），要么测试作者过早停止（发起人应该要求补齐）。

为什么由发起人承担编写责任？

发起人已经负责推动 SEP 完成评审、跟踪参考实现并管理状态转换。在这个既有角色上增加“确保有人编写一致性测试”，只增加少量职责，并且给出了明确的责任人。

已考虑的替代方案

要求在 SEP PR 中包含一致性测试。 拒绝：这会把由不同维护者负责的两个独立评审流程绑定在一起，也会耦合二者的 CI。

仅限制“重大”SEP。 拒绝：“重大”是主观判断。可观察行为这一范围是客观的：符合规范的对等方要么能够检测到变化，要么不能。

让 conformance 维护者判断测试是否充分。 拒绝：这会把否决权集中到一个并非经选举负责批准规范变更的群体。可追溯文件模型使发起人无需阅读测试代码即可验证完整性。

向后兼容性

本 SEP 不追溯适用。在本 SEP 生效前已达到 Final 的 SEP 无需补充一致性测试，但仍欢迎相关贡献。

安全影响

没有直接影响。用于验证安全相关行为（认证流程、输入验证、传输安全）的一致性测试可以捕获回归，从而改善生态系统的安全状况；但除了底层 SEP 中的 MUST 要求外，本 SEP 不强制增加安全特有的覆盖。

参考实现

conformance 仓库已经展示了本 SEP 所正式确立的场景标记模式：

• JsonSchema2020_12Scenario——SEP-1613
• ElicitationDefaultsScenario——SEP-1034
• ServerSSEPollingScenario——SEP-1699
• ElicitationEnumsScenario——SEP-1330

结构化可追溯文件格式和场景脚手架工具（npx @modelcontextprotocol/conformance new-scenario --sep <number>）将在本 SEP 达到 Final 前加入 conformance 仓库。

流程变更通过更新 docs/community/sep-guidelines.mdx 实现，在 Accepted → Final 转换中增加一致性检查（参见本 PR 中随附的变更）。

达到 Final 状态的前置条件

本 SEP 自身标为 Final 前，必须完成以下 conformance 仓库工作：

• 结构化可追溯文件格式（sep-NNNN.yaml）及其 schema
• 场景脚手架工具
• conformance harness 支持将 draft 规范版本标签作为可协商的协议版本
• 发布 MAINTAINERS.md，并在 MCP 治理文档中列出该仓库

这些是本 SEP 自身的参考实现检查清单，不是持续适用的流程要求。