一个周末，微软、字节、阿里、港大齐刷刷押注『看屏操作』：CUA 赛道怎么突然卷成这样

一个周末，微软、字节、阿里、港大齐刷刷押注『看屏操作』：CUA 赛道怎么突然卷成这样

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

打开任何一个技术社区，你很难不被这个词淹没：CUA（Computer-Using Agent，计算机使用智能体）。过去几天，从 CSDN 上密集涌现的「手写一个会操作电脑的 AI 智能体」教程，到微软、字节、阿里、港大与 Kimi 相继放出的模型与开源项目，再到各路自媒体对 OpenAI Operator、Claude Computer Use 的反复复盘——「让 AI 直接看屏幕、动鼠标键盘」突然从论文术语变成了全行业冲刺的竞赛项目。本文不堆叠新闻标题，而是把四方玩家的打法拆开，用开源仓库里的真实代码回答三个问题：大家到底在抢什么？各自的切口在哪里？拥挤的赛道上，谁在定义标准，谁可能先掉队？

一、从「聊天」到「看屏」：一条被多方验证的技术主线

CUA 的技术内核并不复杂：截取屏幕 → 多模态模型理解界面状态 → 输出受限的动作（点击、输入、快捷键、滚动）→ 截图回环验证。它与传统 RPA 的本质差异在于，RPA 靠固定选择器和录制脚本，界面一变就崩；CUA 靠视觉感知动态决策，界面怎么改都能重新「看懂」。社区里那些井喷的手写教程，几乎都是沿着「截图 + 多模态 API + PyAutoGUI」这条最小闭环在复刻，侧面说明这条技术主线的入门门槛已经低到个人开发者可以在一两个晚上跑通。

但真正的分野发生在闭环的「下半场」。早期计算机使用智能体是典型的 Computer-Use 1.0：一个 agent 独占一台机器，前台抢走鼠标键盘，循环「看截图 → 选动作 → 再截图」。这种模式在一次性沙箱里可用，在开发者自己的电脑上就很尴尬。本仓库团队在 博客 中记录了转折点：2026 年 4 月 Codex 引入后台计算机使用能力后，行业开始转向 Computer-Use 2.0——桌面不再是 agent 的整个世界，而只是主 agent 手里的一个工具，agent 可以在「看屏」与「读文件、看日志、改代码」之间自由切换。这条主线意味着，单点「模型会看屏」远远不够，谁能把「看屏、动手、验证、并行」串成一个可靠的闭环，谁才真正站上牌桌。

二、四方入局时间线：密集放量的「舆论同频」

把社区情报快照里的事件摊开，时间线上密集到令人目不暇接：

• 微软：发布面向屏幕理解的 Phi-Ground 模型，主打通用的「看屏 + 定位」能力；
• 字节：Seed 团队开源 UI-TARS-1.5 智能体模型，宣称在多项 Benchmark 拿到 SOTA；
• 阿里：Qwen-CUA 以 397B 参数 MoE 模型亮相，仅凭屏幕截图输入与键鼠输出实现跨软件通用操作，在 OSWorld 等八个基准上刷新成绩，并支持与 Bash 等工具混合执行；
• 港大 & Kimi：开源 OpenCUA，口号是「每人都可造专属电脑智能体」；
• MIT 科技评论同步报道了一个四人小团队用 1100 万小时屏幕录像训练「通用计算机行为模型」。

严格说，这些动作未必落在同一个日历周内，但它们在 2026 年夏秋之交的密集放量，构成了舆论意义上的「同一个周末」——当四家巨头与顶尖高校在同一窗口期齐声押注同一个赛道，技术社区的体感自然是从「有人试水」变成「全员下场」。而 OpenAI Operator 早在 2025 年初就定义了 L3 级智能体的叙事，Claude 的 Computer Use 也被反复拿来对照，这轮国内玩家的跟进，本质上是把「看屏操作」从英文生态的独舞，拖进了中文开源世界的集体冲刺。

三、各自打法：模型底座、开源生态与场景切口

四方入场，打法是四种不同的姿势。

微软：模型出海 + 把感知层做成「基建」

Phi-Ground 属于典型的小模型路线——不追求全能的 agent，而是把「读懂屏幕、给出定位」这一步做成干净利落的组件。更有意思的是微软的另一块资产：OmniParser。在本仓库中，微软 OmniParser 的图标检测器被以显式安装的cua-perception扩展形式集成进 Cua Driver，用于把原生窗口截图解析成模型中立的文本与图标区域（见 libs/cua-driver/README.md）。这个动作的潜台词是：微软想把感知层做成所有 CUA 玩家绕不开的公共设施，而不是只卖一个模型。当然，开源授权在这里划下了清晰边界——OmniParser 检测器是 AGPL-3.0-only，仓库 README 用了整整一段篇幅提示再分发与网络托管可能触发的开源义务，这本身就是开源生态里「基建 vs 商业」张力的一则标本。

字节：以开源模型卡位 SOTA 排位

字节的打法是典型的「开源抢榜」：UI-TARS-1.5 直接开源权重，用多项 SOTA 成绩在社区心智里占据「开源最强」的位置。这种打法的收益在于，当所有 CUA 教程、评测、演示都在拿你的模型跑分时，你就成了事实上的社区默认选项，后续的插件生态、Agent 框架适配都会优先朝你倾斜。

阿里：底座最厚，走「原生交互 + 工具混合」路线

Qwen-CUA 的差异化在于三点：一是 397B MoE 的底座规模，保证多步长程任务的理解上限；二是刻意最小化的交互接口——只有截图输入和键鼠输出，把模型能力「逼」进通用视觉操作；三是 SAPO 迭代式强化学习，配合长程视觉上下文的处理技巧，让模型在 OSWorld 这类需要几十上百步连续操作的任务上不掉链子。它同时支持与 Shell 工具混合执行，本质上是承认：纯看屏效率低，该用命令行的场景就该切回命令行——这与 Computer-Use 2.0 的「桌面即工具」理念同频。

港大 & Kimi：把「造智能体」本身开源

OpenCUA 的切口最特殊：它不止开源模型，还开源了一套「人人都能造 CUA」的完整软件栈。本仓库的评测代码给出了它落地的实证——libs/cua-bench/cua_bench/agents/opencua_agent.py 中注册了opencuaagent，默认模型为openai/opencua-7b，通过 OpenAI 兼容端点接入 CUA Computer Agent SDK，并把截图、点击、键入、键组合、滚动、拖拽等动作统一封装成自定义 computer handler。旁边还有同构的qwen35agent 适配 Qwen3.5 系模型（qwen35_agent.py）。也就是说，OpenCUA 直接让你用现成的 7B 开源模型 + 一套动作协议，在真实桌面上跑通完整闭环——它争夺的不是单个模型份额，而是「CUA 应用开发」这个入口。

生态承接方：Driver 层、评测层、决策模型层的开源对冲

模型层再热闹，也绕不开「谁来替你动手」的执行层。这正是开源生态里另一类玩家在做的事——把 CUA 的执行底座做成跨平台标准件。以本仓库的 Cua Driver 为例，核心设计文档 展示了一条非常工程化的「动作阶梯」：

1. 无障碍树动作：按element_token走平台语义接口（Windows UI Automation、macOS AX、Linux AT-SPI），这是唯一能被驱动自身验证的层级；
2. 像素坐标动作：对 canvas、Electron 等树不可靠的场景，按截图坐标点击；
3. 页面动作：浏览器标签切到 DOM 层（CDP），不抢焦点；
4. 前台兜底：只有前三级失败才短暂抬窗、落点、恢复原焦点。

每次动作后，驱动返回effect（confirmed / unverifiable / suspected_noop / partial / refused）与escalation建议，让 agent 知道自己该不该「升级动作」。这套设计直击 CUA 落地的最大痛点：应用对合成输入的态度千差万别，「投递成功」不等于「变更生效」，Electron、Catalyst、Web 内容都可能回显一个并未真正生效的写入。

支撑这条阶梯的是跨平台机制矩阵：macOS 走 Accessibility + Scoped CoreGraphics/SkyLight + ScreenCaptureKit，Windows 走 UI Automation + 面向目标 HWND 的窗口消息（且守护进程必须跑在交互会话而非 Session 0），Linux 的 X11 与 Wayland 又各自有组合器级限制。Wayland 上驱动宁可拒绝输入也不冒险打错窗口——background_unavailable是契约的一部分，而不是「藏着掖着的失败」。平台差异如此之碎，仓库选择用超过 500 项行为检查的回归矩阵（覆盖 Windows、macOS、Linux X11、Sway、GNOME，含 Electron、Tauri、原生工具包与嵌入式 WebView）逐格验证，每格都要独立观察到目标应用的状态变更才算通过（见 libs/cua-driver/README.md 与 computer-use-2 博客）。这种「脏活累活」构成了执行层的真实壁垒——谁把这块做成开源标准，谁就在生态里握有不可替代的接口话语权。

四、赛道拥挤度推演：谁在定义标准，谁会先掉队

四方加生态的格局已经形成，接下来真正决定位次的，是三层结构的卡位：模型层、执行层、评测层。

模型层的拥挤最直观，也最危险。各家的屏幕理解能力正在快速趋同。仓库里一份针对电子设计工具 KiCad 的实测可以当作风向标：25 个专家编写的任务、7 个前沿模型、统一 200 步预算，结果最好成绩是 6/25 个完整通关，榜单前几名挤在 5–6 个之间（computer-use-2 博客）。更扎心的是，7 个模型在「空白画布起稿」类任务上全部得零分——长程规划与状态保持依然是集体短板。模型差距如此之小，意味着任何一次版本迭代都可能改写排位，「押错底座」的一方会以极快的速度掉出讨论热度。

执行层的壁垒最硬，却最不性感。权限模型、后台输入、会话管理、平台差异……这些 OS 级的脏活决定了 agent 是「真的可用」还是「demo 里可用」。Cua Driver 的做法是把权限钉死在启动时（standard/bounded/unrestricted三种模式，agent 无法在运行中自我提权），把每次动作的可验证性做成协议的一部分。谁先在这个层面跑通 macOS + Windows + Linux 的统一接口，谁就掌握了让各家模型「上车」的入口——Clicky、Hermes、Qwen Code、Factory 的 Droid 等先后接入，本身就是执行层卡位成功的注脚。

评测层才是话语权所在。排位赛没有裁判就没有意义。Cua Bench 的做法非常「数据基建」：任务一律代码化声明（setup / agent / evaluate 三段式），评测器直接检查文件与应用状态，结果可复现；trajectory.json统一为 ATIF-v1.8 轨迹格式（Harbor 格式），可回放、可评分，还能用cb dataset build导出 aguvis-stage-1、gui-r1 等训练格式（libs/cua-bench/README.md）——评测数据直接回流为下一代模型的训练燃料。更关键的是对既有标准的兼容：仓库里专门有一个 PathBridge 循环回环桥，把 OSWorld 的PythonController/SetupController、CDP 客户端、BrowserGym 这类上游评测控制器的 host/port 假设，翻译成 Fleet 上的签名 URL 服务；另有 DatasetSession 支持 OSWorld-G、ScreenSpot-Pro 这类纯截图 grounding 数据集，「只记录动作、不执行动作」，把定位评测的颗粒度做到像素级。谁把这些评测标准沉淀成开放格式，谁就在事实上定义了「什么算会操作电脑」。

最后看差异化变量。拥挤的模型层之外，有人在赌「小模型专业化」：CUA-S1 系列刻意不做通用 agent，而是把「这个字段该填什么、这个元素该不该动」这类高频低阶决策做成 Option-Attention 分类而非逐 token 生成（MODEL_CARD）——最小的cua-s1-form-v0只有 70 万参数，在分布内 3070 个决策上做到 97.5% 准确率；同时它的评测也诚实揭示边界：面对目录外的新词标签，准确率掉到 29.3%，且倾向输出高置信度的skip。这种「小模型 + 明确边界 + 真实验证」的路线，是在给大模型层做「外挂心脏」——让通用模型负责规划，让专业小模型负责高频动作的快速裁决。相比在 397B 里继续堆参数，这条路的边际成本更低、可验证性更强，也恰恰是拥挤赛道里少数几个还没被卷平的角度。

五、卷的本质：从模型竞赛到闭环竞赛

回看这一轮「看屏操作」的集体押注，真正的变化不在模型，而在闭环。四家的模型再强，都绕不开三个共同的硬约束：感知（看懂屏幕）、执行（可靠地把动作落到真实应用上）、评测（可复现地证明任务完成）。微软押感知基建，字节押开源 SOTA，阿里押底座与混合执行，港大&Kimi 押应用入口，而开源生态里的执行层与评测层玩家则在把这些约束变成标准件。赛道拥挤是事实，但拥挤的方向很清楚：谁能把「模型 + 驱动 + 基准」串成可复现、可训练、可扩展的完整闭环，谁就定义标准；只押注单点能力、补不齐闭环的一方，会在下一轮评测排位中迅速被识别出来。看屏操作这场仗，拼的不是谁先喊出概念，而是谁先把概念变成每一个开发者都能跑通、每一个模型都能对齐的公共基础设施。

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