System One：选择，不是猜

Brain 做决定的方式，就像从一份简短的菜单里点菜：快，而且选项是别人事先列好的。它从不自己用文字写出动作。本页解释为什么这样设计，以及它返回的数字能告诉你什么、不能告诉你什么。

每一步都是一道选择题

每一步，Hands 都把屏幕变成几道带类型的问题，每道题都有一份封闭的选项列表：

• 下一步做什么操作？ CLICK、OPEN、TYPE_TEXT、KEY、DONE、BLOCKED、ASK……
• 点哪个元素？ 屏幕上每个可点的元素各是一个选项。
• 输入什么值？ 每个候选值各是一个选项。
• 按哪个快捷键？ 只列出这里适用的快捷键。

Brain 为每道题的每个选项给出概率。Hands 取概率最高的操作，以及这个操作概率最高的目标。

这样设计带来几点好处：

• 没有要解析的输出。 模型不写 JSON，也不写代码，所以不存在需要修补的格式错误。
• 不会做出列表之外的动作。 模型点不了屏幕上没有的元素，也按不了没给它的快捷键。它能做的，仅限于 Hands 摆在它面前的选项。
• 每个选项都有分数。 你不仅看到它选了什么，还能看到第二名差多少。

回答时不生成文本

每道题变成一段提示：状态、问题，以及带简短标签（A、B、C……）的选项。模型把提示读一遍，它在答案位置对各标签 token 的打分就变成概率。整个过程不解码任何文本。

针对同一个状态的所有问题共用同一段提示前缀（状态、目标和规则），这段只算一次；每道题只是在后面多出一小段。用两段式打分时，先回答操作，再只回答这个操作需要的问题。所以一步的开销是：读一遍公共前缀，再加几小段分支。

在 M4 Pro 上，时间主要花在读提示上，而不是给出答案：桌面的一步约 1,900 个提示 token，4B 每秒约读 850 个。见成绩与局限。

概率意味着什么

概率 0.96 的意思是：模型把 0.96 的权重放在了这个选项上。这是把握，不是正确性的保证。 具体来说：

• 模型可能很有把握，却答错。 概率高，答对的可能更大，但不等于一定对。
• 校准程度是测过的，并不完美。 在 JevBench 的 231 道公开题上，G18b 4B 的期望校准误差（ECE）为 0.089，Brier 分数为 0.269。它给出的把握和实际正确率之间，平均差约 9 个百分点。
• 0.8B 的把握挤在一个窄区间里。 发布版 G18b 中，它的把握集中在约 0.94 到 0.97 之间。这就是它的路由门槛定得这么高、大部分步骤都交给 4B 的原因。
• 在一个数据集上的把握，不能直接搬到别处。 门槛最初是在留出的桌面任务上选的，后来发现那个数据集偏乐观。

把概率当作「该慢下来」的信号：去问、去升级、去检查。不要把它当作某一步做对了的证据。要知道任务是否真的完成，应当像 Bench 那样检查最终状态。

两级：0.8B 再到 4B

发布版的默认配置是一个路由。每一步都先由 0.8B 回答；只有它足够有把握、并且这一步做错代价不大时，才采用它的回答；否则同一步再交给 4B 回答。

以下情况会交给 4B：

• 0.8B 把握不够： 操作及其所需问题的最高概率里，最弱的那个低于门槛；
• 这一步会结束任务： 操作是 DONE 或 BLOCKED；
• 这一步可能丢掉成果或对外产生影响： 除 ⌘S、⌘F、⌘C、Tab、Escape 之外的快捷键，或者点击撤销按钮；
• 上一步效果没法确认，紧接着就要宣布完成： Hands 无法验证上一个操作的效果，而模型马上说 DONE。

门槛随权重一起发布：0.8B 的 deskmind.json 里的 router_threshold，G18b 为 0.96。服务从这里读取；--threshold 可以覆盖；文件里没有这个值时，退回 0.94。

有一个例外是为了保护已完成的工作：如果 0.8B 说 DONE，而 4B 给出的替代做法是点撤销，就保留 DONE。在真实桌面上，不这样做的话，强模型会把做完的任务撤销掉，然后原地打转。

每个回复都用一条 routing 记录说明是谁答的、为什么。原因的完整列表见 API 参考。

代价是速度。G18b 中约 70% 的步骤会升级，所以一次决策通常要 3 秒左右，而不是半秒左右。

问一句，而不是猜

有些目标，不多知道一点就做不对：目标里的名字对得上两条记录，或者要填的值在屏幕上找不到。猜错比问一句更糟。

• Hands 发现目标可能有歧义时，会把 ASK 作为一个操作提供出来，并附上要问你的问题。Brain 可以像选其他操作一样选它。
• 在 Mac App 里，问题以卡片形式出现。问题里列出了几种可能时，每种都是一个按钮；你也可以直接输入回答。你的回答会写进状态，模型也被告知不要再问同样的问题。
• 和 ASK 不同，App 在发送、删除或无法撤回的操作之前，会单独请你审批。

Bench 里有一个任务专门测这一点：目标里提到的记录对得上两行。算通过的条件是：写任何东西之前先问，然后写入选定的完整一行，保存，再宣布完成。

宣布完成之前先检查

太早说「做完了」是 agent 代价最大的错误：你不再盯着它，活却没干完。DeskMind 在几个层面上检查 DONE：

1. 4B 复核每一个 DONE。 0.8B 说的 DONE 一律交给 4B。如果两个模型都选了它，回复会标记 confirmed。
2. Hands 给 DONE 设了门槛。 概率低于 0.8 的 DONE 或 BLOCKED，如果有像样的替代操作，可能被换掉。但 DONE 的概率在 0.5 以上、模型连续两步都选它、或者两级模型都确认过时，DONE 会被保留：把这些 DONE 换掉，曾经导致已完成的工作被撤销。
3. App 拿目标的原话来核对。 在 App 里，一次运行结束之前，Hands 会把目标和这次运行实际做过的事对照：文件写了却没保存、写入的行数少于目标要求、目标说要关的窗口还开着。缺了什么，就把 DONE 退回去，并说明缺什么，最多一两次。这项检查在 App 里是打开的，在 Hands 里默认关闭；成绩与局限里报告的 bench 运行中，它是关闭的。
4. Bench 检查最终状态。 评测时，只有文件和窗口最终都对了才算通过，不管 agent 自己怎么说。评分程序不认可的每一个 DONE，都记为一次「没做完就说完成」。

这些检查都不完美。反过来的失败也有：有一个 bench 任务，文件已经写对了，模型却一直没说完成，直到用完全部步数。