把 Computer Use 的手开源出来Cua 的三件基础设施怎么分工TL;DR 速览本篇只讲手不讲脑决策模型怎么选小模型打分 vs 大模型生成已经在另一篇里拆过这里只讲怎么让 Agent 真的碰到电脑Cua Driver跨macOS / Windows / Linux操作原生应用与浏览器CLI MCP 类型化 SDK三条接入路径后台投递能在不移动指针、不抢窗口焦点的前提下操作平台支持有明确边界Cua Fleets云端Linux 桌面池 Sandbox SDK与本地沙箱共用 SDK 但凭证、镜像、运行时要求不同池子在认领结束后仍可能计费清理步骤是必读项Cua Bench最轻的入门路径——只要 Python 3.12/3.13 uv不要 VM、不要 Docker、不要模型 API Key跑通任务拿到 reward 就能换自己的 agent 进来量授权是混合的主项目MITKasmMIT、OmniParserCC-BY-4.0而可选的 OmniParser 集成会拉进 AGPL-3.0 的 ultralytics实查★25,799/ created2025-01-31——不是新项目别写成刚开源Cua 的定位一句话说清给 AI Agent 一台能用的电脑。它提供的不是模型是能力层——桌面自动化、隔离的云端桌面、本地 macOS 虚拟机以及评测 Computer Use Agent 的基准。仓库 ★25,799主项目 MIT。先划清边界Cua 里有一个叫 CUA-S1 的决策模型走的是小模型对结构化元素打分、而不是逐 token 生成的路线。这条路线在工程上的结论跟另一篇里拆过的那套是同一个方向所以本文不重复讲它。这篇只讲三件基础设施Driver手、Fleets环境池、Bench度量。这三件是任何 Computer Use 项目都会遇到、但很少有人一次讲清的部分。一、Driver把操作原生应用变成可调用的工具Cua Driver 解决的是最基础也最麻烦的一层让 Agent 能看能操作原生桌面应用而且是在三个操作系统上都能。接入路径有三条对应三种不同的工程形态路径适合谁特点CLI快速验证、脚本化调用命令直接调最容易上手MCP已经在用 agent CLI 的人接进 Claude Code / Codex / Cursor 这类工具类型化 SDK要写产品级集成有类型约束便于工程化三条路径的价值在于它承认了一个现实做 Computer Use 的人分两类——一类在验证能不能做成一类在把它做成产品。前者需要的是五分钟能跑一下后者需要的是能写进代码里并有类型检查。同时提供 CLI 和类型化 SDK等于把这两类人都接住了。Driver 里最有意思的能力是后台投递。官方描述是当应用和平台支持时Agent 可以在不移动你的指针、不抢窗口焦点的前提下完成操作。并且明确说明平台支持有边界需要查文档。为什么这个能力重要因为它把 Computer Use 从演示推向日常可用不抢焦点意味着你可以同时干别的。传统的自动化方案一执行就接管你的鼠标键盘机器不能用了能后台投递就变成它在那边干活你在这边干活。不移动指针意味着操作是可并行的。多个 Agent 会话同时操作不同的应用窗口才有意义。同时要把它的边界看明白官方没有把后台投递写成无条件能力而是明确标注取决于应用与平台。这是负责任的做法也意味着你在选型时必须先拿目标应用实测一遍——同样一套代码在不同应用上可能是后台静默完成也可能是直接接管桌面。安装方式三条命令按平台选# macOS / Linux/bin/bash-c$(curl-fsSLhttps://cua.ai/driver/install.sh)# Windows (PowerShell)irmhttps://cua.ai/driver/install.ps1|iex二、第一个能验证的结果让 Agent 操作计算器Driver 官方给的入门目标是这个把你常用的 agent 接上让它去计算器里算6 × 7并且验证应用显示的是 42。为什么这个例子设计得好因为它同时验证了完整闭环的四段发现应用——能不能找到并启动计算器识别元素——能不能定位到数字与运算符按钮执行操作——能不能真的点下去验证结果——能不能读回界面状态并确认正确第 4 段是分水岭。大多数 Computer Use 演示只做到点了按钮但Agent 实际执行任务时必须能自己确认结果对不对——否则任务成功与否只能靠人看。一个能读回自己操作结果的 Agent才具备自动重试和失败上报的能力。换成自己的场景时建议把入门任务设计成同样结构找一个有明确可验证结果的操作算一个数、改一个单元格、把一个文件存到指定位置先跑通操作 → 读回 → 判定这四步再往上叠多步骤任务。跳过验证这步直接做复杂任务会在出问题时无从定位。三、Fleets云桌面池以及那个计费坑Cua Fleets 提供的是隔离的云端桌面。工作机制是Fleet 维持沙箱容量你的代码从池子里认领一台桌面然后用 Sandbox SDK 在里面跑命令、截图、操作应用。这里有一个必须提前知道的计费陷阱官方在文档里明确写了池子在认领结束后仍然可能保有付费容量。也就是说——“我认领用完了不等于不再计费”。这是云沙箱类服务里最典型的一类坑。池子为了能快速响应下一次认领会预热并保留一定量的资源这些资源的存在成本不因为你用完了就消失。所以官方文档把清理步骤列为教程的必读项而不是可选提示。两条实操建议把清理写进代码而不是写进文档。用try/finally这类结构保证认领一定被释放别指望记得手动删。给池子设上限。先从小容量开始跑通全流程含清理确认了一遍完整生命周期之后再扩容。另一个关键差异在本地与云端之间维度本地沙箱云端 FleetsSDK共用 Sandbox SDK共用 Sandbox SDK凭证本地自管需要 Fleet 凭证镜像你自己的环境平台提供的镜像运行时要求受你本机限制由平台环境决定计费你本机的电按容量与时长含池子保留共用 SDK这件事的取舍值得说清好处是代码可以在本地和云端之间迁移先在本地跑通再上云代价是两边的行为不完全一致——镜像、凭证、运行时依赖都不同。所以本地跑通不等于云端能跑上线前必须在云端环境里完整走一遍。四、Bench最轻的入门路径这是三件里门槛最低的一件也是最适合用来量一下自己方案的一件uv toolinstallcua-bench[browser]uv tool run--fromcua-bench[browser]playwrightinstallchromium前提只有两个Python 3.12 或 3.13以及 uv。官方明确说明它不需要 VM、不需要 Docker、也不需要模型 API Key——起步用的是模拟任务。入门路径设计得很聪明先创建一个任务跑它的参考解法确认评测器给出reward为1.0然后再自己动手做同一个任务。为什么先跑参考解法因为这一步验证的是评测环境本身——如果参考解法都拿不到满分问题在环境或任务定义不在你的 Agent。这是评测类工具的标准做法能省掉大量到底是谁错了的排查时间。跑通之后意义在于它可以换成你自己的 agent 和模型进来量。也就是说它提供的是一套可复用的度量框架任务定义、评测器、轨迹导出。轨迹导出这一项值得单独提。能导出轨迹意味着这些数据可以用于训练——对做 Computer Use 的团队来说基准测试的另一半价值是数据生产。这也是这类工具和纯 benchmark 的区别。五、别忽略 Lume本地 VM 那条路除了上面三件Cua 里还有一个独立组件Lume在 Apple Silicon 上用 Apple 的 Virtualization.Framework 创建和管理本地 macOS 与 Linux 虚拟机官方给的入门路径是从 Apple 恢复镜像创建一个 macOS Tahoe VM启动并通过 SSH 连进去。它解决的是我想先在本地验证、不想开云资源这个需求。与 Fleets 的云桌面形成互补本地 VM 用来开发和验证云池用来跑规模和并发。但注意它的平台前提Apple Silicon Apple 的虚拟化框架所以 Windows 和 Linux 机器用不上这条路。如果你的开发机不是 Mac本地验证这一环就得另想办法。我给桌面自动化这类能力做接入时第一件事不是跑复杂任务而是先找一个有明确可验证结果的小动作跑通把它能不能读回自己的操作结果这件事确认掉。这一步过了后面的问题都好定位。我的验证清单和几个平台的实测记录攒在 墨衍 里跟选题素材放一起下次接新工具时直接照着走。六、授权拼图MIT 里混着 CC-BY-4.0 和 AGPL-3.0这一节是做产品集成前必须过的一遍。Cua 的授权结构不是一个 MIT 走到底组件授权主项目MITKasmMITOmniParserCC-BY-4.0可选cua-agent[omni]里的 ultralyticsAGPL-3.0四个里前三个都好处理第四个是雷。AGPL-3.0 的特性是通过网络提供服务时也需要向使用者提供源码。对闭源 SaaS来说这是一个实质性的约束——因为你正是通过网络提供服务的那一方。关键点在可选两个字上。官方把 ultralytics 放在可选依赖里cua-agent[omni]也就是你不装这个 extra它就不在你的依赖树里。所以处置方式很清楚确认自己有没有装[omni]这个 extra。如果装了且你要做闭源产品——要么去掉这个 extra用别的元素识别方案要么评估 AGPL 的合规要求。如果装了但只在内部用——AGPL 的约束通常不触发但**内部使用的边界会随着产品形态变化**比如后来对外提供服务所以这个决定值得留个记录别只在某个人脑子里。CC-BY-4.0 那一项则简单得多它要求署名不传染。所以如果你的产品里用了 OmniParser记得在合适位置保留署名信息——这类要求容易被忽略但排查成本很低属于顺手就该做的事。另外提醒一个容易踩的坑CUA-S1 的模型权重单独托管在 Hugging Face源码是 MIT但权重可能有自己的授权。官方的说法是检查每个模型和数据集卡片的范围、限制和特定授权。代码 MIT和模型 MIT是两件事不能互相推论——这在所有代码开源 权重另发的项目里都成立。七、三件怎么配合用把三件放回一个完整的工作流里阶段用哪件目的开发验证LumeMac或本地沙箱在自己机器上跑通不产生云费用能力度量Cua Bench用标准任务量自己的 agent先确认评测环境本身是对的接入真实应用Cua Driver通过 CLI 或 SDK 操作真实软件验证后台投递在目标应用上成不成立跑规模Cua Fleets上云桌面池并确保清理逻辑在代码里这套分工里最该先做的是第二步。原因是在你投入集成工作之前你需要一个可复现的数字告诉你当前方案到底处于什么水平——否则后面所有优化都是在没有基线的情况下凭感觉调。一个能跑的基准比一套漂亮的架构图有用。最后说回它的定位。这轮 Agent 基础设施的竞争里Models 那一层最热闹但真正决定能不能落地的往往是手和环境这一层——模型能不能点对按钮、环境能不能被安全隔离和快速回收。Cua 把这两层开源出来价值不在于它自己做得多好而在于它让Computer Use 需要哪些组件这个问题有了一个可以照着抄的答案。
把 Computer Use 的手开源出来Cua 的三件基础设施怎么分工TL;DR 速览本篇只讲手不讲脑决策模型怎么选小模型打分 vs 大模型生成已经在另一篇里拆过这里只讲怎么让 Agent 真的碰到电脑Cua Driver跨macOS / Windows / Linux操作原生应用与浏览器CLI MCP 类型化 SDK三条接入路径后台投递能在不移动指针、不抢窗口焦点的前提下操作平台支持有明确边界Cua Fleets云端Linux 桌面池 Sandbox SDK与本地沙箱共用 SDK 但凭证、镜像、运行时要求不同池子在认领结束后仍可能计费清理步骤是必读项Cua Bench最轻的入门路径——只要 Python 3.12/3.13 uv不要 VM、不要 Docker、不要模型 API Key跑通任务拿到 reward 就能换自己的 agent 进来量授权是混合的主项目MITKasmMIT、OmniParserCC-BY-4.0而可选的 OmniParser 集成会拉进 AGPL-3.0 的 ultralytics实查★25,799/ created2025-01-31——不是新项目别写成刚开源Cua 的定位一句话说清给 AI Agent 一台能用的电脑。它提供的不是模型是能力层——桌面自动化、隔离的云端桌面、本地 macOS 虚拟机以及评测 Computer Use Agent 的基准。仓库 ★25,799主项目 MIT。先划清边界Cua 里有一个叫 CUA-S1 的决策模型走的是小模型对结构化元素打分、而不是逐 token 生成的路线。这条路线在工程上的结论跟另一篇里拆过的那套是同一个方向所以本文不重复讲它。这篇只讲三件基础设施Driver手、Fleets环境池、Bench度量。这三件是任何 Computer Use 项目都会遇到、但很少有人一次讲清的部分。一、Driver把操作原生应用变成可调用的工具Cua Driver 解决的是最基础也最麻烦的一层让 Agent 能看能操作原生桌面应用而且是在三个操作系统上都能。接入路径有三条对应三种不同的工程形态路径适合谁特点CLI快速验证、脚本化调用命令直接调最容易上手MCP已经在用 agent CLI 的人接进 Claude Code / Codex / Cursor 这类工具类型化 SDK要写产品级集成有类型约束便于工程化三条路径的价值在于它承认了一个现实做 Computer Use 的人分两类——一类在验证能不能做成一类在把它做成产品。前者需要的是五分钟能跑一下后者需要的是能写进代码里并有类型检查。同时提供 CLI 和类型化 SDK等于把这两类人都接住了。Driver 里最有意思的能力是后台投递。官方描述是当应用和平台支持时Agent 可以在不移动你的指针、不抢窗口焦点的前提下完成操作。并且明确说明平台支持有边界需要查文档。为什么这个能力重要因为它把 Computer Use 从演示推向日常可用不抢焦点意味着你可以同时干别的。传统的自动化方案一执行就接管你的鼠标键盘机器不能用了能后台投递就变成它在那边干活你在这边干活。不移动指针意味着操作是可并行的。多个 Agent 会话同时操作不同的应用窗口才有意义。同时要把它的边界看明白官方没有把后台投递写成无条件能力而是明确标注取决于应用与平台。这是负责任的做法也意味着你在选型时必须先拿目标应用实测一遍——同样一套代码在不同应用上可能是后台静默完成也可能是直接接管桌面。安装方式三条命令按平台选# macOS / Linux/bin/bash-c$(curl-fsSLhttps://cua.ai/driver/install.sh)# Windows (PowerShell)irmhttps://cua.ai/driver/install.ps1|iex二、第一个能验证的结果让 Agent 操作计算器Driver 官方给的入门目标是这个把你常用的 agent 接上让它去计算器里算6 × 7并且验证应用显示的是 42。为什么这个例子设计得好因为它同时验证了完整闭环的四段发现应用——能不能找到并启动计算器识别元素——能不能定位到数字与运算符按钮执行操作——能不能真的点下去验证结果——能不能读回界面状态并确认正确第 4 段是分水岭。大多数 Computer Use 演示只做到点了按钮但Agent 实际执行任务时必须能自己确认结果对不对——否则任务成功与否只能靠人看。一个能读回自己操作结果的 Agent才具备自动重试和失败上报的能力。换成自己的场景时建议把入门任务设计成同样结构找一个有明确可验证结果的操作算一个数、改一个单元格、把一个文件存到指定位置先跑通操作 → 读回 → 判定这四步再往上叠多步骤任务。跳过验证这步直接做复杂任务会在出问题时无从定位。三、Fleets云桌面池以及那个计费坑Cua Fleets 提供的是隔离的云端桌面。工作机制是Fleet 维持沙箱容量你的代码从池子里认领一台桌面然后用 Sandbox SDK 在里面跑命令、截图、操作应用。这里有一个必须提前知道的计费陷阱官方在文档里明确写了池子在认领结束后仍然可能保有付费容量。也就是说——“我认领用完了不等于不再计费”。这是云沙箱类服务里最典型的一类坑。池子为了能快速响应下一次认领会预热并保留一定量的资源这些资源的存在成本不因为你用完了就消失。所以官方文档把清理步骤列为教程的必读项而不是可选提示。两条实操建议把清理写进代码而不是写进文档。用try/finally这类结构保证认领一定被释放别指望记得手动删。给池子设上限。先从小容量开始跑通全流程含清理确认了一遍完整生命周期之后再扩容。另一个关键差异在本地与云端之间维度本地沙箱云端 FleetsSDK共用 Sandbox SDK共用 Sandbox SDK凭证本地自管需要 Fleet 凭证镜像你自己的环境平台提供的镜像运行时要求受你本机限制由平台环境决定计费你本机的电按容量与时长含池子保留共用 SDK这件事的取舍值得说清好处是代码可以在本地和云端之间迁移先在本地跑通再上云代价是两边的行为不完全一致——镜像、凭证、运行时依赖都不同。所以本地跑通不等于云端能跑上线前必须在云端环境里完整走一遍。四、Bench最轻的入门路径这是三件里门槛最低的一件也是最适合用来量一下自己方案的一件uv toolinstallcua-bench[browser]uv tool run--fromcua-bench[browser]playwrightinstallchromium前提只有两个Python 3.12 或 3.13以及 uv。官方明确说明它不需要 VM、不需要 Docker、也不需要模型 API Key——起步用的是模拟任务。入门路径设计得很聪明先创建一个任务跑它的参考解法确认评测器给出reward为1.0然后再自己动手做同一个任务。为什么先跑参考解法因为这一步验证的是评测环境本身——如果参考解法都拿不到满分问题在环境或任务定义不在你的 Agent。这是评测类工具的标准做法能省掉大量到底是谁错了的排查时间。跑通之后意义在于它可以换成你自己的 agent 和模型进来量。也就是说它提供的是一套可复用的度量框架任务定义、评测器、轨迹导出。轨迹导出这一项值得单独提。能导出轨迹意味着这些数据可以用于训练——对做 Computer Use 的团队来说基准测试的另一半价值是数据生产。这也是这类工具和纯 benchmark 的区别。五、别忽略 Lume本地 VM 那条路除了上面三件Cua 里还有一个独立组件Lume在 Apple Silicon 上用 Apple 的 Virtualization.Framework 创建和管理本地 macOS 与 Linux 虚拟机官方给的入门路径是从 Apple 恢复镜像创建一个 macOS Tahoe VM启动并通过 SSH 连进去。它解决的是我想先在本地验证、不想开云资源这个需求。与 Fleets 的云桌面形成互补本地 VM 用来开发和验证云池用来跑规模和并发。但注意它的平台前提Apple Silicon Apple 的虚拟化框架所以 Windows 和 Linux 机器用不上这条路。如果你的开发机不是 Mac本地验证这一环就得另想办法。我给桌面自动化这类能力做接入时第一件事不是跑复杂任务而是先找一个有明确可验证结果的小动作跑通把它能不能读回自己的操作结果这件事确认掉。这一步过了后面的问题都好定位。我的验证清单和几个平台的实测记录攒在 墨衍 里跟选题素材放一起下次接新工具时直接照着走。六、授权拼图MIT 里混着 CC-BY-4.0 和 AGPL-3.0这一节是做产品集成前必须过的一遍。Cua 的授权结构不是一个 MIT 走到底组件授权主项目MITKasmMITOmniParserCC-BY-4.0可选cua-agent[omni]里的 ultralyticsAGPL-3.0四个里前三个都好处理第四个是雷。AGPL-3.0 的特性是通过网络提供服务时也需要向使用者提供源码。对闭源 SaaS来说这是一个实质性的约束——因为你正是通过网络提供服务的那一方。关键点在可选两个字上。官方把 ultralytics 放在可选依赖里cua-agent[omni]也就是你不装这个 extra它就不在你的依赖树里。所以处置方式很清楚确认自己有没有装[omni]这个 extra。如果装了且你要做闭源产品——要么去掉这个 extra用别的元素识别方案要么评估 AGPL 的合规要求。如果装了但只在内部用——AGPL 的约束通常不触发但**内部使用的边界会随着产品形态变化**比如后来对外提供服务所以这个决定值得留个记录别只在某个人脑子里。CC-BY-4.0 那一项则简单得多它要求署名不传染。所以如果你的产品里用了 OmniParser记得在合适位置保留署名信息——这类要求容易被忽略但排查成本很低属于顺手就该做的事。另外提醒一个容易踩的坑CUA-S1 的模型权重单独托管在 Hugging Face源码是 MIT但权重可能有自己的授权。官方的说法是检查每个模型和数据集卡片的范围、限制和特定授权。代码 MIT和模型 MIT是两件事不能互相推论——这在所有代码开源 权重另发的项目里都成立。七、三件怎么配合用把三件放回一个完整的工作流里阶段用哪件目的开发验证LumeMac或本地沙箱在自己机器上跑通不产生云费用能力度量Cua Bench用标准任务量自己的 agent先确认评测环境本身是对的接入真实应用Cua Driver通过 CLI 或 SDK 操作真实软件验证后台投递在目标应用上成不成立跑规模Cua Fleets上云桌面池并确保清理逻辑在代码里这套分工里最该先做的是第二步。原因是在你投入集成工作之前你需要一个可复现的数字告诉你当前方案到底处于什么水平——否则后面所有优化都是在没有基线的情况下凭感觉调。一个能跑的基准比一套漂亮的架构图有用。最后说回它的定位。这轮 Agent 基础设施的竞争里Models 那一层最热闹但真正决定能不能落地的往往是手和环境这一层——模型能不能点对按钮、环境能不能被安全隔离和快速回收。Cua 把这两层开源出来价值不在于它自己做得多好而在于它让Computer Use 需要哪些组件这个问题有了一个可以照着抄的答案。
