> ## 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-932：模型上下文协议治理

* **状态（Status）**: Final
* **类型（Type）**: Process
* **创建（Created）**: 2025-07-08
* **作者（Author(s)）**: David Soria Parra
* **PR**: #931
* **Issue**: #932

## 摘要

本 SEP 为模型上下文协议（MCP）项目确立正式的治理模型。它定义了透明、高效的项目管理所必需的组织结构、决策流程和贡献指南。该提案引入了一套具有清晰角色和职责的分层治理结构，以及用于管理协议变更的规范增强提案（SEP）流程。

## 动机

随着模型上下文协议在采用度和复杂度上不断增长，对正式治理的需求变得至关重要。当前非正式的决策流程缺乏：

1. **透明度**：社区成员无法清晰地看到决策是如何作出的
2. **参与路径**：贡献者缺乏影响项目方向的既定途径
3. **问责机制**：不存在用于解决争议或有争议问题的正式结构
4. **可扩展性**：临时性流程无法随着社区和技术复杂度的增长而扩展

在没有正式治理的情况下，项目面临以下风险：

* 生态的碎片化
* 不清晰或不一致的技术决策
* 社区信任和参与度的下降
* 无法在规模化的情况下有效管理贡献

## 理由

所提议的治理模型借鉴了 Python、PyTorch 和 Rust 等成功的开源项目。关键设计决策包括：

### 分层结构

我们选择了一种分层模型（贡献者 → 维护者 → 核心维护者 → 首席维护者），它实际上就是当前项目决策的作出方式。在此基础上，我们将继续以项目的最佳利益为出发点推动治理的演进。

### 个人成员 vs 公司成员

成员身份被明确绑定到个人而非公司，以便：

* 确保决策将协议的完整性置于公司利益之上
* 防止被任何单一组织所俘获
* 在个人更换雇主时保持连续性

### SEP 流程

规范增强提案流程确保：

* 所有协议变更都经过彻底评审
* 系统性地收集社区意见
* 设计决策被记录下来以供后人参考
* 实现先于定稿

## 规范

### 治理结构

#### 贡献者

* 任何提交 issue、发起 pull request 或参与讨论的个人
* 无需正式的成员资格或批准

#### 维护者

* 负责特定组件（SDK、文档等）
* 由核心维护者任命
* 对其仓库拥有写入／管理员权限
* 可以建立组件特定的流程

#### 核心维护者

* 要求对 MCP 规范有深刻理解
* 负责协议演进和项目方向
* 每两周开会作出决策
* 可以通过多数投票否决维护者的决策
* 现任成员列于治理文档中

#### 首席维护者

* Justin Spahr-Summers 和 David Soria Parra
* 可以否决任何决策
* 任命／移除核心维护者
* 对所有基础设施拥有管理员权限

## 向后兼容性

不适用

## 参考实现

参见 #931

1. **文档文件**：
   * `/docs/community/governance.mdx` —— 完整治理文档
   * `/docs/community/sep-guidelines.mdx` —— SEP 流程指南

## 安全影响

不适用