> ## Documentation Index
> Fetch the complete documentation index at: https://mcp-zh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SEP-1302：在 MCP 治理中正式确立工作组和兴趣组

* **状态（Status）**: Final
* **类型（Type）**: Standards Track
* **创建（Created）**: 2025-08-05
* **作者（Author(s)）**: tadasant
* **Issue**: #1302

PR: [https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1350](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1350)

## 摘要

*对所要解决技术问题的简短（约 200 词）描述。*

在 [SEP-994](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1002) 中，我们引入了"工作组"和"兴趣组"的概念，用于促成 MCP 子社区进行讨论和协作。本 SEP 旨在正式定义这两个术语：它们意在实现什么、群组如何创建、如何治理，以及如何退役。

兴趣组通过促成*讨论*来致力于定义 MCP 应当解决的*问题*，而工作组通过协作产出*交付物*（以 SEP 或社区拥有的规范实现的形式）来推进具体的*解决方案*。兴趣组的输入是创建工作组的一个受欢迎（但非必需）的理由。兴趣组或工作组的输入合起来是 SEP 的一个受欢迎（但非必需）的输入。

## 动机

*动机应清晰解释为何现有的协议规范不足以解决该 SEP 所解决的问题。*

社区已经自组织成若干各不相同的协作群组体系：

* 指导小组长期以来有通过 Discord 频道管理少数协作群组的实践（例如 security、auth、agents）。见 [MAINTAINERS.md 底部](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md)。
* "CWG Discord" 有一套[半正式流程](https://github.com/modelcontextprotocol-community/working-groups)用于推进等价的草根倡议，多为产出供 SEP 考量的产物（例如 hosting、UI、tool-interfaces、search-tools）

随着 SEP-994 促成 Discord 社区的合并，我们需要：

* 将既有倡议合并为一种统一的方式，使得当我们提到"工作组"或"兴趣组"时，每个人都知道它意味着什么、该提法可能承载何种分量
* 围绕此类群组的创建（以及最终退役）标准化一套流程
* 恰当区分"工作"组与"兴趣"组；CWG 的经验表明，启动群组的两种截然不同的动机值得以不同的预期和生命周期对待。简言之，"兴趣"组是关于头脑风暴可能的*问题*，"工作"组是关于推进具体的*解决方案*。

这些群组的存在是为了：

* **促成高信噪比的讨论空间**，使得选择接收通知和参加会议的人感到大部分内容与其相关，且他们能够有意义地贡献自己的经验并向他人学习
* **围绕朝着有助于演进 MCP 的具体交付物取得协作进展，创造规范、预期和单一的投入型领导点**

它还将为跨群组倡议奠定基础，例如维护一份线上会议日历。

## 规范

*技术规范应描述任何新协议特性的语法和语义。规范应足够详细，以支持相互竞争、可互操作的实现。应提供一个包含规范变更的 PR。*

### 兴趣组（IG）\[问题]

**目标**：促成对某个 MCP 子话题或上下文有相似兴趣的 MCP 社区成员之间的讨论和知识分享。焦点在于收集*问题*，这些问题可能值得也可能不值得用 SEP 或其他社区产物来解决。

**预期**：

* 每月至少一个实质性的话题/对话
* 和/或一次有 3 名以上无隶属关系个人参加的线上会议

**示例**：

* MCP 中的安全（当前：#security）
* MCP 中的授权（当前：#auth）
* 在企业内部环境中使用 MCP（当前：#enterprise-wg）
* 围绕托管 MCP 服务器的工具和实践（当前：#hosting-wg）
* 围绕实现 MCP 客户端的工具和实践（当前：#client-implementors）

**生命周期**：

* 创建从在 #wg-ig-group-creation Discord 频道填写模板开始
* 社区版主将评审并在（私有）#community-moderators Discord 频道发起投票。成员在 72 小时内的多数赞成票批准群组创建。可随时撤销（例如在更多意见进来之后）。核心和首席维护者可以否决。
* 主持人和维护者负责组织 IG 达到预期
  * 主持人是一个非正式角色，负责引导群组或为群组代言
  * 维护者是来自 MCP 指导小组的官方代表（并非每个群组都需要有）
* IG 只在社区版主或核心+维护者判定其未达到预期时退役
  * 这意味着成功的 IG 将永久存续

**创建模板**：

* 主持人
* 维护者（可选）
* 标记与其他 IG 的潜在重叠
* 本 IG 如何区别于相关的 IG
* 你想讨论的第一个话题

启动 WG，甚至启动 SEP，都不要求身处某个 IG。然而，在 IG 中形成共识以支撑创建 WG 的理由往往是个好主意。类似地，援引 IG 或 WG 对某 SEP 的支持也有助于该 SEP。

### 工作组（WG）\[解决方案]

**目标**：促成 MCP 社区就某个具体 SEP、成主题的系列 SEP，或官方认可的项目进行协作。

**预期**：

* 每月至少朝着一个 SEP 或规范相关实现取得进展，或者对某个项目承担维护职责
* 主持人负责应对社区版主或维护者的状态更新请求

**示例**：

* Registry
* Inspector
* 工具过滤（Tool Filtering）
* 服务器身份（Server Identity）

**生命周期**：

* 创建从在 #wg-ig-group-creation Discord 频道填写模板开始
* 社区版主将评审并在（私有）#community-moderators Discord 频道发起投票。成员在 72 小时内的多数赞成票批准群组创建。可随时撤销（例如在更多意见进来之后）。核心和首席维护者可以否决。
* 主持人和维护者负责组织 WG 达到预期
  * 主持人是一个非正式角色，负责引导群组或为群组代言
  * 维护者是来自 MCP 指导小组的官方代表（并非每个群组都需要有）
* WG 在以下任一情况退役：
  * 社区版主或核心+维护者判定其未达到预期
  * WG 至少一个月没有进行中的 Issue/PR，或已完成其打算推进的所有 Issue/PR。

**创建模板**：

* 主持人
* 维护者（可选）
* 对兴趣/用例的解释（理想情况下来自某个 IG，但可以来自任何地方）
* 你打算产出的第一个 Issue/PR/SEP

### WG/IG 主持人

WG 或 IG 中的"主持人"角色**不**导致在整个 MCP 组织范围的[维护者角色](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md)。它是一个任何人都可以自我提名的非正式角色，负责帮助引导群组内的讨论和协作。

核心维护者保留随时修改任何 WG/IG 的主持人和维护者列表的权利。

我们希望据以推行本 SEP 的文档变更 PR：[https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1350](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1350)

## 理由

*理由解释为何作出特定的设计决策。它应描述所考虑过的替代设计和相关工作。理由应提供社区内共识的证据，并讨论讨论期间提出的重要异议或关切。*

上述设计源自在 CWG Discord 中促成创建并观察非正式"社区工作组"行为的经验，以及领导/参与/观察"指导委员会工作组"的经验。虽然指导 WG 通常由首席维护者非正式创建，但 CWG Discord 有一套轻量的 WG 创建流程，其步骤与上面的提议类似（社区成员会在 #working-group-ideation 中提议 WG，版主会从该协作中创建频道）。

作为先例，这里的 WG 和 IG 概念类似于 W3C 的[工作组](https://www.w3.org/groups/wg/)和[兴趣组](https://www.w3.org/groups/ig/)概念。

### 考量

在提议 WG/IG 设计时，我们考虑了以下几点：

#### 清晰的社区参与入口

对于想投入 MCP 生态的人，一个非常常见的问题是"我如何参与？"

这些 IG 和 WG 抽象有助于提供一个优雅的入口：

1. 加入 Discord，关注与你相关的 IG 中的对话。参加线上会议。参与。
2. 主动主持会议。在 SEP 提案和其他工作中贡献你的用例。
3. 当你觉得可以贡献交付物时，投入到 WG 工作中。
4. 这样做一段时间，被 WG 维护者注意到，从而被提名为新维护者。

#### 对既有治理结构的最小改动

我们不希望此变更引入新的选举、任命或其他领导概念。我们借助社区版主为新群组创建点赞、允许核心维护者否决，维护者身份保持不变，而"主持人"概念是新的但由自我提名，因此不引入任何新的治理流程。

#### 与当前现状对齐

对于既有的"CWG"工作组和指导工作组，有一条清晰的"迁移"路径——只是理清何为"工作"、何为"兴趣"的问题，但在功能上，本提案不干预改变各群组既有结构中一直行之有效的任何东西。

#### 对聚集空间需求的性质

从 CWG 的请求中可以清楚看到，有些群组的形成动机是就某个交付物协作（例如 `search-tools`），而另一些的形成是由于共同兴趣和对子社区的渴望，但尚无具体交付物（例如 `enterprise`）。因此，我们将动机分为工作组与兴趣组。

#### 范围重叠的可能性

在新群组空间的请求中，有时不明显为何需要一个新群组。例如，`enterprise` 所述的动机有时听起来可能只是 `hosting` 的另一种风格。我们最终确定了一种区分，明确其中一个不是另一个的直接子集；但明确群组之间边界（并让社区版主/维护者围绕"什么是正确的抽象层次"集中决策）的关切，正是创建模板中出现诸如"标记与其他 IG 的潜在重叠"之类问题的原因。

#### 退役陈旧群组的路径

旧 CWG 和指导模型中的许多工作组自创建以来已经陈旧。它们没有真正的用途，应当退役。为此，我们引入了群组中主持人和可选维护者的正式概念，以及社区版主退役它们的权利。通过在每个群组中至少设置非正式领导，版主可以在所有人同意继续推进时轻松作出退役某群组的决定。

### 所考虑的替代方案

#### IG 与 WG 之间的层级

我们曾考虑*要求* WG 由一个"发起"IG 拥有或派生，以便向社区更清晰地展现想法的演进；但决定不作此要求，以避免增加新的治理层，并与如今较不正式的群组运作方式对齐。

#### 单一 WG 概念（而非 WG 和 IG 并存）

在 CWG 和指导小组中，围绕"XYZ 真的是一个工作组吗？维护者身份将如何运作？"这一问题存在经常性的张力。通过让 IG 明确以讨论为导向、且维护者参与可选，我们创造了一个推动这些讨论的空间，而不像在定义明确的 WG 中那样要求某种正式的交付物预期。

#### 完全自由的 WG/IG 创建流程

虽然非常社区驱动，但群组重叠的关切会迅速将对话和协作碎片化到难以为继的程度；我们在此需要一个集中的甄别点。

## 向后兼容性

*所有引入向后不兼容的 SEP 都必须包含一个章节，描述这些不兼容之处及其严重性。SEP 必须解释作者提议如何应对这些不兼容。*

对既有群组的日常运作没有建议重大改变——只要各活跃群组保持现有做法，IG 和 WG 所列出的预期就很容易满足。

所有群组的迁移路径列于下方。

## 参考实现

*参考实现必须在任何 SEP 被赋予 "Final" 状态之前完成，但在 SEP 被接受之前无需完成。虽然在写代码之前就规范和理由达成共识的方式有其价值，但当涉及解决许多协议细节的讨论时，"粗略共识与可运行代码"的原则仍然有用。*

以下是对每个群组建议的迁移路径。"迁移"只涉及对本 SEP 和各群组预期的认可，外加可能的最终退役（或在某些情况下立即退役）的方法。

在本 SEP 获批后，我们可以 ping 每个群组，确认他们认可迁移计划。

### 指导工作组

* 所有官方 SDK 群组 --> 工作组
* Registry --> 工作组
* Documentation --> 工作组
* Inspector --> 工作组
* Auth --> 兴趣组 + 一些 WG：client-registration、improve-devx、profiles、tool-scopes
* Agents --> 工作组 \[长时运行 / 异步工具调用；除非我们想在其之上再设一个 Agents IG？]
* Connection Lifetime --> 退役
* Streaming --> 退役
* Spec Compliance --> 退役（好主意但已陈旧；若有人牵头一个新工作组会很好）
* Security --> 兴趣组（也许配一个 Security Best Practices WG？）
* Transports --> 兴趣组
* Server Identity --> 工作组
* Governance --> 工作组（或若此处无更多工作则退役？）

### 社区工作组

* agent-comms --> 退役
* enterprise --> 兴趣组（请求提交提案以启动）
* hosting --> 兴趣组（请求提交提案以启动）
* load-balancing --> 退役
* model-awareness --> 工作组（请求提交提案以启动）
* search-tools（tool-filtering）--> 工作组
* server-identity --> 与指导版对应者合并
* security --> 与指导版对应者合并
* server-identity --> 与指导版对应者合并
* tool-interfaces --> 退役
* ui --> 兴趣组
* schema-validation --> 退役（与指导版对应者相同）