Cua：给 AI agent 一台能用的电脑，把 Computer Use 变成可评测的工程

原文来源：GitHub - trycua/cua — Cua 把 Computer Use 拆成开源驱动、跨系统云桌面、本地 macOS 虚拟机和界面决策小模型几块，每一块都能单独装、单独测。

让 AI agent 操作电脑，是这个赛道里最容易被讲成一件事、实际上最碎的活。它至少包含四件不同的事：给 agent 一台机器、让 agent 真的能点得到界面、判断下一步该点什么，以及知道它到底做对没有。大部分项目只做其中一件，然后让使用者自己去补剩下的。

Cua 这个开源项目（MIT 许可）的想法是把这几块都做出来，并且每一块都能独立使用。它的自我定位是提供「开源桌面自动化、隔离的云桌面、本地 macOS 虚拟机、专用决策模型，以及评估 computer-use agent 的基准」。

先说清楚它想解决的问题。项目的定义里有个词叫 Computer-Use 2.0：agent 在同一个任务里，会在代码、API 和图形界面之间来回切换。也就是说，它不该只有一种操作通道——能用命令行就用命令行，能用 API 就用 API，实在不行才去点界面。这个定位决定了它的工具形态：不是做一个「帮我点浏览器」的插件，而是给 agent 铺一整套环境。

Cua Fleets：按需领一台云桌面

Fleets 是跑在云上的隔离桌面集群。它维护一个沙箱容量池，你的代码从池子里领一台桌面，然后用 Sandbox SDK 在里面跑命令、截图、操作应用。

上手路径被设计得很短：开一台 Linux 桌面，跑一句 uname -a，存一张截图，然后删除云端资源。文档专门提醒了一件事——池子在一次申领结束之后可能继续保留付费容量，所以清理步骤要照着走完，别只跑到一半。

本地沙箱和 Fleets 共用同一套 Sandbox SDK，但凭证、镜像、可用操作和运行环境要求都不一样。自己有机器的，可以走本地沙箱生命周期管理那条路。

Cua Driver：在后台操作原生应用

Driver 是给 agent 用的操作层。它让 agent 检查并操作 macOS、Windows、Linux 上的原生桌面应用和浏览器，接入方式有 CLI、MCP 和带类型的 SDK 三种。装的时候一条命令：macOS 和 Linux 走 curl 拉安装脚本，Windows 用 PowerShell。

真正值得说的是它能在后台干活。开启之后，agent 可以在不移动你的指针、不抢焦点的前提下操作应用，前提是应用和平台支持——项目给了一份平台支持边界表。对一个要长时间自己干活的 agent 来说，这一点比看上去重要得多：你还能用同一台电脑做别的事。

驱动是分平台写的，每一层都单独写过技术细节：

Linux 上，它用 D-Bus 之上的 AT-SPI 2 拿无障碍树，用 XTEST 合成输入，并且维护一个单独的「agent 光标」，跟你的物理指针分开跑，X11 和 XWayland 都支持。

Windows 上，一个驱动要吃下 Win32、WPF、WinUI、UWP、Electron 和一堆遗留控件，交给模型的是窗口像素、无障碍树和一层动作抽象。

macOS 上，它靠 SkyLight 的窗口内部机制实现多光标的后台操作，同样不碰你的指针。

已经用 Claude Code、Codex、Cursor 这类工具的，项目提供现成的集成方式，源码文档和架构笔记放在仓库的 libs/cua-driver/README.md。

CUA-S1：专管「这一格该填什么」的小模型

这一块是 Cua 里最有意思的设计。CUA-S1 是一批小而专的「System 1」模型，负责 computer use 里那些快速、有边界的判断，比如某个字段该填哪个值、某个界面元素这时要不要动它。

项目对「System 1」的解释很克制：这只是一个工程上的类比，指的是快速、有边界的判断，不是对模型架构的严格分类，也不能替代通用 agent 的规划和推理。这个提醒挺必要——现在讲 agent 架构的文章很容易把 System 1/System 2 当成一套现成的理论往项目上套。

第一个研究 profile 盯的是表单场景。它的做法不是逐 token 生成回答，而是直接从结构化的界面元素和文档值里给候选决策打分。动作的先后顺序由应用代码决定，可选的 Driver 集成负责实际执行，并且明确了动作边界。

仓库里放的是 Python 模型代码、合成数据生成、训练和评估流程；这是个早期的、只有源码的研究发布，模型权重单独放在 Hugging Face。源码是 MIT 许可，但每个模型和数据集卡片都有自己的适用范围和限制，用之前得单独看。

Lume 和 Cua Bench：环境与尺子

Lume 负责在 Apple Silicon 上创建和管理本地 macOS、Linux 虚拟机，用的是苹果自己的 Virtualization.Framework。一条命令装好之后，可以从苹果的恢复镜像起一台干净的 macOS Tahoe 虚拟机，然后用 SSH 连进去，教程里也交代了无人值守安装的默认行为。

Cua Bench 是那把尺子：搭 computer-use 任务、评测 agent、导出轨迹拿去训练。它的第一步设计得不错——先给一个不需要虚拟机、不需要 Docker、不需要模型 API key 的模拟任务。装上 cua-bench[browser] 再让 playwright 装个 chromium，就能建一个小任务、跑一遍参考答案，确认评估器返回的 reward 是 1.0，然后自己上手试同一个任务。

Bench 里的真实题目长什么样，从项目博客能看出一部分：在 KiCad 这套电子设计自动化软件的专家级任务集里，最强的前沿 agent 25 道题只做出 6 道。另一个例子是 Gemini 3.5 Flash，在有原生 Computer Use 工具的前提下跑 Cua-Bench 的 KiCad 套件，拿到了所有受测前沿模型里最高的平均 reward——0.267。

这两个数字比任何 demo 视频都更能说明问题：界面操作的模型能力，离「能替你干活」还差得远。

这套拆法为什么值得留意

把 computer use 拆成环境、交互、决策、评测四块，好处是每一块都能被单独替换。你可以只用 Driver 接自己的 agent，也可以只用 Lume 起虚拟机，或者只用 Cua Bench 给自己的方案打分。这对独立开发者比大公司更重要——没有团队规模去堆，就得靠能拼装的零件。

它的短板也摆在那：早期项目，一部分能力（云沙箱、Fleets）是要花钱的托管服务，云端的凭证和运行时跟本地不完全一样；CUA-S1 还是研究性质，权重和适用范围要自己核。

如果你的目标是让 agent 真的去动某台机器上的软件，而不是在浏览器里点来点去，这个项目的分层方式值得照着抄一遍。至少它承认了一件事：Computer Use 不是一次模型调用，而是一条要有人负责收尾的工程链。