> ## Documentation Index > Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt > Use this file to discover all available pages before exploring further. # SDK 分级系统 > Model Context Protocol SDK 的功能完整性、协议支持及维护承诺级别 MCP SDK 分级系统确立了官方和社区驱动 SDK 在功能完整性、协议支持及维护承诺方面的明确期望。这有助于开发者选择适合其需求的 SDK，并为 SDK 维护者提供一条明确的路径以提高采用期望。 **关键日期：** * **2026 年 1 月 23 日**：一致性测试可用 * **2026 年 2 月 23 日**：官方 SDK 分级发布 在 1 月 23 日至 2 月 23 日之间，SDK 维护者可以与 一致性测试工作组合作采用测试，并使用下面定义的标准化标签设置 GitHub 问题 跟踪。 ## 概述 SDK 根据功能完整性、维护承诺和文档质量分为三个层级： * **Tier 1**：完全支持的 SDK，具有完整的协议实现，包括所有 非实验性功能和可选能力，如采样和诱导 * **Tier 2**：积极维护的 SDK，致力于完全协议规范支持 * **Tier 3**：实验性、部分实现或专用的 SDK 实验性功能（如任务）和协议扩展（如 MCP 应用）不是 任何层级的必需项。 ## 层级要求 | 要求 | Tier 1：完全支持 | Tier 2：承诺完全支持 | Tier 3：实验性 | | ---------- | -------------------------- | --------------------------------- | ---------- | | **一致性测试** | 100% 通过率 | 80% 通过率 | 无最低要求 | | **新协议特性** | 在新规范版本发布之前，根据特性复杂度按版本商定时间表 | 6 个月内 | 无时间表承诺 | | **问题分类** | 2 个工作日内 | 一个月内 | 无要求 | | **严重缺陷解决** | 7 天内 | 两周内 | 无要求 | | **稳定版本发布** | 需要清晰的版本控制 | 至少一个稳定版本 | 不需要 | | **文档** | 全面，包含所有功能的示例 | 涵盖核心功能的基本文档 | 无最低要求 | | **依赖策略** | 已发布的更新策略 | 已发布的更新策略 | 不需要 | | **路线图** | 已发布的路线图 | 已发布的向 Tier 1 推进的计划或保留在 Tier 2 的说明 | 不需要 | **问题分类** 意味着标记并确定问题是否有效，而非解决问题。 **严重缺陷** 指 P0 问题（详见 [优先级标签](#priority-only-if-actionable) 以获取 详细标准）。 **稳定版本发布** 是明确标记为生产就绪的已发布版本（例如，版本 `1.0.0` 或更高，不带 `-alpha`、`-beta` 或 `-rc` 等预发布标识符）。 **清晰版本控制** 意味着遵循惯用的版本控制模式并记录 破坏性变更策略，以便用户在升级时能够理解兼容性期望。 **路线图** 概述了具体的步骤和工作项，跟踪所需 MCP 规范组件的实施（[一致性测试](#conformance-testing) 中描述的非实验性功能和可选能力），让用户了解即将到来的功能支持情况。 ## 一致性测试 所有 SDK 均使用 [自动化一致性测试](https://github.com/modelcontextprotocol/conformance) 进行评估， 该测试针对已发布的规范验证协议支持。SDK 根据测试结果获得一致性评分： * **Tier 1**：要求 100% 一致性 * **Tier 2**：要求 80% 一致性 * **Tier 3**：无最低要求 一致性评分仅针对 **适用的必需测试** 计算： * 针对 SDK 目标规范版本的测试 * 排除标记为 pending 或 skipped 的测试 * 排除实验性功能测试 * 排除旧版向后兼容性测试（除非 SDK 声称支持旧版） * 排除在一致性仓库中标记为 `disputed` 的测试，直至争议解决 一致性测试通过运行标准化测试 场景并检查协议消息交换，验证 SDK 是否正确实现了协议。请参阅 [层级降级](#tier-relegation) 了解如何 处理临时测试失败。 ## 层级晋升 SDK 维护者可以通过以下方式请求层级晋升： 1. 根据层级要求进行自我评估 2. 在 [modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol) 仓库中开设问题并提供支持证据 3. 通过自动化一致性测试 4. 获得 SDK 工作组维护者的批准 SDK 工作组审查晋升请求并做出最终层级分配。 ## 层级降级 如果最新稳定版本上的现有连续性测试连续 4 周失败，SDK 可能会被移至较低层级： * **Tier 1 → Tier 2**：任何一致性测试失败 * **Tier 2 → Tier 3**：超过 20% 的一致性测试失败 如果问题两个月内仍未得到处理，SDK 也可能会被降级。 ## Issue Triage Labels SDK 仓库必须使用一致的标签，以便启用关于问题处理指标的自动化报告。 层级计算使用这些指标来衡量分类响应时间（从问题创建到 首次标记的时间）和严重缺陷解决时间（从 P0 标记到问题关闭的时间）。 ### 类型（选一个） | 标签 | 描述 | | ------------- | -------- | | `bug` | 某些功能无法工作 | | `enhancement` | 请求新功能 | | `question` | 请求更多信息 | 使用 [GitHub 原生问题类型](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization) 的仓库满足此要求，无需类型标签。 ### 状态（选一个） 在所有仓库中使用这些确切的标签名称，以启用一致的报告和分析。 | 标签 | 描述 | | -------------------- | ------------ | | `needs confirmation` | 不清楚是否仍然相关 | | `needs repro` | 信息不足以复现 | | `ready for work` | 已有足够信息可以开始 | | `good first issue` | 适合新人 | | `help wanted` | 欢迎熟悉代码库的人士贡献 | ### 优先级（仅当可操作时） | 标签 | 描述 | | ---- | ---------------- | | `P0` | 严重：核心功能故障或高严重性安全 | | `P1` | 影响许多用户的重大缺陷 | | `P2` | 中等问题，有价值的功能请求 | | `P3` | 锦上添花，罕见的边缘情况 | **P0（严重）** 问题是： * **安全漏洞**，CVSS 评分 ≥ 7.0（高或严重级别） * **核心功能故障**，阻止基本 MCP 操作：连接建立、 消息交换或使用核心原语（工具、资源、提示）