SEP-1302：将工作组和兴趣组正式纳入 MCP 治理

---

​

摘要

对所解决的技术问题进行简短（约 200 字）的描述。 在 SEP-994 中，我们引入了“工作组”和“兴趣组”的概念，以促进 MCP 子社区的讨论与协作。本 SEP 旨在正式定义这两个术语：它们的预期目标、如何创建组、如何治理以及如何退役。 兴趣组致力于通过促进_讨论_来定义 MCP 应该解决的_问题_，而工作组则通过协作产生_交付物_（形式为 SEP 或规范社区拥有的实现）来推进具体的_解决方案_。兴趣组的输入是创建工作组的欢迎（但非必需）理由。兴趣组或工作组的输入集体作为对 SEP 的欢迎（但非必需）输入。

​

动机

动机部分应清楚解释为什么现有的协议规范不足以解决 SEP 所解决的问题。 社区已经自发组织成几个不同的系统来进行这些协作组：

• 指导组长期以来一直通过 Discord 频道管理少数协作组（例如安全、认证、代理）。参见 MAINTAINERS.md 底部。
• “CWG Discord”社区一直有一个半正式流程来推进类似的基层倡议，主要是为了创建供 SEP 审议的产物（例如托管、UI、工具接口、搜索工具）

随着 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 组织中获得维护者角色。这是一个非正式角色，任何人都可以自我提名，负责帮助引导组内的讨论和协作。 核心维护者保留随时修改任何 WG/IG 的协调员和维护者名单的权利。 我们要实施此 SEP 的文档变更 PR：https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1350

​

理由

理由部分解释了为何做出特定的设计决策。它应描述所考虑的替代设计和相关工作。理由应提供社区共识的证据，并讨论讨论期间提出的重要反对意见或担忧。 上述设计源于促进创建 + 观察 CWG Discord 中非正式“社区工作组”行为的经验，以及领导/参与/观察“指导委员会工作组”的经验。虽然指导工作组通常由首席维护者非正式创建，但 CWG Discord 有一个轻量级的 WG 创建流程，涉及与上述提案类似的步骤（社区成员会在 #working-group-ideation 中提出 WG，管理员会从该协作中创建频道）。 作为先例，这里的 WG 和 IG 概念类似于 W3C 的 工作组 和 兴趣组 概念。

​

考虑因素

在提出 WG/IG 设计时，我们考虑了以下因素：

​

社区参与的清晰入口

对于希望投资 MCP 生态系统的人来说，一个非常常见的问题是，“我如何参与？” 这些 IG 和 WG 抽象有助于提供一个优雅的入口：

1. 加入 Discord，关注与您相关的 IG 中的对话。参加现场呼叫。参与。
2. 主动提出协调呼叫。在 SEP 提案和其他工作中贡献您的用例。
3. 当您觉得可以为交付物做出贡献时，跳进来为 WG 工作做出贡献。
4. 这样做一段时间，被 WG 维护者注意到并被提名为新的维护者。

​

对现有治理结构的最小变更

我们不希望此变更引入新的选举、任命或其他领导概念。我们利用社区管理员来点赞新组的创建，允许核心维护者否决，维护者状态保持不变，“协调员”的概念是新的但是自我提名的，因此不会引入任何新的治理流程。

​

与当前现状保持一致

现有的”CWG”工作组和指导工作组有一个清晰的“迁移”路径——只是弄清楚什么是“工作”与“兴趣”的问题，但功能上此提案不会妨碍改变每个组现有结构中一直有效的任何内容。

​

收集空间请求的性质

从向 CWG 提出的请求中可以清楚地看出，有些组形成的动机是协作完成某些交付物（例如 search-tools），而有些组形成是因为共同兴趣和想要子社区但尚未有具体交付物（例如 enterprise）。因此，我们将动机分为工作组与兴趣组。

​

范围重叠的潜力

在新组空间的请求中，有时并不明显为什么需要存在一个新组。例如，enterprise stated 的动机有时听起来可能只是 hosting 的另一种风格。我们最终确定了一个区分，明确表明一个不是另一个的直接子集，但关于在组之间建立清晰边界（并让社区管理员/维护者集中决策“什么是正确的抽象层”）的担忧导致了创建模板中的问题，例如“标记与其他 IG 的潜在重叠”。

​

退役停滞组的路径

旧 CWG 和指导模型中的许多工作组自创建以来已经停滞。它们没有真正的目的，应该退役。为此，我们引入了组中协调员和可选维护者的正式概念；以及社区管理员退役它们的权利。通过在每个组中至少拥有非正式的领导层，如果每个人都同意继续，管理员可以轻松地做出退役组的决定。

​

考虑的替代方案

​

IG 和 WG 之间的层级关系

我们考虑_要求_ WG 由“赞助”IG 拥有或衍生，以便更清晰地向社区展示想法的进展；但决定不要求这样做，以避免增加新的治理层并与今天较少正式的组的工作方式保持一致。

​

单一 WG 概念（而非同时存在 WG 和 IG）

在 CWG 和指导组中，围绕”XYZ 真的是工作组吗？维护者身份如何运作？”的问题一直存在紧张关系。通过使 IG 明确面向讨论且维护者参与可选，我们创建了一个空间来推动这些讨论，而不需要像在定义明确的 WG 中那样对交付物有一些正式期望。

​

完全开放的 WG/IG 创建流程

虽然非常以社区为导向，但组重叠的担忧会迅速将对话和协作碎片化到无法维持的水平；我们需要在这里有一个集中的辨别点。

​

向后兼容性

所有引入向后不兼容性的 SEP 必须包含一个章节，描述这些不兼容性及其严重程度。SEP 必须解释作者提议如何处理这些不兼容性。 现有各组的日常工作中没有建议重大变更——只要现有活跃组继续保持现状，就很容易满足针对 IG 和 WG 提出的期望。 所有组的迁移路径如下所述。

​

参考实现

在任何 SEP 被赋予“最终”状态之前，必须完成参考实现，但在 SEP 被接受之前无需完成。虽然在编写代码之前就规范和原理达成共识的方法有其优点，但在解决许多协议细节讨论时，“粗略共识和运行代码”的原则仍然有用。 以下是建议的各组迁移路径。“迁移”仅涉及对此 SEP 的确认及各组的期望，加上可能最终停用（或在某些情况下立即停用）的方法。 在此 SEP 批准后，我们可以联系各组以确认他们同意迁移计划。

​

指导工作组

• 所有官方 SDK 组 —> 工作组
• 注册表 —> 工作组
• 文档 —> 工作组
• 检查器 —> 工作组
• 认证 —> 兴趣组 + 一些工作组：client-registration, improve-devx, profiles, tool-scopes
• 代理 —> 工作组 [长运行 / 异步工具调用；除非我们想在此基础上建立一个代理 IG？]
• 连接生命周期 —> 停用
• 流式传输 —> 停用
• 规范合规性 —> 停用（好主意但已过时；最好有人带头成立一个新的工作组）
• 安全 —> 兴趣组（或许连同安全最佳实践 WG？）
• 传输 —> 兴趣组
• 服务器身份 —> 工作组
• 治理 —> 工作组（如果此处不再有工作，则停用？）

​

社区工作组

• agent-comms —> 停用
• enterprise —> 兴趣组（请求启动提案）
• hosting —> 兴趣组（请求启动提案）
• load-balancing —> 停用
• model-awareness —> 工作组（请求启动提案）
• search-tools (tool-filtering) —> 工作组
• server-identity —> 与指导工作组中的对应组合并
• security —> 与指导工作组中的对应组合并
• server-identity —> 与指导工作组中的对应组合并
• tool-interfaces —> 停用
• ui —> 兴趣组
• schema-validation —> 停用（与指导工作组中的对应组相同）