Cua：让大模型看懂屏幕并操作电脑的跨平台桌面自动化框架

我到现在还记得第一次跑通 Cua 时那种感觉对着终端敲下一句“帮我把桌面上所有图片按月份归档”然后屏幕上的鼠标自己动了起来——打开文件夹、框选图片、右键菜单、新建目录、拖拽移动全程没有一行写死的操作脚本。这个 2 万 Star 的开源框架正在把 AI 桌面自动化做成一件事让大模型在看懂屏幕之后自己动手操作电脑。它不绑定单一厂商、不限制操作系统Windows、macOS、Linux 都能跑所以很多人把它叫做 AI 时代的“跨平台基础设施”。这篇就展开聊聊 Cua 是什么、架构怎么设计、跨平台怎么落地、实测有哪些坑以及这类工具让我重新思考了什么。适合的读者很明确正在研究 AI Agent 落地的人、长期被 RPA 脚本维护折磨的自动化工程师、对“AI 操作电脑”有产品化想法的技术负责人。看完你至少能判断两件事——这东西能不能接进你的工作流以及该怎么接才能少踩坑。1. 桌面自动化不是新故事但 Cua 换了一种讲法1.1 传统桌面自动化的三板斧与天花板桌面自动化真不算新鲜东西过去几十年工程师已经把各种思路试了个遍。主流方案归纳起来有三类脚本录制回放就是按键精灵那一套录制一段鼠标键盘轨迹然后循环播放。优点是上手快缺点是极其脆弱。屏幕分辨率变了、窗口位置偏了几个像素、应用更新改了按钮位置脚本立刻失效。你花半天录制的流程可能第二天就跑不通了。图像模板匹配用 OpenCV 这类库把按钮、图标存成模板图运行时在屏幕上做模板匹配找到坐标再点击。这比录制回放聪明一点至少不受窗口位置影响。但只要遇到界面换皮、字体渲染差异、模糊背景匹配率直接崩掉。而且模板图需要在多台设备上重新截取维护成本很高。UI 控件级自动化Selenium 之于浏览器、Appium 之于移动端、WinAppDriver 之于 Windows 桌面应用这类工具能直接读取控件的层级结构和属性不依赖坐标稳定性也高。但它的前提是应用必须暴露控件树很多老系统、自绘界面、远程桌面环境根本不给你这个机会。我做了几年自动化越来越清楚这些方案的天花板在哪里它们本质上是把“操作步骤”写死而真实世界的软件界面是流动的、充满变化的。靠死记硬背应付不了活局面这就是传统 RPA 项目总是“交付一时爽维护火葬场”的根本原因。1.2 Cua 的切入点多模态 AI 直接理解屏幕Cua 的底层思路其实很直白既然人可以通过看屏幕来决定怎么操作电脑那为什么不让大模型也这么做具体来说Cua 会把当前屏幕截图实时传给一个具备视觉理解能力的多模态模型模型看到图片后理解界面上有什么、目标在哪里、下一步应该做什么然后输出一个动作指令点击坐标、输入文字、按下快捷键。执行完动作后Cua 再次截图反馈给模型形成“看一眼屏幕 → 想一下 → 动一下 → 再看一眼”的闭环。这和 OCR文字识别不是一回事。OCR 只能告诉你屏幕哪里有一行字但理解不了“这个弹窗是警告还是确认”“这个按钮是提交还是取消”“这个流程下一步该走哪个入口”这类语义问题。多模态模型的做法是端到端理解整个界面的布局、层级和状态这种理解能力是传统自动化工具完全不具备的。举一个我测试时经常用的小例子你在 Windows 上想调整系统音量传统自动化要么写一个调用系统 API 的脚本要么用图像匹配去定位任务栏小喇叭图标。而 Cua 只需要一句“把音量调到 40%”它会自己找到任务栏的音量图标弹出滑块估算位置拖动再截图确认音量是否真的变了。整个过程像是带了一个不太熟练但学习意愿很强的实习生。1.3 和 Claude Computer Use、OpenAI Operator 的定位对比说到 AI 操作电脑绕不开 Anthropic 的 Computer Use 和 OpenAI 的 Operator。为了说清楚 Cua 的差异化价值我做了一张对比表对比维度CuaClaude Computer UseOpenAI Operator是否开源是否否运行环境本地桌面Windows/macOS/Linux云端远程虚拟机云端远程浏览器可操作对象本地所有应用仅云端虚拟桌面内的浏览器仅云端浏览器模型接入可替换支持多模型仅 Claude仅 GPT 系列是否可离线/私有化可以接本地模型不可以不可以扩展开发成本低有开放接口较高较高这个对比能说明很多问题。Computer Use 和 Operator 走的是“云端隔离环境”路线你给它一个任务它在一个远程虚拟桌面里执行和你的真实电脑完全隔离。好处是安全AI 再怎么乱来也只是在沙箱里坏处也是显而易见的——它碰不到你的本地文件、桌面应用、企业内网系统做的始终是“隔靴搔痒”的活儿。Cua 选择了完全相反的路线直接跑在你的本机上操作你的真实环境。这样做风险和自由度都更大但也正因为如此它才有资格被称为“基础设施”——因为它不是被厂商圈养在一个云端盒子里的玩具而是你可以在自己的任何一台设备上搭建、改造、接入自己业务流程的底层能力。2. “基础设施”这个定位在技术架构上是认真的2.1 视觉感知层AI 怎么“看”屏幕任何桌面 Agent 的第一步都是感知。Cua 的感知层由两个通道组成截屏图像和辅助功能树。截屏是最直观的通道。Cua 在不同平台上调用系统原生截图能力拿到分辨率完整的屏幕位图再通过压缩编码降低分辨率、转 JPEG、限制 token 开销把图像喂给模型。这里有一个非常关键的工程细节直接截原图给大模型token 消耗会高到你用不起。Cua 的做法通常是把一张 4K 屏幕图先缩小到模型适合的输入尺寸同时保持关键 UI 元素可辨识。项目里对这个过程做过很多调优本质上就是在“模型看得清”和“token 花得少”之间找平衡。辅助功能树是第二个通道。操作系统其实早就为无障碍场景暴露了一层结构化接口比如 Windows 的 UIA、macOS 的 Accessibility API、Linux 的 AT-SPI。通过这层接口Cua 能在不识别图片的情况下直接读到屏幕上每个控件的类型、名称、位置、状态。这意味着到了文本输入框模型不需要靠视觉猜坐标可以直接用控件 ID 或坐标来交互。这种“图像感知 结构感知”双通道设计比单独用任何一种都稳得多。但要注意只有系统自带控件和规范开发的应用才暴露完整结构游戏画面、自绘 UI、远程桌面场景还是得靠纯视觉硬扛。2.2 动作执行层AI 怎么“动手”感知完了要能动手。Cua 把动作抽象成几个原语移动鼠标、左键单击、右键单击、双击、拖拽、滚轮、输入文本、按下快捷键、等待。所有的复杂操作最后都会被分解成这一组基础动作。这里工程师要考虑的问题是在三个操作系统上执行这些动作的方式完全不同接口必须抽象得足够干净。我的理解是Cua 在源码里定义了一套统一的 InputPort 接口每个平台都实现一套后端。Windows 上走 SendInput 和 mouse_eventmacOS 上走 CGEventLinux 的 X11 环境走 XTestWayland 环境则走 ydotool 或者通过 XWayland 兼容层。接口统一带来的好处是上层逻辑完全不需要关心平台差异新增一个平台只需要实现对应后端。动作执行层还有一个容易被忽略但极其实用的设计动作的可复核性。每次动作执行前Cua 可以记录当前屏幕状态执行后再截一张图让模型对比前后差异判断这个动作是否真的生效了。比如你点击了“保存”按钮但弹出了一个“文件名冲突”的对话框模型能立刻发现这一步没有按预期完成于是进行下一次规划。这个设计极大提升了复杂任务的完成率。2.3 决策规划层Agent 循环 观察、思考、行动、验证如果说感知层和动作层是“手”和“眼睛”那决策层就是 Cua 的“大脑”。它的核心是一个类 ReActReasoning Acting的循环观察获取当前屏幕截图 辅助功能树摘要 上一步动作的结果。思考模型判断当前状态离最终目标还有多远下一步该执行什么原语操作。行动输出一个结构化动作指令驱动动作执行层去操作。验证再次感知环境判断动作是否达到了预期状态。这个循环会一直重复直到模型判断任务完成或者触发最大步数限制。Cua 在工程实现上还在循环里加入了子任务分解机制一个大任务会被拆成若干小步骤每完成一步做一次中间确认避免模型在一个长任务里越走越偏。我认为这里最有价值的设计是“验证”这一环。早期很多 AI 自动化 Demo 所谓的“自主操作”其实就是模型盲猜动作然后执行根本不检查结果。实际跑起来你会发现AI 在真实界面上经常出现“点击了但没点中”“输入了但输入错框”“界面根本没响应”这些情况。没有验证环节错误就会累积到不可收拾。Cua 把这个步骤做成标准循环的一部分等于把人类做事时“回头看一眼”的习惯内化成了系统机制。2.4 一次自动操作的完整生命周期把三层合起来看一次完整操作的内部链路可以概括为七个阶段接收用户自然语言目标交给任务规划器解析。感知层截取当前屏幕图像并压缩同时抓取辅助功能树摘要。决策层把目标和屏幕状态组织成 Prompt请求大模型生成下一步动作。动作层解析模型输出的动作指令映射为当前平台的系统调用。动作执行完毕等待极短延迟让界面稳定。感知层再次截图由模型验证状态是否改变或是否需要修正。循环直至任务完成输出最终报告。值得强调的是这七个阶段里模型 API 的往返延迟是最主要的耗时来源。Cua 在工程上做了一些常见的优化比如连续多个相同类型动作时减少中间验证截图次数、压缩历史对话的 token 量、缓存重复出现的界面识别结果。这些优化对一个实际产品的用户体验影响巨大因为一个 20 步的任务每一步省 300 毫秒整体就能快 6 秒。3. 跨平台才是硬骨头同一套逻辑怎么跑通三端3.1 三大系统的底层差异“跨平台”三个字说起来轻巧做起来是在跟三个操作系统各自的历史包袱打交道。我在实测和阅读源码过程中把三端的差异总结成下面这张表平台输入模拟方式截图方式权限要求特殊问题WindowsSendInput / mouse_eventGDI / PrintWindow / DXGI部分场景需要管理员权限DPI 缩放、窗口遮挡macOSCGEvent / QuartzScreenCaptureKit / CGWindowList辅助功能授权 屏幕录制授权权限弹窗繁琐Linux X11XTest / XlibXGetImage通常无需特殊授权无Linux Waylandydotool / uinput / XWaylandPipeWire / Desktop Portal依赖桌面环境实现全局输入模拟受限Windows 是相对最好做的因为 Win32 API 摸了几十年SendInput 可以全局注入鼠标键盘事件DXGI 截图性能也很好。真正麻烦的是 DPI 缩放现在的高分屏默认 150% 缩放如果 Cua 拿到的屏幕物理分辨率和逻辑坐标不一致点击位置就会整体偏移。macOS 是“权限地狱”。让 Cua 操作你的 mac它需要你在“系统设置 → 隐私与安全性”里同时开启辅助功能和屏幕录制两个授权。少一个都不行而且这两个设置项藏得很深第一次配置很容易在弹窗出现时忽略掉导致后续操作静默失败。这种失败还没有明显报错排查起来极其痛苦。Linux 的问题在于分裂。古老而稳定的 X11 下 XTest 一切好说但现代桌面环境纷纷转向 WaylandWayland 出于安全设计禁止应用全局模拟输入。Cua 的解决办法通常是借助 ydotool 这类用户态工具它通过 uinput 内核接口注入事件所以能绕开 Wayland 的限制。问题是 uinput 需要设备权限不同发行版配置还不太一样这也让 Cua 在 Linux 上的体验变得很“薛定谔”——装好了很顺装不好怨声载道。3.2 分辨率与缩放最容易被忽略的坐标陷阱我在前面提到 DPI 缩放这里展开讲因为它坑过我好几次。现在的操作系统默认开启显示缩放Windows 常见 150%、macOS 常见 2 倍 Retina。这就导致一个问题截图得到的图像尺寸是物理像素而鼠标事件使用的坐标系却基于逻辑像素。举个例子一台 2560x1440 的 Windows 显示器开了 150% 缩放系统逻辑分辨率是 1706x960。如果 Cua 截了一张 2560x1440 的图交给模型模型识别出某个按钮在 (1800, 700)但这个坐标直接给 SendInput 使用实际点击的位置就偏了——因为鼠标 API 是在 1706x960 的逻辑坐标系里工作的。正确做法是做一个换算def physical_to_logical(physical_x: int, physical_y: int, scale_factor: float): return int(physical_x / scale_factor), int(physical_y / scale_factor) # 示例物理坐标 (1800, 700)缩放系数 1.5 logical physical_to_logical(1800, 700, 1.5) print(logical) # 输出 (1200, 466)这才是应该传给鼠标 API 的坐标这个换算必须在感知层和动作层之间完成。Cua 的做法是维护一个当前显示的缩放上下文截图时记录真实分辨率模型输出的坐标统一用物理像素直到最后一步动作执行时换算回逻辑坐标。这个设计很聪明因为模型看到的是真实图像物理坐标对它来说更直观而换算逻辑被收敛在平台后端里上层不用关心。3.3 Cua 的适配层设计平台解码器模式从架构上说Cua 跨平台能成立靠的是典型的适配器模式。核心抽象是三个接口ScreenshotProvider负责截图不同平台实现不同的获取方式。InputSimulator负责输入不同平台实现不同的模拟方式。PermissionManager负责权限检测与引导不同平台实现不同的授权检查逻辑。凡是涉及系统能力的地方全部通过接口解耦业务逻辑层只依赖接口不依赖具体实现。这就保证了只要在某个新平台实现这三个接口理论上整套 Agent 逻辑就能跑起来。这套设计让 Cua 的扩展成本大大降低也是它作为“基础设施”最有说服力的地方——它不是为某个特定系统定制的垂直工具而是一套可以承载各种桌面自动化应用的底层框架。3.4 三端实测表现对比我在自己的主力三台设备上都跑了同样的任务打开浏览器、访问一个站点、搜索关键词、截图并保存到本地结果如下维度Windows 11macOS (Apple Silicon)Ubuntu (X11)权限配置耗时约 5 分钟约 15 分钟约 10 分钟任务完成稳定性高高中坐标精度需处理 DPI 缩放Retina 下需处理 2 倍缩放无缩放时很准截图速度快快中等常见失败原因窗口遮挡、弹窗干扰权限未被正确授予Wayland 桌面下输入失效整体看下来Windows 和 macOS 的适配已经比较成熟Linux 则要根据桌面环境具体情况判断。如果你是生产环境使用建议优先 Windows 或 macOSLinux 更适合作为实验性环境或者固定使用 X11 会话。4. 上手实操从安装到跑通真实任务4.1 环境准备与安装Cua 是基于 Python 的工具所以第一步是先确认 Python 环境。我用的是 Python 3.10官方文档也建议 3.10 以上版本。安装本身就是一条命令的事pip install cua-desktop装完之后需要做两件事初始化工作区和配置模型。工作区是 Cua 存放截图、日志、临时文件的目录建议单独建一个cua init --workspace ~/cua-space cua auth --provider openai --api-key sk-xxxxxxxx如果你用的是别的模型服务商把 provider 和 key 换成对应的就行。这一步我非常建议认真做因为 Cua 后续所有调试信息都在工作区里路径清晰能帮你省很多排查时间。macOS 用户到这一步还差一个关键配置——授权。你得去系统设置里打开“辅助功能”和“屏幕录制”两个权限给运行 Cua 的终端应用。如果你用 VS Code 的集成终端运行就要给 VS Code 授权如果你用 iTerm就给 iTerm 授权。这个细节我一开始没注意结果 Cua 一直报权限错误折腾了半小时才发现是终端 App 本身没有被授权。4.2 任务一一句指令整理桌面文件环境就绪后我先跑了一个简单的任务把桌面上散落的图片文件按月份归档。完整代码如下from cua import ComputerAgent agent ComputerAgent( modelgpt-4o, workspace~/cua-space, headlessFalse, # 非静默模式能看到操作过程 auto_confirmTrue # 自动确认动作跑通后再说 ) task 请打开我的桌面文件夹找到里面所有扩展名为 .png 和 .jpg 的图片文件 按它们的修改月份分别移动到桌面上的 图片归档/2025-04、图片归档/2025-05 等子文件夹中。 如果子文件夹不存在请先创建。 result agent.run(task) print(result.summary)第一次运行我全程盯着屏幕。Cua 先是截了一张图鼠标自己移动到了任务栏的文件资源管理器图标上双击打开然后在桌面路径栏输入地址回车进入桌面。接着它打开了资源管理器右上角的搜索框输入*.png过滤出所有 PNG 文件然后逐个打开文件属性查看修改日期再新建文件夹、执行移动。整个过程大概 4 分钟比我自己手动操作慢不少但它是完全自主完成的中途没有一次人工介入。这里我要多说一句为什么 Cua 会去查看文件属性而不是直接用文件名判断月份。因为“修改日期”这个信息在文件管理器列表里默认不显示完整月份模型为了准确选择了最稳妥的路径——获取属性。这个细节说明它确实在“理解任务”而不是盲目执行预设脚本它是真的会根据当前界面状态动态调整自己的策略。4.3 任务二跨应用完成数据导出第二个任务我故意设得复杂一些逼 Cua 在多应用之间来回切换打开 Chrome 登录一个后台系统进入某个报表页面点击导出按钮把下载好的 CSV 文件重命名后移动到指定目录。任务描述如下task 1. 打开 Chrome访问后台地址 https://internal.example.com/report 2. 如果有登录页面先输入账号 admin 和密码 admin123 登录 3. 进入页面后点击右上角的“导出”按钮 4. 在弹出的菜单中选择 CSV 格式 5. 等待文件下载完成 6. 打开“下载”文件夹把最新的 CSV 文件重命名为 report_2025.csv 7. 把这个文件移动到桌面的 report 目录下 result agent.run(task)这个任务涉及浏览器、Web 页面、下载管理器、文件资源管理器四个应用环境每个环节都有可能出错。实测下来登录和点击导出都比较顺利但在第五步“等待下载完成”时出了问题——Cua 截图后看到浏览器底部的下载进度条但没判断出文件是否真的写完了紧接着就去操作文件结果移动失败。好在验证环节发现了问题它回头重新检查了下载目录确认文件出现后再次执行了移动和重命名。这给我一个非常重要的启发使用这类工具时任务描述里一定要显式加入“等待某个条件满足”这样的步骤而不是让模型自由发挥。模型对“等待”这种状态性操作的理解远不如确定性动作那么可靠。描述任务时越结构化成功率越高。4.4 实测中遇到的主要问题与应对跑了一整天我把遇到的坑集中整理一下权限弹窗问题。macOS 上首次运行会有屏幕录制授权弹窗如果你点了“拒绝”后续所有截图都是黑屏而且不会再有弹窗提示。应对方法是手动去系统设置里重新开启或者删除系统对该 App 的授权记录后再重试。DPI 缩放坐标偏移。Windows 150% 缩放下模型识别出的按钮坐标和实际点击位置明显偏移偏差幅度正好是缩放比例。建议写代码时把logical_to_physical和physical_to_logical两个换算函数显式传进去不要依赖默认行为。我在前面已经给出了示例代码照着抄即可。模型响应超时与断连。长任务跑到十几步后模型 API 偶尔会超时导致整个循环卡住。Cua 有时会重试但等待时间很长。我的经验是给任务设置合理的最大步数限制比如 20 步一次跑不完就分段跑不要指望一个长 prompt 包打天下。窗口遮挡导致的点击失效。如果目标窗口被其他窗口挡住截图上看是点的按钮但实际点到的是遮挡窗口。Cua 的验证机制能发现动作没生效但反复重试会浪费时间。建议在任务开始前先把无关窗口最小化或者给 agent 一个“先聚焦目标窗口”的步骤。提示第一次跑复杂任务前一定要先设置auto_confirmFalse跑一遍流程熟悉各个关键节点的正常界面状态。全自动模式留给那些你已经确认过可稳定执行的任务别一上来就全信任。5. 安全边界与我对 AI 桌面自动化的判断5.1 AI 误操作的现实风险Cua 这类工具把 AI 从“建议者”变成了“执行者”能力变强的同时风险也变了性质。以前 AI 给你一个错误建议你还可以审一审、改一改现在它直接替你删文件、发消息、点付款错了就是真错了。我在测试中亲眼看过一个有意思的危险案例让 Cua“帮我把桌面清理干净”它试图把一堆系统快捷方式也拖进了垃圾箱虽然最终被验证环节发现并恢复了但这个风险是真实存在的。所以我在项目里强烈建议做几层安全兜底一是限定 Cua 可访问的目录范围二是敏感操作删除、覆盖、发送消息强制要求人工确认三是在跑任务前留存关键文件快照。Cua 本身支持部分安全策略配置但我觉得安全阈值宁高勿低尤其当它接入生产环境时。5.2 隐私边界屏幕内容掌握在谁手里屏幕截图是 Cua 感知世界的窗口但这个窗口同时也是隐私的漏洞。你让 AI 读取的每一屏内容只要使用的是云端模型就等于这些信息经过了模型服务商的服务器。如果你处理的是普通文件整理问题不大但如果是客户数据、合同、源代码、企业内部系统就要格外谨慎。我建议的隐私分线策略是这样的普通个人任务用云端模型没有问题效率和能力都更好涉及敏感数据的任务优先接本地或私有化部署的视觉模型实在要混用也要确保敏感任务和数据始终不通过外部 API 传输。这个边界不只是技术问题更是合规层面的红线别等出了问题再后悔。5.3 成本优化与稳定性的实际操作思路Cua 的运行成本主要来自模型 API 调用。一次 20 步的任务每步至少一次截图分析几十万 token 是常态。如果频繁运行费用积累很可观。我个人摸索出几个有效的优化方法把任务拆小单次任务控制在 10 步以内减少上下文膨胀带来的 token 浪费。使用缓存机制同一类界面出现多次时模型结果可以缓存避免重复推理。降低截图频率在动作执行层开启“连续动作模式”连续 2-3 个简单操作之间不截图确认大幅节省 token。代价是误操作发现得晚适合那些单步影响可逆的任务。尽早失败设置最大步骤数和单步超时避免模型在一个错误方向上反复重试耗尽 token。成本优化的本质是“少看几眼、多想一次”跟在现实里带新人是一个道理。该放手的地方放手该盯住的地方盯死。5.4 它真正改变了什么在手动写脚本做 RPA 的年代一个自动化任务从分析、编码、调试到上线标准工期是按天甚至按周计算的。有了 Cua 这类 AI 桌面 Agent开发流程被压缩成了“用自然语言描述需求 审查执行过程 沉淀稳定任务模板”。我实际用下来最大的感受不是“AI 帮我自动化了什么”而是“自动化本身的成本结构被彻底改变了”。以前写一个桌面自动化脚本最大的成本不是代码而是理解目标应用的界面逻辑、异常分支和边界情况。现在这些理解工作被大模型承担了代价是每一次执行都需要推理成本但推理成本正在以肉眼可见的速度下降。这不是一个简单的工具升级而是把“自动化”从工程师手里交还给普通用户手里的开始。当然它离“完美”还很远。Cua 在复杂任务稳定性、Linux 生态适配、长任务上下文管理上仍有明显短板。但方向已经非常确定AI 操作电脑就像当年的命令行操作走向 GUI人机交互在迈向更深一层的自然化。作为一个天天跟自动化打交道的人我现在最关心的不是它现在能做多少而是当它越来越成熟之后我们该如何定义“人”在自动化流程中的角色——是每个环节都参与的监督者还是只在关键节点把关的授权者。这个问题没有标准答案但在找到答案之前先把安全边界和成本模型设计好可能比追求“全自动”更务实。