為何原生多模態 AI，正成為程式代理的關鍵能力

程式代理之間正出現一項愈來愈重要的差異：不只是「能不能接受圖片輸入」，而是視覺證據是否被當成推理與行動流程中的一等資訊。

對要長時間執行任務的代理而言，這個差別很實際。它不該只會寫出一段程式碼，還要能啟動頁面、看見渲染結果、找出哪裡不對，再回頭修改。Moonshot AI 的 Kimi K3 被定位為用於長程式開發、知識工作、視覺理解與推理的原生多模態代理模型；阿里雲則表示，Qwen3.8-Max 的原生視覺理解貫穿規劃、執行與驗證。1735

關鍵不在「看得到」，而在「看完能改」

傳統以文字為主的通用模型，仍很適合程式生成、長上下文分析、工具呼叫，以及輸入與驗收條件本來就能完整文字化的任務。

在模組化工具架構中，代理也可以呼叫 OCR（光學字元辨識）、讀取 DOM 或無障礙樹、取得元件座標，或把截圖交給獨立的視覺語言模型（VLM）分析。若目標是擷取文件內容、檢查結構化介面狀態，或回答一次性的圖片問題，這樣的設計往往合理。

但原生多模態走的是另一條路：在訓練與後續調校中，讓文字、圖片、影片、程式碼與代理狀態共同參與模型的理解，使視覺資訊能直接影響規劃與修正。報導曾將 Moonshot、阿里巴巴與字節跳動描述為投入此方向，而當時 DeepSeek、智譜與騰訊混元的通用模型則相對偏文字導向。15

不過，這不應被解讀成各家公司永久不變的分野。例如 DeepSeek 的 V4 Flash 與 V4 Pro 起初僅支援文字，之後也推出實驗性的 DeepSeek-V4-Flash-Vision-Exp。134 模型產品線變動很快；就現有資料而言，也不足以斷定每一家實驗室採取特定路線的內部原因，尤其是字節跳動、智譜與騰訊。

「視覺在迴圈中」改變了什麼？

網頁不是只有文字與 DOM 結構。畫面還有資訊層級、留白、對齊、對比、字體、裁切、圖片，以及元件彼此之間的視覺關係。當任務是依參考圖重現設計時，這些往往才是真正的驗收標準。

一個具備視覺回饋的代理工作流程，通常可分成四步：

1. 規劃： 理解需求、參考圖、既有程式庫與先前任務狀態。
2. 行動： 撰寫或修改程式、操作瀏覽器或應用程式，或編輯視覺素材。
3. 觀察： 渲染結果後，檢視截圖、影片畫格或其他視覺輸出。
4. 驗證與修正： 對照目標，定位可能缺陷、修補底層成品，然後重複流程。

Qwen3.8-Max 明確描述了這種閉環模式：其原生視覺理解會用於規劃、執行與驗證，支援長時程任務中的自主規劃與反覆改進；託管版本可輸入圖片、文字與影片，輸出則為文字。35 Kimi K3 同樣在單一模型內理解文字、圖片與影片，並提供 100 萬 token 的上下文視窗。25

優勢不只是模型「能看圖」，而是同一個代理能將需求、程式碼、視覺輸出與不斷更新的計畫保留在同一個工作脈絡裡，持續迭代。

為何只靠 OCR、座標或外接 VLM 可能不夠？

外部感知工具並非無效，但它們會在「看見」與「採取行動」之間加入一道介面。

OCR 只能擷取部分資訊。 它能讀出畫面中的文字，卻未必能完整說明按鈕有沒有被裁切、版面是否失衡、彈出視窗是否遮住內容，或視覺層級是否與參考設計不同。

座標資訊結構明確，卻較狹窄。 「某元素位於 x／y 座標」對自動化很有用，但不必然能傳達它是否顯眼、樣式是否正確、是否與其他元件重疊，甚至是否找對了視覺上真正對應的物件。

長鏈任務中的反覆轉譯會增加負擔。 每次把截圖轉成文字描述、把畫面交成座標報告，都可能遺失脈絡，或迫使代理重新拼湊資訊。若依據不完整描述做出修補，又製造了新的視覺問題，就得再進行一次觀察循環。

原生多模態模型當然不會因此不犯錯；但它可以同時參照截圖與實作脈絡，而非只依賴「截圖裡有什麼」的文字摘要。這正是它在前端開發、GUI 自動化、視覺回歸除錯、圖像編修與影片工作流程中吸引開發者的原因。

Kimi K3 的案例：說明使用情境，不等於因果證明

Kimi K3 的公開結果說明了開發者為何重視這類能力。Arena 表示，Kimi K3 在 Frontend Code Arena 以 1,679 分登頂，相較 Kimi K2.6 上升 17 名，並在列出的 7 個前端領域中拿下 6 項第一。32

另有關於瀏覽器開發平台 Puter 測試的報導指出，研究人員在網站中刻意植入 5 個視覺差異；Kimi K3 對照目標頁面與渲染截圖後，找出全部 5 項差異，且沒有誤報。28

這些都是視覺驗證有價值的展示，但不能據此斷言「原生視覺」單獨造成了結果。模型規模、訓練資料、後訓練方法、提示設計、瀏覽器工具、代理框架與基準設計，都會影響表現。較審慎的結論是：視覺回饋確實能補足純文字測試容易漏掉的一類失敗。

何時應優先選擇原生多模態代理？

若工作需要多次觀察與修正，且「視覺正確」本身就是完成定義，原生多模態特別值得優先考慮，例如：

• 依參考設計製作網頁或 App；
• 修復損壞的 GUI 狀態；
• 檢查響應式版面與視覺回歸問題；
• 編修圖片，同時維持主體、構圖或風格限制；
• 檢閱長影片，確認場景層級的一致性。

反過來說，低成本文字擷取、批次處理，或只需要結構化文字與 UI 狀態的流程，模組化 OCR 或外接 VLM 管線仍可能是更合適的選擇。

真正該問的不是視覺能力是否流行，而是代理是否必須一再回答這個問題：「這個輸出看起來真的對嗎？」

對這類任務，原生多模態讓感知不再只是偶爾的一次工具呼叫，而成為代理運作迴圈的一部分；Kimi K3 與 Qwen3.8-Max 正明確朝此方向發展。1735