UI-Venus-2-9B 對比 Microsoft Mage-VL：截圖代理對比編解碼串流監控器

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 是 codec 原生串流感知模型：它觀看壓縮影片，在例行畫面中保持靜默，並在事件完成時輸出文字。UI-Venus-2-9B 是 GUI 代理：它接收靜態截圖、推斷狀態、輸出結構化動作。一個觀看螢幕並描述它；另一個觀看螢幕並操作它。在兩者之間做選擇不是基準測試的決定，因為它們沒有共享任何基準——而是關於你的自動化最終止於答案還是止於行動的決定。

每個模型實際上是什麼

Microsoft Mage-VL 在 microsoft/Mage-VL 儲存庫中發布，未經任何官方公告，是一個約 4B 參數的多模態模型，由 Qwen3-4B-Instruct-2507 語言解碼器、從零開始訓練的視覺編碼器 Mage-ViT，以及一個獨立的約 0.5B 串流閘道所組成。其設計以視訊編解碼器為原生架構：與其均勻抽樣幀，它會完整保留錨點（I）幀，僅保留預測（P）幀中動態顯著的區塊；微軟表示這可將視覺 token 消耗量削減超過 75%，相較於均勻抽樣，可帶來最高 3.5 倍的實際推理加速。其雙流程設計——系統 1 認知閘道監視每個滾動的編解碼器視窗，系統 2 VLM 僅在事件值得回應時才啟動——使它成為一個永遠在線的視訊監看器，而之所以成本低廉，正是因為它大部分時間保持靜默。

UI-Venus-2-9B 由 inclusionAI（Venus 團隊所屬的螞蟻集團實驗室）發布，是從 Qwen3.5-9B 初始化而成的 9B 通用型 GUI 代理（agent）。它觀察介面、推理任務狀態、執行動作並納入回饋，形成「觀察–推理–行動–回饋」的封閉迴圈；其模型卡宣稱以單一檢查點涵蓋行動應用程式、網頁平台與桌面作業系統的訓練範圍。在其自身模型卡中，它報告了 AndroidWorld 80.2、OSWorld-Verified 70.8、WebVoyager 90.8 與 ScreenSpot-Pro 73.0 的成績，這些數據皆為廠商自行報告，且均未經獨立重現。

輸入差距：你所抓取的像素 vs 你所保留的串流

最具啟發性的差異在於每個模型攝取什麼。{{1}}UI-Venus-2-9B 是一個螢幕截圖代理：它的輸入是目前畫面，一次一幀，而其 256K token 的上下文視窗正是它如何在長時間任務中保存這些幀的歷史記錄。{{/1}} {{2}}Mage-VL 是一個串流代理：它的輸入是壓縮影片，而其效率來自於將幀與幀之間的運動視為資料——對傳統編解碼器而言是運動向量與殘餘能量，對神經編解碼器而言則是學習出的速率圖。{{/2}}這就是「看見瞬間」的模型與「看見連續時間軸」的模型之間的差異。{{3}}螢幕截圖代理在結構上對每次捕捉之間的那 100 毫秒視而不見——載入指示器、過場動畫、以及只在螢幕上短暫存在的懸停狀態。{{/3}} {{4}}串流觀察者則生活在這個縫隙之中。{{/4}}這並非任何一種設計的缺陷；{{5}}這正是為什麼需要對即時畫面採取行動的 GUI 代理，與需要摘要串流內容的感知模型，是擁有不同輸入契約的不同產品。{{/5}}

產出缺口：行動與言論

輸出端才是兩者不再可比之處。UI-Venus-2-9B 的輸出是在定義好的動作空間中的結構化動作——滑鼠、鍵盤、捲動、導航——它在 Qwen3 風格的推理 token 之後發出這些動作，而其訓練圍繞接地（grounding）與 CAPTCHA 任務建構，這些任務獎勵在視覺雜亂中精確定位元素。Mage-VL 的輸出則是文字：對其所見事物的事件門控評論。它沒有動作空間、沒有函式呼叫、也沒有代理迴圈。並排閱讀這兩張模型卡，你看到的是感知–行動線的兩端——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 才能執行 Microsoft 的自訂 Python；此外還需要 FFmpeg、用於影片的神經編解碼器（neural-codec）路徑，以及 mamba-ssm 等依賴項，而且它目前還沒有 vLLM 或 SGLang 的服務堆疊——沒有分頁注意力（paged attention），也沒有可供生產使用的服務路徑。Microsoft 回報其 BF16 參數總量約為 10.6 GB，這表示 16 GB 的 GPU 是影像工作的實際最低配置，長影片則需要 24 GB 以上。對於想要今天就將產品導入生產環境的團隊，UI-Venus-2-9B 提供了更乾淨的入門途徑；對於正在建立全天候監控或摘要管線的團隊，Mage-VL 的服務堆疊無論如何都是你必須承擔的部分——包括自訂 Python 在內。

不存在的記分板

這兩個模型之間沒有共同的基準測試，而憑空發明一個基準測試是不誠實的。UI-Venus-2-9B 的分數來自 GUI 定位、行動裝置、網頁與電腦操作排行榜（ScreenSpot-Pro 73.0、AndroidWorld 80.2、WebVoyager 90.8、OSWorld-Verified 70.8，皆為廠商自行通報）。Mage-VL 的分數則來自影片理解與空間理解排行榜（Video-MME 64.0、NExT-QA 83.1、OVO-Bench 64.0、VSI-Bench 比 Qwen3-VL-4B 高出 +11.0，皆為廠商自行通報）。正確解讀這場對決的方式，是將其視為一個分岔點：如果任務是「理解這個螢幕上隨著時間發生的事」，Mage-VL 是合適的工具，而 UI-Venus-2-9B 並非為此而設計；如果任務是「讓這個螢幕執行操作」，情況則相反。

兩者交融之處

這個比較的有趣之處不在於二選一。操作實際運行應用程式的 GUI 代理，有個真正的盲點——兩次截圖之間的這段時間，以及任何從未收斂成靜止畫面的狀態變化——而一個原生編解碼的串流監看模型，正是能在這個空隙中充當感知層的那種模型，能在代理下一次 grounding 掃描之前，偵測到頁面已完成載入，或模態視窗已完成動畫。微軟打造 Mage-VL 不是為了這個任務，螞蟻集團打造 UI-Venus-2-9B 也不是為了讓第二個模型來引導，但這種契合確實存在。至於這樣一個技術棧中已達生產等級的部分——負責分解任務的規劃 LLM、負責驗證螢幕狀態的視覺模型、負責記錄代理會話的轉錄模型——一個具備穿透式定價與自動容錯轉移的 API，正是讓實驗變便宜的原因，而這就是路由器的用途。無論是 UI-Venus-2-9B 還是微軟的 Mage-VL，目前都沒有透過 OrcaRouter 提供服務；兩者都是開放權重的自託管專案，如果有一天被納入路由供應商，也都會以供應商牌價上架。

該由誰來選擇哪一個

當你的問題是持續感知時，選擇 Microsoft Mage-VL——例如攝影機串流、螢幕錄影、需要即時摘要或監控的串流，而且成本要低到能持續運行。當你的問題是控制時，選擇 UI-Venus-2-9B——例如以完成動作收尾的任務、填寫表單、導航流程、操作應用程式。如果你的自動化真的兩者都需要——感知串流，然後對靜態畫面採取行動——就將它們成對運行，把串流監看者視為事件偵測器，將值得採取行動的時刻饋送給截圖代理。它們是同一塊螢幕的兩半，而不是競爭同一份工作的對手。