把「选哪个」交给 70 万参数

让智能体填一张表单，常见做法是每遇到一个字段就把屏幕状态和问题发给大模型，等它回一段文本，再解析出该填什么。这套流程慢、贵，而且脆——解析环节本身就是失败来源。

CUA-S1-FORMS 换了个切分方式。给定一个 UI 元素与一组带类型的候选选项（每个文档实体一个选项，外加 check、click、skip 三个固定动作），模型在一次前向传播里为每个选项输出一个概率。它不生成文本，所以没有解析环节；每个可操作元素独立且批量并行打分，一次推理就能覆盖整张表单。

模型不决定顺序

值得注意的是职责边界：模型只负责打分与选择，执行顺序（先填写、再勾选、最后点一次提交）由下游代码决定。产出的计划交给 Cua Driver 执行，对应 set_value 与 click 两类动作。

这种切分让模型变得极小：706,048 个可训练参数，检查点约 2.8MB，模型、训练代码与数据集以 MIT 许可开源。它的输入输出契约与 TypeSafe 的 Jev 一致——同一套「对预定义选项打分」的接口，说明这类 System One 模型的模式正在被社区复用，而不是各写各的。

不生成文本的模型没有解析失败这一说：输出直接是概率，程序可以直接消费。

什么时候值得换成这种架构

适合的场景有共同特征：动作空间可以先定义完、字段类型相对固定、重复量足够大。不满足这些特征时，硬套小模型反而会带来更多维护成本——每加一种表单就要重训或调整动作空间。

  • 先定义动作空间：哪些实体要填、哪些是固定动作（check / click / skip）；
  • 再定执行与重试策略：顺序、校验、失败回滚都要由你的代码负责；
  • 最后才是训练与替换：用真实表单数据评估它相对当前提示词方案的成功率与延迟。

Cua 主仓库目前约有 2.33 万 star，官方也在公开征集 CUA-S1 系列的下一个专业化方向。这个信号比单个模型更值得留意：如果「大模型负责理解与规划、小模型负责高频决策」的分工被验证，更多流程拆分会沿着同样的路径发生。