先看证据
把屏幕判断从文字生成中拆出来
Nace AI 于 2026 年 10 月 19 日发布 Drex Max，将其定位为面向浏览器和电脑操作智能体的多模态决策模型。它接收情境文字和图像，回答调用方预先定义的问题，目标是帮助智能体判断下一步该做什么，例如在屏幕上选择哪个按钮。
这次发布值得技术负责人读，不是因为它又增加了一种能看图的模型，而是因为它把“理解屏幕”与“生成一段话”分成了两种接口。许多代理流程需要的并非一段自然语言解释，而是一个能直接映射到点击动作的选择。Drex Max 试图用受约束的答案和概率输出，把这一步做成单次 API 调用。
接口的约束，也是它的设计主张
调用方提交一段 state 和问题，问题有三类：是非判断（noul）、从给定标签中选择（choice），或在有序等级上打分（score）。模型只返回这些选项对应的概率分布，不生成自由文本。对智能体而言，这省去了把一段话再解析成动作的环节，也让动作空间在调用前就变得明确。
代价是，候选答案必须由调用方设计。若界面上出现了选项集没有覆盖的情况，模型就没有合适的答案可以表达。一次请求最多可包含 16 个问题，所有问题共享同一组图像；图像通过 images 数组传入，并可在文字中以“Image 1”等方式引用。这个接口适合已知任务边界的屏幕判断，不等于模型能自行规划任意操作。
分数显示出专长，也显示出边界
Nace 报告 Drex Max 在 Decision Index 0.3.2 上得到 67.59 分，高于 Jev 1.14 的 60.70 分；在 JevBench 上是 92.2，对方为 86.7。与屏幕和工具使用相关的结果也较突出：Decision Index Vision 为 74.5，BFCL 工具调用为 98.2，OSWorld-Verified 为 0.780。这些数字指向一个具体定位：它在决策和操作相关任务上表现强，而不是全面领先。
通用知识类结果提供了另一面。Drex Max 的 MMLU-Pro 得分为 72.5，低于 Jev 1.14 的 82.1；HLE 上是 19.0，对方为 19.4。Nace 称 Decision Index 覆盖 37 项公开基准和 140,178 条评分请求，并说明未作答按错误计，但这些仍是厂商公布的数据，现有材料没有独立复测结果。对选型来说，榜单适合用来决定“值得测什么”，还不足以证明它在你的真实界面和任务分布中更可靠。
成本与延迟要按实际调用方式算
Drex Max 的 API 文档列出每百万输入 tokens 0.06 美元，输出 tokens 不收费。这个单价看起来适合高频判断，但图像成本不能只按截图张数估算：每张图在每道问题中最多计 1,602 tokens。若同一张截图一次问多个细问题，图像相关输入量会随问题数量增加，而不是只付一次看图的成本。文档还规定每次最多 8 张静态 PNG、JPEG 或 WebP 图像，每张不超过 16 MiB，单次请求总计不超过 32 MiB。
延迟数据也不能混为一谈。Nace 列出每张截图决策的 174 毫秒中位数，以及 API 的 183 毫秒中位延迟；发布信息另称单次决策为 34 毫秒，但公开材料没有统一这些数字的测试条件。接入前应在目标设备、截图尺寸和问题数量下测端到端耗时，同时计算多问题共用图像带来的 token 费用。这里的 API 由 Nace 托管，参数量未披露，也没有公布开放权重或量化版本，因此成本、延迟之外还要评估对单一服务接口的依赖。
把它放在代理链路中做局部验证
较稳妥的试用方式，是先挑选动作集合清楚的任务，把可点击目标预先列为选项，再检查概率输出能否直接接入点击选择或置信度门控。这样可以验证它是否减少自由文本解析、降低特定截图判断的失败率，而不是把“模型能看图”当作已经解决电脑操作。若任务经常出现未预料到的界面状态，封闭选项反而可能成为主要故障点，需要另有机制识别“没有合适选项”。
还应把“校准概率”当作待验证属性，而不是现成保证。Nace 使用了这一表述，但公开资料没有给出校准误差、校准曲线或独立验证结果。结合托管 API、未公开的模型细节和口径不同的性能数字，合理判断不是立即替换通用模型，而是把 Drex Max 放进可回退的局部链路，按自有任务衡量准确率、拒答或兜底行为、延迟与总成本。它的专门化是否划算，最终取决于这些端到端结果。