SEP-1302：在 MCP 治理中正式定义工作组与兴趣组

社区译文；来源： MCP 29affa6b

摘要

对所处理技术问题的简短说明（约 200 字）。

SEP-994 引入了“工作组”（Working Group）与“兴趣组”（Interest Group）的概念，以促进 MCP 子社区开展讨论与协作。本 SEP 旨在正式定义这两个术语：它们应实现什么目标、如何创建、如何治理以及如何退休。

兴趣组通过促进_讨论_来界定 MCP 应当解决的_问题_，工作组则通过协作产出_交付物_（以 SEP 或社区拥有的规范实现形式）推进具体_解决方案_。兴趣组的意见可以作为创建工作组的有益理由，但不是必要条件。兴趣组或工作组的意见也可以作为 SEP 的有益输入，但同样不是必要条件。

动机

动机应清楚说明为什么现有协议规范不足以解决本 SEP 所处理的问题。

社区已经通过多个彼此分散的体系自发组织这些协作组：

• Steering group 长期以来一直通过 Discord 频道管理少量协作组（例如 security、auth、agents）。参见 MAINTAINERS.md 底部。
• “CWG Discord” 有一套半正式流程，用于推动类似的草根倡议，主要目的是产出可供 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 频道填写模板
• 一名社区 moderator 将审核提案，并在（私有）#community-moderators Discord 频道发起投票。成员在 72 小时内以多数赞成票批准创建该组。该决定可以随时撤销（例如收到更多意见后）。核心维护者和首席维护者可以否决。
• Facilitator 与 Maintainer 负责组织 IG，使其达到预期
  • Facilitator 是非正式角色，负责引导组内工作或代表该组发言
  • Maintainer 是 MCP steering group 的正式代表（并非每个组都必须设置）
• 只有当社区 moderator 或核心及以上级别维护者认定 IG 未达到预期时，IG 才会退休
  • 这意味着成功的 IG 将长期持续存在

创建模板：

• Facilitator
• Maintainer（可选）
• 标明与其他 IG 的潜在重叠
• 说明本 IG 与相关 IG 的区别
• 希望讨论的第一个主题

启动 WG 甚至发起 SEP 都不要求先加入 IG。不过，在 IG 内形成共识以支持创建 WG，通常是很好的做法。同样，在 SEP 中引用 IG 或 WG 的支持也有助于推进该 SEP。

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

目标：促进 MCP 社区围绕特定 SEP、某一主题的一系列 SEP 或获得正式认可的 Project 开展协作。

预期：

• 每月至少推进一个 SEP 或规范相关实现，或者承担某个 Project 的维护职责
• Facilitator 负责回应社区 moderator 或维护者提出的状态更新请求

示例：

• Registry
• Inspector
• Tool Filtering
• Server Identity

生命周期：

• 创建流程始于在 #wg-ig-group-creation Discord 频道填写模板
• 一名社区 moderator 将审核提案，并在（私有）#community-moderators Discord 频道发起投票。成员在 72 小时内以多数赞成票批准创建该组。该决定可以随时撤销（例如收到更多意见后）。核心维护者和首席维护者可以否决。
• Facilitator 与 Maintainer 负责组织 WG，使其达到预期
  • Facilitator 是非正式角色，负责引导组内工作或代表该组发言
  • Maintainer 是 MCP steering group 的正式代表（并非每个组都必须设置）
• 出现以下任一情况时，WG 退休：
  • 社区 moderator 或核心及以上级别维护者认定其未达到预期
  • WG 至少一个月没有进行中的 Issue/PR，或者已经完成其计划推进的全部 Issue/PR。

创建模板：

• Facilitator
• Maintainer（可选）
• 对兴趣点/用例的说明（最好来自 IG，但也可以来自任何地方）
• 计划推动的第一个 Issue/PR/SEP

WG/IG Facilitator

WG 或 IG 中的“Facilitator”角色_不会_赋予其在整个 MCP 组织内的维护者身份。这是任何人都可以自我提名的非正式角色，负责帮助引导组内讨论与协作。

核心维护者保留随时修改任何 WG/IG 的 Facilitator 与 Maintainer 名单的权利。

为实施本 SEP 而对文档作出变更的 PR：https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1350

理由

理由应说明为何作出特定设计决策，还应描述考虑过的替代设计和相关工作。理由应提供社区已达成共识的证据，并讨论在讨论过程中提出的重要反对意见或顾虑。

上述设计源自这些经验：在 CWG Discord 中推动创建并观察非正式“Community Working Group”的运行，以及领导、参与或观察“Steering Committee Working Group”。Steering WG 通常由首席维护者非正式创建，而 CWG Discord 有一个轻量级 WG 创建流程，其步骤与上述提案相似（社区成员会在 #working-group-ideation 中提出 WG，并由 moderator 根据协作结果创建频道）。

作为先例，这里的 WG 与 IG 概念类似于 W3C 的工作组和兴趣组概念。

考量因素

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

社区参与的清晰入口

希望投入 MCP 生态系统的人经常会问：“我该如何参与？”

IG 与 WG 这两种抽象提供了一条清晰的参与路径：

1. 加入 Discord，关注与你相关的 IG 讨论。参加实时会议并参与讨论。
2. 主动提出协助主持会议。在 SEP 提案及其他工作中贡献你的用例。
3. 当你可以参与交付物时，加入 WG 工作并作出贡献。
4. 持续一段时间，让 WG 维护者注意到你的贡献，并提名你成为新维护者。

尽量少改动现有治理结构

我们不希望这项变更引入新的选举、任命或其他领导概念。我们利用社区 moderator 对新组的创建表示赞成，允许核心维护者否决，maintainership 状态保持不变；“facilitator”概念虽然是新增的，但该角色由个人自我提名，因此不会引入新的治理流程。

与当时现状保持一致

现有“CWG”工作组和 Steering 工作组有一条清晰的“迁移”路径，只需区分哪些是“工作”组、哪些是“兴趣”组；在功能层面，本提案不会妨碍各组继续沿用其现有结构中行之有效的做法。

对讨论空间的需求性质

从 CWG 收到的请求可以清楚看出，一些组的成立动机是围绕某个交付物开展协作（例如 search-tools），另一些组则源于共同兴趣和建立子社区的愿望，但尚无具体交付物（例如 enterprise）。因此，我们将其动机分别归入工作组与兴趣组。

范围可能重叠

在申请新的小组空间时，有时并不清楚为什么需要新建一个组。例如，enterprise 所陈述的动机有时听起来只是 hosting 的另一种形式。我们最终确定了一项区分方式，明确前者并不是后者的直接子集；但要求清晰界定各组边界（并让社区 moderator/维护者集中决定“哪些抽象层级才合适”）的顾虑，促使我们在创建模板中加入了诸如“标明与其他 IG 的潜在重叠”等问题。

让停滞小组退出的路径

旧 CWG 和 Steering 模式中的许多工作组自创建以来已经停滞。它们不再发挥实际作用，应当退休。为此，我们引入组内 facilitator 和可选 maintainer 的正式概念，并赋予社区 moderator 让组退休的权利。每个组至少有非正式领导者后，只要所有人都同意推进，moderator 就可以轻松决定让该组退休。

考虑过的替代方案

IG 与 WG 之间的层级关系

我们考虑过_要求_ WG 必须由某个“发起”IG 拥有或衍生，以便更清晰地向社区展示想法的推进过程；但最终没有采用这项要求，以避免增加新的治理层级，并与当时较为非正式的组运作方式保持一致。

只设一种 WG 概念（不同时设立 WG 和 IG）

CWG 和 Steering group 经常围绕“XYZ 真的是工作组吗？maintainership 将如何运作？”产生分歧。明确让 IG 以讨论为导向，并将维护者参与设为可选，可以为这些讨论提供空间，而不要求像定义清晰的 WG 那样承担正式交付预期。

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

这种方式虽然高度由社区驱动，但组范围重叠会迅速把对话和协作分割到难以维持的程度；因此这里需要一个集中判断点。

向后兼容性

所有引入向后不兼容变更的 SEP 都必须包含一节，说明这些不兼容及其严重程度。SEP 必须解释作者计划如何处理这些不兼容。

本提案没有建议对现有小组的日常运作作出重大改变。只要现有活跃小组继续采用当时的做法，就能轻松达到这里为 IG 与 WG 规定的预期。

下面列出了所有小组的迁移路径。

参考实现

任何 SEP 在获得“Final”状态前都必须完成参考实现，但不要求在 SEP 获得接受前完成。虽然在编写代码前先就规范与理由达成共识有其价值，但在解决许多协议细节讨论时，“粗略共识和可运行代码”原则仍然适用。

以下是当时为各组建议的迁移路径。“迁移”仅指认可本 SEP 及其对各组的预期，并确定未来可能退休（某些情况下立即退休）的方法。

本 SEP 获批后，可以联系各组，确认它们是否同意该迁移计划。

Steering 工作组

• 所有官方 SDK 组 –> 工作组
• Registry –> 工作组
• Documentation –> 工作组
• Inspector –> 工作组
• Auth –> 兴趣组 + 若干 WG：client-registration、improve-devx、profiles、tool-scopes
• Agents –> 工作组 [Long Running / Async Tool Calls；除非还希望在其上建立 Agents IG？]
• Connection Lifetime –> 退休
• Streaming –> 退休
• Spec Compliance –> 退休（想法不错，但已经停滞；最好由某人牵头成立新的工作组）
• Security –> 兴趣组（或许另设 Security Best Practices WG？）
• Transports –> 兴趣组
• Server Identity –> 工作组
• Governance –> 工作组（如果这里已无更多工作，也可以退休？）

Community 工作组

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