用 Nix 构建与验证 cua-driver Linux 计算机使用驱动可复现构建、权限策略与原生 Wayland E2E 指南【免费下载链接】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 仓库中 nix/cua-driver/README.md 为骨架系统讲解 Nix 在 cua-driver 测试栈中的两大职责可复现的 Linux 构建以及为 Rust 类型化测试提供桌面会话依赖。读完本文你将掌握如何用 Nix 构建 cua-driver 二进制、在 NixOS VM 中验证 YAML/Rego 权限策略、一键拉起原生 Wayland E2E 测试矩阵并理解为何所有协议与桌面行为断言都收敛到 Rust 测试这一单一事实来源。一、Nix 在 cua-driver 测试栈中的定位cua-driver 是 cua 项目的跨平台计算机使用computer-useMCP 服务器。在 Linux 侧Nix 承担两项明确职责可复现的 Linux 构建从锁定的 Rust 源码构建随版本发布的 Linux 包保证任何机器上产物一致桌面会话依赖为类型化 Rust 测试矩阵Sway、GTK、WebKit、Chromium、Electron、屏幕捕获等提供完整的桌面会话运行环境。这种分工直接反映在 flake 的检查项与 devShell 上。仓库根目录的 flake.nix 中cuaDriverPackage由nix/cua-driver/package.nix导入cuaCompositorPackage由nix/cua-driver/compositor提供nixosModules.cua-driver指向 module.nix。所有检查统一由 Nix 表达无需手工维护 CI 脚本与构建环境。二、七个 Nix attribute 一览原文档给出了七个 attribute 的职责与 CI 归属逐一说明如下Attribute用途CI / 触发方式cua-driver-build从锁定的 Rust 源码构建随发布的 Linux 包ci-nix-linux.ymlcua-driver-linux-rust-unit编译并运行源码自带的 headless Rust 单元测试ci-nix-linux.ymlcua-driver-policy-yaml在 NixOS VM 中执行 YAML 权限策略的 MCP 检查Flake checkcua-driver-policy-rego在 NixOS VM 中执行内嵌 Rego 权限策略的 MCP 检查Flake checkcua-driver-wayland-e2e提供原生 Wayland E2E 所需的 Sway、GTK、WebKit、Chromium、Electron、捕获与 Rust 工具链e2e-rust-linux-wayland.ymlcua-driver-inject-e2e提供与上者相同的类型化测试工具链并额外包含嵌套cua-compositor包实验性嵌套注入工作流cua-compositor-build针对固定的 wlroots 构建可选的原生注入后端Flake check从 tests/README.md 可以看到Nix 表达式按证明了什么分组rust-unit.nix负责无桌面会话的源码构建检查policy-yaml.nix与policy-rego.nix负责 NixOS VM 中的 stdio 权限策略检查。该目录刻意不包含桌面行为目录——Nix 只负责构建驱动、单元检查、会话依赖与可选合成器包权威 GUI 场景与断言全部位于类型化 Rust 测试框架中。三、可复现构建package.nix 的工程细节package.nix 是构建 cua-driver Linux 二进制的核心表达式。二进制通过 stdio 提供 40 个 MCP JSON-RPC 2.0 工具覆盖屏幕捕获、鼠标/键盘输入、窗口管理与基于无障碍树accessibility的元素交互。几个关键设计值得深入版本单一来源version (pkgs.lib.importTOML ${src}/Cargo.toml).workspace.package.version;直接从 Cargo.toml 的 workspace 元数据读取版本。这避免了曾经在 0.5.3 → 0.5.6 之间因硬编码字面量漂移导致的构建错误。基于importCargoLock的依赖锁定直接引用提交的 Cargo.lock而非手工维护cargoHash。importCargoLock从 lockfile 本身推导每个依赖的 fixed-output hash——Cargo.lock 变化版本升级、依赖更新后构建依然可用。仓库内所有依赖均为 crates.io registry crate包括仅 macOS 使用的 apple-cf/apple-metal/objc2零 git 依赖因此无需outputHashes覆盖。按平台裁剪编译目标workspace 还包含 platform-macos、platform-windows 与 cua-driver-uia它们被cfg(target_os)门控无法在 Linux 上编译。构建通过-p cua-driver只解析 Linux 依赖。Portal 能力显式启用cargoBuildFlags/cargoTestFlags均带--features portal-input,portal-capture。这会拉入 GNOME/KDE portal 栈——PipeWire ScreenCast 逐窗口捕获与 libei RemoteDesktop 输入。nixpkgs 提供了 PipeWire 0.3.40libspa-sys 所需与 libei因此该 feature 可正常构建并同时验证了 split feature 合约的两个半区。依赖几乎纯 Rustx11rb纯 Rust无需 libxcb C 绑定、ureq rustls无 OpenSSL、tiny-skia纯 Rust 2D 图形、ring经 stdenv cc 编译自身 C/asm。x11crate用于 MPX 多光标拖拽的 Xlib FFI需要 libX11/libXi/libXtstWayland 平权工作则增加 PipeWirelibpipewire-0.3 libspa 头文件 bindgen/clang 生成 SPA pod与 libei经 ashpd tokio feature 传递依赖。禁用运行时桌面测试doCheck false跳过需要 X11 display 或 AT-SPI bus 的测试该职责由 headless 的 rust-unit 检查与独立 E2E 工作流承接。四、NixOS 模块一条命令安装驱动与运行时依赖module.nix 提供services.cua-driverNixOS 模块用于安装 cua-driver 二进制及其 Linux 计算机使用自动化运行时依赖X11、AT-SPI 无障碍、ImageMagick。在 NixOS 配置中启用imports [ ./nix/cua-driver/module.nix ]; services.cua-driver { enable true; package cuaDriverPackage; };模块内部做三件事向environment.systemPackages添加cfg.package、imagemagickcapture.rs用其import命令截取窗口截图与at-spi2-coreAT-SPI bus 守护进程用于无障碍树查询启用services.dbus——AT-SPI 通信依赖 D-Bus设置环境变量CUA_DRIVER_BIN ${cfg.package}/bin/cua-driver供上层工具定位驱动二进制。该模块要求使用者必须显式设置package选项lib.types.package从而保证用户对自己运行的驱动版本有完全控制。五、权限策略的 NixOS VM 验证YAML 与 Rego权限策略是计算机使用驱动的安全关键点。Nix 侧通过两个 NixOS VM 集成测试在完全隔离的虚拟机内对驱动进行 MCP stdio 黑盒验证。5.1 YAML 策略测试policy-yaml.nixpolicy-yaml.nix 构造如下策略文件allow: tools: - screenshot rules: - tool: click constraints: x: { min: 0, max: 1920 } y: { min: 0, max: 1080 } deny: tools: - type_text随后以cua-driver serve --socket ... --no-permissions-gate --no-overlay启动守护进程再通过cua-driver mcp --socket ...建立 MCP stdio 会话依次断言四条契约initialize成功.result ! nullscreenshot允许调用且返回error nulltype_text被拒绝返回isError true且错误文本以Permission denied:开头click越界坐标x1921被拒绝同样返回 Permission denied。这验证了 YAML 策略的 allow/deny 列表与参数约束arguments constraints在真实 MCP 协议层的执行效果。5.2 Rego 策略测试policy-rego.nixpolicy-rego.nix 验证内嵌 Rego 策略引擎。策略拆成两个文件base.rego声明默认拒绝default allow falsetools.rego放行screenshot以及坐标在 0..1920 / 0..1080 范围内的clickpackage cua.policy default allow false allow if input.tool screenshot allow if { input.tool click input.arguments.x 0 input.arguments.x 1920 input.arguments.y 0 input.arguments.y 1080 }测试流程与 YAML 版本一致但CUA_DRIVER_POLICY_FILE指向目录而非单文件。越界用例为x2000同样期望Permission denied:。两套测试共同证明无论策略以 YAML 还是 Rego 表达驱动都会在 MCPtools/call层强制执行而不是仅靠上层客户端自觉。5.3 headless 单元检查rust-unit.nixrust-unit.nix 与 package.nix 刻意分离随发布的大包必须保持与显示无关而此检查在 Nix 可复现构建环境中验证 Rust 源码与测试工具。cargoTestFlags覆盖cua-driver、cua-driver-core、cua-driver-testkit、platform-linux四个 crate 的全部 target且doCheck true——默认 Cargo 测试集刻意保持 headless被忽略的桌面矩阵交由手工 Linux E2E 工作流运行不藏在 Nix 里。六、原生 Wayland E2E一条命令跑完整矩阵原文档给出了从仓库根目录运行原生 Wayland 测试矩阵的命令nix develop .#cua-driver-wayland-e2e -c \ scripts/ci/linux/run-rust-e2e-wayland.sh这条命令背后的执行链值得拆解见 run-rust-e2e-wayland.sh纯 Wayland Sway 会话脚本生成临时 Sway 配置核心是xwayland disable如需回归验证 XWayland 场景可设CUA_E2E_WAYLAND_SESSIONsway-xwayland脚本会将其改写为xwayland force并在结束后导出CUA_E2E_XWAYLAND_DISPLAY、output HEADLESS-1 mode 1920x1080、focus_follows_mouse no以及为测试框架窗口CuaTestHarness与哨兵窗口CuaTestHarness Sentinel设置的浮动/全屏规则。headless 渲染环境置空DISPLAY/WAYLAND_DISPLAY导出XDG_RUNTIME_DIR私有临时目录权限 700、WLR_BACKENDSheadless、WLR_RENDERERpixman、WLR_RENDERER_ALLOW_SOFTWARE1、WLR_LIBINPUT_NO_DEVICES1、WLR_HEADLESS_OUTPUTS1并开启CUA_DRIVER_RS_ENABLE_WAYLAND1。独立会话总线与无障碍栈自动拉起私有dbus-daemon从 nixpkgs 路径解析 session.conf再用at-spi-bus-launcher --launch-immediately启动无障碍总线通过gdbus轮询org.a11y.Bus.GetAddress与org.a11y.atspi.Registry就绪导出AT_SPI_BUS_ADDRESS并启用org.a11y.Status IsEnabled确保任何测试工具在继承会话前无障碍栈已可用。共享历史加密门当CUA_E2E_INTERNAL_LANE为shared或all时用gnome-keyring-daemon --unlock --componentssecrets解锁 Secret Service并在 15 秒内轮询org.freedesktop.secrets就绪——加密的 Computer History 生命周期测试依赖这个私有的可丢弃会话总线。合成器选择与 socket 就绪检查默认启动sway --unsupported-gpu --config ...若SESSION_KINDcua-compositor则启动嵌套cua-compositor并等待其注入 socketCUA_INJECT_SOCKET。20 秒内等待 Wayland socket 出现并额外校验 Sway IPC socket / XWayland socket视会话类型而定失败时导出合成器日志便于排障。调用共享 Rust 运行器CUA_E2E_WAYLAND_RUNNER默认指向run-rust-e2e.sh即与 X11 完全相同的类型化 Rust 运行器。Wayland 侧只负责会话行为断言全部复用 Rust 目录。结果使用统一的类型化 JSONL schema 输出并在artifacts/cua-driver/linux/下保留 MP4 轨迹录像CUA_WAYLAND_RECORDING_OUTPUTHEADLESS-1指定录像输出。若 Sway 会话失败还会额外导出sway-tree.json帮助定位窗口层级问题。七、嵌套注入实验工作流cua-compositorcua-driver-inject-e2edevShell 在 Wayland E2E 工具链基础上叠加了cua-compositor包。该包定义于 compositor/default.nix一个基于 wlroots 的最小 headless 合成器cua-driver 将其作为嵌套会话CUA_WAYLAND_NEST_COMPOSITORcua-compositor启动通过 unix 控制 socket 提供免聚焦键盘注入与多光标指针注入。它从 wlroots 上游 tinywl 示例经 cua_compositor_patch.py 转换而来并固定到 nixpkgs 中同一wlroots_0_19因此能精确跟踪 nixpkgs 的 wlroots API无需内置 C 代码。在 run-rust-e2e-wayland.sh 中该工作流通过CUA_E2E_COMPOSITORcua-compositor-nested、CUA_E2E_INPUT_BACKENDSatspi,cua-compositor-inject、CUA_E2E_HARNESS_FILTERelectron组合启用等待cua-inject.sock出现后运行同样的 Rust 运行器。八、单一事实来源为什么桌面行为断言只属于 Rust原文档明确强调Rust 测试拥有全部协议与桌面行为。旧的 NixOS Python 客户端、GIF 场景、真实应用冒烟矩阵与合成器矩阵已被移除因为它们维护了第二套断言不同的场景目录。规范化的 Rust 矩阵是覆盖度的事实来源除非有当前类型化用例证明同一契约否则退役的行不被视为等价。对应的目录约定也在 tests/README.md 中固化新的用户行为覆盖应首先进入 Rust 测试框架Nix 检查可以提供会话与包环境但必须调用共享的 Rust 目录而不是定义第二套行为断言。这与 rust-unit.nix 中默认 Cargo 测试刻意 headless、桌面矩阵交 E2E 工作流的分层设计一脉相承保证了行为覆盖的唯一性与可追溯性。九、在本地复现与验证把上述内容落到本地核心操作如下仓库根目录执行# 1. 构建随发布的 Linux 驱动包 nix build .#cua-driver-build # 2. 编译并运行 headless Rust 单元检查 nix build .#cua-driver-linux-rust-unit # 3. 在 NixOS VM 中验证 YAML / Rego 权限策略 nix flake check .#checks.x86_64-linux.cua-driver-policy-yaml nix flake check .#checks.x86_64-linux.cua-driver-policy-rego # 4. 启动原生 Wayland E2E 全矩阵见上文第六节 nix develop .#cua-driver-wayland-e2e -c \ scripts/ci/linux/run-rust-e2e-wayland.sh # 5. 实验性嵌套注入工作流 nix develop .#cua-driver-inject-e2e -c \ scripts/ci/linux/run-rust-e2e-inject.sh各检查对应的包与 shell 均注册在 flake.nixcua-driver/cua-compositor作为 packagescua-driver-build、cua-driver-linux-rust-unit、cua-driver-policy-yaml、cua-driver-policy-rego、cua-compositor-build作为 checkscua-driver-wayland-e2e与cua-driver-inject-e2e作为 devShells。运行结果JSONL 与 MP4 轨迹统一落在artifacts/cua-driver/linux/可结合仓库内的 e2e-ci-reporting.md 等文档进一步分析。十、适用前提与边界构建环境以上命令依赖 Nix含 flakes与 nixpkgs 中对wlroots_0_19、PipeWire 0.3.40、libei 的打包不同 nixpkgs 版本下依赖可用性可能变化。平台限制package.nix的meta.platforms platforms.linux构建目标是 Linux 发行包macOS/Windows 侧由 workspace 内对应平台 crate 处理。行为覆盖Nix 检查只证明构建、单元测试、权限策略强制、会话可用不替代 Rust 端 GUI 行为断言新增用户行为覆盖请遵循第八节约定先写进 Rust 测试框架。【免费下载链接】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），仅供参考