现在几乎所有能操作电脑的大模型都在做同一件事:看截图、算坐标、点一下。微软 Mage 团队开源的 Mage-VL-Cowork 抛出的问题很直接——一只靠像素的智能体要交多少税?一张 1920×1080 的截图就是几千 token,一次结构化的表格改动要靠几十次鼠标拖拽重新推导一遍,而这台机器上明明有一条更快、更可验证的通道:直接写代码。
这个 4B 参数的模型由 Mage-ViT(16×16 patch、3D RoPE)加 Qwen3-4B 组成,权重以 Apache-2.0 发布在 Hugging Face,完整技术报告见 arXiv。它把 GUI 与终端收进同一个策略内部的两条动作通道,没有外接编排器,每一步自己决定该点还是该敲。
分数:66.0%,以及它说明了什么
最终 RL checkpoint 在 OSWorld-Verified 上拿到 66.0%(361 道保留任务,排除 Google Drive,50 步预算,两次评测平均 65.33% 与 66.75%)。分项是 OS 87.5、Office 64.9、Daily 65.0、Professional 66.3、Workflow 62.7。
论文自己跑的对比表里,4B 档位另一款 Fara1.5-4B 只有 13.9%;往上,30B 的 Muse Glimmer-30B 是 65.9%,27B 的 Qwen3.6-27B 是 63.9%,32B 的 EvoCUA-32B 是 56.7%,72B 的 OpenCUA-72B 是 44.9%。开源阵营里压过它的只有 9B 的 ScaleCUA-Qwen3.5-9B(68.7%)。闭源那边,人类参考线 72.4%,GPT-5.5 是 78.7%,GPT-5.4-mini 是 69.6%。
论文报告的"同参数量级最优"具体指:4B 这一档没有对手,不是全面领先。压过 30B 靠的是 0.1 个百分点,压过 72B 靠的是 21 个百分点。要留个心眼的是,这张表由论文作者自己跑,同行的分数也都出自这张表,不是各家独立复测的结果。
真正值钱的不是分数,是"先改教师"
最能说明问题的是一组 harness 对照。教师模型固定为 GPT-5.4,在 672 道跨应用保留任务上,只保留 GUI + code 的精简 harness 教师拿到 92.0%、平均 25.0 步;加一条 accessibility 通道的版本反而只有 89.6%、35.3 步。用各自教师的轨迹去训 4B 学生,差距被放大成 37.6% 对 25.1%——12.5 个百分点,轨迹还短了 21.5%。
工具越多不等于越强。前沿教师能靠多走几步消化掉冗余通道,4B 学生却对被切碎的监督极其敏感。
数据合成:每个任务成本砍到六分之一
Mage-CUA-Forge 不再为每个任务跑一次开放式 agent 循环,而是每个原子技能写一次可复用的工作流。在同一套生成模型下,每任务 token 从 1,276K 降到 85K(-93.3%),成本从 0.906 美元降到 0.158 美元(-82.6%)。经过三轮学生反馈迭代,流水线合成 293,806 个任务、覆盖 6,915 个原子技能,其中 38.24% 跨多个应用;最终保留 318,837 条混合轨迹,GUI 调用占 68.19%,终端占 31.81%。
五阶段课程与在线 RL
路径是:GUI 定向中期训练 → GUI Agent SFT → 代码与终端 SFT → 混合 CUA SFT → 在线混合 RL(GRPO、异步 rollout、可验证任务奖励)。先把两条通道各自练硬,再教它什么时候切换,而不是让路由成为 GUI 能力薄弱的临时补丁。
分数沿着这条路走:45.56% → 55.84% → 66.0%。第一阶段把 OSWorld-G 从 30.6% 拉到 56.9%,ScreenSpot-v2 从 78.8% 拉到 87.2%,双双越过 Qwen3.5-4B(54.5%)和 Qwen3-VL-4B(85.3%)。
在线 RL 那一段最反常识:成绩涨了,消耗反而降了——平均模型调用 21.57 → 18.77(-13.0%),每任务输出 token 7,374 → 5,499(-25.4%)。对照 GPT-5.4-mini 的 18.24 次调用与 12,397 个输出 token,4B 模型在轮次上基本持平,输出 token 少了 55.6%,论文称之为 2.25 倍 token 效率。
我的看法
这条路线里最值得抄的不是架构,是"先把教师 harness 改对,再去收数据"这个顺序。过去两年谈智能体,默认模型是瓶颈;这篇把镜头反了过来——教师脚手架上多一条冗余工具,4B 学生就掉 12.5 分,而这种损失在训练日志里几乎看不见。
另一个方向是"混合"正在成为默认形态。纯 GUI 路线撞的是 token 墙和可靠性墙,纯代码路线看不见画布,混合策略把选择权交还给模型本身。官方项目页给的一段实时对拍很说明问题:同一个 LibreOffice Calc 合并单元格、加图表的任务,4B 模型用 Python 在终端改表,39 秒、6 步跑完;27B 的 Qwen3.6-27B 纯靠鼠标拖拽,9 分 56 秒、39 步。这是单个演示,不能当普遍结论,但方向清楚。
至于"端侧"这层:独立站点 modelfit.io 的统计显示,这个模型目前唯一的量化构建是 2.716 GB 的 Q4_K_M GGUF 外加 0.353 GB 视觉投影器,16GB 内存的 Mac 装得下。但它要驱动的是一整台 Linux 桌面,离"手机上的智能体"还有距离。
所以真正该问的不是"小模型能不能追上大模型",而是:当智能体的能力差距越来越不由参数量决定的时候,它到底由谁写的脚手架决定?