MMSP
GitHub123
RFCs: RFC 索引

RFCs

RFC 索引

MMSP 遵守的每项规范与改变它的每个决定都是 RFC：这里是索引，以及哪些改动需要 RFC。

MMSP 遵守的规范，以及改变过它的决定，每一项都是一篇 RFC。代码与已采纳的 RFC 不一致时，以 RFC 为准：要么修正代码，要么先经另一篇 RFC 取代它。

全部 RFC

RFC 标题 类别 状态
MMSP-RFC-0001 RFC 流程 process 已采纳
MMSP-RFC-0002 消息协议 spec 已采纳
MMSP-RFC-0003 消息请求 spec 已采纳
MMSP-RFC-0004 消息保真 spec 已采纳
MMSP-RFC-0005 客户端路由 spec 已采纳
MMSP-RFC-0006 服务上游密钥 spec 已采纳
MMSP-RFC-0007 异常类型 spec 已采纳
MMSP-RFC-0008 请求中断 spec 已采纳
MMSP-RFC-0009 协议转换 spec 已采纳
MMSP-RFC-0010 轨迹记录 spec 已采纳

spec 固定代码遵守的一个概念、协议或算法；change 修改协议或公开 API；process 是这个目录的运作方式。状态为「已采纳」或「被 MMSP-RFC-NNNN 取代」，因此现行的规范就是状态为「已采纳」的 spec 行。提议中的 RFC 是一个未关闭的 PR（gh pr list --search "MMSP-RFC-"），撤回的 RFC 是一个已关闭的 PR；两者在表中都没有行。

RFC 曾于 2026-10-24 按项目负责人的要求重编号两次；MMSP-RFC-0001 §5 列出 0.5.5 的编号、第一次重编号后的编号与现在编号的对应关系。

文件 内容
rfcs/ 一个文件记录一个决定，MMSP-RFC-NNNN-<slug>.md
0000-template.md 新 RFC 的起点

除模板外，每个文件都有一份中文对照 <name>.zh.md，逐节对应。网站直接用这些文件在 /rfcs/ 渲染这份索引与每一篇 RFC。

哪些改动需要 RFC

  • 修改任何一项规范。
  • 修改消息或流的结构：内容项的类型或字段，UniEvent、UniMessage 或 UniConfig 的键，StreamItems 的判定方式。
  • 修改公开 API：AutoLLMClient 的方法与构造参数、包的导出、错误类。
  • 改变路由表或凭据规则的含义。新增一行不算。
  • 修改 MMSP 服务端的线上协议（/v1/stream、/v1/models）。
  • 任何会破坏调用方的改动。

新模型或新一代模型、遵循既有模式的新厂商或新协议客户端、新增的模型族或客户端类型行、注册表条目、文档、网站、CI 与缺陷修复，提普通 PR 即可。

编写 RFC

  1. 从 origin/dev 拉出 rfc/<slug> 分支，把 0000-template.md 复制为 rfcs/MMSP-RFC-NNNN-<slug>.md。NNNN 取 ls design/rfcs/ 与未关闭的 PR（gh pr list --search "MMSP-RFC-"）都没有用过的下一个编号；编号永不复用。一篇 RFC 只记一个决定。把 Kind 设为 spec、change 或 process：spec 类 RFC 包含 Abstract、Introduction、Conventions and Terminology、正文各节与 Conformance；change 与 process 类 RFC 包含 Abstract、Introduction 与 Rust RFC 的各节，全部编号。无话可说的小节直接删去。
  2. 在同一个 PR 中写好中文对照 MMSP-RFC-NNNN-<slug>.zh.md。模板中的节名（Abstract、Introduction、Conventions and Terminology、Conformance 与 Rust RFC 的各节）在两份文件中都保持英文；spec 类 RFC 正文各节的标题在中文对照中翻译，两份文件靠节号逐节对齐。两份文件在元数据下方的一行互相链接：[中文版](MMSP-RFC-NNNN-<slug>.zh.md) 与 [English](MMSP-RFC-NNNN-<slug>.md)。
  3. 规范只能经由一篇 spec 类 RFC 修改：它完整陈述修改后的规范，并在 Supersedes: 一行写明旧的那篇。在同一个 PR 中，往旧文件的元数据末尾追加 - Superseded by: [MMSP-RFC-NNNN](MMSP-RFC-NNNN-<slug>.md)，两种语言都要加，并在上表中更新旧行的状态。
  4. 在上表中添加这篇 RFC 的一行，状态为「已采纳」：这一行随 PR 合并落地，而合并正是采纳这篇 RFC 的方式。
  5. 按 changelog/README.md 的格式添加一条 Type: process、Scope: design 的变更记录。
  6. 用 gh pr create --base dev 提交 PR，标题为 MMSP-RFC-NNNN: <Title>，然后在后续提交中把 PR 链接填进 RFC PR 一行。

未关闭的 PR 是提议中的 RFC，合并即被采纳，关闭即被撤回，编号作废。RFC 文件没有状态字段；它是「已采纳」还是「被取代」，由上表记录。实现某篇已采纳的 change 类 RFC 的 PR 在 RFC PR 一行之后加上 - Implementation PR: [#N](<url>)，并在自己的变更记录中链接这篇 RFC。

写作规则

  • spec 类 RFC 读起来是对一件固定不变之事的规范：Abstract 用一到三句话说明规范了什么，正文分编号的小节陈述它，Conformance 一节在文件层面列出保证它成立的模块与测试。
  • 规范性语句使用大写的 MUST、MUST NOT、SHOULD、SHOULD NOT 或 MAY，含义按 BCP 14 的定义；描述代码行为的句子用 MUST 或 MUST NOT，SHOULD 只用于对调用方与贡献者的要求。中文对照把它们写作 必须、不得、应当、不应、可以。
  • 每一句规范性语句都要符合代码。不符合时，要么修正代码，要么取代这项规范。
  • 数字要么是不变量，要么带有时态。不写数量，也不写当下的清单：有哪些客户端，某个客户端支持哪些模型。
  • 代码标识符、文件路径与模板中的节名在两种语言中都保持英文。
  • PR 与 issue 链接写完整 URL；指向仓库内文件的链接用相对路径。
  • 上表是唯一的索引。grep -l MMSP-RFC-0004 design/rfcs/ 找出引用某项规范的 RFC。
下一页MMSP-RFC-0001 RFC 流程

在 GitHub 上编辑本页以 Markdown 打开