近 2 万 Star！AI 在后台操控电脑不抢你鼠标，Cua 让 Agent 真正「用」上电脑了

你有没有想过一个问题——现在的 AI Agent，其实挺"残疾"的。

它们能写代码、能回答问题、能调 API，但你要让它"打开 Chrome 浏览器，登录邮箱，点开最新那封邮件，把附件下载到桌面"——它做不到。不是做不到，是压根没有"手"去操作。

这就是为什么 Cua 这个项目在 GitHub 上炸了——将近 2 万 Star，Hugging Face、Meta、NVIDIA、Apple 都在用。

它干的事一句话说清楚：让 AI agent 像人一样，真正上手操控电脑。

而且是后台静默操作，不抢你鼠标。

AI Agent 缺的那双「手」

先理解一下问题。

现在的大模型，说白了就是个"大脑"。你跟它说话，它回答你。但要让它在电脑上干活——打开软件、点按钮、拖文件——它没手。

以前怎么解决？

要么写死脚本，要么用 Selenium 这种自动化测试工具。但脚本太死板，Selenium 只能在浏览器里用，离开了浏览器就抓瞎。

Cua 的思路直接得有点粗暴：给 AI agent 装上一套「操作系统驱动」。

这套驱动让 agent 可以：

• 截图看屏幕，理解当前界面在显示什么
• 移动鼠标、点击、右键，操作界面元素
• 敲键盘、输入文字、按快捷键
• 执行 shell 命令，直接在终端里干活
• 所有这些操作都在后台完成——不抢占你的鼠标和键盘焦点

说白了，Cua 就是 AI agent 的「鼠标键盘扩展包」。

而且最离谱的是，它一套 API 管四套系统：macOS、Windows、Linux、Android。你写一次代码，AI 可以在任何系统上操作。

没懂这个"后台"有多重要是吧？接着往下看。

后台运行才是真·自动化

我觉得 Cua 最炸裂的设计，是那个 Cua Driver。

以前的自动化工具，不管是 Selenium 还是 PyAutoGUI，操作电脑的时候都是"前台抢焦点"——你的鼠标突然被"夺走"了，光标自己在屏幕上乱飞，你想干点别的事都干不了。

Cua Driver 解决了这个问题。

它在后台运行，通过截图理解屏幕内容，然后直接操作系统底层事件。不抢你的鼠标，不占你的键盘。你该写代码写代码，该刷网页刷网页，AI 在后台默默把活干了。

说实话，第一次看到这个设计的时候我愣了一下——"这种东西真的能稳定？"

然后翻了文档，发现它已经在 macOS 和 Windows 上跑生产环境了，Linux 也出了预发布版。而且可以通过 MCP 协议和 Claude Code、Cursor、Codex 等工具集成，相当于你写代码的时候，助手还能在后台帮你测试。

这让我想起之前用 PyAutoGUI 写自动化脚本的血泪史——脚本跑起来啥都干不了，只能盯着屏幕看光标自己跳舞。Cua 这个"后台不抢焦点"的设计，怎么说呢，就是……就是那种"早该有人这么做"的感觉。

三行代码，你的 AI 就能操控桌面

Cua 的使用方式很"Pythonic"。装好之后，你的 AI agent 可以直接调用沙箱环境：

from cua import Sandbox, Image

# 一键拉起一个 Linux 沙箱
async with Sandbox.ephemeral(Image.linux()) as sb:
    # 截个屏看看
    screenshot = await sb.screenshot()
    # 移动鼠标点一下
    await sb.mouse.click(100, 200)
    # 再打几个字
    await sb.keyboard.type("Hello from Cua!")

看见没？三行代码，AI 就能控制一台完整的桌面系统。

你说这玩意儿能干嘛？

• 自动化测试：不用写脚本了，让 AI 自己打开 App、截图、比对结果
• 数据采集：AI 像人一样在网页里点来点去，把数据扒下来
• DevOps：让 AI 登录服务器、执行命令、检查日志
• 移动端测试：连 Android 都支持，手机 App 自动化也包了

而且它还支持 快照和分支——你可以配好一个环境，保存成快照，然后瞬间 fork 出 7 个并行测试实例。热启动不到 1 秒。

一条命令搞定 macOS 虚拟机

Cua 体系里还有一个我很喜欢的小工具——Lume。

如果你在 Apple Silicon 的 Mac 上开发，想跑个 macOS 或者 Linux 虚拟机做测试，Lume 一条命令搞定：

lume run macos-sequoia-vanilla:latest

它用的是 Apple 原生的 Virtualization.Framework，性能接近原生，不是那种跑起来风扇狂转的模拟器。

Lume 和 Cua Sandbox 是打通的，你可以在 Lume 虚拟机里跑 Cua agent，让 AI 在虚拟机里随便造，反正不影响宿主机。

一个让 AI「长出手」的开源全家桶

Cua 这个生态已经做起来了：

每个组件都是独立的，你可以只用一个，也可以全套上。全部 MIT 协议开源。

官网：https://cua.ai/

GitHub 地址：https://github.com/trycua/cua

最后说两句

Cua 解决了一个很朴素但一直被忽视的问题：AI 如果想真正帮人干活，它得有双"手"。云 API 调得再溜，不如它能自己打开浏览器点一下"导出"按钮。

装不装都行，看你自己。但说实话——如果你的工作流里涉及大量重复的桌面操作，Cua 可能会让你发出和我一样的感叹：

"擦，以前我怎么没想到还能这么搞。"

转自：https://mp.weixin.qq.com/s/OflrIVYrPWQxyskEgXuEjw" />
插件也能直接用了，这才是完整体验：

你还别说，这个方案是我目前用下来最丝滑的，强烈推荐。

如果想回滚怎么办

• 在管理工具里清除 API 模式，切回官方配置就行。
• 如果 Codex 更新后 Codex++ 不好使了，等它适配就行，不影响原版使用。

方案三：CCX + CC Switch

这个方案适合重度玩家，把「网关」和「切换工具」拆开了：

• CCX：API 代理网关，负责协议转换和路由。支持 Claude、OpenAI、Codex、Gemini 等多种入口。
• CC Switch：桌面管理工具，一键切换不同供应商配置。

什么时候用这个方案？你有多个国产模型 API、多个中转服务、多个 Key，或者上游只支持 Chat Completions 需要转换成 Responses API 的时候。

第 1 步：部署 CCX

用 Docker 一行命令搞定：

启动后浏览器打就能看到了。

第 2 步：添加上游渠道

在 CCX 管理界面里添加你的渠道：

1. 选择上游服务类型。
2. 填 API Key 和 Base URL。
3. 配置模型映射和路由规则。
4. 用自带的测试功能确认能通。

这里有个关键点：Codex 需要 Responses API 入口。如果上游只有 Chat Completions，CCX 会帮你做协议转换，这也是用它的核心原因。

第 3 步：安装 CC Switch

命令行安装：

npm install -g cc-switch

初始化：

cc-switch init

初始化时填入 CCX 的地址作为中转入口。

第 4 步：切换配置并启动

一行命令切换供应商：

cc-switch use <配置名>

然后重启 Codex 就生效了。

切换后建议打开 ~/.codex/config.toml 核对一下：

• model_provider 是不是你刚选的。
• base_url 是不是指向 CCX。
• Key 有没有不小心写进公开仓库（这个很重要）。

常见踩坑汇总

最后放一张排错表，遇到问题先对照看：

说实话，三种方案我都跑通了，日常用的最多的还是方案二 Codex++，省心。

如果你是那种手里有好几个 Key、好几个供应商的重度用户，方案三更适合你。

转自：https://mp.weixin.qq.com/s/Qvfr9LC2wF9ltCEyKFqK3g