「让 AI 操作电脑」这几年被讲得很热闹，但真正做过的人都知道，难点很少在「点按钮」这个动作上。真正的难点是你从哪弄到一台干净、可隔离、用完能回收的电脑，以及你敢不敢让它自己按下确认键。
Cua 这个开源项目把这件事拆成了五个组件，而且每个组件的边界划得挺清楚。它的自我定位很直白：Give AI agents computers they can use.
一、五件套分别解决什么
先把全貌摆出来，再看细节：
| 组件 | 层次 | 解决什么问题 |
|---|---|---|
| Cua Fleets | 云端 | 按需分配隔离的云桌面，维护沙箱池与生命周期 |
| Cua Driver | 本机 | 通过 CLI、MCP 或类型化 SDK 操作原生桌面应用 |
| CUA-S1 | 模型 | 用小而专的模型做表单类的高频决策 |
| Lume | 本机 | 在本地创建和管理 macOS 虚拟机 |
| Cua Bench | 评测 | 提供可复现的模拟任务与结果校验 |
官方把它们串成一个概念叫 Computer-Use 2.0：同一个任务里，Agent 可以在代码、API 和图形界面之间来回切换，而不是被锁死在某一种交互方式上。这个提法很实在——生产环境里最省事的路径往往是「能用接口就别点界面」，但总有一部分系统没有任何接口，只能点。
二、Fleets：把「一台机器」变成可申请的池子
Fleets 在云端提供隔离的 Linux 桌面。用法是池化思路：一个 Fleet 维护沙箱容量，你的代码从池子里认领一个桌面，然后用 Sandbox SDK 在里面跑命令、截屏、操作应用。
# 文档给的路径是三步：认领桌面 → 跑一条命令 → 截屏保存
uname -a这套设计的核心价值是隔离。让 Agent 执行模型生成的代码，最怕的就是它在你的开发机上乱来。一个用完即弃的云桌面把所有副作用框在盒子里，这比任何「提示词里要求它别删文件」都有效。
⚠️ 沙箱池会在认领结束后继续保留付费容量
这是文档里明确提示的一条。演示任务跑完必须按清理步骤释放资源，否则账单会持续累积。做技术验证时最容易踩这个坑。
还有两个实际约束：本地沙箱和云 Fleets 共用同一套 Sandbox SDK，但凭证、镜像、可执行操作和运行时要求都不同；桌面运行时支持范围也有差异，选环境前要核对支持矩阵，不然会出现「本地能跑、云端跑不动」。
三、Driver：让 Agent 操作原生应用，但不抢你的鼠标
Driver 给 Agent 的是一组操作原生桌面应用与浏览器的能力，覆盖 macOS、Windows、Linux，接入方式有三种：命令行、MCP、类型化 SDK。
安装是一行脚本：
# macOS / Linux
/bin/bash -c "$(curl -fsSL https://cua.ai/driver/install.sh)"
# Windows PowerShell
irm https://cua.ai/driver/install.ps1 | iex三种接入方式意味着它能嵌进不同的 Agent 生态：已经在用 MCP 的可以直接接，需要精细控制流的用类型化 SDK，只想快速试的走命令行。
但最值得注意的一个特性是后台投递：在应用和平台支持的情况下，Agent 可以在不移动你的指针、不抢走焦点的前提下完成任务。这一条听起来像体验优化，实际是可用性门槛——如果每次 Agent 干活都要抢占鼠标，这台机器就没法同时给人用了。官方给的支持范围说明值得细读，因为它是按平台和窗口类型分级的。
官方演示里有一个细节很能说明能力边界：两个 Driver 会话在欧姆archy 桌面上分别操作 LibreOffice Calc 的单元格和 Inkscape 的图形对象，同时终端始终保持在前台。三个应用各干各的，说明它不是简单的前台模拟点击。
四、CUA-S1：把决策从「生成」改成「打分」
CUA-S1 是五件套里最容易被误解的一个：它名字里有 S1，指的是 System 1，官方明确说明这是工程类比——用来描述「快而受限的决策，比如判断某个字段该填哪个值、或者某个元素该不该动」，不是对模型架构的严格分类，也不替代通用 Agent 的规划推理能力。
它的第一个研究方向是表单。做法和常规 Agent 很不一样：
- 不从结构化界面元素和文档值里逐 token 生成响应，而是对候选决策打分；
- 动作的先后顺序由应用代码决定，模型只负责局部判断；
- 可选的 Driver 集成负责执行，并且有显式的动作边界。
这个分工很有启发：把「顺序」这种确定性的东西交给代码，把「选择」这种模糊的东西交给模型。相比让一个大模型端到端输出整个动作序列，这种拆法在表单这类高频、边界清晰的任务上更容易控制。
但必须看清它的成熟度。 官方说得很直接：项目处于早期研究阶段，仓库提供的是模型代码、合成数据生成、训练与评测代码，不包含也不下载权重、数据集、演示程序和录屏，源码发布本身不构成任何检查点性能声明。已有检查点 cua-s1-form-v0 是面向表单类界面任务的专用版本，不应被视为通用助手。
安装与使用：
uv sync --project libs/cua-s1/python --extra pdf --group test
uv run --project libs/cua-s1/python pytest libs/cua-s1/python/testsimport cua_s1
print(cua_s1.__version__)加载检查点需要本地提供 safetensors 文件和匹配的 JSON 配置——基于 pickle 的 PyTorch 检查点会被拒绝，这是一个明确的安全取舍。
五、安全边界：这套设计比功能列表更值得抄
CUA-S1 的安全声明写得比多数同类项目都狠，逐条看下来几乎是一份桌面 Agent 的准入清单：
- 规划与执行分离，运行默认走干跑；
- 要求恰好一个明确的目标窗口，避免操作到错误的窗口；
- 使用快照绑定的元素标识，防止两次观察之间元素已经变化；
- 每次变更后重新观察窗口，不复用过期状态；
- 执行与提交是两个独立开关，必须分别显式打开；
- PDF 访问被限制在配置的允许根目录内，未配置时默认使用当前工作目录，生产环境应改用专用的最小权限目录。
最值得关注的是提交动作的收窄：开启提交后，最多允许点击一个高置信度的、标准标签恰好为提交的按钮，其余点击决策一律省略。
💡 这个保守度是对的设计
无人值守场景下最危险的失败不是「没点到」，而是「点错了但没人发现」。把不可逆操作收窄到最少、要求先看干跑计划，本质上是把最坏情况的可控性放在覆盖率之前。等观察到决策稳定之后再逐个场景放开，这个顺序值得所有桌面 Agent 借鉴。
MCP 服务 cua-s1-mcp 走标准输入输出传输，需要两个宿主配置：一个用「模块:属性」形式指定可信的规划器工厂，一个列出可以读取的 PDF 目录。文档特别提醒：导入工厂会以服务进程的权限执行代码，所以绝不能指向不可信模块。这个提醒很必要——MCP 把「加载一段配置」变成了「加载并执行一段代码」，权限边界必须自己想清楚。
六、Lume 与 Cua Bench：补齐两端
Lume 负责本地 macOS 虚拟机，官方教程是以创建一台 Tahoe 虚拟机并通过 SSH 连接为例。它的意义在于给需要 macOS 环境的任务（比如 iOS 相关、Safari 相关）一个可编排的本地运行环境，而不必依赖云端。
Cua Bench 负责评测。它提供创建与校验模拟任务的流程，配合 Driver 就能形成「造任务—跑轨迹—校验结果」的闭环。对计算机使用类 Agent 来说，评测的难点恰恰在于结果验证：不是看它点了什么，而是看最终状态对不对。这一点如果做不扎实，所有性能数字都没意义。
七、评：什么场景值得用
- 值得：需要无人值守操作桌面应用；需要在评测环境里批量起隔离桌面；需要把已有 Agent（Claude Code、Codex、Cursor 等）接上原生应用操作能力；需要一个能自我约束的安全边界模板。
- 可以等：想直接拿到一个可用的专用计算机使用模型——目前是研究脚手架，权重未发布。
- 注意成本：云沙箱池的容量计费、本地与云端运行时的能力差异、生产环境必须使用专用最小权限目录。
- 组合建议：网页内操作交给浏览器层工具，桌面与系统级操作交给 Cua，两层通过工作目录交换产物。这样每层都用自己的强项，整体最稳。
把「给 Agent 一台电脑」拆成五件可独立选用的组件，本身就是很成熟的工程判断——多数团队一开始并不会全用，但知道每一块的边界在哪，选型时就不会押错方向。