圈内内参｜这期讲 trycua/cua 这个仓库怎么把“规划”从模型里拆出去。结论先放：CUA-S1 干的是打分和小决策的活，动作顺序和复杂规划回到上层代码和 Cua 的桌面/驱动栈里管。这套拆分和仓库里 MIT、FSL-1.1、AGPL 杂着来的许可编排，控制的是同一件事。这篇没有匿名信源，材料全部来自仓库公开文本、许可文件、项目自己的说明和 Hugging Face 模型卡，大部分标（确认），我的判断标（分析）。
模型那层最值得注意的，是它不肯做什么
现在圈内很多 agent 路线都在往一个方向加码：模型自己拆任务、自己选工具、自己 loop，完整规划吞进上下文。CUA-S1 不是这条路，而且它把“不是这条路”写进了项目自己的说明里。
仓库把 "System 1" 当工程类比，描述快速、边界明确的小决策——某个字段该填什么值、某个界面元素要不要保持不变。项目自己说了这不是严格的模型架构分类，也不承担通用 agent 的规划与推理职责（确认）。一个模型项目公开声明自己不规划、不推理，这几乎等于反向声明：别拿一个大模型来理解这个东西。
第一个研究方向落在表单场景。模型对结构化界面元素和文档取值打分来做决策，不采用逐 token 生成回答（确认）。这句话拆开看比表面重：一般模型卡强调自己多能生成，这边强调的却是不生成。输出层是判别式/打分的路子，模型被做成一个快速判断器，套在上层已经切好的动作边界里用。
动作边界在这个仓库里不是抽象口号。CUA-S1 流程里，动作先后顺序由上层应用代码编排，可选的 Cua Driver 集成负责在显式动作边界内执行动作（确认）。这是整条线的核心机制：模型只负责在已经被切好的边界内做决定，边界谁切？上层代码切。这个项目把大多数 agent 框架里属于模型的“接下来做什么”拿出来，放回了代码里。不是没有规划，是规划不属于可分发的那层模型。
（分析）这比单纯把模型做小有信号量。相当于在工程层面对模型说：你不需要知道整个任务长什么样，只需要在给定的小框里给出当前这一跳的答案。带来的不只是轻量，是可控。一个只打分的模型，加一层显式编排的动作图，出错之后怎么回滚、怎么审计、怎么切掉，比全自主 loop 清楚得多。
接上桌面和驱动，边界就变得很具体
CUA-S1 自己不带执行。执行是 Cua 生态另一摊事：Cua Spaces 给完整桌面环境，Cua Driver 管输入执行。Spaces 底层是本地构建的 macOS 虚拟机或 Linux/Omarchy 镜像，跑在用户自己的 Mac、自有机器或自有云账户上（确认）。个人免费，Pro 18 美元一个月，Teams 每席位 30 美元起（确认）。稀奇的是它把“用户自己的机器/云”放进了默认路径里——不是运营方托管一大片云桌面给你用，是让你在自己环境里跑。
Teleport 那块更明显。已登录的 Chrome、Slack 迁入 Space 保持登录态，会话存放在本机加密的 Cua Keyvault，用户批准后才送达 Space（确认）。Keyvault 的位置很关键：本机、加密、批准后才出去。agent 要用的登录态锁在用户手里，不默认同步云端。多人协作也一样，用户和 agent 在同一桌面上各自独立光标，用户随时接管再交回（确认）。这套设计给 agent 的动作空间加了很实的约束：你能点、能输入，但用户的手就悬在旁边。
Cua Driver 像执行边界上的插头。覆盖 macOS、Windows、Linux，通过 CLI、MCP 或类型化 SDK 接入，平台支持时后台投递，不移动用户指针也不抢占焦点（确认）。“不移动指针、不抢占焦点”听着像细节，在 agent 执行里其实是边界问题：执行器的操作不粗暴打断用户正在做的事。这和前面说的 action boundary 是一路的——动作空间被人为收窄，收窄到能安全执行的那个范围。
还有一条必须记一笔：仓库把 Computer-Use 2.0 定义为 agent 在同一任务中在代码、API 与图形界面之间切换操作（确认）。这个定义本身没把“切换”归给模型。切换是动作编排问题，在这套设计里按他们自己的架构说明，还是上层的活。一个正在跑表单任务的打分模型，不需要理解什么叫“切去 API 层”——它只需要在给定字段上给一个判断。
许可那摊事，是同一套控制逻辑的反面
前面是工程控制，许可结构就是分发控制，切得相当不整齐。主仓库代码 MIT（确认）。CUA-S1 源码也是 MIT，但模型权重单独托管在 Hugging Face，配了说明适用范围、局限和许可条件的模型卡与数据集卡（确认）。已经是在做切分：源码开放，权重和数据集另走一套，配自己的约束说明。源码给你看，权重不跟源码同一个包裹发。
再往外，Cua Spaces 和 Cua Driver Bench 用 FSL-1.1-MIT，禁止用于竞争的托管服务，每次发布两年后自动转 MIT（确认）。这条有点意思：允许你用，也承诺将来转 MIT，但当下最直接的商业对手不能拿去开托管服务。不稀奇，但放在一个主流标签是“开源”的项目里，等于把“你现在能用它做什么”和“两年后能拿它做什么”用条款切开了。
更绕的是可选包 cua-perception，不属于 MIT。它组合了 AGPL-3.0-only 的 OmniParser 模型产物、Apache-2.0 的 PP-OCR 模型产物、以及单独打包的 ONNX Runtime；通过网络分发或托管可能触发 AGPL-3.0 源码义务（确认）。只想用主流程，大概是 MIT；捡起感知这个可选项，许可性质就变了，分发和托管都可能背上 AGPL 的事。我不是律师，不下法律判断，只把仓库自己标的摆出来。这条界限之硬，和 CUA-S1 不肯做规划，是同一种分法：核心可以薄、边界必须厚。
旧包那条也值得记。仓库已经把 cuabot（npm）标记为不要运行，原因是已知安全问题，同时停止维护 cua-computer、cua-computer-server、cua-agent 和 cua-som 等旧包，给出替代方案（确认）。一个同时维护 Spaces、Driver、Lume、CUA-S1、Cua Bench 五条线的仓库，已经动手淘汰掉一批早期包，自己也在收敛边界。CITATION.cff 建议引用 2025 年发布的软件 Cua，并注明实验所用的 release 或 commit 以便复现（确认）。一个靠边界立命的项目，连引用都要求钉住版本。小信号，不算大判断。
（分析）把规划踢回上层代码不是新思路。很多做 GUI agent 的团队在工程实现里都这么做，只是没把边界划得这么外露。Cua 的不同在于它把这件事同时体现在模型设计、执行栈、用户接管机制和许可条款里，四处写的是同一个字：控制。我不打算替它判断这条路能不能成，这不是我要记的范围。值得记下的只是这个截面——2026 年秋天这个时点上，一个 3 万 star 的仓库，把 agent 模型做成了不规划的快速决策器，然后用大量机制去补“谁来规划”这层。
几个值得盯的信号，不下注，只列出来一起看：一、CUA-S1 下一步研究方向会不会继续守在“打分决策”壳里，还是开始引入生成式输出——只要一动，这个项目最核心的边界就变了。二、Cua Bench 任务类型会不会从表单往多步规划扩展，如果测试任务本身要求复杂规划，上层编排那套就要被反复检验。三、FSL-1.1-MIT 第一批发布版本什么时候满两年，看它到承诺时间是真的转 MIT 还是继续往后挪。四、cua-perception 里那组 AGPL-3.0 组合会不会在后续 release 里被拆掉，或者干脆从可选里除名。这四条都是公开可查、可以回来看的。本期到这，有更准确信源或读许可证经验的同学，欢迎匿名补充。