企业官网建设流程全解析

Cua 上手指南：让 AI Agent 替你操作电脑

【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua

Cua 是一个开源的计算机使用（Computer-Use，即让 AI 通过看屏幕、点鼠标、敲键盘来完成工作）自动化平台，采用 MIT 协议。它面向两类人：想给 Agent 装上"操作真实机器"能力、又不敢直接放行的开发者，以及需要评测和训练这类模型的团队。最打动人的设计是：它把图形界面当作 Agent 可调用的工具面之一，和写代码、跑 Shell、调 API 并列，同一任务里哪个面最省事就用哪个。仓库里包含 Driver、Sandbox、Cua-Bench、Lume 四个可独立使用的组件。

⏱️ 10 分钟跑起来：安装沙箱 SDK 并第一次运行

最短路径走 Python 沙箱 SDK，全程不需要配置任何密钥，也不需要准备虚拟机。安装后创建一台临时 Linux 沙箱，让它在里面跑一条命令，跑完即销毁：

# 安装 SDK（需 Python 3.11+），然后第一次运行：临时 Linux 沙箱里执行命令 pip install cuda

抱歉，上面命令写错了，正确内容如下：

# 安装 SDK（需 Python 3.11+），然后第一次运行：临时 Linux 沙箱里执行命令 pip install cua python -c " import asyncio from cua import Sandbox, Image async def m(): async with Sandbox.ephemeral(Image.linux()) as sb: print(await sb.shell.run('echo hello')) asyncio.run(m()) "

看到hello输出就说明跑通了。同一个环境对象上还挂着sb.screenshot()、sb.mouse.click(x, y)、sb.keyboard.type(text)，可以直接截屏、点击和打字，Image.linux()换成.macos()、.windows()、.android()就能换系统。

如果你要驱动的不是沙箱而是"自己这台电脑"，装 Cua Driver 即可：macOS / Linux 用一行 bash 安装脚本，Windows 用一行 PowerShell 脚本，官方教程里有按平台的完整步骤（macOS 需要额外开启辅助功能与屏幕录制权限）。完整入口看 Cua 文档目录，从入门教程 第一次驱动一个应用 开始最合适。

它是怎么工作的：走一遍"打开计算器算 6×7"

官方教程的第一个任务很适合理解原理：让 Agent 打开计算器，算出 6×7，并回答 42。整个过程是一个不断重复的循环：

1. 看：驱动程序截一张屏幕截图，必要时结合操作系统的可访问性树（辅助功能信息，结构化描述界面上有哪些控件）一起交给模型。
2. 想：模型看到画面后给出下一步动作，比如"点击数字 6 的坐标"。
3. 做：驱动程序在后台投递这个输入。注意是后台——你的鼠标不动，当前窗口不被抢焦点，人完全可以同时干别的事。
4. 验：再截一张图，看结果有没有变化。没算对就回到第 1 步继续纠正。

这个循环由三个角色分担：模型（在你选的任意 Agent 里）、Agent 运行框架（Claude Code、Codex 这类编码 Agent 都算）、Cua Driver（UI 层，通过 MCP——一种 Agent 调用外部工具的标准协议，或直接当命令行工具接入）。如果"计算机"不是你的电脑，而是一次性桌面，那台电脑就是 Cua Sandbox，循环逻辑完全一样。

Cua 整体架构图：Sandbox 提供跨操作系统环境，Driver 负责 UI 输入，Agent 负责决策

用伪代码概括这个循环（简化版）：

# "打开计算器算 6×7"的循环 while "42" not in screen_text: obs = computer.screenshot() # 看：截图 act = model.decide(obs, goal) # 想：模型给出下一步动作 driver.perform_background(act) # 做：后台输入，不抢焦点 # 模型确认答案出现在屏幕上后退出循环，汇报 42

能用来干什么：三个真实场景

驱动只有图形界面的老应用。有些老 Windows 桌面程序连 API 都不提供，界面就是唯一的操作入口。官方演示里，Agent 通过 Driver 在后台填完一张发货单并打印回执。结果是：任务完成了，而你自己的窗口和鼠标全程没被打扰。

给 Agent 一台一次性的隔离桌面。装软件、跑来路不明的脚本这类操作放在自己机器上总归悬。用Sandbox.ephemeral()起一台干净的 Linux / macOS / Windows / Android 环境，Agent 在里面既能写代码又能点界面，同一套 API。跑完销毁，需要复现时再建一台一模一样的。

给模型"考科目二"。你很难凭感觉判断一个模型到底会不会操作电脑。Cua-Bench 把 OSWorld、ScreenSpot、Windows Arena 这类可验证任务打包成基准，支持并行跑分并自动打分，还能把整段操作轨迹导出去做强化学习训练数据。

和同类方案比：什么时候该选 Cua

先说结论：API 够用就用 API，重复性网页流程用浏览器自动化就够了；Cua 的价值出现在任务跨应用、依赖视觉状态、或者目标软件根本没有可用接口的时候。

差异点有两处：一是"2.0"的含义——GUI 只是工具面之一，同一任务里代码、工具调用和点界面可以互相切换；二是任何有破坏性的动作都能放进沙箱里做，坏了也不心疼。

边界与下一步

局限，坦白讲有三个。第一，UI 面依赖模型的视觉理解和坐标定位，界面变了或点偏了，Agent 会走弯路，所以任务里要留验证步骤，官方文档自己也将"观察、恢复、权限、验证"列为设计重点。第二，驱动真机需要系统级授权：macOS 要手动开启辅助功能和屏幕录制两项权限，Linux 的 Wayland 上后台原始输入有明确的能力限制（X11 路线更完整）。第三，本地跑 macOS 沙箱依赖 Lume，而 Lume 基于 Apple Virtualization Framework，只跑在 Apple Silicon 上；要全平台覆盖得用云端环境。

演进方向看路线图就很清楚。云端 Fleet 桌面池已经可用；BYOI（自带.qcow2、.iso自定义镜像）在支持矩阵里标着"即将支持"；Cua-Bench 的基准注册表和轨迹导出会持续往训练数据管线上加料。

想深入的话，从文档入口开始，Driver 的架构笔记在 libs/cua-driver/README.md，想参与贡献看 CONTRIBUTING.md。

【免费下载链接】cuaScale computer-use 2.0 with open-source drivers, cross-OS fleets, and benchmarks for training, evaluation, and data generation.项目地址: https://gitcode.com/GitHub_Trending/cua/cua