macOS 开源 Computer Use 方案对比：UI-TARS Desktop、open-computer-use、macOS-use 与 Computer Use OOTB
先给结论
这四个项目都能参与 macOS 的“让 Agent 操作图形界面”问题，但它们并不是同一层的替代品：UI-TARS Desktop 是独立的视觉 GUI Agent；open-computer-use 是给 Codex、Claude Code 等上层 Agent 使用的 MCP 执行服务；macOS-use 是基于 Accessibility 的 Python 库；Computer Use OOTB 是用于 API 与本地模型实验的 Gradio 操作台。选型应先问“谁规划任务、谁执行、是否需要本地模型、是否已有 Agent 客户端”，而不是只比较哪个项目能点鼠标。^[来源：UI-TARS Desktop、open-computer-use、macOS-use、Computer Use OOTB]
它们对应的详细介绍分别见 UI-TARS Desktop、open-computer-use、macOS-use 和 Computer Use OOTB。
核心对比
| 维度 | UI-TARS Desktop | open-computer-use | macOS-use | Computer Use OOTB |
|---|---|---|---|---|
| 主定位 | 原生视觉 GUI Agent | MCP Computer Use 服务 | Python Agent 库 | 多模型 GUI Agent 实验操作台 |
| 主要交互入口 | 桌面应用；也覆盖本地/远程计算机和浏览器 operator | Codex、Claude Code、Gemini CLI 等 MCP 客户端 | Python 代码 | Gradio Web UI |
| 主要环境表示 | 截图 + 视觉语言模型 | 应用状态与可访问性驱动的工具调用 | macOS Accessibility 元素树 | 截图 + 所选 API/本地 GUI 模型 |
| 模型形态 | UI-TARS、Seed 系列等，实际取决于配置 | 由宿主 Agent/模型决定 | 由接入的 LLM provider 决定 | 可比较 API 后端与 ShowUI、UI-TARS 等本地路径 |
| macOS 明示前提 | 原生桌面支持；仍需按实际客户端完成系统授权 | macOS 14+；需 Accessibility 与 Screen Recording | macOS 12+、Python 3.12+；需相应辅助功能授权 | Apple Silicon 本地 ShowUI 建议 M1+、16GB 统一内存；Python 3.12+ |
| 最适合的起点 | 直接试用视觉桌面 Agent | 把 GUI 控制接进现有 Agent | 用 Python 编排可验证的桌面流程 | 比较/复现本地与 API 模型 |
| 许可证 | Apache-2.0 | MIT | MIT | 以仓库 LICENSE 为准，部署前应核对 |
上表来自各项目 README 与项目页中的定位、安装前提和能力说明。它并不比较模型基准分数：四者的模型、推理后端、屏幕环境和任务定义不同，不能用“一个项目更强”概括。^[来源：UI-TARS Desktop、open-computer-use、macOS-use PyPI、Computer Use OOTB]
用执行层而非项目名理解差异
独立交互层： UI-TARS Desktop Computer Use OOTB
│ │
Agent/模型层： 视觉模型 / API / 本地推理后端
│ │
执行与可观察层： open-computer-use macOS-use
│ │
系统能力层： macOS 屏幕、Accessibility、键盘鼠标、AppleScript这不是严格的产品架构图，而是选型心智模型。UI-TARS Desktop 和 Computer Use OOTB 都可以包含模型与交互层；open-computer-use 与 macOS-use 都更接近可被其他程序使用的执行底座。实际项目可以组合它们的思路，但不应假定任意两个项目可以无改造地直接互相替换。^[来源：UI-TARS Desktop、open-computer-use、macOS-use、Computer Use OOTB]
按需求选择
1. 已经使用 Codex，想让它操作当前 Mac
优先评估 open-computer-use。它把桌面能力封装成 MCP 工具，能匹配“Codex 负责理解和规划，服务负责执行”的已有工作流。先用 doctor 和单步调用验证权限与目标应用状态，再逐步扩大任务范围；不要一开始让 Agent 处理账号、付款、删除或发布。^[来源：open-computer-use README]
2. 需要一个开箱可见的视觉 GUI Agent
优先试 UI-TARS Desktop。它直接面向本机、远程计算机和浏览器 operator，并将截图识别与鼠标键盘控制串成完整 Agent 体验。适合验证视觉界面任务是否可自动化，但应把长流程拆成带检查点的小任务。^[来源：UI-TARS Desktop README]
3. 需要把 macOS 自动化纳入 Python 工程
优先使用 macOS-use。它的 Accessibility 驱动方式能给原生控件提供元素角色、名称和状态，便于在代码中加入断言、重试和测试；它不是适用于所有自绘 UI 的万能视觉替代品。^[来源：macOS-use PyPI 项目页]
4. 想比较本地模型与云端 API，并关注 Apple Silicon 性能
优先使用 Computer Use OOTB。它把 API 型和本地 ShowUI/UI-TARS 等路径收敛在一个 Gradio 操作台，方便做可重复的实验；本地路径也需要为模型文件、MPS/PyTorch 与统一内存压力做准备。^[来源：Computer Use OOTB README]
共同的安全底线
四类方案的核心风险不是开源与否，而是屏幕读取、辅助功能、键盘鼠标控制、文件和 Shell 权限叠加后形成的高权限执行通道。视觉模型可能误点，Accessibility 驱动也可能误判元素；本地模型减少的是数据外传，并不会消除错误操作。^[来源：open-computer-use README、macOS-use PyPI 项目页]
推荐的最小实践：
- 用测试账号、独立浏览器 profile 或受限 macOS 用户试验，不把主账户当沙箱。
- 让 Agent 先执行只读动作，再验证单步可逆操作，最后才运行多步骤任务。
- 对发送、支付、删除、授权、发布等动作加入显式人工确认。
- 优先调用有 API、CLI 或 AppleScript 的系统；只把界面不可避免的部分交给 Computer Use。
- 记录模型、版本、权限、屏幕设置、任务前提、成功判据和失败情况，形成可复用的运行手册。
这套记录方法可接入 技术知识库维护方法；长期价值不在于收集“能控制电脑”的项目，而在于沉淀每个自动化流程的可验证边界。
最终建议
对个人开发者，若目标是把当前的 Codex 工作流延伸到 GUI，先从 open-computer-use 的单步、低风险测试开始；若目标是体验一个独立的视觉 Agent，先试 UI-TARS Desktop；若目标是把自动化能力编码进 Python，选 macOS-use；若目标是做本地模型试验与比较，选 Computer Use OOTB。四者可以在不同阶段共存，但没有一个项目能免除权限治理、业务校验和人工确认。