先给判断：这篇把 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 栈搭起来的系统，看看分层到底有没有变成分数