Skip to main content
  • 状态（Status）: Final
  • 类型（Type）: Standards Track
  • 创建（Created）: 2025-08-05
  • 作者（Author(s)）: tadasant
  • Issue: #1302
PR: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1350

​
摘要

对所要解决技术问题的简短（约 200 词）描述。 在 SEP-994 中，我们引入了”工作组”和”兴趣组”的概念，用于促成 MCP 子社区进行讨论和协作。本 SEP 旨在正式定义这两个术语：它们意在实现什么、群组如何创建、如何治理，以及如何退役。 兴趣组通过促成讨论来致力于定义 MCP 应当解决的问题，而工作组通过协作产出交付物（以 SEP 或社区拥有的规范实现的形式）来推进具体的解决方案。兴趣组的输入是创建工作组的一个受欢迎（但非必需）的理由。兴趣组或工作组的输入合起来是 SEP 的一个受欢迎（但非必需）的输入。

​
动机

动机应清晰解释为何现有的协议规范不足以解决该 SEP 所解决的问题。 社区已经自组织成若干各不相同的协作群组体系：
  • 指导小组长期以来有通过 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 频道填写模板开始
  • 社区版主将评审并在（私有）#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 中促成创建并观察非正式”社区工作组”行为的经验，以及领导/参与/观察”指导委员会工作组”的经验。虽然指导 WG 通常由首席维护者非正式创建，但 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 所述的动机有时听起来可能只是 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 —> 退役（与指导版对应者相同）