DeepSeek V4 Flash Vision 深度解析：384 tokens 看得清螢幕嗎？（2026）

2026 年 8 月 21 日，DeepSeek 在 API Docs 發布〈DeepSeek-V4-Flash-Vision-Exp Release: Multimodal API Now Live〉，宣布實驗模型 deepseek-v4-flash-vision-exp 登上 DeepSeek API Platform。這個 DeepSeek V4 Flash Vision 的真正意義，不只是「又一個模型會看圖」，而是讓原本只能讀文字、呼叫工具的平價 Agent，有機會把工具產生的截圖直接送回模型，形成看畫面、採取行動、再看結果的迴圈。

市場興奮得很快：截至 2026 年 8 月 22 日 12:35（台北時間），相關 Hacker News 討論已有 472 points、149 則討論回覆。但這次發布也藏著一個比跑分更實際的問題：官方文件同時寫明，每張圖片最高以 384 tokens 計算，較大的圖片會縮到約 800×800 的總像素量級。Agent 終於有眼睛了；它看見的細節，夠不夠支撐下一步動作？

以下先忠實還原這次 API 到底交付了什麼，再把「接近 Opus-4.8」的比較拆開查證，最後給出一套不必先相信廠商跑分、也能判斷 DeepSeek V4 Flash Vision 是否適合自己工作流的方法。

這次真正上線的是什麼？

先把發布範圍說準。這次可核對的交付物是一個實驗性多模態 API 模型，模型 ID 是 deepseek-v4-flash-vision-exp。官方公告稱，它保留 DeepSeek-V4-Flash 的文字、Agent、推理與世界知識能力，同時增加圖片輸入；但「文字能力相當」是廠商主張，發表頁沒有提供一套獨立重跑結果供外界直接驗證。

• 輸入介面：支援 Chat Completions、Messages 與 Responses API，可混合文字和圖片。
• 圖片來源：可傳 base64、外部 URL，或先上傳到 Files API，再用 file_id 重複引用。
• Agent 整合：DeepSeek Harness 0.1.1 同日加入現成支援；Responses API 也能把工具輸出的圖片當成真實圖片交給模型處理。
• 價格定位：官方表示圖片 token 與文字 token 一起計費，沿用 V4 Flash 的價格。

這些都是 API 文件明載的介面能力。本文不把它擴大解讀成一般聊天產品已全面開放，也不把 Exp 當成穩定版承諾。

為什麼「工具輸出的截圖」才是關鍵？

純文字 Agent 的盲點很直觀：它可以呼叫瀏覽器、執行程式、修改前端，卻未必能直接看見操作後的畫面。若工具只回傳「已成功」或一段 DOM 摘要，模型不知道按鈕是否被遮住、圖表是否跑版、錯誤提示是否出現在角落。

DeepSeek 的 Responses API 文件明確寫出：function_call_output 與 custom_tool_call_output 可以帶入 input_image，而 DeepSeek V4 Flash Vision 會把它當成圖片處理。這讓開發者在自行提供瀏覽器、自動化或截圖工具，並使用目前支援的工具類型時，可以組出一個真正的觀察迴圈：

1. Agent 先操作網頁、App 或視覺化工具。
2. 工具截取目前畫面，回傳給模型。
3. 模型根據新畫面判斷狀態，再決定下一個工具呼叫。
4. 流程重複，直到通過驗收條件或觸發停止規則。

這是「閉合回饋迴路」的必要條件，卻不是可靠性的充分條件。模型還是可能看錯、點錯，或把相似圖示混在一起；截圖也只是當下的畫面，不等於瀏覽器內部狀態。正確定位應該是：視覺讓 Agent 多一條觀察通道，不會自動把觀察變成可信的系統狀態。

384 tokens：成本優勢，也是細節上限

Larger images are scaled down while preserving their aspect ratio, so that the total pixel count after resizing is roughly that of an 800×800 image.

中文：較大的圖片會在維持長寬比的情況下縮小，使處理後的總像素量約等於一張 800×800 圖片。

DeepSeek Vision API Guide

同一份官方視覺文件進一步說明：圖片在推理前會自動調整大小；低於約 384×384 總像素量的圖片會放大，較大的圖片則按比例縮小；因此每張圖片有 384 tokens 的上限。文件舉例，2000×2000 與 5000×5000 圖片在縮放後會消耗相同數量的圖片 tokens。

這裡要避免兩個誤讀。第一，約 800×800 指的是總像素量級，不是每張圖都硬切成正方形 800×800。第二，384 是文件公開的圖片 token 計算上限；它沒有告訴我們模型內部採用哪一種 vision encoder、patch 尺寸或 pooling 方法。

畫面類型	384-token 視野較可能保留	較容易受壓縮影響
商品照、單一圖表、版面大區塊	主體、整體構圖、顯眼趨勢	角落註記、細小標籤
桌面軟體、IDE、後台	主要面板與大型按鈕	小圖示、行號、狀態列、密集文字
試算表、監控牆、長頁面	大尺度結構	儲存格數值、刻度、遠距目標與精確座標

外部研究也支持「小目標不能只靠整張截圖」這個方向。ScreenSpot-Pro專門用高解析度專業軟體畫面與極小目標測試 GUI grounding，研究結果顯示，先搜尋與裁切相關區域能大幅改善定位。這不直接等同於 DeepSeek 的表現，卻提醒開發者：遇到小字與精準點擊時，crop／zoom 不是補救小技巧，而可能是工作流的一部分。

「接近 Opus-4.8」到底有多接近？

On multimodal agent benchmarks, V4-Flash-Vision-Exp makes a major leap over V4-Flash, bringing multimodal agent performance close to Opus-4.8.

中文：DeepSeek 稱，Vision 實驗版在多模態 Agent 基準上明顯超越原本的 V4 Flash，整體表現接近 Opus-4.8。

DeepSeek API announcement

只看發布圖的四個多模態項目，結果不是「全面追平」，而是各有勝負：

DeepSeek 自報 benchmark	V4 Flash Vision Exp	V4 Flash 0731	Opus-4.8
ApexBench（Pass@1）	36.5	26.2	39.4
Agents’ Last Exam	27.3	25.2	25.7
Chartography	64.3	—	65.0
ZeroBench（Pass@5）	35.0	—	34.0

其中 V4 Flash 0731 在 ApexBench 與 Agents’ Last Exam 的數字，是 DeepSeek 圖中標註 ** 的文字模型基準；官方註腳說它忽略任務裡的多模態元素，所以這不是兩個 vision model 的對等比較。Vision Exp 在 Agents’ Last Exam 與 ZeroBench 的圖表數字略高於 Opus-4.8，在 ApexBench 與 Chartography 略低。若只接受 DeepSeek 自報發布圖，這只能支撐「在這四個選定測試裡落在相近區間」，不足以支撐「所有視覺任務都接近 Opus」。更重要的是，發表頁只提供分數表與簡短設定註腳，讀者無法從這一頁重建逐題輸出、評分腳本、樣本量或誤差範圍。

外部公開榜也提醒我們，Agent 分數是模型 × harness × 工具 × 提示 × 預算的系統結果。以 2026 年 8 月 22 日可見的 Terminal-Bench 2.1 公開榜為例，Claude Code + Opus 4.8 顯示為 78.9±1.3，與 DeepSeek 圖中 Opus-4.8 的 85.0 並不相同；這不代表其中一方造假，而是說明不同執行框架與設定不能當成同一場考試。公開榜當時也沒有列出 Vision Exp 的可對照結果。

官方示範很吸睛，但它證明的是什麼？

這個案例確實讓人理解 vision 對 coding agent 的價值：模型不只讀需求，還能參考影像素材、版面與視覺語言，再生成對應頁面。可是一張被挑選進發表頁的成功作品，沒有任務分母、重試次數、人工挑選規則與失敗案例。它適合回答「這類工作可以長什麼樣」，不適合回答「丟進 100 個真實任務會成功幾次」。

AlphaLab 判讀：眼睛補上了，可靠性沒有自動補上

1. 我同意：這是平價 Agent 工作流的實質升級

理由不是「多模態」三個字，而是 API 把圖片放進工具輸出迴圈。在支援的 Responses／function-tool 流程裡，同一個模型可以接收工具回傳的截圖，再決定下一步工具呼叫；但實際能操作哪些工具，仍取決於開發者的 harness 與 DeepSeek Responses API 目前支援的工具類型。對網頁改版檢查、圖表解讀、視覺回歸與 UI debug，少接一個獨立視覺模型的可能性，確實降低了部分整合成本。

2. 我保留：廠商 benchmark 還不能證明通用可靠性

發布圖證明的是 DeepSeek 在指定 harness 與選定 benchmark 下得到這些分數。它沒有把 Agent 在真實產品裡最麻煩的長尾問題消失掉：彈窗擋住目標、畫面載入一半、文字太小、按鈕長得相似、狀態藏在頁面之外。若沒有完整 trace 與任務級成功率，「接近 Opus」應該保留為廠商對特定測試的摘要。

3. 384 tokens 不是壞事，但迫使系統學會主動看近一點

固定上限讓視覺成本更容易預估，也可能讓大量截圖迴圈更便宜；代價是不能假設一張 4K 全螢幕截圖裡的每個小字都被保留。好的 harness 應該先看全景，再依任務裁切局部；遇到表格數字或 DOM 元素，則把 OCR、accessibility tree、DOM、API 回傳值或結構化狀態一起交給模型。

4. 最有價值的測試不是問答，而是「看錯後會發生什麼」

Vision Agent 的風險不只是一題答錯，而是錯誤觀察會驅動下一個動作。讀錯價格可能送出錯誤報告；看錯按鈕可能改到正式資料。因此驗收應同時記錄觀察正確率、工具選擇、最終任務成功率、重試次數與危險動作是否被攔下，而不是只看模型能不能描述圖片。

如果要導入，先做這個 20–50 張截圖測試

不要先拿別人的總分替自己做決定。從真實工作流抽出 20–50 張代表性畫面，至少包含正常狀態、載入中、彈窗遮擋、小字、深色模式、錯誤訊息與長頁面。每張圖先寫下唯一可驗收答案，再比較三種輸入：

1. 全螢幕截圖：量出最便宜、最直接的基準。
2. 全景＋局部 crop：檢查小字與精準定位是否改善。
3. 圖片＋結構化狀態：把 DOM、OCR、座標候選或 API 值一起提供，觀察是否降低幻覺。

接著把每次錯誤分成「沒看見、看錯、推理錯、工具錯、驗收錯」五類。只有當錯誤分布、成本與延遲都符合你的任務，才值得把 DeepSeek V4 Flash Vision 接到自動操作；涉及付款、刪除、對外發布或正式環境變更時，保留獨立的程式規則與人工確認點。

最後結論：先把它當便宜的視覺回饋通道

DeepSeek V4 Flash Vision 最值得注意的，不是發表圖上與 Opus-4.8 相差幾分，而是它把圖片正式接進 API 與工具輸出，讓成本敏感的 Agent 有機會自己看結果。這會降低視覺 coding、UI 檢查與圖表工作流的整合門檻。

但官方同時給出的 384-token 上限，也提醒我們不要把「看得到」寫成「看得清，更不會看錯」。在 DeepSeek 釋出逐題 trace、樣本量、評分腳本或第三方可重跑結果之前，合理的採用方式是：把它當成便宜、可迭代的觀察通道，用 crop 與結構化狀態補細節，用 guardrail 與驗收規則限制錯誤後果。