Cua Driver 与 Lume 的持久化发布渠道选择机制RFC 3101 设计与实现全解析【免费下载链接】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导读Cua Driver 与 Lume 是 Cua 项目中的两个核心客户端组件分别以 Rust 与 Swift 实现各自维护独立的安装、签名与更新链路。RFC 3101Persistent release-channel selection为二者定义了一套统一、持久化的stable/nightly发布渠道release channel选择契约用户通过显式安装参数或 CLI 命令保存渠道偏好随后的更新检查、横幅提示与显式 apply 都严格限定在该渠道内而精确版本固定exact pin始终作为一次性复现与回滚手段绝不改写已保存的偏好。读完本文你将掌握这套渠道状态文件的格式与读写规则、channel status/channel set的 CLI 与 JSON 输出契约、安装器--channel参数的四级选择优先级、跨渠道转换stable→nightly→stable的判定语义以及两个产品在 Rust 与 Swift 两套代码库中的真实落地方式。背景与动机从不可变 nightly 到持久化选择RFC 3101 并非凭空出现它建立在 RFC 3096 奠定的不可变 nightly 发布机制之上。RFC 3096 确立了以下核心事实稳定版与 nightly 使用互不相交的标签命名空间稳定标签形如cua-driver-rs-vX.Y.Z与lume-vX.Y.Znightly 标签采用渠道前置语法形如nightly-cua-driver-rs-vX.Y.Z-nightly.YYYYMMDD.RUN与nightly-lume-vX.Y.Z-nightly.YYYYMMDD.RUN。GitHub 的 prerelease/latest 元数据不能作为渠道边界因为稳定版 Driver 的发布也使用该元数据只能依靠严格标签语法区分渠道。精确 nightly 安装exact pin是当时唯一受支持的 nightly 接入方式用户可以复现某一个具体 nightly但无法让一台机器跟随后续 nightly——除非用户自己逐个发现并 pin 每个新标签。RFC 3101 正是要补齐这块空白让用户显式选中 nightly 渠道后后续更新自动跟随该渠道内最新的不可变 nightly 发布。同时它必须不削弱RFC 3096 的隔离不变量稳定版客户端绝不能发现 nightly除非用户显式选择了 nightly。核心概念与术语RFC 3101 用三个精确定义的术语消除了渠道一词的歧义术语定义语义Selected channel选中渠道经过校验并持久化的用户偏好取值仅为stable或nightly未来意图缺失状态等价于stableCurrent channel当前渠道仅由运行中工件artifact的严格发布版本语法推导得出当前状态不代表未来意图Exact pin精确固定完整的稳定版本号或规范的不可变 nightly 身份通过既有产品环境变量提供一次性复现/回滚控制永不改写已保存的偏好选中渠道与当前渠道的分离是整个设计的精髓前者回答用户想跟随哪条线后者回答这个二进制当前属于哪条线二者可能不一致例如用户已切换到 nightly 但二进制仍是 stable而这种不一致正是渠道转换被判定为可更新的依据。持久化设计一行 UTF-8 的 release-channel 状态文件文件格式与放置位置每个产品在自己的包/更新状态目录旁拥有一个独立的单行 UTF-8release-channel文件文件合法内容仅限stable与nightly两值Cua Driver位于CUA_DRIVER_RS_HOME未设置时回退到HOME/USERPROFILE下的用户目录中的release-channel文件路径计算见 release_channel.rs 的state_path()Lume位于LUME_HOME未设置时回退到~/.lume目录下的同名文件见 ReleaseChannel.swift 的stateFileURL()。产品主目录覆盖home override同时也会搬迁状态文件从而保证安装器与测试可以创建完全隔离、可移植的安装。读写语义缺失即 stable非法即 fail-closed缺失文件读取为stableselected_at()捕获NotFound错误并返回ReleaseChannel::Stable严格双值词表Driver 的FromStr实现只接受stable/nightly允许首尾空白其余一律报错invalid release channel {value:?}; expected stable or nightly见 release_channel.rsLume 侧通过LumeReleaseChannel(rawValue:)枚举初始化做同等校验非法/不可读状态 fail-closed绝不把未知内容解释为 nightly而是报错并给出修复指令cua-driver channel set stable或channel set nightly。这一行为由 release_channel_cli_test.rs 的channel_cli_fails_closed_on_invalid_saved_state测试锁定写入broken\n后channel status --json必须失败且 stderr 同时包含expected stable or nightly与修复提示。原子写入与 Windows 兼容写入时先创建父目录再写临时文件后通过 rename 原子替换。Driver 的实现特别处理了 Windows 上std::fs::rename无法覆盖已有目标的问题先删除旧文件再执行 rename确保任何平台上都不会把部分内容留在规范路径上见 release_channel.rs。Lume 侧则直接使用Data(...).write(to:options:.atomic)的原子写 API。需要强调的是该文件是用户偏好不是授权工件。它不含任何 token、凭证、身份、路径或会话数据也不授予任何权限——这一点在 RFC 的安全、隐私与遥测章节有专门说明。CLI 契约channel status 与 channel set两个产品暴露完全一致的 CLI 形态product channel status [--json] product channel set stable|nightly [--json]Driver 侧的 Rust 实现cua-driver channel命令在 cli.rs 的run_channel_cmd中实现channel无子命令等价于status与set构成两级子命令结构set只持久化意图绝不作为副作用替换运行中的二进制打印选中渠道后提示用户运行update --applystatus --json输出结构化状态selected_channel已保存偏好、current_channel由CARGO_PKG_VERSION经ReleaseChannel::from_version推导开发构建输出development、current_version。Driver 对current_channel的推导使用严格版本语法见 release_channel.rs无 build 元数据、无预发布后缀的X.Y.Z→stable预发布段严格匹配nightly.YYYYMMDD.RUN规范形态8 位日期、非零开头的 RUN 序号→nightly其余形态如0.19.4-dev、0.19.4-nightly.foo、0.19.4build、RUN 为0→None即不属于任何渠道。Lume 侧的 Swift 实现Lume 使用 Swift ArgumentParser 实现了同名命令见 Channel.swiftchannel默认子命令为statusChannelStatus输出selected_channel/current_channel/current_version的 JSON使用.sortedKeys保证输出稳定或人类可读文本ChannelSet校验参数必须是stable或nightly写入偏好后若current ! selected会提示运行lume update --applyLume 侧current(for:)同样通过plainVersion/nightlyVersion两套严格语法判定当前渠道。结构化更新状态区分版本升级与渠道转换更新状态中必须同时暴露selected_channel与current_channel使调用方CLI、MCP 结构化状态能够区分渠道内的普通版本升级与跨渠道转换。Driver 的UpdateState结构体在 version_check.rs 中定义这两个字段并在check_update_state_with_ownership中填充若状态文件损坏selected_channel置空、error携带修复指令。特殊情形pacman 管理的 Linux 安装Driver 对 pacman 包管理器托管的安装有专门保护见 release_channel_cli_test.rs 的pacman模块channel set与check-update/update会直接返回sudo pacman -Syu的包管理指引且绝不创建或改写上游缓存测试还验证了 PATH 上的冒牌pacman无法禁用非托管渠道切换fake_path_pacman_cannot_disable_unmanaged_channel_switching防止权限边界被欺骗。安装器--channel 参数与四级选择优先级两个产品的规范安装器Cua Driver 的 Bash/PowerShell 脚本 install.sh、Lume 的 install.sh均接受--channel stable|nightly参数带--channel时持久化该选择并安装该渠道内可见的最高已发布版本不带 flag 也没有精确 pin 时读取已保存的状态状态缺失时直接使用内嵌baked的稳定版本不发任何 API 请求nightly 选择总是通过 releases API 解析因为 nightly 标签不可变、且不引入任何可变指针只有 API 才能枚举出最新的不可变 nightly。选择优先级从高到低精确版本环境变量exact pin显式--channel参数已保存的渠道状态稳定版默认值。两个约束值得特别注意精确 pin 不写渠道状态pin 是一次性复现/回滚控制不能污染持久偏好pin 与--channel组合使用被拒绝避免到底以谁为准的歧义性持久化RFC 明确要求在 Bash 与 PowerShell 两个安装器上覆盖该拒绝路径的测试。内嵌的稳定版本仅对 stable 渠道保持权威性nightly 渠道永远不会使用内嵌稳定版本。版本发现与 apply 语义严格隔离与显式转换解析器单前缀 缓存按渠道隔离渠道解析器每次只选中一个前缀并应用严格语法stable 发现路径绝不考虑 nightly 标签nightly 路径也绝不考虑 stable 标签。Driver 的tag_prefix函数在 version_check.rs 中按渠道返回RELEASE_TAG_PREFIX或NIGHTLY_RELEASE_TAG_PREFIX。缓存同样以渠道为键VersionCache记录channel字段命中条件要求cached.channel selected_channel见 version_check.rs 与 L389-L395。因此stable 的缓存结果无法满足 nightly 检查反之亦然即便网络请求失败回退缓存也只在渠道匹配时允许。渠道内普通 SemVer 排序跨渠道显式转换同一渠道内普通 SemVer 顺序决定是否存在更新的发布当前渠道与选中渠道不同时无论相对 SemVer 大小如何都会把选中渠道内最新的发布作为一次显式渠道转换提供。也就是说即使 nightly 标签的 SemVer 版本号看起来更旧nightly 基于 patch1 派生但日期/运行号与主版本演化无关只要用户选了 nightly 而当前二进制是 stable就判定为可更新——update_is_available中current_channel ! selected_channel即视为可更新见 version_check.rs对应测试为channel_mismatch_is_available_even_when_target_version_is_lower。update --apply会固定pin解析出的那个不可变目标版本用于本次安装同时保留选中渠道不变从而不会改变未来的更新意图。这一转换优先于 SemVer的语义保证了用户channel set nightly后执行update --apply一定能切到 nightly反过来channel set stable后也一定能切回 stable而不受两个渠道版本号相对大小的干扰。可复用组件契约给未来组件的模板RFC 3101 明确列出了未来 Cua 组件可复用的六要素RFC 文档双值渠道词表stable/nightly严格命名空间选择渠道内单前缀 严格语法产品自有的单行状态文件选择优先级规则结构化状态字段selected_channel/current_channel测试矩阵。同时组件专属部分home 路径、安装器、打包、签名、平台更新器实现继续由各组件自行维护——共享的是契约而非实现这与 RFC 3096共享发布层拥有渠道机制、组件适配器拥有构建与签名的职责划分一脉相承。备选方案与设计取舍RFC 记录了几个被否决或推迟的方案理解这些取舍有助于把握设计边界方案结论理由仅环境变量选择渠道否决不持久重启即丢失从已安装工件推断用户意图否决回滚会静默改写未来行为装回旧版意外退回旧渠道用 GitHubprerelease/latest元数据作渠道边界否决RFC 3096 已定元数据不是渠道边界稳定版 Driver 也在使用该元数据中央跨产品 JSON 文件否决shell 与 PowerShell 安装器无法在不引入另一套解析器和锁协议的情况下安全更新多个无关产品的键后台/无人值守自动 apply非目标始终要求显式 apply可变 nightly 标签/资产、注册表渠道、对象存储指针非目标/推迟保持不可变性与精确复现兼容性与迁移路径RFC 3101 对既有安装完全向后兼容旧机器没有状态文件 → 保持 stable行为与现在一致已有的精确 stable pin 与 nightly pin 语义不变opt-in / opt-out 流程channel set nightlyupdate --apply切入 nightly对应的 stable 命令切回稳定版单次安装器调用--channel同时完成设置安装两步精确 pin 仍是受支持的回滚与复现路径。RFC 明确承诺不改变任何稳定标签、nightly 标签、manifest、签名、权限或会话契约。安全、隐私与遥测边界渠道选择是显式的本地用户意图状态文件不含 token/凭证/身份/路径/会话数据不授予任何权限GitHub 元数据无法参与渠道选择渠道边界只由标签语法决定既有的签名、公证notarization、摘要digest、审批与显式 apply 边界保持各自独立约束遥测只允许记录规范化渠道词表与既有的有界更新结果不得记录偏好文件路径也不得把渠道状态用作标识符。实施计划与测试验收从合并到公开资产验证RFC 给出的实施步骤依次为为 Driver 增加经过校验的渠道状态与渠道感知发现逻辑 → 打通 Unix/Windows 安装器、CLI、更新器、缓存、MCP 状态与生成文档 → 为 Lume 增加同等契约 → 补充跨平台解析器/持久化/安装器/契约测试并保留稳定版可见性测试 → 普通 CI 转绿后合并随后发布精确 main SHA 的 nightly并通过公开资产证明 stable→nightly→stable 的完整往返。验收要点均有对应测试矩阵锁定缺失状态解析为 stable、合法状态可往返、非法状态 fail-closed 并带修复指令两个产品的 stable 发现拒绝一切 nightly 形态、nightly 发现拒绝一切 stable 形态Bash 与 PowerShell 上覆盖精确 pin 优先级与 pin--channel拒绝内嵌稳定版本仅在 stable 渠道使用nightly 总是解析不可变公开标签更新缓存不得跨渠道复用结构化 CLI 与 MCP 更新状态暴露 selected/current 渠道stable→nightly 与 nightly→stable 转换跨 SemVer 边界也能被提供并应用新鲜的 Driver/Lume nightly 从合并后的 main SHA 发布含签名工件、manifest、校验和与归因发布说明。小结渠道选择在 Cua 中的定位RFC 3101 把用户想跟随哪条发布线变成了 Cua Driver 与 Lume 两套代码库中同构、可持久、可审计的一等公民一行 UTF-8 状态文件承载偏好两个 CLI 命令承载读写安装器--channel承载一次性接入严格标签语法与渠道键缓存承载隔离而精确 pin 始终独立于偏好、专司复现与回滚。对于想要长期吃 nightly、随时可回滚稳定版的用户这套机制提供了明确且安全的操作路径对于未来的 Cua 组件它也给出了一份可以直接照搬的组件契约。如需深入可继续阅读RFC 原文、前置 RFC 3096、Driver 的渠道状态实现 release_channel.rs、渠道 CLI 实现 cli.rs、渠道感知的更新检查 version_check.rs、CLI 集成测试 release_channel_cli_test.rs以及 Lume 侧的 Channel.swift 与 ReleaseChannel.swift。【免费下载链接】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），仅供参考 Cua Driver 与 Lume 的持久化发布渠道选择机制：RFC 3101 设计与实现全解析
Cua Driver 与 Lume 的持久化发布渠道选择机制RFC 3101 设计与实现全解析【免费下载链接】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导读Cua Driver 与 Lume 是 Cua 项目中的两个核心客户端组件分别以 Rust 与 Swift 实现各自维护独立的安装、签名与更新链路。RFC 3101Persistent release-channel selection为二者定义了一套统一、持久化的stable/nightly发布渠道release channel选择契约用户通过显式安装参数或 CLI 命令保存渠道偏好随后的更新检查、横幅提示与显式 apply 都严格限定在该渠道内而精确版本固定exact pin始终作为一次性复现与回滚手段绝不改写已保存的偏好。读完本文你将掌握这套渠道状态文件的格式与读写规则、channel status/channel set的 CLI 与 JSON 输出契约、安装器--channel参数的四级选择优先级、跨渠道转换stable→nightly→stable的判定语义以及两个产品在 Rust 与 Swift 两套代码库中的真实落地方式。背景与动机从不可变 nightly 到持久化选择RFC 3101 并非凭空出现它建立在 RFC 3096 奠定的不可变 nightly 发布机制之上。RFC 3096 确立了以下核心事实稳定版与 nightly 使用互不相交的标签命名空间稳定标签形如cua-driver-rs-vX.Y.Z与lume-vX.Y.Znightly 标签采用渠道前置语法形如nightly-cua-driver-rs-vX.Y.Z-nightly.YYYYMMDD.RUN与nightly-lume-vX.Y.Z-nightly.YYYYMMDD.RUN。GitHub 的 prerelease/latest 元数据不能作为渠道边界因为稳定版 Driver 的发布也使用该元数据只能依靠严格标签语法区分渠道。精确 nightly 安装exact pin是当时唯一受支持的 nightly 接入方式用户可以复现某一个具体 nightly但无法让一台机器跟随后续 nightly——除非用户自己逐个发现并 pin 每个新标签。RFC 3101 正是要补齐这块空白让用户显式选中 nightly 渠道后后续更新自动跟随该渠道内最新的不可变 nightly 发布。同时它必须不削弱RFC 3096 的隔离不变量稳定版客户端绝不能发现 nightly除非用户显式选择了 nightly。核心概念与术语RFC 3101 用三个精确定义的术语消除了渠道一词的歧义术语定义语义Selected channel选中渠道经过校验并持久化的用户偏好取值仅为stable或nightly未来意图缺失状态等价于stableCurrent channel当前渠道仅由运行中工件artifact的严格发布版本语法推导得出当前状态不代表未来意图Exact pin精确固定完整的稳定版本号或规范的不可变 nightly 身份通过既有产品环境变量提供一次性复现/回滚控制永不改写已保存的偏好选中渠道与当前渠道的分离是整个设计的精髓前者回答用户想跟随哪条线后者回答这个二进制当前属于哪条线二者可能不一致例如用户已切换到 nightly 但二进制仍是 stable而这种不一致正是渠道转换被判定为可更新的依据。持久化设计一行 UTF-8 的 release-channel 状态文件文件格式与放置位置每个产品在自己的包/更新状态目录旁拥有一个独立的单行 UTF-8release-channel文件文件合法内容仅限stable与nightly两值Cua Driver位于CUA_DRIVER_RS_HOME未设置时回退到HOME/USERPROFILE下的用户目录中的release-channel文件路径计算见 release_channel.rs 的state_path()Lume位于LUME_HOME未设置时回退到~/.lume目录下的同名文件见 ReleaseChannel.swift 的stateFileURL()。产品主目录覆盖home override同时也会搬迁状态文件从而保证安装器与测试可以创建完全隔离、可移植的安装。读写语义缺失即 stable非法即 fail-closed缺失文件读取为stableselected_at()捕获NotFound错误并返回ReleaseChannel::Stable严格双值词表Driver 的FromStr实现只接受stable/nightly允许首尾空白其余一律报错invalid release channel {value:?}; expected stable or nightly见 release_channel.rsLume 侧通过LumeReleaseChannel(rawValue:)枚举初始化做同等校验非法/不可读状态 fail-closed绝不把未知内容解释为 nightly而是报错并给出修复指令cua-driver channel set stable或channel set nightly。这一行为由 release_channel_cli_test.rs 的channel_cli_fails_closed_on_invalid_saved_state测试锁定写入broken\n后channel status --json必须失败且 stderr 同时包含expected stable or nightly与修复提示。原子写入与 Windows 兼容写入时先创建父目录再写临时文件后通过 rename 原子替换。Driver 的实现特别处理了 Windows 上std::fs::rename无法覆盖已有目标的问题先删除旧文件再执行 rename确保任何平台上都不会把部分内容留在规范路径上见 release_channel.rs。Lume 侧则直接使用Data(...).write(to:options:.atomic)的原子写 API。需要强调的是该文件是用户偏好不是授权工件。它不含任何 token、凭证、身份、路径或会话数据也不授予任何权限——这一点在 RFC 的安全、隐私与遥测章节有专门说明。CLI 契约channel status 与 channel set两个产品暴露完全一致的 CLI 形态product channel status [--json] product channel set stable|nightly [--json]Driver 侧的 Rust 实现cua-driver channel命令在 cli.rs 的run_channel_cmd中实现channel无子命令等价于status与set构成两级子命令结构set只持久化意图绝不作为副作用替换运行中的二进制打印选中渠道后提示用户运行update --applystatus --json输出结构化状态selected_channel已保存偏好、current_channel由CARGO_PKG_VERSION经ReleaseChannel::from_version推导开发构建输出development、current_version。Driver 对current_channel的推导使用严格版本语法见 release_channel.rs无 build 元数据、无预发布后缀的X.Y.Z→stable预发布段严格匹配nightly.YYYYMMDD.RUN规范形态8 位日期、非零开头的 RUN 序号→nightly其余形态如0.19.4-dev、0.19.4-nightly.foo、0.19.4build、RUN 为0→None即不属于任何渠道。Lume 侧的 Swift 实现Lume 使用 Swift ArgumentParser 实现了同名命令见 Channel.swiftchannel默认子命令为statusChannelStatus输出selected_channel/current_channel/current_version的 JSON使用.sortedKeys保证输出稳定或人类可读文本ChannelSet校验参数必须是stable或nightly写入偏好后若current ! selected会提示运行lume update --applyLume 侧current(for:)同样通过plainVersion/nightlyVersion两套严格语法判定当前渠道。结构化更新状态区分版本升级与渠道转换更新状态中必须同时暴露selected_channel与current_channel使调用方CLI、MCP 结构化状态能够区分渠道内的普通版本升级与跨渠道转换。Driver 的UpdateState结构体在 version_check.rs 中定义这两个字段并在check_update_state_with_ownership中填充若状态文件损坏selected_channel置空、error携带修复指令。特殊情形pacman 管理的 Linux 安装Driver 对 pacman 包管理器托管的安装有专门保护见 release_channel_cli_test.rs 的pacman模块channel set与check-update/update会直接返回sudo pacman -Syu的包管理指引且绝不创建或改写上游缓存测试还验证了 PATH 上的冒牌pacman无法禁用非托管渠道切换fake_path_pacman_cannot_disable_unmanaged_channel_switching防止权限边界被欺骗。安装器--channel 参数与四级选择优先级两个产品的规范安装器Cua Driver 的 Bash/PowerShell 脚本 install.sh、Lume 的 install.sh均接受--channel stable|nightly参数带--channel时持久化该选择并安装该渠道内可见的最高已发布版本不带 flag 也没有精确 pin 时读取已保存的状态状态缺失时直接使用内嵌baked的稳定版本不发任何 API 请求nightly 选择总是通过 releases API 解析因为 nightly 标签不可变、且不引入任何可变指针只有 API 才能枚举出最新的不可变 nightly。选择优先级从高到低精确版本环境变量exact pin显式--channel参数已保存的渠道状态稳定版默认值。两个约束值得特别注意精确 pin 不写渠道状态pin 是一次性复现/回滚控制不能污染持久偏好pin 与--channel组合使用被拒绝避免到底以谁为准的歧义性持久化RFC 明确要求在 Bash 与 PowerShell 两个安装器上覆盖该拒绝路径的测试。内嵌的稳定版本仅对 stable 渠道保持权威性nightly 渠道永远不会使用内嵌稳定版本。版本发现与 apply 语义严格隔离与显式转换解析器单前缀 缓存按渠道隔离渠道解析器每次只选中一个前缀并应用严格语法stable 发现路径绝不考虑 nightly 标签nightly 路径也绝不考虑 stable 标签。Driver 的tag_prefix函数在 version_check.rs 中按渠道返回RELEASE_TAG_PREFIX或NIGHTLY_RELEASE_TAG_PREFIX。缓存同样以渠道为键VersionCache记录channel字段命中条件要求cached.channel selected_channel见 version_check.rs 与 L389-L395。因此stable 的缓存结果无法满足 nightly 检查反之亦然即便网络请求失败回退缓存也只在渠道匹配时允许。渠道内普通 SemVer 排序跨渠道显式转换同一渠道内普通 SemVer 顺序决定是否存在更新的发布当前渠道与选中渠道不同时无论相对 SemVer 大小如何都会把选中渠道内最新的发布作为一次显式渠道转换提供。也就是说即使 nightly 标签的 SemVer 版本号看起来更旧nightly 基于 patch1 派生但日期/运行号与主版本演化无关只要用户选了 nightly 而当前二进制是 stable就判定为可更新——update_is_available中current_channel ! selected_channel即视为可更新见 version_check.rs对应测试为channel_mismatch_is_available_even_when_target_version_is_lower。update --apply会固定pin解析出的那个不可变目标版本用于本次安装同时保留选中渠道不变从而不会改变未来的更新意图。这一转换优先于 SemVer的语义保证了用户channel set nightly后执行update --apply一定能切到 nightly反过来channel set stable后也一定能切回 stable而不受两个渠道版本号相对大小的干扰。可复用组件契约给未来组件的模板RFC 3101 明确列出了未来 Cua 组件可复用的六要素RFC 文档双值渠道词表stable/nightly严格命名空间选择渠道内单前缀 严格语法产品自有的单行状态文件选择优先级规则结构化状态字段selected_channel/current_channel测试矩阵。同时组件专属部分home 路径、安装器、打包、签名、平台更新器实现继续由各组件自行维护——共享的是契约而非实现这与 RFC 3096共享发布层拥有渠道机制、组件适配器拥有构建与签名的职责划分一脉相承。备选方案与设计取舍RFC 记录了几个被否决或推迟的方案理解这些取舍有助于把握设计边界方案结论理由仅环境变量选择渠道否决不持久重启即丢失从已安装工件推断用户意图否决回滚会静默改写未来行为装回旧版意外退回旧渠道用 GitHubprerelease/latest元数据作渠道边界否决RFC 3096 已定元数据不是渠道边界稳定版 Driver 也在使用该元数据中央跨产品 JSON 文件否决shell 与 PowerShell 安装器无法在不引入另一套解析器和锁协议的情况下安全更新多个无关产品的键后台/无人值守自动 apply非目标始终要求显式 apply可变 nightly 标签/资产、注册表渠道、对象存储指针非目标/推迟保持不可变性与精确复现兼容性与迁移路径RFC 3101 对既有安装完全向后兼容旧机器没有状态文件 → 保持 stable行为与现在一致已有的精确 stable pin 与 nightly pin 语义不变opt-in / opt-out 流程channel set nightlyupdate --apply切入 nightly对应的 stable 命令切回稳定版单次安装器调用--channel同时完成设置安装两步精确 pin 仍是受支持的回滚与复现路径。RFC 明确承诺不改变任何稳定标签、nightly 标签、manifest、签名、权限或会话契约。安全、隐私与遥测边界渠道选择是显式的本地用户意图状态文件不含 token/凭证/身份/路径/会话数据不授予任何权限GitHub 元数据无法参与渠道选择渠道边界只由标签语法决定既有的签名、公证notarization、摘要digest、审批与显式 apply 边界保持各自独立约束遥测只允许记录规范化渠道词表与既有的有界更新结果不得记录偏好文件路径也不得把渠道状态用作标识符。实施计划与测试验收从合并到公开资产验证RFC 给出的实施步骤依次为为 Driver 增加经过校验的渠道状态与渠道感知发现逻辑 → 打通 Unix/Windows 安装器、CLI、更新器、缓存、MCP 状态与生成文档 → 为 Lume 增加同等契约 → 补充跨平台解析器/持久化/安装器/契约测试并保留稳定版可见性测试 → 普通 CI 转绿后合并随后发布精确 main SHA 的 nightly并通过公开资产证明 stable→nightly→stable 的完整往返。验收要点均有对应测试矩阵锁定缺失状态解析为 stable、合法状态可往返、非法状态 fail-closed 并带修复指令两个产品的 stable 发现拒绝一切 nightly 形态、nightly 发现拒绝一切 stable 形态Bash 与 PowerShell 上覆盖精确 pin 优先级与 pin--channel拒绝内嵌稳定版本仅在 stable 渠道使用nightly 总是解析不可变公开标签更新缓存不得跨渠道复用结构化 CLI 与 MCP 更新状态暴露 selected/current 渠道stable→nightly 与 nightly→stable 转换跨 SemVer 边界也能被提供并应用新鲜的 Driver/Lume nightly 从合并后的 main SHA 发布含签名工件、manifest、校验和与归因发布说明。小结渠道选择在 Cua 中的定位RFC 3101 把用户想跟随哪条发布线变成了 Cua Driver 与 Lume 两套代码库中同构、可持久、可审计的一等公民一行 UTF-8 状态文件承载偏好两个 CLI 命令承载读写安装器--channel承载一次性接入严格标签语法与渠道键缓存承载隔离而精确 pin 始终独立于偏好、专司复现与回滚。对于想要长期吃 nightly、随时可回滚稳定版的用户这套机制提供了明确且安全的操作路径对于未来的 Cua 组件它也给出了一份可以直接照搬的组件契约。如需深入可继续阅读RFC 原文、前置 RFC 3096、Driver 的渠道状态实现 release_channel.rs、渠道 CLI 实现 cli.rs、渠道感知的更新检查 version_check.rs、CLI 集成测试 release_channel_cli_test.rs以及 Lume 侧的 Channel.swift 与 ReleaseChannel.swift。【免费下载链接】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），仅供参考