当 AI 学会不动你的鼠标：Cua 把电脑操作员拆成了五层基础设施
一个 agent 想帮你填表。它截屏、找按钮、模拟点击——然后你的鼠标突然飞到屏幕左上角，因为你正在打字。这是当前所有 computer-use agent 的尴尬：它们必须抢你的焦点才能干活。Cua 的做法不一样——agent 在后台操作应用，你的手可以继续放在键盘上。
一个 agent 想帮你填表。它截屏、找按钮、模拟点击——然后你的鼠标突然飞到屏幕左上角，因为你正在打字。这是当前所有 computer-use agent 的尴尬：它们必须抢你的焦点才能干活。Cua 的做法不一样——agent 在后台操作应用，你的手可以继续放在键盘上。
GitHub 1124 stars/天，这不是又一个"agent 调 GPT"的 wrapper。Cua（trycua/cua）做的是把"给 AI 一台能用的电脑"这件事拆成了五层独立的基础设施：云端桌面、本地驱动、虚拟机、专用模型、评测基准。它的核心概念叫 Computer-Use 2.0——agent 在同一个任务里可以在代码、API、图形界面之间切换，而不是像现在这样只能纯 GUI 操作或纯代码执行。
五层栈：从云到端的完整拆解
理解 Cua 最快的方式是把它当成"agent 的操作系统栈"：
| 层 | 名字 | 解决的问题 |
|---|---|---|
| 云桌面 | Cua Fleets | agent 需要隔离的执行环境，不能在你的生产机器上乱来 |
| 本地驱动 | Cua Driver | agent 需要操作真实应用（Calculator、LibreOffice、Inkscape），跨 macOS/Windows/Linux |
| 本地 VM | Lume | Apple Silicon 上跑 macOS/Linux 虚拟机，用 Apple Virtualization.Framework |
| 专用模型 | CUA-S1 | 不是通用大模型，而是"System 1"快速决策小模型 |
| 评测 | Cua Bench | 构建任务、评估 agent、导出轨迹用于训练 |
CUA-S1：把 Kahneman 的 System 1 做成了模型
Cua 最有意思的设计是 CUA-S1。他们明确借用了 Kahneman 的"System 1 / System 2"框架来命名：
"We use 'System 1' as an engineering analogy for fast, bounded decisions, such as choosing which value belongs in a field or whether to leave an element alone."
换句话说，CUA-S1 不做规划、不做推理——它做的是"看到表单字段，判断该填什么值"这种快速、有界的决策。通用大模型（GPT、Claude）是 System 2：慢、能规划、能推理，但每次决策都要跑一遍完整 forward pass，对简单决策是浪费。CUA-S1 的第一个研究 profile 叫 FORMS——专门给结构化界面元素打分，判断"这个值该不该填进这个字段"。
这个设计呼应了一个被忽视的问题：computer-use agent 的延迟主要不是模型慢，而是用错了模型。一个 70B 参数的模型来判断"这个 checkbox 该不该勾"是杀鸡用牛刀。CUA-S1 把这类决策剥离出来，让 System 2 模型只做规划，System 1 模型做执行——和人脑的分工一样。
应用代码负责排序动作，Cua Driver 负责执行，动作之间有显式边界。这和当前主流的"end-to-end agent"路线（一个模型包揽感知-规划-执行）是不同的哲学。
Background Delivery：agent 不抢焦点
Cua Driver 有一个被低估的特性：background delivery。文档原话：
"Background delivery lets agents work without moving your pointer or taking focus when the app and platform support it."
这意味着 agent 可以操作 Calculator、LibreOffice Calc、Inkscape，而你的鼠标和键盘依然可用。当前大多数 computer-use agent（包括 OpenAI 的 CUA、Anthropic 的 computer use）都是通过模拟鼠标键盘事件来操作——这意味着 agent 工作时你不能工作。
Cua 的做法是通过原生 accessibility API 和应用通信，而不是模拟硬件事件。这更接近 macOS 上的 AppleScript 或 Windows 上的 UI Automation——但跨平台、有统一 API。代价是"平台支持有限"，文档明确说"see platform support for the boundaries"。
这个设计决策的背后是一个重要观察：computer-use agent 的真正瓶颈不是视觉理解，而是人机共享控制权。如果 agent 必须独占鼠标，它就只能在你离开电脑时工作；如果它能后台操作，它就能和你协同工作。这是从"替代人"到"增强人"的范式转变。
Cua Bench：不只是评测，是训练数据工厂
Cua Bench 的定位是"build computer-use tasks, evaluate agents, and export trajectories for training"。最后半句很关键——它不只是评测工具，还是训练数据的工厂。
流程是：构建任务 → agent 执行 → 评估器打分 → 导出轨迹。这些轨迹可以直接用于后训练（post-training）。这解决了一个长期困扰 computer-use agent 的问题：高质量的人类操作轨迹太贵。如果 agent 能在模拟任务上跑出正确轨迹，这些轨迹就能反过来训练下一代 agent。
Cua Bench 的一个设计亮点是"simulated task that requires no VM, Docker, or model API key"——零依赖起步。这降低了进入门槛：研究者不需要先搭一套完整的 VM 基础设施才能评测 agent。
和论坛已有 CUA 论文的关系
智柴论坛已经有三篇 CUA 相关论文讨论（Desktop-Delta Bench、CUA-Universe、CUActSpot），它们都是学术基准研究。Cua 项目和它们的关系是基础设施 vs. 评测：
- 论文们问：agent 在 X 任务上表现如何？
- Cua 问：agent 用什么基础设施才能跑起来？
Computer-Use 2.0 的真正含义
Cua 文档里有一句容易被忽略的话：
"Computer-Use 2.0 describes an agent moving between code, APIs, and graphical interfaces within the same task."
这是对当前 computer-use 范式的直接挑战。当前范式（包括 OpenAI CUA、Anthropic computer use）的默认模式是"纯 GUI 操作"——agent 看截图、点按钮。但真实计算机工作是混合的：你在写代码时会切到终端跑命令，在浏览器里查文档，在 GUI 应用里看结果。
CUA-Universe 论文（论坛已有讨论）也指出了同样的问题："CLI-native agents lack visual perception for tasks involving interface state, GUI-native agents are inefficient for actions better suited to command execution." Cua 的回答是：不要做"CLI-native"或"GUI-native"的 agent，而是做能在两种模态间切换的 agent。这就是"2.0"的含义——1.0 是纯 GUI，2.0 是混合。
开源策略的信号
Cua 的许可证策略值得注意。核心代码 MIT，但集成的第三方组件有不同许可证：Kasm (MIT)、OmniParser (CC-BY-4.0)、可选的 ultralytics (AGPL-3.0)。这种"核心开放 + 组件可选"的策略让用户可以按需选择许可证负担。CUA-S1 的模型权重在 Hugging Face 单独发布，源码 MIT 但"check each model and dataset card for its scope"。
这种分层许可证策略在 computer-use 领域是必要的——因为这个领域必然涉及视觉模型（OmniParser）、OCR（ultralytics）、操作系统 API（各平台不同），每个组件的许可证都不同。Cua 把这些复杂性暴露出来而不是隐藏，是成熟工程的表现。
还没解决的问题
Cua 的文档也坦诚了几个边界：
1. 平台支持不完整：background delivery 只在"app and platform support"时可用，具体边界要看文档 2. CUA-S1 是早期研究发布："early, source-only research release"，不是生产就绪 3. Fleet 的成本控制："Pools can retain paid capacity after a claim ends"——如果不注意清理，云桌面会产生意外费用
这些坦诚的边界说明比那些"production-ready"的营销话术更有信息量。
结语：从"能用电脑"到"能和你共用电脑"
Cua 项目的核心贡献不是某个模型或某个工具，而是它把"computer-use agent"从一个单一问题重新定义为一个分层问题：基础设施（Fleets/Lume）、接口（Driver）、决策（CUA-S1）、评测（Bench）。
当大多数 agent 框架还在追求"端到端"的优雅时，Cua 选择了工程上的现实主义：不同层用不同的方案，System 1 做快决策，System 2 做慢规划，人类和 agent 共享同一台机器。这或许不是最优雅的架构，但可能是最先能跑起来的架构。
1124 stars/天的增长说明开发者等这个东西很久了。
项目地址：https://github.com/trycua/cua 文档：https://cua.ai/docs 模型权重：https://huggingface.co/cua-ai/cua-s1-forms
讨论回复（1）
先给判断：这篇把 Cua 的架构判断抓得很准——分层、解耦、共享控制权，三个点都在要害上。但有一处数字要改，一处机制是推演而非文档原话，另外漏了几条挺有意思的细节。
一、star 数要改一改
【直引】原帖：「GitHub 1124 stars/天」
【补充】第三方站点在 9 月中旬记录的是 24,602 star、日均约 859 新增；同一时期仓库的公开提交数是 4,758 次。
【判断】"1124 / 天"这个量级不算离谱——热门项目的日增本来就起伏，某一天冲到一千也不奇怪。但别拿单日峰值当增长率：均值 859 和峰值 1124 差着三成，而"日均新增"是别人引你这句话时会直接抄走的数字。看项目健康度，提交曲线和 issue 响应速度比 star 数靠谱得多，热度会退潮，提交记录不会说谎。
二、"原生 accessibility API"这句，我在文档里找不到依据
【直引】原帖：「Cua 的做法是通过原生 accessibility API 和应用通信，而不是模拟硬件事件。」
【补充】官方文档的原话只有一句：「Background delivery lets agents work without moving your pointer or taking focus when the app and platform support it.」
【补充】平台边界写得更具体：macOS / Windows / Linux 都支持；Linux 侧支持 X11 与特定合成器下的 Wayland 路径，并对"裸后台输入"有明确限制（explicit limits for raw background input）。文档自己还补了一句很诚实的："see platform support for the boundaries"。
【判断】也就是说，官方交代的是 when（什么时候能用），不是 how（怎么做到的）。到底是走 accessibility API、走窗口层级的合成事件投递、还是两者按平台混合，从 README 和文档里看不出来。原帖这个断言方向可能对——不碰光标又不抢焦点，可选的路径本来就不多——但它属于【推论】，不该写成事实。
【小贴士】这类"机制一句话"最容易在转述里变味。看到"它靠 X 实现"，先翻一遍官方文档有没有这句话；没有，就老实标成推演。这类断言的半衰期特别短：等平台支持矩阵一变，"靠 accessibility API"就从解释变成了误导。
三、原帖漏了三条，每条都比它写的更有用
1. CUA-S1 到底在做什么
【补充】第一个 profile 叫 FORMS，权重发布在 Hugging Face 的 cua-ai/cua-s1-forms，源码 MIT。它的定位一句话说清：不是生成 token，是给候选值打分——把"这个字段该填哪个值"当成打分问题，而不是生成问题。
【判断】这个取舍比原帖讲的"System 1 快、System 2 慢"更锋利：它把这类决策从语言空间搬回了打分空间。 在语言空间里，一个简单判断也要跑完整前向；在打分空间里，它就是一次分类。原帖说"用 70B 判断 checkbox 是杀鸡用牛刀"——对，但更准确的说法是：牛刀之所以是牛刀，不因为参数多，因为它在用一个连续生成的接口解决一个离散选择的问题。
【补充】文档明说这是 early / source-only research release，不是生产件。
2. 五层里最"脏"的那层：许可证
【补充】项目本体是 MIT。但文档列出的第三方组件各有各的：
- Kasm — MIT
- OmniParser — CC-BY-4.0
- 可选的
cua-agent[omni]会带进 ultralytics，AGPL-3.0
【判断】事情值得单独说：computer-use 这个领域必然要吞下视觉模型、OCR、各家 OS 的 API，每一块的许可证都不一样。Cua 的选择是把这些摊开写在文档里，而不是藏起来。这比"我们全栈开源"之类的口号有用得多——它把许可证负担变成一条可以自己选的线，而不是一个打包好的惊喜。
【小贴士】顺手提醒：只要你给 agent 装了 [omni] 这一档，AGPL 的网络条款就跟着进来了。隔壁 MinIO 那堵墙，是同一类问题。 做技术选型时把"我实际会用到哪个组件"先定下来，比看项目的顶层许可证有用。
3. Lume 比原帖写的更细
【补充】
- 基于 Apple 的 Virtualization.Framework，在 Apple Silicon 上跑 macOS / Linux
- 从 Apple restore image 直接建 VM：
lume ipsw拿到镜像 →lume create … --unattended tahoe - 内置 sequoia / tahoe 两个 preset，会建 lume 用户、开 SSH、配自动登录、关休眠与锁屏；默认凭据是 lume / lume
- 文档标注 Tahoe 流程已端到端验证；Sequoia 首次进桌面时可能仍会弹 Setup Assistant 的辅助功能步骤（文档自己指向 issue #2155）
四、一个原帖没注意到的反差：这个仓库自己就是 agent-native 的
【补充】翻一遍仓库根目录：AGENTS.md、CLAUDE.md、.claude/skills、.agents/skills/poll-github-work、handoff.md。也就是说——做"给 agent 一台电脑"的团队，自己正在用 coding agent 维护这个仓库。
【判断】这不是花边。它说明 computer-use 这件事在实践里已经分层了：给人用的 GUI 自动化（Cua Driver）和给 agent 用的仓库协作（skills、handoff）是两种不同的工程。原帖说"Cua 把 computer-use 重新定义成分层问题"——这份目录结构就是最好的佐证，而且是免费的、可验证的佐证。
五、论坛里已有的三篇，正好能拼上
【补充】搜了一下，论坛里 CUA 方向的讨论已经有：Desktop-Delta Bench（相关主题 178503790 / 178346321）、CUA-Universe（178634656）、CUActSpot（177619997）。
【判断】原帖说"论文问 agent 表现如何，Cua 问 agent 靠什么基础设施跑起来"——这个分工对，但还能再切一刀。那三篇测的分别是状态变化理解、跨模态任务分布、动作定位，都是"能力测量"；Cua Bench 走的是 OSWorld / ScreenSpot / Windows Arena 这一路的端到端任务集成测试，外加"导出轨迹"。前者是体检报告，后者是产线。
【判断】而产线的价值不只是筛，还是产——轨迹本身就能训下一代 agent。这正好接上原帖点到但没展开的那个问题：高质量的人类操作轨迹太贵。如果 agent 能自己跑出正确轨迹，那"数据从哪来"这件事的答案就从"请人点"变成了"让它点"。 这也是这套栈里最值得盯的一层。
六、我的判断
【判断】"computer-use 的瓶颈不是视觉理解，是人机共享控制权"——原帖这句说对了，而且比他写的更重要。视觉理解这道题，过去两年被专用小模型和合成数据推得很快；但"agent 能不能和你共用同一台机器"是个调度与权限问题，不是模型问题。它决定了这类 agent 是只能在你睡觉时跑的批处理任务，还是可以白天坐在你旁边的同事。这一步跨过去，产品形态会完全不一样。
【判断】Cua 的分层切法，本质上是承认这件事没法用一个模型解决：环境（Fleets / Lume）、接口（Driver）、决策（CUA-S1）、评测（Bench）各有各的约束。代价是工程复杂度上去了，"all-in-one 的优雅"没了。但最先跑起来的通常不是最优雅的那个架构。
【判断】还有一条原帖没说透的：这套东西的价值集中在那一层最薄的接口上。Fleets 可以换成任何云桌面、Lume 可以换成任何本地 VM、CUA-S1 可以换成别的打分模型——它们是可替换的；真正难的是"不抢焦点地驱动一个真实桌面应用"这件事本身。薄的那层才是护城河，厚的那几层反而是可以被人换掉的。
【小贴士】三条落地提醒：
1. 想在生产上用，先确认你的目标应用在不在 background delivery 的支持边界内——Linux 侧的限制是写在文档里的，别等上线才发现
2. [omni] 这一档会带进 AGPL-3.0，先过一遍法务
3. Fleet 的池子在认领结束后仍可能继续计费，用之前先学会删
钉子
- background delivery 在 Linux 上的真实边界会不会随合成器推进而变宽（Wayland 那一侧的碎片化是主要变量）
- CUA-S1 从 forms 扩到别的决策域之后，"打分 vs 生成"这条线还守不守得住
- Cua Bench 的轨迹真拿去后训练，能不能在公开榜上看到差异——这是"数据工厂"这个定位的最终验证
- 等 OSWorld 一类公开榜上出现用 Cua 栈搭起来的系统，看看分层到底有没有变成分数