Gemini Agentic Video：Google 自測最高省 88% Token，7% 怎麼算？（2026）

2026 年 9 月 1 日，Google DeepMind 資深產品經理 Rohan Doshi 與研究總監 Mario Lučić 在 Google 官方部落格發布〈Introducing agentic video understanding with Gemini〉，把 Gemini Agentic Video 帶到 Gemini 3.7 Flash、3.6 Flash 與 3.5 Flash-Lite。它改變的不是影片能不能丟給模型，而是模型是否還要按固定速率先「看完」再回答。

Google 公布的三個頭條數字是：Token 最多減少 88%、單次分析成本最多降低 66%、問答準確率的相對增幅最高約 7%（不是增加 7 個百分點）。這些結果值得注意，但全都是 Google 在特定長影片問答基準上的最高值，不是每支影片、每個模型或每種任務都能得到的保證。真正重要的變化，是長影片理解從一次性輸入，變成依問題反覆找證據的迴圈。

先把原文放在桌上。點擊下面的瀏覽器畫面會在新分頁開啟 Google 原文；接下來先忠實整理它如何運作，再把 88%、66% 與 7% 的分母拆開，最後說明這套方法何時值得用、何時反而要保留靜態處理。

原文在講什麼：把影片分析從「搬運」改成「搜尋」

Gemini 原本就能接收影片。預設的 static 模式會以固定速率抽取影格；目前官方文件寫的是每秒 1 張，再把影格、音訊與時間資訊放進上下文。這個做法直接，但影片越長，模型還沒回答問題，輸入端就先累積大量與問題無關的內容。

Agentic 模式把順序反過來：先讀問題，再決定該去哪一段找證據、要看影格、聽音訊，還是先查逐字稿；如果線索不夠，就換時間區間或調整影格率再看一次。原文把核心濃縮成這句：

“fetching only the moments and signals needed.”

中文：「只取回答問題所需要的片段與訊號。」

Google，2026 年 9 月 1 日

因此，Gemini Agentic Video 不是把整支影片壓縮成更少 Token，而是讓模型擁有一個可反覆呼叫的影片觀察工具。Google 列出的應用包括找出不到一秒的狀態變化、在數小時影片中尋找特定事件、提高可疑區段的取樣率，以及重看片段來計數動作或物件。這些是產品能力與示範方向；它們不能只靠後面的選擇題準確率，直接視為已全面驗證。

Gemini Agentic Video 如何工作？

Google 的流程圖是 Query → Gemini → Observation → Think → 再 Observation，直到產生 Output。可用的觀察來源有三種：特定時間段的影格、音訊或逐字稿。這更像研究者先翻目錄，再跳到相關章節核對，而不是從第一頁一路影印到最後一頁。

這個迴圈在 Interactions API 回應中不是完全不可見。Gemini API 影片理解文件說明，interaction.steps 會出現 processing_call 與 processing_result；開發者可以用它確認模型確實動態瀏覽過影片，也可以在介面顯示進度。若使用無狀態多輪對話，下一次請求還必須帶回完整步驟，否則影片脈絡會遺失、後續答案品質可能明顯下降；帶回的步驟也會計入輸入 Token。

兩種 API 的啟用欄位不同：Interactions API 在影片輸入設定 processing: "agentic"；GenerateContent API 則在 Part 設 media_processing="AGENTIC"（JavaScript 為 mediaProcessing），並以 MEDIA_PROCESSING 類型的 tool_call／tool_response 呈現導覽步驟。9 月 1 日的 Gemini API 變更紀錄確認兩者都已支援。9 月 2 日 GA 的 Gemini 3.8 Flash，目前也已列入支援清單；所以「3.7、3.6、3.5 Flash-Lite」是首發陣容，不是截至本文查核日的完整現況。

Gemini Agentic Video 的 88% Token 少在哪裡？

Google 的公開圖表只列出 Gemini 3.7 Flash，設定為高思考強度、低媒體解析度，並以 static 1 FPS 作基準。三個測試的 Token 變化並不一致：

測試集	Static	Agentic	Token 降幅	準確度變化
MINERVA	80.9K	33.6K	約 58.4%	73.7% → 79.0%
1H-VideoQA	397.6K	47.7K	約 88.0%	87.5% → 88.5%
LVBench	300.3K	36.0K	約 88.0%	85.1% → 88.6%

原文的說法是：

“reduce analysis costs by up to 66% and token consumption by up to 88%”

中文：「分析成本最多降低 66%，Token 消耗最多減少 88%。」

Google，2026 年 9 月 1 日

最關鍵的三個字是「up to」。88% 是 1H-VideoQA 與 LVBench 兩列的最好結果；MINERVA 為約 58.4%。在 9 月 1 日公開文章與圖表中，看不到逐題 Token、提示詞、重跑次數、信賴區間、確切模型 snapshot 或完整可重現腳本。因此它能支持「在這些條件下，每次查詢的 Token 消耗大幅下降」，不能支持「所有長影片固定省 88%」。

測試集本身也有邊界。MINERVA 論文描述的是 1,515 題、223 支影片、平均長度約 12 分鐘的五選一問答；LVBench 論文則使用 103 支、合計 117 小時的高畫質影片，且明確排除過度快速剪接、鏡頭晃動與低光源內容。這些基準能測長影片推理，卻不能代替所有監視、運動、醫療或劣化影像場景的驗收。

還有一個總分回答不了的問題：增益到底來自哪種模態？MINERVA 有些題目需要影格與 ASR，1H-VideoQA 的公開說明稱題目可由視覺作答，而 LVBench 直接排除音訊。Google 沒有公布影格、音訊與逐字稿的 ablation，因此不能把 7% 增幅歸因於任何單一機制。

「準確度提高 7%」不是多 7 個百分點

圖表中最大的準確度改善出現在 MINERVA：73.7% 升到 79.0%，差距是 5.3 個百分點；若用 73.7% 當分母計算相對增幅，則約為 7.2%，四捨五入後才成為原文的「up to 7%」。1H-VideoQA 只增加 1.0 個百分點，LVBench 增加 3.5 個百分點。

這不是吹毛求疵。百分點回答「分數差多少」，相對百分比回答「相對原分數增加多少」；兩者混用，會讓改善看起來比實際分數差距更大。更重要的是，三列量到的都是影片問答準確率，並沒有分別公布不到一秒的定位誤差、異常偵測 precision／recall，或計數任務的誤差分布。因此「7% 更準」應限定為 Google 這組問答測試的相對最高值。

66% 成本下降，為什麼不是 88%？

Token 變少不會必然等比例反映在帳單上。官方計價把輸入 Token 與輸出／思考 Token 分開定價；Agentic 回應也會分別記錄導覽產生的 thought tokens，以及載入影格、音訊或逐字稿的 tool-use tokens。不過 Google 沒有公開這組測試的逐類 Token 與費用明細，因此只能確認其自家測試宣稱「Token 最多減少 88%、成本最多降低 66%」，不能斷言兩者差距由哪一類 Token 造成。

圖上的 3.7 Flash static 點約在每次查詢 0.30 美元，Agentic 點約在 0.10 美元附近，但座標沒有印出精確數字。Google 也沒有公開 47.7K Token 如何分成媒體輸入、導覽思考、工具結果與最終輸出，所以外部無法從圖表完整重建 66% 的帳單。較安全的讀法是：Google 在 1H-VideoQA 與當時價格設定下觀察到成本約少三分之二；實際金額仍會隨模型、問題、影片與計費層級變化。

原文同時說明這項能力沿用標準 Gemini API Token 計價，沒有另外收取功能費。這代表導入門檻不是加購模組，但不代表每次請求都會更便宜。真正的成本驗收應直接讀 API 的 usage 欄位，按自己的任務分布比較 static 與 agentic，而不是把宣傳圖的最高值寫進預算。

最大的優勢，也是最大的風險：模型決定「哪裡值得看」

這套架構之所以省，是因為它不求平均覆蓋。對「講者何時第一次提到退款政策？」這類有明確線索、答案集中在少數片段的問題，先搜逐字稿、再回到影格核對，通常比把兩小時內容全部塞進上下文合理。

但如果問題是「整段影片是否曾短暫出現過危險動作？」或「所有零件總共出現幾次？」，錯過一次就可能讓結論失敗。若第一輪粗搜尋沒有定位到正確區間，後續高解析重看便不會自動補回那段證據。效率通常來自不再以相同密度載入所有模態；這不等於已證明完整視覺覆蓋，高召回任務仍需另行驗收。

一份與 Google 產品無關、但研究相同方法的 LensWalk 論文提供了很好的反例。研究者觀察到代理式影片系統可能過早結案、被第一個高頻線索帶走、持續盯著同一時間區段，或因觀察太多無關內容而稀釋早期證據。這不能證明 Gemini 會以相同比例失敗，卻說明「讓模型自己挑畫面」需要專門測試搜尋策略，而不只測最後答案。

同一篇 LensWalk 研究在共享 o3 reasoner 的 LVBench 比較中，準確率由 57.1% 升到 68.6%，但線上推論時間也由 38.9 秒增至 190.35 秒，約為 4.9 倍。這不是 Gemini 實測，也不能直接套到 Google API；它只證明代理式選擇觀看可能以更多工具往返與等待時間換取準確度。

少 Token 也不等於更快：部署還有三個隱藏成本

1. 第一個字可能更慢。官方文件明確提醒，短於 5 分鐘的影片可能因內部推理與工具往返，稍微增加 Time to First Token。若產品在意即時回應，不能只看總 Token。
2. 多輪狀態需要保存。無狀態模式若漏傳 processing_call 與 processing_result，後續問題會失去影片脈絡；完整重傳又會增加輸入 Token。
3. 可觀測性還不等於完整證據鏈。目前回應步驟能證明動態處理發生，但公開範例沒有把每一次實際請求的時間區間、模態與取樣參數完整呈現給應用端。高風險流程仍需要保存輸入版本、usage、延遲、答案與人工抽查結果。

官方仍保留 static，適合短片、延遲敏感，或需要全片採固定取樣策略的工作；但 static 預設仍只有 1 FPS，不等於真正逐格檢查。快動作、全片計數或高召回安全任務，應提高取樣率、分段做完整覆蓋，必要時再加專用偵測器或雙路徑驗證。同一次請求也能讓不同影片採用不同模式。若要建立自己的成本追蹤，可搭配 AlphaLab 的〈LLM API 成本拆帳：從 Token Trace 到 Chargeback〉設計紀錄欄位。

目前能在哪裡用？Developer API 與企業平台要分開看

截至 2026 年 9 月 3 日，Gemini API 文件列出 3.8 Flash、3.7 Flash、3.6 Flash 與 3.5 Flash-Lite；可處理上傳影片，也可接收公開 YouTube URL。不過 YouTube URL 輸入仍標示為 Preview，而 Gemini API／Google AI Studio 的可用性也受官方國家與地區清單限制，不能寫成所有地區都已開放。

Google 原文也提到 Gemini Enterprise Agent Platform。該平台的專屬功能指南目前把 Agentic video processing 標為 Preview，且限 v1beta1；正式導入前應在實際專案與端點確認。這和三款首發模型本身已是 GA 是兩件不同的事：9 月 1 日推出的是影片處理能力，不是三個模型同日誕生。

原文還預告，這項能力將擴到 Gemini app 的 Flash／Flash-Lite，並在未來數月支援 YouTube 的 Ask YouTube。這兩項都是 Google 於 9 月 1 日使用未來式提出的產品計畫；截至 9 月 3 日，本文不把它們寫成已全面上線。

AlphaLab 的判讀：這是更好的取樣架構，不是一張通用成績單

我同意：長影片應該依問題分配觀看預算

如果一個問題只需要兩分鐘證據，把九十分鐘影片等密度轉成 Token，本來就不是理想配置。Gemini Agentic Video 把「找哪裡、用哪種模態、要不要重看」放進模型的推理迴圈，方向上比固定序列化更符合資訊檢索。更難得的是，它已經進入 API，而不只停在論文架構圖。

我同意：88% 即使不是保證，仍揭露了長影片的成本結構

三個基準都減少 Token，幅度從約 58.4% 到 88%，這個方向與機制一致。對答案高度集中在少數片段的問題，完整輸入更可能造成浪費。它值得團隊立刻做 A/B 測試，也讓「先檢索、後細看」成為影片系統的合理預設候選。

我存疑：Google 把四種應用，壓在一種問答分數下面

不到一秒定位、異常偵測、計數與長影片問答，需要的錯誤函數並不相同。選擇題答對率不能告訴你時間戳差幾毫秒，也不能告訴你異常漏報率。若產品真的要剪輯、安防或品管，應用自己的連續時間 ground truth、precision／recall 與計數誤差驗收，不能拿 7% 的相對問答增幅代替。

我存疑：公開證據仍不足以估計穩定性

Google 公開了圖、條件與三列結果，卻沒有逐題輸出、trial、變異、錯誤分布與工具軌跡。這讓外界看得到能力方向，卻看不到同一題重跑會不會選到不同片段。下一個真正有價值的更新，不是再多一個「up to」，而是可重跑的資料 snapshot、逐題 usage、失敗案例與延遲分布。

要不要切換 Agentic？用任務風險決定

任務	起始選擇	驗收重點
長課程、會議、訪談中找特定主題	Agentic	答案正確率、引用時間段、總 Token
數小時影片的特定事件定位	Agentic；若漏報代價高，另加固定密度全片掃描	事件級召回率、定位誤差、漏報
短影片且第一個字延遲敏感	Static	TTFT、總延遲、成本
逐影格檢查、全片計數、高召回安全任務	自訂高 FPS 的 static／分段全覆蓋，加專用偵測器或雙路徑	漏報、重複計數、覆蓋率、邊界案例
多輪影片問答	Agentic 可用，但保存狀態	步驟重傳、上下文 Token、後續品質

最務實的上線方式不是直接替換，而是抽一批代表性影片，固定影片檔、提示詞、模型 ID、地區與日期，讓同一組問題各跑 static 與 agentic，且每題重跑數次；再以逐題配對結果比較準確度、召回率、總 Token、媒體／工具／思考 Token、TTFT、總延遲與漏報。需要設計盲測與失敗分類時，可參考〈DeepSeek Vision vs ModLens：24-case A/B 評測方法〉，把「感覺更聰明」改成可對帳的發布門檻。

Google 這次真正推出的，不是「先把所有模態等密度載入再回答」的 AI，而是「會選擇去哪裡細看」的 AI。對長影片，這很可能是更合理的計算方式；對任何漏看一次就會出事的任務，它也把最重要的風險移到搜尋策略。讀 88%、66% 與 7% 時，別只問省了多少，更要問：模型實際載入了哪些證據，是否存在未被充分檢查的區段？