Qwen3.8-Omni-Flash：長影音成為 Agent 輸入，真正突破在哪？（2026）

Qwen 官方發布頁標示 2026 年 9 月 18 日，Qwen 團隊在該頁刊出〈Qwen3.8-Omni-Flash: Omni Senses. Agentic Delivery.〉，把 Qwen3.8-Omni-Flash 描述成一個能同時接收文字、圖片、音訊與影片，並把理解接到規劃、工具呼叫與工作交付的全模態模型。這篇發布最值得看的，不是又多了一個「1M context」標籤，而是 Qwen 想把長影音從聊天附件變成 Agent 可以搜尋、取證、操作與延續工作的輸入。

市場確實迅速注意到它：截至 2026 年 9 月 19 日 06:18（台北時間），對應的 Hacker News 討論累積 325 點與 123 則留言。這只代表關注度，不代表技術主張已被驗證。下面先忠實整理原文，再對照產品文件與公開 benchmark，最後判斷這次進步究竟發生在模型、Harness，還是整套工具鏈。

Qwen3.8-Omni-Flash 想改寫的，不只是多模態輸入

原文的核心命題可以濃縮成一句：過去的多模態模型負責「看懂」，這次 Qwen 想讓影音進入完整的 Agent 迴路。

advancing omnimodal models from “understanding omnimodal content” to “planning tasks, calling tools, and completing creative work.”

中文：讓全模態模型從「理解全模態內容」，走向「規劃任務、呼叫工具並完成創作工作」。

Qwen Team，官方發布文章

但這句話裡其實包了四個不同層次。把它們拆開，才不會把一套系統的成果全算到單一模型頭上。

層次	它真正負責什麼	讀者應注意的邊界
qwen3.8-omni-flash	接收文字、圖片、音訊與影片，做理解、推理、規劃與 function calling	官方產品表列出的輸出是文字；工具由外部程式執行
qwen3.8-omni-flash-realtime	Qwen 發布文另行介紹它處理連續鏡頭與聲音、即時對話與音訊回覆	這是另一個 Realtime 型號與連線介面；現行主產品文件尚未完整列出其價格與限制
Qwen-MM-Plugins	補上影音切段、記憶、Video2Note、剪輯與 Skill 產製等工具	完成影片往往還要呼叫 ffmpeg、生成模型或其他服務
Qwen-Live Harness	發布圖與公開套件顯示它管理 context、memory、sub-agent、工具與連續互動	Agent 的穩定性取決於這一層如何保存狀態、重試與驗證

1M context 不是重點，會不會找對片段才是

QwenCloud 的 9 月 18 日 changelog把 Qwen3.8-Omni-Flash 列為最高 1M token context，並確認可原生接收文字、圖片、音訊與影片。Alibaba Model Studio 的型號文件則列出檔案上限：影片最長 2 小時、音訊最長 3 小時；同頁的影片 token 估算範例把抽取影格上限設為 2,048。Qwen 發布文的會議案例另稱原生支援最長 1 小時影音輸入。這些不是同一種上限，也不能證明整段內容有同等召回率。

Qwen 真正有意思的做法，是讓 Agent 先讀問題，再決定要看哪一段、聽哪一段。原文在 OmniVideoBench 上比較同一模型的兩種路徑：靜態理解得到 63.4 分，每題使用 145,736 tokens；加入 Qwen Code 做多輪粗到細證據搜尋後，分數升到 67.8，tokens 降到 79,117，Qwen 換算為減少約 45.7%。

這組數字仍是 Qwen 的發布日實驗，但它揭示了一個比 context 上限更重要的方向：長影音工作不應等同於把每一幀塞進 prompt。有效系統要先定位證據、保留時間戳，再只把相關片段送進推理。Qwen 將差異連結到粗到細的選擇性取證與跨回合 context 保留；這組比較沒有 component ablation，不能把 45.7% 單獨歸因於模型、memory 或 Harness。

模型會呼叫工具，不等於模型自己完成影片

原文展示 Music2MV、短劇翻譯、長片解說、Video2Note 與從示範影片建立 Skill 等工作流。這些展示的價值，是讓使用者用一句需求啟動完整流程；但從工程邊界看，function calling只會讓模型輸出結構化的工具指令，真正的下載、剪輯、配音、渲染與檔案寫入仍由 Client、Harness 與外部服務完成。

這不是缺點，反而是產品化的正常方式。問題只在於命名：如果把「模型 + Harness + Plugins + 其他媒體服務」的結果說成單一模型能力，之後就很難知道錯誤該在哪一層修。Qwen 自己的架構圖其實很誠實：主 Agent 周圍還有 context manager、內外部 memory、sub-agents、monitor 與 search／code／retrieval tools。

同樣要分清楚基礎型號與 Realtime 型號。前者的官方產品表是多模態輸入、文字輸出；Qwen 發布文另行介紹的 Realtime 型號才處理連續鏡頭、麥克風與音訊回覆。截至本文查核，主產品目錄、價格與 rate-limit 文件仍未完整列出這個新 Realtime 型號，因此不能把發布示意圖直接套成基礎 API 的能力或可用性承諾。

Qwen3.8-Omni-Flash Benchmark 很亮眼，但測到的是模型乘上 Harness

Qwen 報告的代表性結果包括 WildClawBench-MM 71.0、UniClawBench 69.6、AgenticVBench 36.8，以及 OmniVideoBench 63.4。和 Qwen3.5-Omni-Plus 相比，WildClawBench-MM 提高 36.5 分、AgenticVBench 提高 22.3 分；在主表的靜態理解數值裡，Gemini 3.8 Flash 在 AgenticVBench、OmniGAIA、OmniVideoBench、Video-MME-v2 與 LVOmniBench 高於 Qwen3.8-Omni-Flash。但改用同一個 Qwen Code Harness 比較三項長影音測試時，Gemini 在 OmniVideoBench 以 70.1 對 67.8、Video-MME-v2 以 72.7 對 71.3 領先，Qwen 則在 LVOmniBench 以 73.6 對 70.7 反超。這不是全面碾壓，而是任務與執行框架都會改變勝負。

更關鍵的是測試 Harness 並不一致。Qwen 的註腳寫明：WildClawBench-MM 與 AgenticVBench 用 Claude Code，UniClawBench 用 OpenClaw，OmniGAIA 不使用 Agent framework；長影音的 Agentic Understanding 比較則加入 Qwen Code。AgenticVBench本身也把 Harness 視為結果的一部分。當模型、可用工具、上下文壓縮、重試策略與評分器一起改變時，最終分數測到的是整套 Agent system。

原文還說 29 項評測平均提升超過 25%。這是 Qwen 自行彙整、但未公開聚合公式的跨評測主張：表格同時混合愈高愈好的分數、愈低愈好的錯誤率，以及 DER／cpWER 等多欄位結果，因此不能把畫面上的數字直接做普通平均重算。比較安全的讀法，是逐項看你真正要用的任務，而不是用一個總平均替代產品驗收。

原文另有一個尚未經外部重現的模型優化案例：Qwen 稱 Agent 在 12 小時、四輪實驗中建立 3,413 筆訓練樣本，使 Qwen2.5-Omni-3B 在 WenetSpeech-Chuan 的 CER 由 25.79% 降至 15.30%，相對下降約 40.7%。發布文沒有提供足以獨立重現的完整資料與訓練設定，也沒有拆出模型、Harness、資料管線、訓練評測迴路或預先準備環境各自的貢獻，因此目前只能視為公司自報案例。

成本下降很大，但那是特定計價假設

Qwen 宣稱相較 Qwen3.5-Omni-Plus，每小時音訊輸入價格下降超過 98%，影音輸入下降超過 93%。原文也公開計算方法：用 2 分鐘素材的輸入成本乘以 30；影音採 720p、每秒 1 幀；Gemini 3.8 Flash 設 media_resolution=high，Seed 2.0 Lite 設 max_frame_tokens=384，其餘 API 參數使用預設。

因此這個比較能回答「在同一組發布方假設下，媒體 token 費用差多少」，卻不能直接回答「一支成片的總成本差多少」。剪輯、配音、影像或影片生成、搜尋、儲存、失敗重試與人工返工都在模型輸入費之外。對長影音 Agent 而言，最重要的成本指標應是每個成功交付任務的總成本，而不是單獨一小時媒體的 ingestion 價格。

我同意什麼，也存疑什麼

我同意：影音正在從「內容」變成「可操作的工作記憶」

把語音、畫面、時間軸與工具呼叫放在同一個工作迴路，確實比「先轉錄，再把幾張截圖丟給文字模型」更有潛力。特別是會議、教學影片、長片素材與現場互動，問題通常跨越人物、聲音與畫面；只保留逐字稿會丟掉指涉、動作與空間資訊。

我存疑：1M 與漂亮 Demo 還不足以證明長時穩定性

Context 上限只告訴你請求可以多大，沒有告訴你第 1 分鐘與第 119 分鐘的細節能否同樣可靠地被找回。發布文展示多個成功案例，但未公開失敗率、完整 traces 或 recovery 統計；真正的生產問題是錯片段、錯說話者、工具失敗、外部 API 超時與錯誤累積後，系統能不能知道自己該重試、回滾或請人介入。

真正的護城河，可能在 Harness 而不只在模型

Qwen 這次可供開發者直接檢查與改造的材料，主要落在 Qwen-MM-Plugins 與相關 Harness。截至 2026 年 9 月 19 日本文查核，此次發布頁與官方產品文件提供的 Qwen3.8-Omni-Flash 入口是 Qianwen／DashScope／Alibaba Model Studio API；本文未找到該型號的官方權重下載連結。這個取向很務實：先把工具鏈做通，開發者很快就能做產品。但也代表評估時必須把「模型品質」與「整合工程品質」分開記錄，否則換一個 Harness，結論可能跟著改變。

如果你要試，請用四個數字驗收

1. 證據召回率：先為一段 30–120 分鐘素材標出答案與時間戳，看系統是否找到正確片段，而不只是生成流暢摘要。
2. 端到端任務成功率：把「理解正確」與「工具真的完成剪輯、寄信或建任務」分開計分。
3. 每次成功交付成本：把模型 tokens、搜尋、媒體生成、重試與人工返工全部放進同一分母。
4. 可追溯性：要求答案保留時間戳、畫面或音訊證據，以及每次 tool call 的輸入、輸出與失敗原因。

最有意義的 A/B 不是「Qwen3.8-Omni-Flash 對另一顆模型」，而是同一批素材、同一組工具、同一個驗收答案下，比較傳統 ASR＋抽幀＋檢索流程，和 Omni 模型＋Agentic evidence gathering。這樣才能知道被移除或轉移到 Harness／Plugins 的 pipeline 複雜度，有沒有換來更高的正確率、更低的總成本與更少的營運負擔。