全网刷屏的 AI 操作电脑混战：trycua/cua、Qwen-CUA、UI-TARS-1.5、Operator，到底谁更能干活

全网刷屏的 AI 操作电脑混战：trycua/cua、Qwen-CUA、UI-TARS-1.5、Operator，到底谁更能干活

【免费下载链接】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

从 2025 年 OpenAI 发布 Operator、Anthropic 跟进 Computer Use，到 2026 年阿里开源 397B 参数的 Qwen-CUA、字节开源 UI-TARS-1.5、微软开源自己的 CUA，再到 MIT 科技评论报道"四人团队用 1100 万小时屏幕录像训练通用计算机行为模型"——"AI 操作电脑"已经从演示视频变成了全行业最拥挤的赛道。但热闹归热闹，一个关键问题始终没有统一答案：这四类玩家到底谁更能干活？本文不堆概念，而是把四条技术路线拆开对比，并用开源仓库 trycua/cua 中真实可运行的驱动层、评测套件与安全机制，回答"能干活的评判标准"到底是什么。

四条路线，四种哲学

原生模型派：把"看屏—动手"焊进权重里

这一派的核心做法是：模型只接收屏幕截图，只输出鼠标键盘动作，中间不再依赖任何 API、选择器或 DOM。

• Qwen-CUA：基于 397B 参数的混合专家模型，交互接口被压缩到最小——屏幕截图进、键鼠操作出。社区报道称它在 OSWorld 等八大基准上显著超越 Qwen3.7，并用长程视觉上下文分块折叠和迭代式强化学习（SAPO）解决长任务漂移问题，安全性也有明显提升，且支持与 Bash 等工具混合执行。
• UI-TARS-1.5：字节 Seed 团队开源，官方宣称在多项 Benchmark 上取得 SOTA，属于同一"视觉—动作"范式的开源实现，可本地部署。
• Operator（OpenAI CUA）：首个 L3 级智能体，方向一致但闭源、运行在云端浏览器沙箱里，普通用户零门槛但能力边界受限于产品环境。

这一派共同的技术赌注是：GUI 理解能力必须内化到模型里。代价是参数规模巨大（Qwen-CUA 397B 意味着高昂的推理成本），且面对从未见过的专业软件界面时，表现仍不稳定。

开源基础设施派：把"电脑"交给任何模型

与"训练模型"相反，trycua/cua 走的是另一条路：不训练大脑，只提供能让任何模型真正操作电脑的四肢、眼睛和评测场。仓库 README.md 的定位写得非常直白：Give AI agents computers they can use——把完整的桌面、无障碍树、输入通道和评测工具开源出来，模型换成谁都行。

架构图左侧是 Python / Node / Swift / Kotlin / WASM 的多语言 SDK，中间是 Rust 核心（cua-sdk、cua-vmm、cua-image、cua-fleet），右侧是运行在沙箱内部的 cua-spacesd 守护进程。整套体系里，"谁来做决策"和"谁来碰电脑"被彻底切开：决策层可以接 Claude Code、Codex、Cursor、OpenClaw，甚至 GPT-6 Astra、Gemini 3.5 Flash；执行层统一由 Cua Driver 负责。

这个仓库本身就是 Computer-Use 混战的最好观察样本——它不是参战方之一，而是给所有参战方提供同一个"考场"和"驾驶舱"。

谁更能干活：三个实测维度

维度一：任务成功率——先看看"考试"是怎么设计的

"成功率"最容易变成营销数字，因为 demo 极易过拟合。开源仓库给出了一个更严谨的回答方式：Cua Bench（cb命令）把任务做成"可验证的桌面考试"，每个任务模块由@tasks_config（变体）、@setup_task（环境准备）、@solve_task（参考答案）、@evaluate_task（评分）四个函数构成，同一套评分逻辑同时打 oracle、人类和 agent 的分数（见 docs/content/docs/cua-bench/index.mdx）。

考试题库分两层：

1. 自研任务集：cua-bench-basic（13 个任务、68 个变体，覆盖点击、输入、拖拽、表单填写）、cua-bench-kicad（25 个真实 EDA 原理图编辑任务，按网表计分）、cua-bench-workflows（52 个 OpenShot/Unity 多步骤工作流变体），详见 docs/content/docs/cua-bench/guides/benchmarks.mdx。
2. 业界标准适配器：通过cb run dataset一行命令即可跑 OSWorld-Verified（369 个桌面任务）、MiniWoB++（130）、WebVoyager（643）、Online-Mind2Web（300）、WebGym（1167）以及 OSWorld-G（564 项点击定位）和 ScreenSpot-Pro（约 1581 张高分辨率专业软件截图），见 docs/content/docs/cua-bench/guides/adapter-benchmarks.mdx。这意味着社区任何 agent 都能在同一套试卷上横向比较。

仓库还记录了真实评测结果。在 Cua-Bench 的 KiCad EDA 套件上（25 个真实电路设计任务、统一 200 步预算），没有任何前沿模型能完整通关：Gemini 3.5 Flash 平均奖励最高（0.267，5 个完整解决 + 3 个部分解决），GPT-5.5 完整解决最多（6 个）但因无部分得分而以 0.240 居次（见 blog/evaluating-gemini-3.5-flash-on-computer-use.md）。失败模式高度一致：从零设计类任务在 200 步预算内超时、截图两次后模型幻觉出并不存在的界面状态。

这组数据透露的真相是：原生模型强在"看屏就点"的通用性，弱在"需要边思考边操作"的专业任务。Qwen-CUA 在 OSWorld 类基准上的提升是真实的，但"基准提升"和"CAD 里完成一次原理图修改"之间，还隔着漫长的工程距离。

维度二：跨软件通用性——"看懂屏幕"和"够得着软件"是两回事

Qwen-CUA、UI-TARS-1.5 的通用性来自"只吃截图、只吐键鼠"的最小接口——理论上任何界面都能操作。但纯截图路线有一个隐蔽的短板：像素不代表可操作性。一个按钮在截图里是像素，在无障碍树里才是带element_token的可点击对象。

Cua Driver 恰恰把这两条通道合二为一：get_window_state一次调用同时返回窗口的无障碍树和截图——树告诉你"什么可操作"，像素告诉你"是哪一个"（见 docs/content/docs/cua-driver/concepts/how-cua-driver-works.mdx）。更重要的是它的"动作阶梯"（action ladder）：

1. 元素级后台操作：按element_token调用平台无障碍动作（Windows UIA / macOS AX / Linux AT-SPI），这是唯一能自我验证的一档；
2. 像素级后台操作：按同一张截图的坐标点击；
3. 页面级：浏览器标签页走 CDP 直接操作 DOM，无需焦点；
4. 前台操作：仅在必要时抬升窗口（游戏、Blender 等画布类应用）。

每一档执行后都会返回confirmed / unverifiable / suspected_noop / partial / refused等效果判定，未确认就建议升档重试。这套阶梯直接回答了跨软件通用性的工程难题：不是"能不能模拟点击"，而是"每档操作能不能验证、验证不了时怎么降级"。

与之对照的边界同样清晰：Linux Wayland 上组合器不保证把原始输入送到指定窗口，驱动会直接拒绝并返回结构化的background_unavailable，而不是冒险把键鼠敲进错误的应用——宁可拒答也不误操作，这正是"能干活"和"敢乱干"的分水岭。

维度三：上手门槛——从安装到授权，三分钟和三天是两种体验

Operator 对普通用户门槛最低（订阅即用），但环境受限在浏览器沙箱；Qwen-CUA 与 UI-TARS-1.5 需要自持大规模权重与 GPU，且要让模型在本地桌面真正动起来，仍需自己接一套输入执行层——这正是社区大量教程的痛点所在：截图拿到了、模型回复了动作，但"坐标怎么映射、DPI 怎么适配、点击怎么不抢焦点"全部要自己踩坑。

Cua 的上手路径是另一套设计哲学。快速开始只需三行命令（见 docs/content/docs/cua-driver/quickstart.mdx）：

/bin/bash -c "$(curl -fsSL https://cua.ai/driver/install.sh)" open -n -g -a CuaDriver --args serve # macOS；Windows 用 autostart kick cua-driver permissions grant

然后cua-driver mcp暴露给任意 MCP 智能体，cua-driver call list_apps验证可见性，即可让 agent 打开计算器完成"6 × 7 = 42"并验证结果。对开发者还有 Python / TypeScript 原生 SDK（CuaDriver.create()直接嵌进进程），以及cua sb create一行拉起 gVisor 沙箱、cua sb screenshot dev截图检查（见 libs/cua/README.md）。

安全性也不是事后补丁，而是内建的分层授权：每个调用在触碰桌面之前都必须依次通过硬性不变量（如自我保护、宿主保护）、内置工具风险映射、管理员策略、用户策略、权限模式、能力清单和启动授权共七层检查（见 docs/content/docs/cua-driver/guides/permissions.mdx）。三种模式各司其职：standard无提示跑本地自动化、bounded面向无人值守 agent 默认全拒只放行清单内工具、unrestricted必须显式--dangerously-bypass-approvals且失败即关闭（fail closed）。能力清单是"默认拒绝"的 YAML——不在allow.tools里的工具一概不给，且任何模式都只能收窄不能放宽：

version: 3 allow: tools: - start_session - get_window_state - click - type_text

选型结论：没有单一赢家，只有分工

回到标题的问题——"到底谁更能干活"，仓库里的源码给出的答案不是某一家，而是一个清晰的分工模型：

• 普通用户：想让 AI 代购、订票、填表，Operator 这类闭源产品最省事，浏览器内任务是其舒适区；但一旦任务落到原生桌面专业软件，它和所有模型一样会受限于执行层的能力。
• 想自建 Agent 的开发者：决策层（大脑）选 Qwen-CUA、UI-TARS-1.5 或任意闭源模型均可——它们决定"会不会干活"；执行层（手脚）接 Cua Driver 这样的开源驱动——它决定"能不能干、干得干不干净（不抢焦点、可验证、可降级）"。
• 想低成本跑垂直场景的团队：Cua 的 CUA-S1 系列展示了第三条路——不做通才，做"专用小模型 + 外部执行"：cua-s1-4b-0.2是基于 Qwen3.5-4B 冻结权重加 LoRA 的微调模型，最小的tinyx表单检查点仅 70 万参数，在分布内表单决策上准确率达 97.5%，但一旦标签词汇超出训练集，准确率骤降到 29.3%（见 libs/cua-s1/MODEL_CARD.md）。模型卡毫不讳言这份局限——"高置信度的 skip 不代表表单已完成"。这种诚实，恰恰是当前 Computer-Use 生态最稀缺的品质。
• 做评测与数据生产的团队：cb run <taskset> --agent <agent> --model <model>一行命令即可让任何 agent 在统一试卷上出分，输出 ATIF 轨迹并导出训练数据——混战越激烈，这套"统一考场"的价值越大。

回看这场混战：原生模型派在卷"看得懂"，基础设施派在卷"碰得准、验得真、退得稳"，评测体系在卷"怎么公正地打分"。谁更能干活，取决于你把手里的任务交给哪个环节——而真正能确定答案的，永远不是宣传稿，而是像cua-bench-kicad这样一份 25 道、按网表判分的真实考卷。

【免费下载链接】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