UniPat AI開源SWE-Vision：五百行代碼打造SOTA視覺智能體！

機器之心報道

多模態大模型在代碼能力上進步驚人，但在基礎視覺任務上卻頻繁失誤。UniPat AI 構建了一個極簡的視覺智能體框架 ——SWE-Vision，讓模型可以編寫并執行 Python 代碼來處理和驗證自己的視覺判斷。在五個主流視覺基準測試中，SWE-Vision 均達到了當前最優水平。

• 官網鏈接：https://unipat.ai
• 博客鏈接：https://unipat.ai/blog/SWE-Vision
• 開源地址：https://github.com/UniPat-AI/SWE-Vision

01｜模型看得見，卻沒法精確處理

多模態大模型的代碼能力在過去一年取得了驚人進展 —— 獨立搭建項目、排查 bug、完成復雜重構，表現已可比肩資深工程師。然而在 "理解視覺世界" 這件事上，它們的表現遠沒有代碼能力那樣可靠。UniPat AI 此前發布的多模態基準 BabyVision 就揭示了這一現象：模型常常給出大段看似合理的推理，卻在最基礎的計量、計數和空間關系判斷上出錯。

UniPat AI 此前發布的多模態理解 benchmark BabyVision 已被多個近期發布的重磅模型產品納入評測體系，并在其技術報告中被引用，體現了社區對這一問題的廣泛關注。

當我們仔細審視 BabyVision 中模型出錯的案例時，可以發現一個關鍵點：問題往往是 "模型看見了，卻無法精確處理"：

• 閱讀柱狀圖時，模型能感知到 "大約 75%"，但無法精確計算比值；
• 在復雜場景中計數時，模型可能識別了每一個物體，但在逐一清點時出錯；
• 描述空間位置時，模型能給出定性判斷，但難以穩定進行距離計算和幾何推理。

面對這些錯誤，人類通常會怎么做？

掏出工具：畫輔助線、作出標記、用尺測量、用筆計算。

這個觀察引發了一個關鍵猜想：既然模型已經極其擅長編程，能否讓它用代碼 —— 這個它最熟悉的工具 —— 來彌補視覺處理中的精度短板？

SWE-Vision 正是對這一猜想的系統性驗證。

其結果令人矚目：在五個不同的視覺基準測試中 —— 涵蓋基礎感知、圖表推理、數學問題解決、空間理解和復雜的多步驟視覺挑戰 ——SWE-Vision 均提升了前沿 LLM 的表現，如 GPT-5.2-xhigh 和 Seed-2.0-Pro，并取得了最先進的結果：在 BabyVision 上達到 64.4，在 MathVision 上達到 94.0，在 Zero-Bench-Sub 上達到 50.1，在 OmniSpatial 上達到 69.0，在 CharXiv-RQ 上達到 82.5。

02｜SWE-Vision 是什么：一個「極簡視覺智能體」

SWE-Vision 并不需要再造一堆專用視覺工具，而是把要做的事壓縮到極簡：

2.1 工具層：只保留兩個工具

config.py 里定義的工具只有兩個：execute_code 和 finish。

• execute_code：讓模型在一個可持續保留狀態的 Jupyter 環境里執行 Python
• finish：當模型確信答案正確時輸出最終答案

這里最關鍵的不是 “能執行代碼”，而是工具接口本身非常小、非常通用。SWE-Vision 沒有給模型塞一堆專用視覺 API，而是只暴露一個模型本來就很熟悉的動作：寫 Python。

2.2 控制層：一個標準的 agentic loop

agent.py 里的 VLMToolCallAgent 實現了完整的循環：先把用戶問題和圖片組織成消息；然后調用支持 tool use 的聊天接口；如果模型發起 execute_code，就把代碼送到 notebook 內核執行；再把執行結果作為 tool message 回流給模型；模型據此決定繼續調用工具還是 finish。repo 里默認 tool_choice="auto"，并支持 reasoning 模式；在開啟時會把推理 effort 設為高檔，并允許最多 100 輪迭代。

2.3 執行層：Docker 里的持久化 Jupyter kernel

kernel.py 不是簡單 exec () 一段代碼，而是正經啟動一個 Docker 容器，再在容器里拉起 ipykernel。宿主側通過 jupyter_client.BlockingKernelClient 連接這個內核，并從 IOPub /shell 通道收集執行結果。內核是持久化的，變量、導入、圖像對象和中間結果都能跨多次 execute_code 保留；同時代碼運行在隔離的 Docker 環境里，宿主與容器通過掛載目錄交換文件。kernel.py 還會在啟動后做 health check，并把 matplotlib 后端配置成 inline，以便抓取圖像輸出。

簡單來說，SWE-Vision 不強迫模型每題都寫代碼，但給它一個隨時可用并且熟悉的 “視覺工具庫”。

03｜一次請求在系統里到底怎么流動：從看圖推理到帶圖循環驗證

SWE-Vision 像一個會看圖的數據科學家，其完整工作流如下：

1. 用戶給問題 + 圖片

2. 模型先思考：這題能不能直接答？需不需要計算 / 驗證？

3. 需要就調用 execute_code：在 Notebook 里用 PIL / NumPy /matplotlib 等做分析

4. 代碼輸出（數值 / 報錯 / 可視化圖）回流給模型

5. 模型繼續迭代，直到調用 finish 給最終答案

它有幾個關鍵設計：

• 有狀態的執行環境：變量、導入、圖片加載都能跨多次調用保留
• Docker 沙箱：確?？煽匕踩h境 + 復現性；
• Image-in / Image-out：意味著模型不僅能讀取輸入圖像，還能將自己生成的可視化結果回傳給自身進行驗證 —— 這是實現自我糾錯的關鍵；
• OpenAI function calling 標準接口：保證了與主流模型的開箱即用兼容性。

這套設計的價值在于：允許模型像一個真正的科學家一樣，先做實驗再下結論。

04｜為什么 stateful notebook 比一次性 code executor 更關鍵

很多人第一次看 SWE-Vision 會覺得，它不過是在 VLM 外面加了個 Python 工具。真正的差別其實在于 stateful。在 SWE-Vision 中內核狀態會在多次調用間保留；這意味著模型可以像人類分析師那樣分步工作：第一輪先讀圖、檢查尺寸；第二輪裁剪局部、看邊緣；第三輪統計顏色或測距離；第四輪畫輔助線做確認；最后再生成答案。

如果代碼執行是無狀態的，這種多步分析會非常笨重：每一步都要重新導入庫、重載圖片、重建變量，模型也更難維護中間假設。SWE-Vision 通過持久化 kernel，把 “多輪工具調用” 變成了 “同一個 notebook 會話里的連續實驗”。從工程實現上看，這也是它為什么能處理圖表測量、空間關系和復雜多步視覺任務，而不只是做一次性的 OCR 或檢測。

05｜SWE-Vision 的關鍵在于「能驗證自己的視覺判斷」

在 SWE-Vision「觀察科學圖表、總結規律」的案例中，我們看到了一種截然不同的行為模式。如下圖所示，這是科研場景中常見的圖表分析任務：我們要求模型判斷，在 Quarters = 15 時，哪一張子圖中紅色虛線與黑色實線之間的差距最大。

SWE-Vision 智能體給出了一套極其嚴謹且可解釋的解法。首先，它排除了不存在紅色虛線的子圖（d）；隨后，對每一張候選子圖在 Quarters = 15 處精確繪制輔助線，定位紅線與黑線的交點；接著，通過可執行代碼精確計算兩條曲線在該位置的數值差距；最終基于計算結果給出正確答案。

這種 “先結構化分析、再程序化測量、最后數值驗證” 的思維與行動閉環，與傳統視覺語言模型依賴直覺式 “瞪眼觀察” 直接給出答案的方式形成鮮明對比。它不僅顯著提升了結果的可靠性與可解釋性，也展示出更高的能力上限與更強的泛化潛力。

06｜為什么極簡設計反而更強

SWE-Vision 的一個重要結論是：對視覺任務而言，加入通用代碼工具，是提升前沿多模態模型視覺能力的一個有效 test-time scaling 方向

它之所以有效，恰恰在于其極簡：

• 工具數量少，決策邊界清晰；
• 工具語義與模型已有能力高度一致；
• 支持多輪迭代和狀態積累；
• 中間結果可被再次觀察，而不是一次性返回文本；
• 不綁定某個特定 benchmark 的專用手工策略。

這與很多 “為了某類視覺任務單獨發明一套工具接口” 的方法不同。這些方法往往在某些窄任務上能提升，但泛化性不足；而 SWE-Vision 的目標，是提供一個盡可能通用的視覺增強框架，讓模型自己決定何時調用代碼、如何組織分析步驟。

07｜五大基準全線提升：更加通用的 “視覺能力增強器”

SWE-Vision 在五個覆蓋面很廣的視覺基準上進行了評測（基礎感知、圖表、數學、空間、綜合多步推理），核心發現高度一致：引入代碼執行能力，能系統性地抬升前沿模型的視覺表現上限。

在對比實驗中（同一模型 vs SWE-Vision），SWE-Vision 對兩個前沿的視覺語言模型（GPT-5.2，Seed-2.0）都帶來顯著提升：

“反直覺” 的一點是：

提升幅度最大的，往往不是最復雜的高階推理任務，而是最基礎的感知和精確處理能力—— 例如 BabyVision 中的計數、顏色識別和空間關系判斷。這類任務人類靠直覺加簡單工具就能穩定完成，而模型僅憑 "語言化視覺" 則極易忽略細節、數錯個數、缺乏驗證手段。

SWE-Vision 的結果也給我們揭示了另一種可能：

對于視覺來說，測試時擴展（test-time scaling，TTS）不一定只能靠 “多想幾段文字”，也可以靠 “多寫幾行代碼” 來看得更精細。

08｜未來的發展方向：讓 “代碼增強視覺” 變成視覺智能體的原生能力

與用于訓練多模態 LLMs 的傳統數據（基本上是問題，圖片，答案三元組）不同，訓練視覺智能體模型需要多模態交錯的智能體軌跡。它還需要一個交互式環境來支持強化學習、工具使用和評估，使模型不僅能學習回答問題，還能學習感知、行動和反思，要徹底釋放 “工具增強視覺” 的潛力，模型需要更多深度交織的視覺 - 編程 SFT/RL 數據與環境，來學會感知、行動和反思。

具體而言，下一步的關鍵方向包括：

• 判斷時機：學會識別何時視覺推理需要代碼輔助，何時可以直接回答
• 中間驗證：在多步推理過程中主動檢驗中間結果的正確性
• 失敗恢復：在代碼方案無效時及時跳出，切換到替代策略
• 原生融合：讓 "觀察" 與 "計算" 不再是兩個獨立步驟，而是深度融合，一體兩面

SWE-Vision 的開源代碼已在 GitHub 發布。編程輔助的精確視覺理解是一個值得社區共同探索的方向 —— 五百行代碼的極簡框架，也許是這段旅程一個不錯的起點。