trycua/cua：一套代码驱动五类操作系统，计算机使用智能体的开源底座

一个仓库，四个工具，解决计算机使用智能体的规模化问题

一个仓库，四个工具，解决计算机使用智能体的规模化问题。trycua/cua 把驱动、沙箱、基准测试和 macOS 虚拟化打包在一起。cua-driver 负责后台驱动原生应用，cua-sandbox 提供统一 API，cua-bench 用于评估和训练，Lume 管理 macOS 虚拟机。每个工具服务不同人群，但共享同一套设计理念：让智能体操作真实计算机，而不是模拟环境。

cua-driver：后台输入是亮点，也是限制所在

cua-driver 的核心卖点是“在后台”操作。智能体点击、输入、验证时，用户仍然可以使用自己的鼠标和键盘。这对编码智能体尤其重要，因为开发者不想看着自己的光标被程序抢走。安装方式很简单，macOS 和 Linux 用 curl 脚本，Windows 用 PowerShell 一行命令。但文档没有详细说明 Windows 后台输入的具体实现机制，只提到 Linux 支持 X11 和“compositor-specific Wayland routes with explicit limits”。这个“explicit limits”值得注意，说明 Wayland 下并非所有窗口都能被后台操作。对 macOS，文档提到需要遵循 post-install 指令，通常涉及辅助功能权限。如果你需要驱动受保护的系统对话框，比如 macOS 的权限弹窗，后台输入可能失效。这是 cua-driver 的边界，也是评估时最需要实测的部分。

Sandbox API：同一套代码，五种操作系统

cua-sandbox 的抽象非常直接。pip install cua 之后，用 Sandbox.ephemeral(Image.linux()) 创建沙箱，然后调用 shell.run、screenshot、mouse.click、keyboard.type。切换操作系统只需换 Image.macos() 或 Image.windows()。代码示例中还有 mobile.gesture 处理多点触控，说明 Android 也被纳入统一抽象。支持矩阵显示，Linux 容器和 Linux VM 在本地 QEMU 和云端 cua.ai 都可用，macOS、Windows、Android 在本地依赖 QEMU，云端也支持。BYOI（自带镜像）在本地支持 .qcow2 和 .iso，云端标注“soon”。这意味着你可以用本地 QEMU 跑 Windows 虚拟机，但性能取决于硬件虚拟化支持。对于需要真实操作系统环境的智能体，这个 API 省去了大量胶水代码。但注意，ephemeral 意味着每次创建都是全新环境，状态不保留，这适合测试，不适合需要持久化的任务。

cua-bench：不只是跑分，还能导出训练轨迹

cua-bench 的价值在于它连接了评估和训练。命令 cb run dataset datasets/cua-bench-basic --agent cua-agent --max-parallel 4 可以并行跑基准测试。支持 OSWorld、ScreenSpot、Windows Arena 这些公开基准，也支持自定义任务。更重要的是，它能把轨迹导出用于训练，这对强化学习尤其有用。安装方式使用 uv tool install -e .，然后 cb image create linux-docker 创建基础镜像。这意味着 cua-bench 依赖 Docker 或类似容器运行时。如果你没有 Docker 环境，这个工具无法工作。另外，cua-bench 的 registry 在 cuabench.ai，但需要“Partner With Us”才能访问，说明部分数据集可能不是完全开放。对于只做推理评估的人，cua-bench 可能过重，直接用现成基准脚本更轻。

Lume：macOS 虚拟化的实用主义方案

Lume 解决的是 macOS 虚拟化这个特殊问题。在 Apple Silicon 上，用 Apple 的 Virtualization.Framework 创建 macOS 虚拟机，性能接近原生。安装后，用 lume ipsw 下载恢复镜像，然后 lume create 创建虚拟机，--unattended 选项可以离线预配置系统。内置的 sequoia 和 tahoe 预设会自动创建 lume 用户，启用 SSH，配置自动登录，并禁用休眠和屏幕锁定。默认凭据是 lume / lume，这在生产环境需要立即修改。文档明确说 Tahoe 流程已端到端验证，但 Sequoia 首次显示启动时可能仍会打开 Setup Assistant 的 Accessibility 步骤，见 issue #2155。这意味着如果你需要自动化部署 Sequoia 虚拟机，可能会卡在手动步骤。Lume 的价值在于它让 macOS 虚拟机可以脚本化创建，但稳定性取决于 macOS 版本。

安装与上手：从一行命令到 Python API

实际使用路径很清晰。cua-driver 的安装是 curl 或 PowerShell 一行命令，然后根据 post-install 指示配置权限。cua-sandbox 更简单，pip install cua 即可，但要求 Python 3.11 或更高。README 中的示例代码展示了完整流程：创建沙箱、运行 shell 命令、截图、鼠标点击、键盘输入、手势操作。cua-bench 需要 git clone 仓库，然后 uv tool install -e .，这要求系统有 uv 工具。Lume 的安装也是 curl 脚本，但创建虚拟机需要下载 IPSW 镜像，体积可能很大。注意，所有安装脚本都通过 cua.ai 域名分发，如果你在受限网络环境，可能需要手动下载。另外，cua-driver 的安装脚本没有提供校验和，安全性依赖 HTTPS，这在企业环境可能是个问题。

局限与替代方案：不是所有场景都适合

这个项目有明显的边界。cua-driver 的 Wayland 支持有限，Windows 后台输入机制不透明，macOS 需要辅助功能权限，这些都可能成为失败点。cua-sandbox 依赖 QEMU，本地运行虚拟机需要硬件虚拟化支持，否则性能不可用。cua-bench 依赖 Docker，且部分数据集需要合作访问。Lume 只支持 Apple Silicon，Intel Mac 无法使用。替代方案方面，如果你只需要 Linux 容器内的屏幕操作，可以考虑更轻量的方案，比如直接使用 Docker 和 Xvfb，但那样你需要自己处理屏幕捕获和输入注入。对于 macOS 虚拟化，没有其他开源方案能直接替代 Lume，但商用方案如 Anka 或 Parallels 提供类似功能，只是不是开源。对于基准测试，OSWorld 和 ScreenSpot 本身就有官方脚本，如果你不需要训练数据导出，直接用官方实现更简单。

维护与许可：MIT 许可证下的多组件风险

整个仓库采用 MIT 许可证，这对商业使用很友好，没有 copyleft 约束。但要注意，仓库包含多个独立组件，每个组件的维护节奏可能不同。最近发布记录显示，cua-computer-server 有 v0.3.45 和 v0.3.43，相隔不到一小时，说明迭代频繁。nightly-lume 版本几乎每天更新，这意味着 Lume 的稳定性可能不如稳定版。如果你在生产环境使用，建议锁定具体版本，而不是跟随 nightly。升级成本方面，cua-sandbox 的 API 变化可能需要关注，因为 Python SDK 的接口如果变动，你的代码需要同步更新。cua-driver 的安装脚本是远程执行的，升级需要重新运行脚本，但文档没有说明版本回滚机制。对于长期维护，你需要关注 GitHub 上的 issue 跟踪，比如 Sequoia 的 Accessibility 问题，这会影响你的部署计划。

编辑结论

若你在构建需要操作真实桌面应用的智能体，且希望同一套抽象同时覆盖 Linux、macOS、Windows 与 Android，trycua/cua 值得认真评估。它用统一的 Sandbox API 屏蔽了底层差异，又用 cua-driver 解决了后台输入这个棘手问题。但不要被“跨 OS”的宣传迷惑：本地 macOS 与 Windows 依赖 QEMU 与 Apple Virtualization.Framework，性能与宿主机配置强相关；cua-driver 的 Windows 后台输入能力在文档中未明确承诺，Linux Wayland 也有明确限制。建议先跑通 README 中的 Python 示例，确认你的目标系统在支持矩阵内，再用 cua-bench 的 cua-bench-basic 数据集验证 agent 的真实表现。若你只需要 Linux 容器内的屏幕操作，更轻量的方案可能更合适；若你需要 macOS 虚拟机，Lume 是唯一直接可用的开源选择，但 Sequoia 首次启动可能卡在 Accessibility 步骤，这是已知问题。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes