当大模型能够操控桌面操作系统完成复杂任务时，如何安全、可复现地训练与评测这类能力，成为行业亟待解决的基础设施难题。GitHub 上斩获 16.4k Stars 的开源项目 CUA（trycua/cua）给出了一套完整的答案：它以统一 SDK 为核心，构建了覆盖沙箱创建、后台控制、基准评测、macOS 原生虚拟化的全栈技术方案，让 Computer-Use Agent 的开发与评估从玄学走向工程化。
问题的本质：桌面控制为何需要专用基础设施
传统的 AI Agent 多运行于 CLI 环境或浏览器沙箱中，其交互边界相对清晰。然而，当 Agent 需要「控制完整桌面」—— 点击原生应用按钮、操作本地文件、跨应用协作时 —— 问题复杂度急剧上升。macOS 上的非 AX 表面（如 Chromium 内核、Figma、DAW、游戏引擎）无法通过标准辅助功能 API 访问；Windows 需要真正的虚拟机隔离而非容器共享内核；Linux 则面临 Wayland/X11 并存与显示服务差异。这些差异意味着，为每个操作系统单独实现控制层的工作量足以劝退大多数团队。
CUA 的核心价值在于将这种平台差异抽象为统一的编程接口。开发者使用同一套 Python SDK 发起 sandbox.screenshot()、sandbox.mouse.click()、sandbox.keyboard.type() 调用，底层自动路由至对应平台的实现：macOS 上的 Cua Driver、QEMU 虚拟机、或 Docker 容器中的 Linux 会话。这种设计使得 Agent 算法开发者可以专注于决策逻辑，而将跨平台兼容性的复杂度下沉至 CUA 层。
分层架构：从虚拟机到 Agent SDK
CUA 的技术栈可以划分为四个核心层次，每一层解决一个关键问题。
沙箱运行时：多后端隔离执行环境
最底层是沙箱运行时，负责提供隔离的执行环境。CUA 支持四种后端，覆盖从轻量到完整的全谱场景。
Docker Linux 容器是最轻量的选项，适用于不需要完整桌面会话的场景。CUA 官方提供两个预构建镜像：trycua/cua-xfce（轻量 XFCE 环境，推荐日常使用）和 trycua/cua-ubuntu（完整 Ubuntu 桌面，基于 KASM）。在 Docker 中运行意味着共享宿主机内核，资源开销极低，适合大规模并发评测任务。典型启动命令仅需指定平台架构即可拉取镜像并创建会话。
QEMU 虚拟机提供真正的硬件虚拟化，支持 Linux、Windows 和 Android 的完整桌面环境。Windows 评测需要通过微软评估中心下载 90 天试用版 ISO（当前约 6GB），首次使用需执行 Golden Image 准备流程 ——CUA 容器会自动完成从 ISO 启动、安装配置、直至生成可复用的虚拟机镜像。Linux 的 Golden Image 流程类似，需要准备 Ubuntu 22.04 LTS Server ISO（约 2GB）。Android 镜像则无需准备步骤，可直接启动，但当前仅支持 Android 11。QEMU 模式下，通过 --device=/dev/kvm 启用硬件加速虚拟化（需宿主机启用 KVM），环境变量 RAM_SIZE、CPU_CORES、DISK_SIZE 控制资源配置，默认建议 8GB 内存与 4 核 CPU。
Apple Silicon macOS 主机可选 Lume 作为虚拟化引擎。Lume 基于 Apple 原生 Virtualization Framework，相比 QEMU 在 macOS 上性能更优 ——CPU 指令通过硬件虚拟化直接执行，GPU 支持通过 Apple 的准虚拟化层实现（当前限于 GPU Family 5）。Lume 支持从 IPSW（系统固件文件）自动构建 macOS 虚拟机，自动化程度极高。值得注意的是，Lume 依赖 Apple Silicon 的硬件特性，Intel Mac 用户无法使用此方案。官方还提供云端 macOS 沙箱的试点服务，面向需要远程 macOS 环境的团队。
Windows 用户则可利用 Windows Sandbox——Windows 10 Pro/Enterprise 或 Windows 11 内置的轻量级虚拟机技术。需预先启用该功能，并通过 pywinsandbox Python 包实现自动化集成。
后台控制层：Cua Driver 与无障碍访问
在 macOS 平台上，Cua Driver 是实现后台桌面控制的核心组件。与传统辅助功能（Accessibility API）依赖 AX 树不同，Cua Driver 通过 VNC 协议结合 OCR 技术实现「所见即所控」—— 即便应用未暴露辅助功能接口（如 Figma 的 Canvas 渲染、DAW 软件、自定义游戏引擎），Agent 仍可通过截图理解界面状态、模拟鼠标点击完成交互。这种设计绕过了 macOS 对非 AX 应用的访问限制，是 CUA 能够「控制任何原生 macOS 应用」的关键所在。
Cua Driver 还提供会话录制功能，每一轮交互自动保存为可回放轨迹（Trajectory），便于复现 Agent 行为、分析错误决策、或收集高质量训练数据。结合 MCP（Model Context Protocol）服务器实现，Claude Code、Cursor 等主流 Agent 工具可直接接入 Cua Driver，在不占用用户前台焦点的前提下完成后台任务。
统一 SDK：跨平台 API 抽象
CUA 的 Python SDK（pip install cua，要求 Python 3.11+）是开发者实际交互的接口层。它将底层差异封装为一致的异步 API，核心操作涵盖以下几个维度：
屏幕交互方面，sandbox.screenshot() 返回当前桌面截图；sandbox.mouse.click(x, y)、sandbox.mouse.drag() 等方法模拟指针操作；sandbox.keyboard.type() 与 sandbox.keyboard.hotkey() 分别处理文本输入与组合键。移动设备支持通过 sandbox.mobile.gesture() 实现多点触控手势。文件系统与进程管理则通过 sandbox.shell.run() 执行命令，返回结构化的标准输出与错误信息。
云端沙箱与本地沙箱共享同一 API 契约，差异仅在于创建方式：云端通过 cua.ai 平台管理身份认证与远程实例，本地则通过 QEMU/Docker/Lume 启动本地虚拟机或容器。这种设计使得同一套 Agent 代码可以无缝切换运行环境 —— 本地开发调试完成后，直接部署至云端进行大规模评测。
评测与训练：Cua-Bench 基准体系
CUA 不仅提供运行时基础设施，还内置了基准评测能力。Cua-Bench 是专门用于评估 Computer-Use Agent 能力的框架，支持 OSWorld（跨操作系统任务评测）、ScreenSpot（桌面 UI 定位能力评测）、Windows Arena（Windows 环境综合评测）等主流数据集，并允许用户导入自定义评测任务。
基准测试的输出不仅包含最终评分，还包括完整的执行轨迹（Trajectory Export）。这些轨迹数据可以直接用于强化学习（RL）训练 —— 记录 Agent 在每一步的状态观察、采取的动作、以及获得的奖励反馈，形成可用于微调模型的经验回放缓冲区。对于研究 Agent 能力演进而非仅做能力评测的团队，这一特性大幅降低了数据收集与预处理的成本。
关键设计决策与工程权衡
在理解 CUA 整体架构后，几个关键设计决策值得深入探讨，它们直接影响实际使用中的能力边界与注意事项。
非 AX 控制的代价：视觉识别 vs 结构化语义
Cua Driver 采用 VNC+OCR 路径控制非 AX 应用，意味着 Agent 的「理解」基于视觉特征而非应用内部状态。这一选择的优势是覆盖范围极广 —— 几乎任何可见界面都可被操控；但劣势同样明显：对于需要精确数值输入（如在文本框中输入精确坐标、选择特定颜色值）的场景，OCR 识别的精度限制可能成为瓶颈。实际使用中，Agent 通常需要多次重试才能命中小尺寸按钮或重叠的 UI 元素。官方建议在设计评测任务时考虑任务的视觉可辨识性，避免过度依赖像素级精确操作。
Apple Silicon 独占：性能与生态的取舍
Lume 依赖 Apple Virtualization Framework，而该框架仅在 Apple Silicon 上可用。这导致整个 macOS 虚拟化方案对 Intel Mac 用户关闭 —— 他们只能通过 cua.ai 的云端 macOS 沙箱间接使用。考虑到当前 M 系列芯片在 AI 开发群体中的高普及率，以及苹果硬件的持续迭代，这一限制的短期影响有限。但对于需要本地 macOS 虚拟化的 Intel Mac 遗留用户，CUA 团队建议转向 QEMU 方案（性能较低）或等待社区贡献的替代实现。
Golden Image 的维护成本
QEMU 后端的 Windows 和 Linux 评测依赖预先生成的 Golden Image—— 包含完整操作系统、桌面环境、预装依赖项的基线虚拟机快照。首次创建需下载 ISO 并执行完整的无人值守安装流程（Windows 约 6GB ISO + 安装时间，Linux 约 2GB ISO）。一旦基础镜像创建完成，后续启动非常快速；但当需要更新操作系统版本、添加预装软件、或修补安全漏洞时，需要重新执行整个 Golden Image 流程。建议团队建立镜像版本管理机制，为不同评测场景维护对应的镜像版本标签，避免在评测过程中因环境不一致引入变量。
快速上手：从零构建桌面 Agent 评测流程
以下参数配置与步骤清单可作为工程落地的起点。
环境准备阶段需根据目标平台选择对应方案：Linux 容器评测仅需 Docker Desktop；跨平台评测需 QEMU 环境并启用 KVM 加速（--device=/dev/kvm）；macOS 评测需 Apple Silicon Mac 并安装 Lume CLI。安装脚本统一收敛至官方安装入口：Linux/macOS 执行 curl -LsSf https://cua.ai/cli/install.sh | sh，Windows 执行 powershell -ExecutionPolicy ByPass -c "irm https://cua.ai/cli/install.ps1 | iex"。
本地沙箱创建示例采用 Python SDK 方式，以 Linux Docker 为例：
from cua import Sandbox, Image
async with Sandbox.ephemeral(Image.linux()) as sb:
result = await sb.shell.run("echo hello")
screenshot = await sb.screenshot()
await sb.mouse.click(100, 200)
await sb.keyboard.type("Hello from Cua!")
云端沙箱则需先在 cua.ai 注册并获取 API Key，然后通过 CLI 创建实例：cua auth login 完成认证，cua sb create --os linux --size small --region north-america 创建云端沙箱。
评测任务执行使用 Cua-Bench CLI。安装后，通过 cb image create linux-docker 创建评测用基础镜像，cb run dataset datasets/cua-bench-basic --agent cua-agent --max-parallel 4 启动并行评测，--max-parallel 4 控制同时运行 4 个评测实例以平衡速度与资源消耗。评测完成后轨迹数据导出至指定目录，可直接喂入 RL 训练流程。
应用场景与局限性
CUA 的典型使用场景涵盖三类需求。训练数据收集方面，通过大规模运行 Agent 任务并录制轨迹，构建计算机操控能力的行为数据集，用于微调或 RL 训练。能力基准测试方面，在标准化的隔离环境中评估不同模型或 Agent 架构的桌面操控能力横比结果。CI/CD 集成方面，利用沙箱的确定性环境执行 GUI 应用的自动化测试，替代传统的截图对比方案。
然而，CUA 并非万能解决方案。以下场景需谨慎评估：实时性要求极高的操控任务（如 FPS 游戏）受限于 VNC 延迟与帧率；需要访问系统级权限的操作（如内核模块、硬件直通）在沙箱中被隔离；依赖特定硬件外设（如手写板、专业色彩校准器）的应用无法在虚拟化环境中完整还原。理解这些边界有助于在实际项目中做出合理的技术选型决策。
资料来源：CUA GitHub 仓库（https://github.com/trycua/cua）及其官方文档（https://cua.ai/docs）。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。