Cua 项目 RFC 治理机制全解析：从提案、评审到决策落地的完整流程
Cua 项目 RFC 治理机制全解析从提案、评审到决策落地的完整流程【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cuaRFCRequest for Comments请求评论是 Cua 项目对发布前必须被充分理解的变更所采用的反馈与决策机制。Cua 将全部 RFC 直接保存在本仓库的 rfcs 目录中使得提案、实现、测试与历史记录能够被一起评审与追溯。本文以 rfcs/README.md 为骨架结合仓库内真实 RFC 实例如生命周期会话、SDK 自有运行时、不可变 nightly 发布通道等完整拆解 Cua 的 RFC 流程何时必须发起、如何组织目录与命名、生命周期如何流转、模板如何填写、评审关注哪些要点以及状态标签体系的含义帮助你掌握在 Cua 生态中发起、参与和评审一份高质量 RFC 的完整方法。理解 RFCCua 的反馈与决策机制在 Cua 仓库中RFC 草案是决策输入decision inputs。一旦 RFC 被接受合并后的 RFC 文档及其链接的实现 PR 便成为事实来源source of truth。这意味着 RFC 并不是一份仅供参考的设计文档而是贯穿了提案 → 评审 → 实现 → 验收 → 历史沉淀全生命周期的治理载体。把 RFC 放进代码仓库而不是独立的 Wiki 或讨论帖带来三个可验证的好处可一起评审提案文档与后续实现代码在同一仓库中评审者可以对照阅读可追溯从 issue 讨论、RFC 文档、实现 PR 到最终验收所有环节形成完整的证据链历史不可篡改已完成的决策以文档形态永久留存即便后来的 RFC 将其取代旧决策也依然可查。何时发起 RFC触发条件与豁免情形必须发起 RFC 的六类变更按 rfcs/README.md 的规定凡影响以下任意一项的变更都应使用 RFC公共契约公共 SDK、CLI、MCP、协议或文件格式契约public SDK, CLI, MCP, protocol, or file-format contracts跨平台架构边界跨平台架构或进程与权限边界cross-platform architecture or process and permission boundaries安全与信任安全、隐私、信任或授权行为security, privacy, trust, or authorization behavior兼容性策略兼容性、迁移或弃用策略compatibility, migration, or deprecation policy跨组件共享行为多个 Cua 组件共享的行为behavior shared by multiple Cua components需要外部反馈的决策外部贡献者反馈能实质性改进结果的决策。仓库中的实例可以逐一对应上述类别例如 RFC 3682类型化原生窗口 SDK 流程涉及公共 SDK 契约RFC 3007生命周期会话与逐调用捕获涉及授权与生命周期边界RFC 3096不可变 nightly 发布通道涉及发布与版本兼容策略而 RFC 3550Hyprland 隔离输入则横跨平台行为与输入/权限边界。不需要 RFC 的情形以下情况不需要走 RFC 流程小规模 bug 修复例行文档变更保持公共行为不变的内部重构紧急的私有安全响应。特别需要警惕的是疑似漏洞必须走仓库的私有安全报告路径SECURITY.md而不是公开 RFC。这一条在下一节展开。安全设计与漏洞报告的分工Cua 的 RFC 流程对安全设计与漏洞报告做了明确切分这是最容易混淆的一对概念安全设计security design公共 RFC 是决定安全边界应当是什么的正确场所——例如哪个进程持有某项能力capability、权限提示必须声明什么、哪些数据不得被收集或暴露、授权如何体现在公共契约中。漏洞报告vulnerability report描述的是已发布 Cua 代码或配置中具体可利用的缺陷应通过 SECURITY.md 私有提交。规则很简单公开设计边界私密报告缺陷Design the boundary in public; report the defect privately。如果一个加固提案在不泄露可利用缺陷的前提下无法描述就应先私密报告待修复协调完成后由维护者再开启或解锁对应的公开 RFC。仓库结构rfcs/ 目录约定与命名规则rfcs 目录的物理结构如下见 rfcs/README.mdrfcs/ ├── 0000-template.md ├── issue-short-name.md └── issue/ ├── architecture-overview.png └── other-supporting-material...命名规则的核心约定是GitHub discussion 的 issue 编号就是 RFC 的标识符。例如issue#2447对应rfcs/2447-cua-driver-native-core-and-mcp-adapter.md即 RFC 2447可选的侧车目录为rfcs/2447/存放架构图等配套材料仓库中实际存在 rfcs/2447/architecture-overview.png 与 rfcs/2447/lifecycle-modes.png配套材料在文档内部使用相对链接引用保证提案的可移植性与在仓库中的可评审性。这一命名规则在仓库中执行得非常一致2512-*系列有四份 RFC环境收敛、MCP 信封载体、Python fleet 首片、共享 driver MCP 客户端3007、3096、3101、3197、3550、3682均以 issue 号开头一一对应仓库内的真实讨论 issue。RFC 生命周期六步走完一份提案rfcs/README.md 将 RFC 从诞生到落地的过程规范为六个步骤开 issue使用Request for comments的 issue 表单发起讨论。issue 本身就是讨论与决策记录discussion and decision record。建 RFC 文件并提交评审当提案内容超出 issue 正文承载范围时复制 RFC 模板 为issue-short-name.md填入 issue URL并以status: review打开拉取请求PR。双向链接与完整评审issue 与 RFC PR 必须在两个方向上互相链接。在开始实现之前评审必须覆盖公共契约、备选方案、迁移、平台行为、安全性与未决问题。维护者发布决策摘要维护者在 issue 中发布决策总结内容涵盖实质性反馈、被接受的修改、被否决的备选方案、剩余风险与最终处置final disposition。接受并合并对已接受的提案设置status: accepted并在首个实现 PR 之前或与之同时合并 RFC。每个实现 issue 与 PR 都必须从 RFC 中链接出来。收官或归档验收标准上线后将 RFC 标记为completed视情况使用declined、withdrawn或superseded。绝不允许重写历史决策使其看起来像是另一种结果。评审期要求正常提案应获得与影响面成比例的评审期。破坏公共契约与跨平台权限变更的提案通常至少保持开放 7 个日历日若紧急变更需要更短窗口必须在决策摘要中记录缩短的原因。这一规则在仓库实例中有清晰的执行痕迹RFC 3682 的 Decision 部分明确记录了缩短的提案窗口shortened proposal window及其理由——使 SDK 在一个修订内对齐既有原生能力同时保留跨平台验证与实现评审作为关卡RFC 3007 的决策记录同样说明缩短的评审期建立在先前已落地的决策、全仓库 issue/PR 审计与两轮对抗式架构评审之上。这正对应了 README 中记录缩短原因的流程要求。状态词汇表RFC 的状态字段frontmatter 中的status使用统一受控词汇含义如下状态含义draft作者仍在打磨提案。review提案已准备好接受技术与产品反馈。accepted决策已获批准实现可能尚未完成。completed已接受提案所要求的实现已发布上线。declined评审结论为 Cua 不应采纳该提案。withdrawn作者在决策前主动终止了提案。superseded由链接的后续 RFC 取代了该决策。仓库实例与词汇表一一对应RFC 3197本地现代 MCP 与嵌入式技能目前为review状态RFC 2549SDK 自有运行时为reviewRFC 3007、RFC 3096、RFC 3550 与 RFC 3682 均已accepted而 RFC 2447 的 frontmatter 明确写着status: superseded与superseded_by: 2549——它被 RFC 2549 继承并取代这正是被后续 RFC 取代这一状态的标准示范。模板结构深度解析一份合格 RFC 的骨架RFC 模板 定义了所有 RFC 必须遵循的统一骨架包括 frontmatter 与正文章节。理解模板是撰写合格 RFC 的第一步。Frontmatter 元数据模板要求的元数据字段包括字段用途title提案标题authorsGitHub 账号或团队created/last_updated创建与最后更新时间YYYY-MM-DDstatus生命周期状态见上文词汇表discussion对应讨论 issue 的 URLrfc_prRFC 文档本身的 PR 链接implementation实现 issue / PR 链接列表supersedes/superseded_by取代关系可空以 RFC 3007 为例其 frontmatter 完整填写了rfc、title、authors、created、status: accepted、discussion、rfc_pr等字段且implementation留空并在文档中说明接受后由单个实现 PR 交付体现了模板的灵活运用。正文章节模板要求正文按以下顺序组织每一节都有明确的评审价值Summary一段话描述拟议的决策Motivation需要决策的用户或工程问题是什么、为什么是现在Goals提案必须达成的具体成果Non-goals刻意不解决的邻近问题防止范围蔓延Terminology定义影响提案含义的术语Current state描述当前可观察的架构或行为并尽可能链接仓库证据Proposal描述公共契约、组件所有权、数据与控制流、生命周期、兼容性与平台行为配套资源放入issue/侧车目录并以相对链接引用Alternatives considered最强的备选方案及未被选中的原因Compatibility and migration增量交付、弃用、破坏性变更、回滚与发布时序Security, privacy, and telemetry权限边界、敏感数据处理方式、遥测可以/不可以包含什么Implementation plan将工作拆分为可独立评审的增量并给出明确的 parity 与 rollback 关卡Test and acceptance plan判定 RFC 已实现所需的证据清单Unresolved questions必须在评审期间作出的决策Decision record评审结束时填写总结实质反馈、被接受的修改、被否决的备选方案、剩余风险与最终处置。这些章节在真实 RFC 中的执行质量很高。例如 RFC 3007 的 Terminology 节给出了 7 个精确术语定义lifecycle session、trusted ownership namespace、authenticated transport lease、implicit session、explicit session、authorization context、capture modality并在 Current state 中直接链接了实现文件——session_tools.rs、session.rs 与 capture_scope.rs对应仓库相对路径为 libs/cua-driver/rust/crates/cua-driver-core/src/session_tools.rs、libs/cua-driver/rust/crates/cua-driver-contract/src/session.rs、libs/cua-driver/rust/crates/cua-driver-core/src/capture_scope.rs。这份 RFC 还给出了固定实现选择如默认五分钟 idle TTL、标签联合目标target window {...} | desktop {...}、按依赖顺序拆分的 8 个提交单元表格以及逐条的验收测试清单——堪称模板各章节的完整范本。同样值得参考的是 RFC 2549 对模板中 Alternatives considered 与 Compatibility and migration 两节的高强度运用它列出了 7 组备选方案保留共享 daemon、daemon 级权限模式、信任公共 session ID 选择权限模式、移除全部 daemon/worker、每个动作无状态化、SDK 与传输层各自维护契约、以 gRPC 作为原生核心契约并逐一给出否决理由兼容性一节则拆出 Phase 0 到 Phase 7 的阶梯式迁移路径每个阶段都标明不得改变公共签名的锁定条件。评审期望评审什么、禁止什么rfcs/README.md 明确指出要评审提案本身而不仅是实现计划Review the proposal rather than only the implementation plan。评审时应重点检查用户问题与成功标准是否具体concrete契约由哪一层拥有是否已有其他标准拥有该契约生命周期、取消、并发与失败隔离涉及桌面行为时的平台约束macOS 权限身份、Windows 会话放置session placement、Linux 显示约束兼容性与可观察的回滚路径隐私边界与遥测内容如何跨公共表面证明对等性parity。这些期望在 RFC 3682 的验收步骤中体现为具体的关卡先在共享 SDK 边界统一规范化成功结果与拒绝结果、重新生成绑定并迁移 fixtures/examples、以规范的 Windows/Linux 桌面 E2E 与 macOS Lume 矩阵在稳定 SHA 上认证涵盖 application-effect、token 新鲜度、焦点、光标与输入隔离检查——这正是评审提案而非仅评审计划的落地形态。内容红线公共 RFC严禁包含凭据credentials客户或合作伙伴身份私有报告个人数据敏感截图原始会话记录raw session transcripts可利用性增强的安全细节exploit-enabling security details。标签与自动化约定issue 表单会自动应用仓库已有的review标签并为标题添加[RFC]前缀——这意味着不需要预先配置新的仓库状态即可运转整个流程。如果未来 RFC 数量增长到需要专用标签README 给出了演进方向新增type: rfc标签配合accepted、declined、withdrawn、superseded的生命周期标签。但无论标签如何演进RFC frontmatter 与维护者决策摘要始终是状态的权威来源The RFC frontmatter and maintainer decision summary remain the authoritative status。这一点在仓库中可以得到验证RFC 3096 的决策记录完整记录了维护者选择的方向、接受的修订最小引用式注册表、channel-first 标签、组件自有构建器、精确 pin 优先于持久通道等与被否决的选项same-prefix 标签、自动十四版本删除、nightly 验证前重构稳定发布并给出最终处置Disposition: accepted for implementation——决策摘要就是权威状态的最佳注脚。仓库内 RFC 实例巡览从流程到实践截至当前仓库rfcs 目录下共有 11 份正式 RFC不含模板覆盖了流程文档列举的几乎所有触发类别。以下按主题快速巡览可作为撰写与评审 RFC 时的对照样本RFC 2447Cua Driver 原生核心与 MCP 适配器确立类型化 SDK 契约 版本化 C ABI 实现替换缝 原生核心的分层架构MCP/HTTP/CLI 一律作为 SDK 的下游消费者。当前状态superseded被 2549 取代是取代关系的标本级案例。RFC 2549SDK 自有运行时与可选服务把运行时所有权从 daemon 迁回 SDK 对象定义直接 SDK、私有 worker、服务三种显式拓扑并将授权收敛为运行时授权天花板 不可变会话上下文两层模型。这是理解 Cua Driver 现代运行时与授权模型必读的一份长文。RFC 3007生命周期会话与逐调用捕获定义隐式会话、一次性 CLI 会话、命名会话重连约束与逐调用捕获模态彻底剥离会话生命周期与授权上下文两个关注点。模板各章节最完整的示范。RFC 3096Cua 组件不可变 nightly 发布通道设计nightly-cua-driver-rs-vX.Y.Z-nightly.YYYYMMDD.RUN这类 channel-first 标签语法隔离 stable 与 nightly 命名空间确保稳定解析器无法意外发现 nightly。其术语定义stable tag / nightly tag / component descriptor / build version sites与 release-please-config.json 的衔接说明了跨组件发布治理的写法。RFC 3197本地现代 MCP 与嵌入式技能为既有 Rust stdio 服务器增加 MCP2026-07-28协议支持并保留 legacy 初始化同时通过 Skills 扩展与 Resources 方法服务内置技能。当前处于review状态。RFC 3550Hyprland 隔离输入设计双合成输入通道在不抢占用户主 seat 焦点的情况下向指定后台目标投递输入并把 transport/dispatch/application-effect 三层结果分离守住可移植 Cua Driver 契约。RFC 3682类型化原生窗口 SDK 流程将 discover/snapshot/act/verify 原生流程暴露为生成的 Python/TypeScript 方法click改为坐标或元素 token联合类型加显式目标与投递模式属于典型的公共 SDK 契约变更演示了如何接受一次有意的破坏性 SDK 修订并规划迁移。从 RFC 2447 与 RFC 2549 之间可以看到 Cua RFC 体系最具价值的一个特性决策可以演进但历史完整保留。2549 明确列出2447 中继续有效的决策清单typed SDK 为公共契约、原生核心保持私有、MCP/HTTP 为下游适配器等同时也列出被替换的部分运行时所有权默认归属、单进程单运行时约束、权限模式归属不可变会话等。这让新读者能在几分钟内完成一次契约沿革审计也让后续实现与评审始终有据可依。结语把 RFC 当作工程资产而非流程负担对 Cua 这样横跨 macOS/Windows/Linux、涉及原生驱动、SDK 生成绑定、MCP 协议与发布管线的复杂仓库而言RFC 不是写文档的负担而是一份可审计的工程资产。它强制在实现之前澄清公共契约、平台边界、安全语义与兼容路径并通过issue 讨论 PR 评审 决策摘要 状态流转把每一次重大变更都沉淀为永久记录。无论是计划向 Cua 提交行为变更的贡献者还是需要在自有项目中建立类似治理机制的工程师都可以直接以 rfcs/README.md 的流程、RFC 模板 的骨架以及 RFC 3007、RFC 2549 等高质量实例为蓝本让先想清楚、再写代码、后留记录成为团队协作的默认路径。【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考