UI-Venus-2-9B vs Microsoft Mage-VL：截图智能体 vs 编解码流观察者

UI-Venus-2-9B 和 Microsoft Mage-VL 在一个月内先后悄然发布——Mage-VL 的仓库于 2026 年 7 月 26 日出现，UI-Venus-2-9B 于 2026 年 8 月 26 日出现——两者均为 Apache-2.0 开放权重，且都基于 Qwen 系列骨干网络。相似之处大致到此为止；区别不在程度上，而在于每个模型各自生活在屏幕的哪一侧。Microsoft Mage-VL 是一个编解码器原生的流式感知模型：它观看压缩视频，对常规画面保持安静，并在事件完成时输出文本。UI-Venus-2-9B 是一个 GUI 智能体：它接收静态截图，推理状态，并输出结构化动作。一个注视屏幕并加以描述；另一个注视屏幕并加以操作。在它们之间做选择不是一个基准测试的抉择，因为它们没有任何共同的基准——而是关于你的自动化最终落在"一个答案"还是"一个动作"上的抉择。

每个模型到底是什么

微软的 Mage-VL 在未作任何公告的情况下发布在 microsoft/Mage-VL 仓库中，是一个约 4B 参数的多模态模型，由 Qwen3-4B-Instruct-2507 语言解码器、从零训练的视觉编码器 Mage-ViT，以及一个独立的约 0.5B 流式门控组成。其设计是视频编解码器原生的：它不对帧进行均匀采样，而是完整保留锚定帧（I 帧），仅保留预测帧（P 帧）中运动显著的区域块。微软报告称，这可将视觉 token 消耗减少逾 75%，并且与均匀采样相比，端到端推理速度最高可提升 3.5 倍。双进程设计——System 1 认知门控负责监视每个滚动编解码窗口，System 2 VLM 仅在事件值得响应时才参与进来——使其成为始终在线的视频监视器；它之所以成本低廉，正是因为它大部分时间保持静默。

由 inclusionAI（Venus Team 的 Ant Group 实验室）发布的 UI-Venus-2-9B，是一个基于 Qwen3.5-9B 初始化的 9B 通用 GUI 代理。它观察界面、推理任务状态、执行操作并整合反馈——形成闭环的观察–推理–行动–反馈循环——其模型卡声称在单个检查点中覆盖了移动应用、网页平台和桌面操作系统的训练。在其自身模型卡上，它报告了 AndroidWorld 80.2、OSWorld-Verified 70.8、WebVoyager 90.8 和 ScreenSpot-Pro 73.0 的成绩，全部为厂商自报，且均未经独立复现。

输入差距：抓取的像素与持续保留的流

最具启发性的区别在于每个模型各自以什么为“食”。UI-Venus-2-9B 是一个截图代理：它的输入是当前屏幕，一次一帧，而它那 256K token 的上下文窗口，正是它在长时间任务中保存这些帧历史的方式。Mage-VL 是一个视频流代理：它的输入是压缩视频，它的高效来源于把帧与帧之间的运动当作数据来处理——对传统编解码器而言是运动矢量与残差能量，对神经编解码器而言则是学习得到的码率图。这就是“看见瞬间的模型”与“看见连续时间线的模型”之间的差别。截图代理在结构上对两次捕获之间的那 100 毫秒是盲视的——转圈加载的动画、加载中的过渡、只在屏幕上短暂存在的悬停状态，它都看不见。而流观察者就活在那段间隙之中。这并非两种设计中的任何一方有缺陷；正因如此，需要在实时屏幕上行动的 GUI 代理与需要总结视频流的感知模型，是输入契约截然不同的两种产品。

产出缺口：行动与言论

就输出端而言，两者已无法相提并论。UI-Venus-2-9B 的输出是在定义好的动作空间中的结构化动作——鼠标、键盘、滚动、导航——这些动作在 Qwen3 风格的推理 token 之后生成，其训练围绕 grounding 和 CAPTCHA 任务构建，奖励在视觉杂乱环境中对元素的精确定位。Mage-VL 的输出则是文本：对所见内容的事件门控式评述。它没有动作空间，没有函数调用，也没有 agent 循环。将两张模型卡并排阅读，你看到的是感知-动作分界线的两端——Mage-VL 以描述收尾，UI-Venus-2-9B 以点击收尾。

• 工作 — UI-Venus-2-9B：GUI代理，操作界面。Microsoft Mage-VL：流式感知，描述界面。

• 输入 — UI-Venus-2-9B：静态截图，256K token 历史记录。Microsoft Mage-VL：压缩视频编解码器流，运动显著 token 稀疏性。

• 输出 — UI-Venus-2-9B：结构化的鼠标/键盘/导航操作。Microsoft Mage-VL：事件门控的文本解说。

• 大小 — UI-Venus-2-9B：9B。Microsoft Mage-VL：~4B + ~0.5B 流式门控。

• 骨干——UI-Venus-2-9B：Qwen3.5-9B。Microsoft Mage-VL：Qwen3-4B-Instruct-2507 以及从零训练的 Mage-ViT。

• 许可证 — 两者均为 Apache-2.0（Mage-VL 的模型卡在其仓库中注明仅限研究用途）。

服务差距

在这里，更新、更大的模型反而更容易运行。UI-Venus-2-9B 只需一条 vLLM 命令即可运行，支持 256K 上下文窗口，并提供标准的 OpenAI 兼容 API。Mage-VL 需要trust_remote_code来执行微软的自定义 Python，外加 FFmpeg、用于视频的神经编解码器路径，以及 mamba-ssm 等依赖项；而且它目前还没有 vLLM 或 SGLang 服务栈——没有分页注意力，也没有生产级服务路径。微软报告 BF16 参数总量约为 10.6 GB，这意味着 16 GB 的 GPU 是图像工作的实际最低配置，而长视频则需要 24 GB 以上。对于希望今天就将产品投入生产的团队，UI-Venus-2-9B 的入门路径更清晰；对于构建常驻监控或摘要管道的团队，Mage-VL 的服务栈无论如何都是你需要承担的，包括自定义 Python 在内。

一个不存在的记分牌

这两个模型之间没有共同的基准测试，凭空编造一个将是不诚实的。{{1}}UI-Venus-2-9B 的成绩来自 GUI 定位、移动端、网页和计算机操作榜单（ScreenSpot-Pro 73.0、AndroidWorld 80.2、WebVoyager 90.8、OSWorld-Verified 70.8，均为厂商自报）。{{/1}} {{2}}Mage-VL 的成绩来自视频理解和空间感知榜单（Video-MME 64.0、NExT-QA 83.1、OVO-Bench 64.0、VSI-Bench 比 Qwen3-VL-4B 高出 +11.0，均为厂商自报）。{{/2}} 看待这场对决的正确方式，是将其视为一个岔路口：{{3}}如果任务是“理解屏幕上随时间发生的情况”，那么 Mage-VL 是合适的工具，而 UI-Venus-2-9B 并非为此而建；{{/3}} {{4}}如果任务是“让这个屏幕完成某项操作”，则情况正好相反。{{/4}}

两者交融之处

这种比较的有趣之处不在于二选一。运行中的应用程序上的GUI代理有一个真正的盲区——截图之间的时间间隔，以及任何从未稳定为静态画面的状态变化——而一种编解码器原生的流监视模型恰恰可以在这一间隙中充当感知层，在代理下一次grounding之前检测到页面是否加载完成或模态框是否动画结束。微软并不是为了这个任务而构建Mage-VL，蚂蚁集团也不是为了让UI-Venus-2-9B受另一个模型引导而构建它，但这种契合是实实在在的。对于这样一个技术栈中已经达到生产级的部分——分解任务的规划器LLM、验证屏幕状态的视觉模型、记录代理会话的转录模型——一个采用直通定价并具备自动故障转移的API正是让实验成本低廉的关键，而这就是路由器的用途。目前，UI-Venus-2-9B和Microsoft Mage-VL都没有通过OrcaRouter提供服务；两者都是开放权重、可自托管的项目，如果它们将来接入某个路由提供商，也将以提供商的标价出现。

谁应该选择哪个

当你的问题是持续感知时——摄像头视频流、屏幕录制、需要实时总结或监控且成本低到足以持续运行的流——选择 Microsoft Mage-VL。当你的问题是控制时——以完成操作、填写表单、走完流程、操作应用程序为终点的任务——选择 UI-Venus-2-9B。如果你的自动化确实两者都需要——先感知流，再对静态画面采取行动——就将它们成对运行，把流监控器当作事件检测器，为截图智能体提供值得行动的时刻。它们是同一块屏幕的两半，而非争夺同一工作的竞争对手。