当我们讨论 AI 代理（Agent）控制计算机时，最常见的思路是将视野限定在浏览器自动化上 —— 让模型点击网页元素、填写表单、执行 JavaScript。这种浏览器控制代理（Browser Agent）在过去一年里出现了大量开源实现，如 browser-harness、browser-use 等，它们本质上是基于 DOM 结构的 UI 自动化。然而，真实世界的计算任务远不止浏览器：AI 需要操作桌面应用程序、处理文件系统、与原生 GUI 交互、在多个窗口间切换，甚至控制开发工具链。这就是 CUA（Computer-Use Agents）诞生的背景 —— 一个专注于全桌面控制的完整基础设施开源项目。CUA 不仅仅是一个更大的浏览器自动化工具，它是一套面向跨平台沙箱、标准化 SDK 与可复现评估基准的完整技术栈。
全桌面控制与浏览器自动化的本质差异
理解 CUA 的设计思路，首先需要区分全桌面控制与浏览器自动化的根本区别。浏览器自动化的操作对象是网页 DOM 树，核心输入是 HTML 结构和 CSS 样式，模型通过解析页面语义来完成点击、输入等动作。这种方式的优点是结构清晰、可预测性强，缺点是能力边界明显 —— 它无法操作浏览器之外的任何软件。全桌面控制面对的是真实的操作系统：鼠标指针、窗口管理、文件系统、系统级 API 调用、跨进程交互。CUA 支持 macOS、Linux、Windows 三大桌面系统，甚至扩展到 Android 和 BYOI（Bring Your Own Image，自定义虚拟机镜像），这意味着模型可以在一个统一的抽象层下完成从 “打开记事本” 到 “运行 Blender 建模” 的任何任务。
CUA 项目目前的星标数已超过 14.2k，拥有 883 个分支和超过 460 个发布版本，项目活跃度极高。它由多个核心组件构成：Cua Driver（后台 macOS 代理）、Cua Sandbox（跨平台沙箱 SDK）、CuaBench（评估基准与强化学习环境）、CuaBot（多代理沙箱 CLI）以及 Lume（macOS 虚拟化工具）。这些组件并非简单的工具集合，而是一个面向全桌面控制场景的完整技术生态系统。每一个组件都围绕同一个核心目标设计：让 AI 代理能够安全、可控、可评估地操作真实桌面环境。
沙箱架构：跨平台统一的隔离层
CUA 的沙箱设计是整个基础设施的核心。它并非为每个操作系统单独构建一套方案，而是通过统一的抽象接口屏蔽底层差异，开发者只需调用同一套 Python API，即可在 Linux 容器、Linux 虚拟机、macOS 虚拟机、Windows 虚拟机或 Android 模拟器之间切换。这种设计思路类似于云计算中的基础设施抽象 —— 无论底层是 AWS EC2 还是 GCP VM，对上层应用来说都只是 “一个可以运行的实例”。具体而言，CUA 提供了 Sandbox.ephemeral(Image.linux()) 这样的链式调用语法，其中 Image 可以是预定义的系统镜像，也可以是用户自定义的 .qcow2 或 .iso 文件。这意味着团队可以在本地用 QEMU 运行 macOS 虚拟机进行调试，也可以无缝切换到云端 cua.ai 托管的相同环境进行大规模评测。
沙箱的安全性是全桌面控制框架的命门。与浏览器自动化不同，桌面环境拥有更高的系统权限，AI 代理的每一个操作都可能导致不可逆的系统变更 —— 删除关键文件、修改注册表、执行恶意命令等。CUA 通过三层机制保障安全：第一层是环境隔离，无论是 Docker 容器还是 QEMU 虚拟机，每个沙箱实例都是独立运行环境，天然防止对宿主机的破坏；第二层是操作审计，CUA 记录每个鼠标点击、键盘输入和 shell 命令的执行轨迹，形成可回放、可复现的训练数据；第三层是可选的权限控制，通过配置文件限制沙箱内的网络访问、文件系统范围和 API 调用白名单。对于云端部署，CUA 额外提供了沙箱资源配额管理和会话超时控制，单个任务的最长执行时间建议设置为 5 至 15 分钟，具体取决于任务复杂度。
SDK 设计：统一 API 背后的工程权衡
Cua-Sandbox SDK 是整个项目工程化程度最高的部分。它的设计哲学是 “同一套 API，适配所有操作系统”。当你写 await sb.mouse.click(100, 200) 时，底层可能是 Linux 容器中的 xdotool、macOS 虚拟机中的模拟输入事件，或者 Windows 虚拟机中的 UI Automation API。这种抽象是有代价的：不同操作系统的坐标系统、输入事件模型和 UI 层级结构存在显著差异。例如，macOS 的坐标原点在左下角而 Windows 和 Linux 在左上角，macOS 的 Accessibility API 对非 AX 表面（如 Chromium 内嵌内容、Canvas 绘图应用）的支持有限。CUA 团队通过构建平台特定的适配层来弥合这些差异，并在 Cua Driver 中实现了对非 AX 表面的后台控制能力 —— 这意味着即使面对 Figma、Blender 或游戏引擎这类特殊应用，AI 代理也能在不抢占用户光标的前提下完成操作。
从工程实践角度，使用 CUA SDK 时有几个关键参数值得注意。初始化超时默认设为 60 秒，适用于大多数云端镜像拉取场景；如果是本地 QEMU 启动 macOS 虚拟机，初始引导时间可能达到 2 至 3 分钟，需要相应调整。截图功能默认返回 PNG 格式，分辨率与沙箱窗口尺寸一致，如果需要高频截图用于模型视觉输入，建议将窗口尺寸固定为 1280×800 或 1920×1080 以减少坐标归一化误差。键盘输入方面，CUA 自动处理了特殊键映射，但在非英语键盘布局下可能出现字符错位，建议通过 keyboard.type 的 locale 参数显式指定。此外，Cua Agent 框架内置了 OmniParser 支持，这是一个基于视觉语言模型的 UI 元素解析器，可以将截图转换为结构化的可交互元素坐标，使得模型无需依赖平台的 Accessibility API 也能理解界面布局。
跨平台评估基准：从 Benchmark 到强化学习环境
CUA-Bench 是基础设施中面向模型评估与训练的关键组件。它不是一个单一的基准测试集，而是集成了多个业界评估框架的统一入口：OSWorld、ScreenSpot、Windows Arena 以及自定义任务集。OSWorld 是当前最成熟的桌面任务基准，它在真实的 Ubuntu、Windows 和 macOS 虚拟机中预定义了数百个开放式任务 —— 从 “打开 VS Code 并创建一个 Python 文件” 到 “在 Excel 中完成数据透视表”，每个任务都有明确的成功判定标准。ScreenSpot 则侧重于评估模型的 UI 元素定位能力，给定一张截图和一个自然语言指令（如 “点击红色的关闭按钮”），模型需要输出准确的点击坐标。Windows Arena 专门针对 Windows 生态，涵盖 Office 365 应用程序、文件资源管理器、系统设置等原生 Windows 场景。
CUA-Bench 的真正价值在于它将基准测试与强化学习训练流程打通。开发者可以使用 cb run 命令在指定数据集上运行代理，并将执行轨迹（trajectory）导出为训练数据。轨迹数据包含每一步的屏幕截图、执行的 Action、返回的观察结果（Observation）以及任务是否成功完成。这种设计使得 CUA 不仅是一个评测工具，更是一个数据生成管线 —— 对于训练桌面控制模型的研究团队来说，高质量的交互轨迹是最稀缺的资源。实践中建议的参数配置包括：单次评测最大步数设为 50 至 100 步（根据任务复杂度调整），并行评测数量本地环境不超过 4 个（避免资源争抢），云端可根据实例规格提升至 16 至 32 个。任务超时设置建议为 300 秒，超时任务直接判定为失败并记录截断原因。
实践建议与可落地参数
在生产环境中部署 CUA 基础设施时，有几个工程要点值得特别关注。首先是镜像管理：预定义的 Linux 容器镜像大约在 500MB 至 2GB 之间，首次使用建议在本地缓存；macOS 虚拟机镜像更大，通常需要 10GB 以上存储空间，建议使用 SSD 并预留充足的空间避免 I/O 瓶颈。其次是资源调度：Cua-Bench 在本地运行时默认使用 QEMU 虚拟化，单个 macOS 虚拟机建议分配 4 核 CPU 和 8GB 内存，Linux 容器则可以更激进地共享宿主资源。第三是安全策略：除非明确需要网络访问，建议将沙箱的网络模式设为 isolated 或仅允许白名单域名；云端部署时可启用会话级别的资源配额，超出配额后自动终止并清理。
如果你正在评估或构建全桌面控制的 AI 代理系统，CUA 提供的不仅是一套工具，更是一个经过大规模社区验证的设计范式。它证明了 “统一抽象层加平台适配器” 这一架构在跨操作系统场景下的可行性，同时通过沙箱隔离保障了安全性。对于浏览器自动化无法覆盖的场景 —— 如 IDE 操作、桌面应用工作流、系统配置任务 ——CUA 提供了目前最完整的开源解决方案。
资料来源：
- CUA 官方仓库：https://github.com/trycua/cua
- CUA 文档中心：https://cua.ai/docs