2026 多模態 AI 代理：正式產品團隊的實用架構指南
1. 一切都長出眼睛的那一刻
一家 B 輪的客服新創，我們九月初和他們聊過，他們花了十八個月把他們的 CTO 所說的「一個真的很強的文字代理」做出來。這個代理可以拉工單、做摘要、起草回應、把困難的升級出去，並且和 CRM 整合。他們內部的評測集全綠。但他們的客戶仍然在寄截圖——壞掉 UI 的照片、錯誤對話框的圖、手機拍下、紅筆圈出錯誤數字的儀表板。每一張這樣的工單都掉進同一個迴圈：代理請客戶描述，客戶打出很糟的描述，代理猜錯，人類被迫接走這個案件。
他們十月的第一週，把現有模型的視覺輸入開關打開。四天之內，無需人工接手的工單解決率從 41% 升到 67%。他們沒有寫新模型、沒有重訓任何東西、沒有改他們的提示架構。他們只是打開一個十八個月前對他們而言還是個邊緣實驗的功能，整個產品就變了樣。
這就是 2026 下半年 AI 代理的故事：多模態輸入不再是一個你為小眾功能打開的特殊能力。它是任何真正在處理實務的代理的預設輸入層。有趣的問題已經不再是「這個代理要不要支援視覺？」而是「怎麼架構一個代理，讓它把每一個輸入——截圖、錄音、PDF、UI 狀態、短影片、感測器資料——都視為原生可理解的候選，而不是先壓平進文字再開始？」
這份指南是寫給在 2026 Q4 正在打造代理的工程師、創辦人、產品主管，他們已經受夠行銷等級的多模態故事。它有立場。它在該引用時引用當前模型、當前模式、當前定價。它試著回答多數供應商內容迴避的問題：打造多模態原生代理到底什麼時候划得來，什麼時候是昂貴的岔路？
2. 2026 真正改變了什麼
2026 年多模態有趣的地方，不是模型變得更聰明。是多模態呼叫的成本和延遲掉得夠多、周邊工具成熟得夠多，讓設計決策整個翻轉過來。
2023 跟 2024 的時候，「視覺」是一個高階功能。你要為每張圖、每秒音訊、每頁 PDF 多付錢。多模態是一個分開的模型呼叫，常常透過一個專家模型，然後回傳文字，再餵給你主要的文字代理。當時的架構是：專家 → 壓平 → 文字代理 → 工具 → 再壓平 → 回應。壓平那一步會讓你損失資訊。每一層你壓過去，就在邊緣地方賠掉準確率。
到了 2026 年中，三件事同時位移。
- Frontier 通用模型原生吸收了視覺與音訊。GPT-5.5、Claude Opus 4.8、Gemini 3.5 Flash、Gemini 3.1 Pro Preview 全部把文字、圖、音、影片視為單一前向傳遞裡的一級輸入。「視覺模型」這個類別在開源權重層仍然存在，但在 frontier 已經不再是推薦路徑。
- 開源權重多模態模型到達正式產品等級。Llama 4 Maverick（還有 Llama 4 Scout 處理超長上下文）把原生圖文一起帶進了開源權重生態。這件事對自架跟受監管的部署有意義，frontier 封閉層做不到。
- 多模態輸出的工具鏈跟上來了。圖片定位引用、螢幕截圖區域選取、音訊時間戳、文件排版感知、影片章節標註，這些現在是標準輸出能力，不再是每家供應商各自接的不同整合。
加總的效果是：2026 下半年的設計問題很少是「這個代理要不要看？」而是「給這個代理每一個相關輸入模態，最便宜也最安全的方式是什麼，而我應該刻意排除哪些？」
3. 每個正式產品代理都有的五層輸入
2026 年我們審視一個正式產品的代理堆疊，預期會看到五個不同的輸入層。每一層技術上都是多模態輸入，但每一層有不同的成本特性、失敗模式、設計約束。把它們當成一個未分化的整團，是最常見的架構錯誤。
3.1 視覺（截圖、照片、圖表、UI 狀態）
視覺現在是正式產品裡最常見的多模態輸入。我們最常看到的模式：客服代理檢查使用者傳來的相片；文件處理代理讀收據、發票、表單；QA 與測試代理檢查截圖、抓迴歸；UI 除錯代理比對預期與實際截圖；資料分析代理讀圖表跟儀表板。
有趣的細節：視覺不只是「描述這張圖」。一個好的正式產品等級視覺代理會引用區域、把答案錨到像素，並且在證據薄弱時願意說「我從這張圖無法判斷」。2026 下半年把這件事做得好的模型——Claude Opus 4.8 與 GPT-5.5——會這樣表現，多半是因為它們被訓練要把答案接地，而不是因為有什麼特別的視覺頭。
3.2 音訊（會議、通話、語音、環境音）
音訊是第二常見的輸入，也是各家供應商品質差異最大的。誠實的拆解：聽你會議逐字稿的模型、跟對會議逐字稿做推理的模型，通常是不同的模型，兩者之間的接縫就是大多數音訊代理壞掉的地方。
2026 年務實的架構把音訊當成兩段管線——一個即時音訊模型（Whisper 等級或各家原生等效品）產出帶時間戳跟講者標籤的逐字稿；一個 frontier 文字或多模態模型對逐字稿、相關的音訊嵌入、以及任何視覺上下文進行推理。想跳過逐字稿、直接對音訊做推理，技術上 frontier 做得到，但延遲預算常常撐不過那一跳。
3.3 文件（PDF、表單、試算表、合約）
文件理解是一個獨立的輸入層，因為排版很重要。同樣一段話，出现在 PDF、Word 文件、掃描的列印影像中，對代理是三個不同的問題。2026 frontier 模型這三種都能處理，但失敗模式不同：模型可以把字讀得完美，卻仍然漏掉第 12 頁的註腳和第 4 頁的條款矛盾。正式產品的修法通常是一個 retrieval-augmented 的層，把答案接地在文件區域，不只是寬泛的模型記憶。
3.4 瀏覽器與 UI 狀態
這是過去十二個月改變最多的層。Google I/O 2026 圍繞 agentic Search、WebMCP、Chrome DevTools for agents 的公告，指向一個瀏覽器原生為代理檢查提供介面的網路世界。2026 下半年的實務裡，瀏覽器代理混合使用 DOM 抓取、螢幕截圖檢查、以及（有提供時）結構化協定存取。結構化協定層是真的，但它不是普及的。大多數瀏覽器代理在 DOM 抓取失敗時，仍然依賴視覺當備援。
3.5 影片（短片、螢幕錄影、監視影像）
影片是最稀有、最貴的輸入層。Gemini 仍然是原生影片理解最自然的選擇；封閉 frontier 模型有支援影片的，但定價相對應。2026 年的務實模式是把影片當成一個取樣問題：找出關鍵影格、講者輪替、狀態轉換的瞬間，把挑選過的子集餵給推理模型。把一整個小時的影像一個 token 一個 token 倒進去，幾乎永遠不是正解。
4. 原生 vs 組合：架構問題
2026 下半年最重要的架構決策，是要做一個多模態原生代理（一個模型、每個模態、單一前向傳遞），還是一個組合專家代理（一個路由器，把工作分派給專門的視覺、音訊、文件、文字模型，再把結果接起來）。
兩者都行。沒有哪個永遠對。決策歸結到四個變數。
4.1 變數 1 — 延遲預算
多模態原生代理打一次模型。組合代理打好幾次。如果你有低於一秒、端對端的硬延遲預算，組合幾乎不可行。如果你的預算兩到 5 秒，兩者都做得到。如果你的預算十秒以上，組合常常是更好的答案，因為每個專家可以各自最佳化。
4.2 變數 2 — 每個模態的品質天花板
2026 frontier 多模態原生模型在視覺與文字上很優秀。它們在音訊上參差。在影片上最弱。如果你產品的差異化是「我們比誰都理解音訊」，那麼用專屬音訊模型的組合堆疊是對的。如果你產品的差異化是「我們理解文件與截圖」，多模態原生模型通常就夠好了。
4.3 變數 3 — 成本天花板
多模態原生呼叫通常按 token 數統一計價，把圖與音算成 token。組合堆疊讓你為容易的模態挑便宜的專家，把 frontier 模型留給推理那一步。在大多數輸入是音訊或影片、只有一小部分需要深度推理的工作負載上，組合堆疊可以比原生便宜 30% 到 60%。
4.4 變數 4 — 維運複雜度
多模態原生代理只有一套可觀測性、一個提示管理介面、一條評測管線。組合代理有好幾套。對於沒有專職 AI 基礎建設平台工程師的團隊，較簡單的架構多半會勝出。
誠實的總結：先從多模態原生代理開始。只有當某個模態是專家明顯更好或明顯更便宜、且你有團隊能維運時，才走向組合。
5. 2026 下半年的真實模型版圖
值得用具體的選項談談 2026 Q4 真正出貨的東西。下面的清單不完整。它是正式產品團隊此刻真正在多模態代理之間抉擇的那個短清單。
- GPT-5.5——通用多模態推理、程式碼、工具呼叫。全面智慧都很強。定價頂級。同一個模型又要對輸入做推理又要採取行動時，這是預設選擇。
- Claude Opus 4.8——細緻的視覺推理、文件排版、螢幕截圖除錯、長時代理工作的最佳選擇。延遲頂級。當引用與接地品質比吞吐量更重要時的選擇。
- Gemini 3.5 Flash——穩定、快速、搜尋接地、1M token 上下文。當延遲很重要、又無法承受 preview 風險的高量多模態代理選擇。
- Gemini 3.1 Pro Preview——preview 等級模型，更強的多模態理解與更長的上下文。當智慧比穩定性重要、且你能吸收 preview 風險時的選擇。
- Llama 4 Maverick——開源權重在圖文工作上的首選，當客製化、自架託管、私有部署很重要的時候。品質隨託管商而異；自架可行但不是免費。
- Grok 4.3——當工作流包含網路或 X 搜尋、且代理需要新鮮多模態接地時的選擇。不是通用首選。
- Qwen3-VL 系列——值得特別提出。2026 下半年有幾個 Qwen3-VL 開源權重模型已經到達正式產品等級的文件與圖表理解，權重可以在 8B 到 32B 的範圍自架。如果你在自架，且你的工作負載偏文件，這是開源權重版圖上值得關注的一段。
陷阱是把這份清單當成排名。它不是。每個選項都對應特定形狀的工作負載最佳。按 benchmark 數字選，而不是按你自己的評測集選，是在這類別裡你能犯的最貴的錯。
6. 正式產品中真正跑得動的模式
2026 年我們看過的所有正式產品多模態部署中，有幾個模式反覆出現。它們不是理論。它們是和真實使用者碰撞之後留下來的那幾個。
6.1 截圖先行的客服
開頭故事裡那個 67% 解決率的模式：代理預期使用者的第一個輸入可能是圖；如果收到的文字是在描述 UI 問題，就提示要圖；把推理接地到圖的區域。模型在提議動作時，會指出它讀的是截圖的哪個部分。
6.2 音訊 + 文字 + 檢索的會議代理
兩段式管線（用帶時間戳與講者標籤的方式轉寫，再對逐字稿做推理並搭配檢索）是會議助理的預設架構。有趣的細節：檢索這一步不只是文件。還包含先前的決策、先前的工單、跟同一個客戶先前的對話。沒有檢索的會議代理通常解不掉「上禮拜那場會議」這種指涉。
6.3 帶引用區域的文件接地
在發票處理、合約審閱、表單抽取上，跑得動的模式是：模型讀文件、模型提結構化輸出、每一個輸出欄位都被接地到它來自的邊界框或頁面。任何人只要點過去就可以稽核任何一個欄位。可稽核性才是真正的產品；抽取是容易的部分。
6.4 DOM 優先、截圖備援的瀏覽器代理
2026 下半年的瀏覽器代理把 DOM 抓取當主路徑，當 DOM 抓取失敗、或頁面夠動態以至於 DOM 狀態與視覺狀態對不起來時，再用視覺當備援。要避免的錯誤，是把視覺當主路徑。它在同樣的工作流上比 DOM 抓取貴 2 到 5 倍、慢 3 到 10 倍。
6.5 影片當關鍵影格取樣
在產品示範、訓練短片、監視影像審查上，跑得動的模式是：抽取關鍵影格與講者輪替，把挑選過的子集餵給推理模型，並讓代理在需要時再去要更多影像。把整個小時的影片當成原始輸入倒進去，幾乎永遠不是正解。十秒的剪輯配上正確的影格，通常就夠了。
7. 什麼時候多模態是對的選擇，什麼時候不是
值得直接講清楚。多模態不是預設升級。它是工作負載特定的架構選擇。
多模態是對的選擇，當：
- 你的使用者天生就會傳富媒體（照片、截圖、音訊片段、PDF），你的純文字代理正強迫他們在使用產品之前把輸入壓平。
- 你的差異化仰賴把答案接地到輸入的特定區域（引用、邊界框、時間戳），而不是接地到抽象事實。
- 你的資料結構上就是多模態——附帶截圖的通話記錄、加上病歷註記的醫療影像、帶逐字稿的影片證據——跨模態的連結本身就是價值。
- 你的產品介面已經有豐富的輸入介面（相機、麥克風、檔案上傳），你的純文字後端是使用者能做什麼的限制因素。
多模態是錯的選擇，當：
- 你的工作負載壓倒性是文字、平均輸入只有幾百個 token。加上視覺的邊際效益小；支援它的邊際成本是真的。
- 你的延遲預算很緊，多模態來回增加的延遲你撐不住。組合專家或純文字可能是正解。
- 你沒有評測多模態輸出的辦法。2026 大多數團隊的評測集仍然有九成是文字。用一個文字評測集去跑多模態代理，幾乎告訴你任何事情它有沒有在工作。
- 你的客戶在意絕對的資料最小化，把內容送到第三方多模態模型是不可行的。對這些工作負載，自架開源權重多模態是對的答案，但前提是你有團隊能維運。
- 你把多模態當行銷賣點而不是產品需求。支援一個你不需要的模組的成本很少是零。
誠實的總結：當產品沒有多模態就上不了線的時候，再加一個模態。不要因為主題演講這樣說就加。
8. 常見地雷
- 假設 frontier 模型在每個模態都最強。2026 下半年 frontier 在不同模態上並不平均。音訊、影片、某些文件類型仍然有利於專家。相信你的評測集，不要相信行銷頁。
- 把一切都壓平回文字再展開。如果你的管線把圖變描述、對描述做推理、再把推理變回圖，你是在丟資訊。能保留模態原生就盡量保留到管線深處。
- 沒有為多模態儲存與檢索編列預算。圖與音比文字大。如果你的檢索層是純文字的，你的代理會在需要查找前一張圖時無聲失敗。從第一天就把多模態放進檢索層。
- 跳過評測集。一個沒有評測集的多模態代理是一個展示品。打造完第一個問題是：它失敗的時候看起來像什麼？如果你沒辦法用具體案例回答，你沒有評測集。
- 忽略 token-as-image 的成本。大多數 frontier 供應商把圖按 token 計價，一張高解析度截圖可能是 1,500 到 4,000 個 token。一次 10 輪的代理迴圈，每輪 5 張截圖，光是輸入就有 75,000 到 200,000 個 token。要測的是每次完成工作流的成本，不是每次呼叫的成本。
- 把 OCR 跟文件理解搞混。OCR 給你文字。文件理解給你排版、結構、表格、引用、交叉參照。產品是後面那一個。如果你的代理用 OCR 就停在那裡，它是用 2026 模型跑的 2023 架構。
- 無條件信任截圖輸入。使用者可以傳任何頁面的截圖，包括假儀表板、釣魚網站、刻意誤導的 mockup。你的 prompt-injection 防禦需要把截圖當成對抗式輸入。套用在網頁內容上的同樣規則，套用在任何使用者展示給模型的東西上。
- 把多模態當成 UI 噱頭。一個不能用好的麥克風按鈕，比沒有麥克風按鈕更糟。如果你出了多模態輸入的介面，它必須可靠。2026 年的使用者會注意到壞掉的轉錄、讀錯的圖表、憑空捏造的 UI 元件。
9. 90 天打造者檢查清單
如果你 2026 Q4 開始一個多模態代理專案，你有 90 天，這個順序能用最低風險產出最高價值。
- 把你代理今天收到的每一個輸入按模態列出來。找出那些被迫壓平為文字的輸入。它們是你原生多模態的候選人。
- 挑出壓平傷害最大的那一層輸入。2026 大多數產品，這一層是截圖、音訊逐字稿、或文件理解。從這裡開始。
- 用你自己產品的 50 到 100 個真實範例建立一個多模態評測集，附 ground-truth 輸出與已知失敗模式。不要從公開 benchmark 開始。你的工作負載不是 benchmark。
- 在你的評測集上，把多模態原生 frontier 模型與組合專家堆疊面對面比一場。量品質、量延遲、量每次工作流的成本。讓數字選架構。
- 先出最簡單的端對端版本：一個模型、一個提示、一層檢索、一條評測管線。不要過早組合。
- 在你擴展之前，把多模態儲存與檢索補上。圖嵌入、音訊嵌入、文件區域索引——早點把它們建進去。之後再回頭補是痛苦的。
- 把引用與接地能力加進每一個輸出。任何碰觸使用者輸入的論點，都應該可以被錨到一個區域、時間戳、或頁面。可稽核性就是產品。
- 把多模態接入你的可觀測堆疊。每個模態的 token 數、每個模態的成本、每個模態的延遲、每個模態的失敗率。2026 大多數團隊在模態層上仍然是瞎的。
- 設定每季模型審查節奏。2026 下半年的 frontier 比 2024 年的純文字 frontier 移動得更快。2026 Q4 對的，2027 Q2 會錯。每季重訪評測集。
10. 快速比較：挑對的模態堆疊
| 工作負載形狀 | 最佳預設 | 強勁替代方案 | 要注意 |
|---|---|---|---|
| 截圖 / UI 除錯 | Claude Opus 4.8 | GPT-5.5、Gemini 3.5 Flash | 歧義 UI 上的引用品質 |
| 帶引用的文件抽取 | Claude Opus 4.8 | Gemini 3.1 Pro Preview、Qwen3-VL | 跨頁參照、註腳 |
| 圖表與示意圖推理 | Claude Opus 4.8 | GPT-5.5、Gemini 3.5 Flash | 數字精度、座標軸標籤 |
| 長影片 / 短片分析 | Gemini 3.1 Pro Preview | Gemini 3.5 Flash 配關鍵影格取樣 | 整片通過的成本；延遲 |
| 即時語音 + 推理 | 兩段式：即時音訊 + GPT-5.5 / Claude Opus 4.8 | 各家原生統一語音模型 | 音訊與推理之間的接縫 |
| 高量文件代理 | Gemini 3.5 Flash | Qwen3-VL 自架 | 穩定性 vs preview 風險 |
| 自架 / 私有多模態 | Llama 4 Maverick | Qwen3-VL 系列 | 託管品質、評測漂移 |
| 搜尋接地的視覺推理 | Grok 4.3 | Gemini 3.5 Flash 配搜尋 | 搜尋結果新鮮度的相依性 |
| 通用程式碼 + 截圖審查 | GPT-5.5 | Claude Opus 4.8 | 延遲與深度的取捨 |
11. 常見問題
多模態到 2026 下半年真的已經到正式產品等級了嗎？
對視覺、文件、大多數工作流的音訊，是的。對正式產品規模的影片與即時語音，它是真的但不平均——正解架構是組合兩段式管線，不是單一統一模型呼叫。對正式產品品質的自架多模態，它是窄任務上可行，但還不是 frontier 模型的替代品。
我該做多模態原生代理還是組合堆疊？
先做多模態原生。最簡單的架構，一個模型、一個提示、一條評測管線，是對的答案，除非你有某個模態是專家明顯更好或明顯更便宜。大多數團隊永遠不需要組合。
開源權重多模態模型夠好了嗎？
對文件與圖表為主的工作負載，夠了。Llama 4 Maverick 跟幾個 Qwen3-VL 變體在這些任務上是正式產品等級。對開放式推理的 frontier，閉模型仍然有實質領先。把你的架構當差距會縮小來規畫，不要當差距會維持來規畫。
團隊在多模態上最常犯的最大錯誤是什麼？
跳過評測集。一個沒有評測集的多模態代理是展示品。在你出貨任何東西之前，從你自己的產品抓 50–100 個真實案例，附 ground-truth 輸出與已知失敗模式。
多模態實際成本是多少？
視覺：依解析度，每張圖大約等於幾百到幾千個文字 token。音訊：大致是逐字稿的成本加上一點推理加成。影片：通常比等效文字工作流貴 5 到 20 倍。要測的是每次完成工作流的成本，不是每次呼叫的成本。
我需要擔心透過截圖進來的 prompt injection 嗎？
要。截圖是使用者供應的內容。用你對待網頁內容的那套對抗式輸入紀律來對待它。保護你對抗 prompt injection 的那些規則，同樣保護你對抗圖片輸入的 prompt injection。
12. 結語
2026 下半年誠實的總結是這樣：多模態不再是你打開的功能。它是你繞著設計的輸入層。會在這個類別勝出的團隊，是那些挑出能滿足工作負載的最簡架構、建立真正的多模態評測集、把每一個輸出都接地到產生它的輸入、並且在沒有具體理由時抗拒組裝誘惑的團隊。會輸的團隊，是那些把多模態當行銷賣點、出了一個不能用的麥克風按鈕、無驗證地相信圖片而不防禦 prompt injection、或是按 benchmark 數字而不是按自己評測集選模型的團隊。
如果你只能從這份指南帶走一件事，帶走這個：把代理設計成每一個輸入都可能多模態，然後刻意排除那些不值得成本的模態。這是一個能出貨的代理，跟一個能展示的代理之間的差別。