Computer Use Agent：当 AI 学会操作你的电脑

你大概已经习惯了 AI 在终端里跑命令、在编辑器里写代码。但有没有想过——如果 AI 能直接看到你屏幕上的窗口、读懂每个按钮的含义、然后像人一样点击和输入，会怎样？

这就是 Computer Use Agent（CUA）在做的事。

从浏览器自动化到桌面自动化

过去几年，AI Agent 的「手」主要伸向两个地方：终端和浏览器。Cursor 里的 Agent 能帮你改文件、跑测试；Playwright 和 Puppeteer 能帮你填表单、爬数据。但它们有一个共同的边界——离开了文本界面和 DOM，就无能为力。

想让 AI 帮你在 Figma 里拖一个组件？在 Excel 里调整一个图表？打开 Calculator 验算一下？这些都超出了传统工具的能力范围。

CUA 就是为了打破这个边界。它的目标是让 AI 像人一样使用图形界面——看到屏幕、理解 UI 元素、执行点击和键入。

CUA 的核心难题：感知与操作

构建一个 CUA 需要解决两个根本问题：

感知：AI 怎么"看懂"屏幕？

人类看屏幕时，瞬间就能识别按钮、输入框、菜单。AI 要做到同样的事，有两条路径：

纯视觉路径：截屏 → 多模态模型识别 UI 元素 → 推断坐标。Anthropic 的 Claude Computer Use 走的就是这条路。优点是通用性强，什么界面都能截；缺点是坐标不精确、识别容易出错、每一步都需要调大模型。

结构化路径：通过操作系统的 Accessibility API 直接读取 UI 树——每个按钮、文本框、菜单项都有明确的语义标签和层级关系。优点是精确、快速、不需要视觉模型参与；缺点是依赖应用对 Accessibility 的支持程度。

最好的做法是两者结合：结构化的 UI 树提供精确的元素索引，截图提供视觉上下文辅助判断。

操作：AI 怎么"动手"？

感知之后是执行。操作也有两条路径：

AX Action（无障碍操作）：直接调用元素上的语义化动作——「点击这个按钮」「设置这个输入框的值」。不需要移动鼠标、不需要窗口在前台，纯 RPC 调用。

合成输入事件：模拟真实的鼠标移动、点击、键盘输入。通过 CGEvent（macOS）或类似机制注入到目标进程。适合 AX 树不完整的场景，比如 Canvas 渲染的界面或游戏。

cua-driver：一个 macOS 原生的 CUA 实现

cua-driver 是一个运行在 macOS 上的 Computer Use Agent 驱动。它不是一个独立的 AI Agent，而是一个基础设施层——通过 MCP 协议暴露工具，让任何支持 MCP 的 AI（Cursor、Claude Code、OpenCode 等）都能操作桌面应用。

它的技术栈完全是 macOS 原生的：

• 感知层：Accessibility API（AX tree walk）+ ScreenCaptureKit（窗口截图）
• 操作层：AX Action（语义化操作）+ CGEvent（合成鼠标/键盘事件）
• 通信层：MCP stdio / Unix domain socket

一轮操作长什么样？

list_apps → 找到目标进程 PID
    ↓
list_windows → 拿到 window_id
    ↓
get_window_state(pid, window_id) → 获得 UI 树 + 截图
    ↓
click / type_text / hotkey → 执行动作
    ↓
get_window_state → 确认结果，进入下一轮

get_window_state 是核心工具。它做两件事：

第一，遍历目标进程的 AX 树，把所有可交互元素渲染成 Markdown，并给每个元素标上 [element_index N]。AI 看到的是这样的结构：

## Window: Calculator
- [element_index 0] Button "AC"
- [element_index 1] Button "±"
- [element_index 2] Button "%"
- [element_index 3] Button "÷"
- [element_index 4] Button "7"
...

第二，截取该窗口的 PNG 图像，作为视觉参考。

AI 拿到这两个信息后，就能做出判断：「我要点第 4 号元素」或者「我要点坐标 (120, 80) 的位置」。

两种点击模式的取舍

element_index 模式：click({pid, window_id, element_index: 4})

通过 AX Action 直接在元素上触发操作。窗口不需要在前台，不会抢焦点，坐标绝对精准。适合大多数标准 UI 场景。

像素坐标模式：click({pid, x: 120, y: 80})

合成一个真实的鼠标事件，送到目标进程。适合 AX 树覆盖不到的场景，比如 Canvas 画布、WebGL 内容、自绘 UI。

三种 capture_mode

cua-driver 提供三种感知模式，适配不同场景：

som 模式下，AI 既能用 element_index 精确操作，也能看截图来辅助理解布局。

和其他方案的对比

Anthropic Claude Computer Use

Anthropic 在 2024 年发布的 Computer Use 走的是纯视觉路径：截全屏 → Claude 识别 → 输出坐标 → 合成鼠标事件。

优点是完全通用——Linux、macOS、Windows 都能用，不依赖 Accessibility API。但代价也明显：

• 每一步都要调大模型做视觉推理，延迟高
• 坐标精度依赖模型的视觉能力，容易偏移
• 没有语义化的元素信息，AI 只能看像素

cua-driver 的做法更像是「先读 DOM 再看页面」——结构化信息优先，视觉作为补充。

浏览器自动化（Playwright / cursor-ide-browser）

浏览器自动化工具只作用于 Web 页面。它们通过 CDP（Chrome DevTools Protocol）或 WebDriver 协议操作 DOM。

对比：

两者互补：浏览器内用 Playwright；需要操作原生 App 时用 cua-driver。

实际应用场景

CUA 不是玩具——它在几个方向上有明确的实用价值：

自动化测试原生应用

传统的 macOS App 测试要么依赖 XCUITest（只能在 Xcode 里跑），要么用 AppleScript（能力有限）。cua-driver 提供了一种新路径：AI 像用户一样操作应用，验证行为是否符合预期。

AI Agent 的「最后一公里」

很多 AI 工作流卡在「需要操作 GUI」这一步。比如：

• 需要打开 Figma 检查设计稿的具体数值
• 需要在本地 App 里确认某个设置
• 需要操作一个没有 CLI / API 的遗留系统

CUA 补上了这个缺口。

录制与回放

cua-driver 内置了 trajectory recording 功能——记录每一步操作的参数和截图，之后可以回放。这可以用于生成操作手册、复现 bug 步骤、或者训练更好的 Agent 策略。

权限与安全

操作系统级的自动化，权限管控是关键。macOS 的 TCC（Transparency, Consent, and Control）机制要求：

• Accessibility 权限：读取 AX 树、执行 AX Action
• Screen Recording 权限：截取窗口内容（ax 模式不需要）

cua-driver 通过一个 /Applications/CuaDriver.app 壳应用来持有这些权限，避免把高危权限直接授给 Shell 或 IDE 进程。

CUA 的意义

CUA 代表了 AI Agent 能力边界的一次扩展。从「只能在终端和编辑器里干活」到「能操作任何有图形界面的应用」，这个跨度不小。

但也要看到局限：目前 CUA 的可靠性还不够高，特别是面对复杂 UI、动画、自绘控件时。它更适合作为 AI Agent 工具箱里的一件武器，而不是万能解法。

如果你在用 Cursor 或 Claude Code，可以通过 MCP 配置一行接入 cua-driver：

{
  "mcpServers": {
    "cua-driver": {
      "command": "cua-driver",
      "args": ["mcp"]
    }
  }
}

之后在对话里说「帮我打开 Calculator 算一下 123 × 456」，Agent 就会真的去操作计算器。

相关链接：

• cua-driver GitHub
• Anthropic Computer Use 文档
• macOS Accessibility Programming Guide