Gemini 4 Hydrogen 解讀：四種思考檔位，怎麼看速度、成本與 Agent 成績？（2026）

2026 年 11 月 12 日，Google 的 Koray Kavukcuoglu 在官方部落格發布了〈Introducing Gemini 4 Hydrogen〉，介紹 Gemini 4 Hydrogen。這次的主角，是偏重日常程式與代理執行的模型：既能獨立工作，也能與 Carbon 分工。值得追問的，是更快的回應，最後能否變成更快交出的正確成果。

先看原文如何安排模型角色，再核對規格與成績的測量條件，最後決定哪些工作值得先試。尤其要分清三件事：單一模型的能力、思考檔位的代價，以及多模型流程的整體結果。

一、Gemini 4 Hydrogen 的定位：把執行速度放進日常工作

Hydrogen is built for rapid execution across diverse agentic workflows.

中文：Hydrogen 的設計重點，是在多樣的代理工作流程中快速執行。

Google，2026 年 11 月 12 日公告節錄

原文的安排很清楚：Carbon、Argon 負責較深、較長的推理；Hydrogen 則面向寫程式、跑測試、查資料與修正產物的迭代。這不是說每一項工作都得組成一支模型隊伍，而是 Google 想把「思考多深」和「執行多快」變成可以按階段調整的選擇。

對照 模型規格頁，Hydrogen 的輸入涵蓋文字、圖片、音訊、影片與 PDF，輸出為文字，並支援工具呼叫、程式執行與結構化輸出。原文展示的網頁、簡報與試算表，應放在模型搭配工具的脈絡理解；一段漂亮的示範，還不能交代不同需求下的完成率。

這與前一篇 Carbon 擴大開放與 /swarm 解讀 的問題不同：那篇看誰能使用深度推理與平行團隊，這次要看執行模型如何在一個工作途中接棒，以及何時值得把推理再調深。

二、四種思考檔位：同一個模型，也有不同的等待與帳單

新版開發文件 列出 low、medium、high、xhigh，預設為 high。文件把較低檔位放在延遲敏感、互動式的工作，把 xhigh 留給 high 表現不足的困難多步任務；並明確提醒，xhigh 會增加延遲與 Token 用量，簡單題可能過度思考。

外部證據方面，截至 2026 年 11 月 13 日查閱，Artificial Analysis 的 Hydrogen xhigh 原始評測頁 列出 Intelligence Index 54 分。這支持它在該套綜合題組中的能力，但指數分數不是工作成功百分比，也不能用 54 分替每一種思考檔位背書。Google 公告的預設 high 為 51 分，應與外部頁面這個 xhigh 條目分開讀。同一 AA 條目也列出每道指數測試任務平均約 13.5 分鐘、US$3.16；這些只描述該評測的 xhigh 配置，不能推回預設 high，也不能當成你的單次呼叫價格。

真正有用的比較，是同一份需求、同一個完成標準下，較深思考究竟救回哪些錯誤。若只是多寫一段說明，卻沒有提高測試通過與引用正確率，多出來的等待就沒有換回你需要的品質。反過來，若能少一次整段重做，較慢的一輪也可能讓總交付更快。

三、Gemini 4 Hydrogen 的百萬 Token：輸入、思考、輸出共用空間

公告把長輸入與長輸出放在一起介紹，落地時則要讀 API 的精確規格：共用視窗為 1,048,576 Token；同步呼叫的預設最大輸出為 65,536 Token；輸出預算也包含思考，不能全當成讀者可見的答案。要超過這個同步上限，須走 long decode；長輸出說明 列出背景執行或客戶端續接等路徑。輸入、思考與輸出會占用同一個總視窗。

可以把它想成同一張工作桌：你攤開的材料、推演中的草稿、最後寫出的答案，都要有位置。百萬容量並非「先塞滿百萬輸入，再額外保證百萬輸出」。準備長文件任務時，應為推理與答案留下空間，並在結束後檢查輸出是否完整、引用是否對得上原文。

容量也不等於讀懂。讓模型在長材料中找回某一行，與要求它跨章節核對矛盾，是不同的考題。Qwen4-Max 預覽的共用輸出預算 提供了另一個對照：規格回答裝得下多少，任務驗收才回答留下來的結論有多少可信。

四、Orchestrator 的 19% 與 24%：先認清是誰的成績

consuming 24% less quota and completing 19% faster.

中文：配額用量減少 24%，完成速度快 19%。

Google，2026 年 11 月 12 日公告節錄

這段原文談的是 Orchestrator 多模型流程在任務成功率接近 Carbon 時，相對 Carbon 的 Google 自報結果，不是 Hydrogen 單獨相對所有模型的提升。Antigravity 團隊原文 描述的機制，是同一條任務軌跡內雙向切換：Carbon 可以先唯讀探索並規劃，Hydrogen 接手修改與測試，遇到阻力再交回 Carbon 重整計畫。它與開多個工作者平行處理的 /swarm 是不同層次的安排。

版本標示也值得保留：截至 11 月 13 日查閱，Google 主公告把這組 Orchestrator 結果寫成 Terminal-Bench 4.0，Antigravity 團隊文章則寫 4.1。兩篇都列出 24% 與 19%，但這個差異尚待釐清。因此，可以忠實轉述 Google 的宣稱，卻不宜把它當成版本已對齊、可直接搬到自家專案的效能常數。

「省配額」還不是「API 帳單打七六折」。配額是產品內部的使用計量；實際 API 費用則要看各模型的輸入、思考與輸出用量，以及工具請求。若切換時重讀上下文、重做規劃，或最後仍需返工，這些都要放回完整工作成本。

原文另稱 Hydrogen 在 Terminal-Bench 4.1 為 57%，相對 3.8 Flash 的 18.2% 有明顯進步。Google 的評測方法 PDF 說明，Hydrogen 這項成績是自行計算，採 mini-swe-agent vision harness、high effort，每題五次後取平均獎勵，並使用作弊調整分數。這組單模型結果不能與前面的 Orchestrator 提升混算，也不是每位使用者都能重現的成功率。原文同段另自報，相對 3.8 Flash，Hydrogen 的預設 high 完成任務快 2.5 倍，捏造陳述減少逾 5 倍；這兩項仍須保留 Google 的報告歸屬，也不能把前述 Terminal-Bench 的評測程序自動套成它們的量測方法。

五、費率與可用入口：快模型，也要把思考用量算進去

依 11 月 13 日查閱的 Gemini API 費率表，Hydrogen 的 Standard 付費層為每百萬一般輸入 Token US$1.50，每百萬輸出 Token US$7.50；輸出計費包含 thinking tokens。這裡只比較 Standard 模型費，沒有把快取、Batch、Flex、搜尋等不同費目混在一起。

以純算術例子說明：10 萬一般輸入 Token 加上 2 萬計費輸出 Token，模型費為 US$0.15＋US$0.15＝US$0.30。如果計費輸出增為 6 萬 Token，則為 US$0.15＋US$0.45＝US$0.60。這是固定假設的算術，沒有替任何真實任務預測用量；它解釋了為什麼相同單價仍可能有不同帳單。

入口也要各自看。Google 主公告宣布向 AI Studio、Gemini API、Gemini app、Search 與企業產品推出；Gemini app 免費使用者的註腳則說，會在適當提示下透過自動選模取得 Hydrogen，不能把這句話擴大成每個免費帳戶都有相同的手動選模入口。

Antigravity 團隊另外寫明：Hydrogen 向付費 Google AI Pro 與 Ultra 訂戶推送，Orchestrator 則向 Google AI Ultra 訂戶推送，企業可透過 Gemini for business 存取兩者。已在推送與自己的帳戶已出現選項，仍是兩件事。這也避免把「能用 Hydrogen」誤當成已具備整套 Orchestrator。

六、原文想說的可靠執行，還要連同限制一起看

原文從程式工作延伸到密集文件、圖表、影片、網頁製作，以及 Gemini app 和 Search 的日常任務，核心訴求是讓快速模型承擔更多完整流程。客戶證言則描述減少來回修正、表格分析與視覺產物的經驗；這些是受訪單位在其條件下的觀察，不宜合併成一個通用增益倍率。

安全部分，公告宣稱減少越界與不實陳述；Hydrogen 模型卡 同時保留了較具體的界線：模型仍可能幻覺、偶爾遲緩或逾時，高思考檔位也可能用更多 Token。其自動化內容安全比較中，無正當理由拒答的指標較 3.8 Flash 增加 5.57 個百分點，而這項指標是越低越好；不能只挑改善項目推論所有面向一起變好。模型卡另說，人工複查被標記的退步，絕大多數屬誤判或不嚴重；這是整體複查的說明，不能據此把拒答指標的上升直接消去。

對要寫入檔案、更新資料或呼叫外部服務的 Agent，這些差異會影響交付：拒答要記為未完成，工具失敗要保留原始回應，越權動作則要在執行前被權限攔住。模型的安全評分和系統允許它做什麼，需要分開驗收。

七、AlphaLab 的判讀：把快用在能被核對的地方

我同意：依任務階段調整推理，比全程固定深度更值得試

規格釐清、局部修改、執行測試與追根因，對推理的要求本來就不同。Hydrogen 與動態切換的合理性，在於可以讓昂貴的探索集中於真正卡住的段落。這個方向有清楚的工程理由；是否划算，則取決於交棒條件能否辨認問題，而不是只認得一句「遇到錯誤」。

我存疑：路由省下的時間，能否抵過誤判與交接

一次提早交回強模型，可能只是多花費用；一次太晚交回，卻可能讓錯誤假設變成數十筆修改。評估 Orchestrator 時，應看它在哪一個狀態切換、帶回哪些證據、是否保留測試失敗的細節。只知道最後用了哪些模型，還不足以解釋一次成功或失敗。

讓驗收獨立於產生答案，速度才有可累積的價值

同一種模型也可以擔任驗證角色，但「多叫一個 Agent」不會自動產生獨立證據。驗證者需要回查原始需求、資料與實際測試，並能拒收看似完整的產物。程式修改可對照 瀏覽器相容與 fallback 驗收，有記憶的代理則可參考 WikiTrace 的進步與退步分開評分；兩者都提醒我們，總分進步不會消除個別退步。

八、現在怎麼試：先挑一段能算清楚的工作

先選一項可復原、已有完成標準的任務，例如修改一個小元件並通過既有測試，或從自有文件產出可逐項核對的表格。保存同一份起點、提示、工具權限與時間上限，先跑目前方案，再比較 Hydrogen 的 high；只有在品質缺口明確時，才加入 medium、xhigh 或可用的 Orchestrator。這是一個建議的比較設計，並非本文已執行的模型測試。

每輪留下合格與否、整段耗時、全部計費用量、失敗重跑與人工修改時間；遇到工具操作，再核對真正留下的檔案或資料狀態，做法可參考 本機測試與雲端保真度的差別。最後用總支出除以合格交付數，而不是只比較第一段文字出現得多快。

Gemini 4 Hydrogen 最值得檢驗的承諾，是讓日常工作更快到達可驗收的終點。先定義那個終點，再選思考深度與交棒方式；若一種配置保住品質、少了返工，速度才真正留在你的工作裡。