9 月 19 日，Cua 把自家第一个「System One」模型挂上了 Hugging Face，文件名 cua-s1-forms。参数 706,048，盘上 2.8MB，只干一件事：看一眼表单里的某个字段，再决定要不要从文档里挑一个值填进去。模型卡给的数字是合成测试 99.95%、真实表单 100%。
中英文圈这几天转的就是这几个数字。中文侧的说法基本是「70 万参数正在挑战千亿参数的大模型」，没有人把权重下下来自己跑过。
我跑了。官方的测试集 test.jsonl 一共 24,370 条决策，我全量过了一遍：24,359 条正确，错了 11 条，99.9549%。声明属实。
但同一份权重，换一批它没见过的字段名，就是另一个故事：我自建了 23 个域外字段，它有 21 次直接选择放弃，平均置信度 0.999。不是「拿不准」，是非常确定地不填。
这两件事都值得摊开说。
一个不做推理的模型在做什么
先说定位。Cua 这家公司做的是「让 Agent 操作真实电脑」的基础设施，cua-driver 负责读界面的无障碍树、发点击和按键。表单填写是这条链路上最琐碎的一环：一张表十几个字段，每个字段要判断「该填哪个值、该不该勾、该不该点、还是什么都不做」。用通用大模型逐字段推理当然能做，但一次表单几十次 API 调用，成本和延迟都不划算。
CUA-S1 的思路是把这件事降级成一个分类问题：不看截图，不做自回归，一次前向出分。
它的输入是两段纯文本。第一段叫 context，描述当前这一个界面元素，最多 224 字节：
TASK fill the form from the document, then submit
FORM Test Insurance - Auto Claim Form
ELEMENT Edit "Policy #" value=""第二段是选项列表，每个选项最多 96 字节：文档里提前抽出来的每个「标签：值」各成一条 fill，再加上三个固定动作。
| 选项 | 含义 | 谁来执行 |
|---|---|---|
fill <文档标签>: <值> |
把这个文档实体写进当前字段 | 下游代码排好顺序后逐步下发 |
check |
勾上这个复选框 | 同上 |
click |
点这个控件（提交类按钮） | 同上，默认只放行标签恰好是 Submit 的 |
skip |
什么都不做 | —— |
模型输出的只是一个概率分布。argmax 选出选项，剩下的「先填、再勾选、最后提交」由普通代码决定。这一点很关键：模型没有多步规划能力，也不需要。
这套「一次前向、只做选择、不做生成」的思路来自 TypeSafe 的 Jev —— 我们此前拆过那个模型背后的浏览 Agent，也在端到端实测里见过它的静默假成功。CUA-S1 是这条路线上的第一批「单任务」变体：不做通用 agent，只做填表。
内部结构比想象的还小：字节级 embedding（257 × 128）加两层 4 头 transformer 编码 context，另用一个单层 transformer 编码每个选项，最后用一个 option-attention 头把两者打成一组分数。128 维的 query、key、value，除以 sqrt(128)。没有分词器，没有词表，输入直接按 UTF-8 字节切，超出上限就截断。
我在一台装不了 torch 的机器上把它跑了起来
先说方法，因为这篇的可信度全在这里。
我的工作沙盒是 aarch64 的 Alpine Linux。torch 在这个平台上没有可用的轮子（PyPI 只有 glibc 的 aarch64 构建），onnxruntime 同样装不上，官方仓库要求 uv sync 拉一整套依赖跑测试，这条路直接走不通。
于是我从 model.py 逐行移植了一个 numpy 版本的前向传播。要小心的地方不少：PyTorch 的 nn.MultiheadAttention 把 q、k、v 打包成一个 in_proj_weight 张量（384 × 128），得按块切；TransformerEncoderLayer 用 norm_first=True，是预归一化的残差写法；padding 位置在注意力和池化两处都要屏蔽。为了让结果可信，我又手写了一个 ONNX 的 protobuf 解析器和一个小型的 ONNX 图解释器（第三方仓库里有一份导出的 model.onnx，242 个节点、68 个初始化器、opset 18），把它当成第二套独立实现。
三组交叉校验全部通过：
- 权重位级一致。把 ONNX 里的 45 个初始张量与官方 safetensors 逐个比对，最大差值 0；safetensors 的 sha256 是
05954c1c…356ddc，与 Hugging Face 上的 LFS oid 完全相同，2,828,784 字节。
- 我的输出对得上官方参考概率。官方在数据集里留下了每一条决策的参考概率，我的 numpy 实现跑出来最大偏差 2.4e-6，argmax 一次都没翻。
- 参数计数对得上。45 个张量求和正好 706,048，与模型卡声称的一致。
过程里有个插曲值得写出来：我第一版跑出来只有 47.7% 的正确率，差得离谱。逐张量对比之后才发现，是我自己把掩码写反了（np.where 的真值分支放错了位置，又把「全掩码行清零」的判断写反），导致注意力被整体清零、模型退化成「永远偏向 skip」。修掉之后，逐层输出与 ONNX 的最大差值降到 1e-6 量级。如果我没有逐张量对齐，这篇文章就会变成一篇「我实测这个模型只有 47.7%，官方数据造假」的错误结论。
24,370 条测试：数字是真的
官方在 Hugging Face 上把数据集也放出来了：test.jsonl 24,370 条、validation.jsonl 16.8MB、train.jsonl 142.6MB、demo.jsonl 196 条。我把测试集和 demo 集都跑了一遍。
| 模型卡声明 | 我复现的结果 | 判定 |
|---|---|---|
| 706,048 参数 / 2.8MB | 45 个张量求和 = 706,048；safetensors 2,828,784 字节 | 属实 |
| 合成测试 99.95%（约 15k 条） | 官方 test.jsonl 全量 24,370 条 → 99.9549% |
属实，样本比模型卡写的更多 |
| 真实表单 100%（196 条） | demo.jsonl 196 条 → 196/196 |
属实 |
| 与托管 Jev 对比 99.7% vs 83.6% | 没有公开的对比决策集 | 无法复现 |
| 打乱 context 对照 37% | 无脚本、无产物 | 无法复现 |
| 「完整数字见仓库 docs/RESULTS.md」 | 仓库里没有这个文件 | 缺失 |
分动作看更清楚：fill 9,802/9,802，check 816/816，click 1,040/1,040，skip 12,701/12,712。放弃率 52.2%，选择性准确率 1.000 —— 只要它决定动手，在这个分布上一次都没做错。
那 11 个错误值得单独拆。5 个是把同一个值重新填一遍：字段里已经写着 NE，它选了另一个文档标签 ST: NE；已经写着 Tomas，它选 First name: Tomas。这类错误在语义上是幂等的，实际执行不会写坏数据。剩下 6 个才是真错：4 个是文档里根本没有对应实体，它从别的实体里硬凑（「Current employer」被填了「Company reg: REG3878384」，「Relation to applicant」被填了车牌号）；另外 2 个是字段已经填好，它想用另一个值覆盖，而且置信度高达 0.999。
顺带一个工程发现：同一个表单里，所有元素面对的选项列表是完全一样的，而模型对每个选项独立打分。把重复的选项去重、再按字节长度分桶之后，我的 numpy 实现快了约 300 倍（1,048 条从 188 秒降到 0.6 秒，argmax 一次没变）。这也说明这个模型的推理是天然可缓存的：你不需要为同一个文档实体重复算第二遍。
换个字段名，它 21 次里放弃 21 次
验证完声明，我做了第二件事：把它推到词表外面看看。
仓库里 concepts.py 只有 55 个概念（first_name、policy、vin 这类），每个概念配一组表单标签和一组文档标签。我照着它的输入格式，自造了 4 张表、23 个字段，语义上都明确不属于这 55 个概念：船舶登记号、咖啡生豆含水率、图书馆 OCLC 编号、DBS 证明编号……文档里都为它们准备了语义上一一对应的实体，所以「正确答案」应当是把对应实体填进去。每一张表里也混了它的词汇表内的干扰实体，尽量贴近真实分布。
结果：23 个域外字段里只有 2 个填对，21 个选择了放弃，平均置信度 0.999，其中大多数直接给到 1.000。对照组（「我确认以上信息属实」勾选框、Submit 按钮、浏览器边框元素）16/16 全对，说明不是我的输入格式出了问题。
这个现象不是我先发现的。9 月 19 日，用户 0xsline 在仓库里报了 issue #3978：他的域外集合 41 条里只有 12 条正确（29.3%），其中 36 条回答 skip，平均置信度 0.974。他还做了设备对照（CPU 与 MPS）和批处理对照（单条与整批），41/41 预测完全一致，排除了硬件与 padding 因素。我的实验独立复现了同一件事，而且因为字段名更彻底地落在词表外，数字更难看。
结论要说清楚：这是一个标签匹配器，不是语义理解器。它在自家 55 个概念的分布里几乎是完美的，走出分布之后不会退化成「不确定」，而是退化成「自信地不做事」。模型卡确实写了「只在演示集上验证过、未在任意真实表单上验证」，但没有写这个失败的具体形态 —— 而对下游执行器来说，「不确定」和「自信地放弃」是两种完全不同的风险。
一份「源码优先」发布里的三处对不上
再看治理层。这个组件是 9 月 18 日通过 PR #3964 一次性加进 trycua/cua 的（7,550 行新增、35 个文件、0 条评审意见），三天内已经攒下 12 个相关 issue 和 PR，能看出社区很活跃。但发布材料本身有几处对不上：
第一处是权重。组件内的 README.md 写着「不包含也不下载模型权重、数据集、demo 二进制或录制」，MODEL_CARD.md 的状态栏写着「weights not distributed」，还专门强调「本次仅源码发布不构成任何检查点性能声明」。可同一天，Hugging Face 上就有 2.8MB 权重和四个 JSONL 数据集（合计约 178MB）。仓库根目录的 README 后来改成了「权重另行托管在 Hugging Face」，但组件里的两份文档没跟上 —— PR 正文里那句「不含模型权重、数据集、二进制、录制、原始实验日志、托管供应商对比或检查点性能声明」，和一天后模型卡上的 99.95%、100%、37%、99.7% 是直接矛盾的。
第二处是那份被引用了两次的 docs/RESULTS.md。模型卡说「完整数字见仓库的 docs/RESULTS.md」，仓库里没有这个文件；issue #3977 在 9 月 19 日就报了这个 404，也报了模型卡提供的加载方式根本跑不通 —— 模型卡给的快速开始用的是 pickle 版 .pt，而这个包自己的加载器按设计拒绝 .pt/.pth/.bin/.pkl，理由是「pickle 反序列化对公开检查点等于代码执行风险」。当天 15:30，HF 仓库补传了 safetensors 加 JSON 配置（我下载并校验的就是这一版，格式签名通过），但那份 RESULTS.md 至今没有。
第三处是残留字段。检查点配置里写着 hf_model: "Qwen/Qwen2.5-0.5B"，可这个模型是字节级的、根本没有分词器，make_system 的 tinyx 分支不读这个字段，仓库自己的单元测试还断言这种字段配 encoder="hf" 必须被拒 —— 它更像模板里没删干净的东西。检查点元数据里源文件名写的是 jevform-best.pt，第三方声明也说 model.py 里的字节拼装与小注意力原语改编自 MIT 许可的 jevlike 项目。换句话说，这条路线是照着 TypeSafe 的 Jev 那套「System One」思路做的一个独立实现，模型卡自己也承认「不是 Jev 的复现」。
该不该用
我的判断分三句。
它是真的。 你没有理由怀疑 99.95% 这个数字 —— 我把 24,370 条全跑了，一条不差地复现了，还顺手核对出参数、字节数与哈希。在一个到处是营销数字的领域里，这份可复现性值得肯定。
它的适用范围比宣传语窄得多。 55 个概念、英文标签、结构规整的表单，这是它的全部射程。把你自己的业务表单丢进去之前，先用你自己的字段名做一次我上面那种域外探测 —— 如果字段名掉出它的词表，你会得到的不是低置信度，而是一堆 0.999 的 skip。
它的失败方向需要额外闸门。 11 个错误里有 2 个是高置信度的错误覆盖动作；域外探测里 21 个是高置信度的放弃。这两类错误都不会自己举手说「我不确定」，所以下游必须自己加一层校验：把置信度 0.8 以下的决策（正确项平均 0.9993、错误项平均 0.8076，这个差距是可用的信号）挑出来人工复核，并且对「已经填了值的字段」单独做一次幂等判断 —— 那 5 个「重复填同一个值」的错误就属于这一层能拦掉的。
如果你正在做的是「一批结构固定的表单 + 一份抽好实体的文档」这种批处理，而且字段名正好落在它的词表里，这个 2.8MB 的东西确实值得试：CPU 就能跑，不吃 GPU，一次决策的时间成本可以忽略。反之，如果你的表单多变、多语言，或者业务上不允许「悄悄不填」，那它现在还不适合放进无人值守的链路。
权重和数据集都在 Hugging Face 上（cua-ai/cua-s1-forms），测试集是公开的 24,370 条，你完全可以照着上面三步自己验一遍。需要的话，我这套 numpy 实现、ONNX 解释器与全部结果都已留档。