Google Antigravity 推出 Orchestrator：Carbon 負責思考、Hydrogen 負責執行，官方測試減少 24% 配額消耗

作者注：解讀 Google Antigravity Orchestrator 的規劃與執行分工機制、官方測試中 24% 配額與 19% 速度數據的含義，以及它與獨立模型、並行 Agent 的選型差異。

2026 年 11 月 12 日，Google 發佈 Gemini 4 Hydrogen，同時在 Antigravity 中推出 Orchestrator 多模型編排。它的做法是在同一個開發任務裏，讓 Carbon 或 Argon 負責規劃，讓 Hydrogen 負責執行。Google 官方對照測試顯示，Orchestrator 相比單獨使用 Carbon，平均減少 24% 的配額消耗，完成速度提高 19%。

這不是坊間傳言，Google Antigravity 官方博客、模型選擇文檔和 Google 發佈總覽都已確認這項功能。本文彙總 Google Antigravity Orchestrator 目前已公開的信息，包括工作機制、測試數據的正確讀法、套餐與入口，以及什麼樣的任務適合用它。

核心價值：讀完本文，你能判斷自己的工程任務該選 Orchestrator、Hydrogen 獨立模式，還是 Carbon / Argon 獨立模式。

一句話摘要：Antigravity Orchestrator 在單一 Agent 會話中讓 Carbon 或 Argon 規劃、Hydrogen 執行，Google 官方報告了它在配額和速度上的收益。

to know：閱讀前需要了解的 5 個術語

• Planner（規劃者）：負責分析任務、制定方案，並在必要時重新規劃的模型角色，在 Orchestrator 中由 Carbon 或 Argon 擔任。
• Executor（執行者）：按計劃修改代碼、運行工具、驗證結果的角色，在 Orchestrator 中由 Hydrogen 擔任。
• Agent：由模型和工具執行環境共同完成多步驟任務的系統，不等於單個模型。
• 配額：平臺用來限制可用服務量的額度。配額減少不能直接等同於實際賬單減少。
• Harness：組織模型輸入、工具執行和任務計分的測試框架。同一個模型放進不同 Harness，分數可能不同。

Google Antigravity Orchestrator 核心信息速覽

Google 爲什麼推出 Antigravity Orchestrator

一個真實的軟件開發任務通常包含多種工作：先讀懂代碼庫和依賴關係，再決定改哪裏、怎麼改，然後批量編輯文件、跑構建和測試，最後檢查結果。這些步驟對推理能力的要求差別很大。”決定怎麼改”需要深度判斷，”按方案改十個文件並跑測試”更看重速度、精準編輯和工具調用的穩定性。

如果整個任務都交給 Carbon 這類高端推理模型，執行階段的大量重複操作也要按高端模型的節奏和配額來消耗，任務時間和額度開銷都會被拉高。只用輕量模型又可能在方案設計或疑難錯誤上判斷失誤，導致返工。

Hydrogen 的定位正好填補這一塊。Google 將它定義爲高效率的日常編程與 Agent 執行模型，強調精準編輯、多工具調用，以及工具失敗後調整策略的能力，並明確表示它可以在多模型系統中充當執行者或驗證者。Orchestrator 就是把這種分工產品化：貴的模型只用在最需要判斷的環節。

Antigravity Orchestrator 如何工作：Carbon 思考，Hydrogen 執行

根據 Google Antigravity 官方文檔，Orchestrator 不會在收到請求時只判斷一次難度、然後選一個模型幹完全程。它會在同一個任務中反覆切換規劃模型和執行模型。

Orchestrator 的五步工作流程

以官方舉的依賴升級場景爲例，一次完整流程大致如下：

1. 分析代碼庫：Carbon（或 Argon）以只讀方式梳理代碼結構和依賴關係。
2. 制定方案：Planner 確定修改範圍和步驟，同時設定什麼情況下需要重新規劃。
3. 修改代碼：Hydrogen 接手具體編輯、升級依賴。
4. 執行測試：Hydrogen 運行構建和測試，驗證修改是否生效。
5. 驗證結果：通過後檢查結果並結束任務；遇到複雜錯誤則交回 Planner。

Orchestrator 重新規劃的觸發條件

官方文檔列出了幾類會把控制權交還 Planner 的情況：驗證步驟連續失敗兩次、接口行爲與預期不一致、實施中出現原方案沒有覆蓋的設計選擇。Planner 重新判斷後，會調整方案，再交給 Hydrogen 繼續執行後續修改和驗證。

這個機制很關鍵。執行模型不會一直盲目重試，而是在”超出原計劃”時及時上交決策權，高端模型只在關鍵節點介入。

動態交接與一次性模型路由的區別

常見的”模型路由”是在請求入口做一次分類：簡單任務給小模型，複雜任務給大模型，之後不再變化。Orchestrator 的區別在於，一個任務內部會多次交接，規劃和執行由不同模型承擔，而且執行過程中隨時可能回到規劃階段。它路由的是任務階段，而不是整條請求。

Orchestrator 官方測試：24% 配額與 19% 速度意味着什麼

以下數據全部來自 Google 官方的終端任務對照測試，對比對象是”Orchestrator”與”單獨使用 Carbon”。

爲什麼多模型分工能省配額

收益主要來自執行階段。代碼編輯、依賴更新、反覆跑測試這些步驟調用次數多、上下文長，如果都由 Carbon 完成，高端模型會被大量重複調用。交給 Hydrogen 後，Carbon 只負責開頭規劃和中途重新規劃，高端推理的調用量自然下降。從 API 標價也能看出兩者的成本差距：截至 2026 年 11 月 13 日，Google AI Studio 官方標準價格中，Hydrogen 輸入和輸出分別爲每百萬 tokens 1.50 美元和 7.50 美元；Carbon 在 2026 年 11 月 30 日前爲每百萬 tokens 2 美元和 10 美元，官方頁面註明 12 月 1 日起調整爲 4 美元和 20 美元。

需要注意的是，以上是 API 價格，而 Orchestrator 運行在 Antigravity 的訂閱配額體系中，兩者的計量方式不同。我們不能用 API 價格去推算 Orchestrator 的”真實花費”。

這組數字對開發團隊的意義

對團隊來說，評價 AI 編程工具的效率不能只看單次回答質量，還應同時觀察三個維度：任務成功率、額度消耗和完成時間。Orchestrator 的官方結果顯示，在成功率基本不變的前提下，後兩項都有改善。這爲團隊提供了一個可參考的思路：把”規劃質量”和”執行吞吐”拆開評估，而不是隻盯着最強的模型。

💡 數據說明：本節效率數字均歸屬於 Google 官方對照測試，尚未有獨立第三方複測。如果你想在自己的業務中驗證”規劃模型 + 執行模型”分工的效果，可以通過 API易 apiyi.com 用同一個 Key 調用不同檔位的模型，自行設計對照實驗。

Orchestrator 對比獨立模型與並行 Agent

獨立 Carbon 對標分析：Carbon 在複雜判斷上保持領先，但在執行階段的重複操作中也會消耗高端模型的配額和時間。相比之下，Orchestrator 在大多數規劃加執行的常規工程任務中，用接近的成功表現換來了更低的配額消耗。

獨立 Hydrogen 對標分析：Hydrogen 速度快、編輯精準，但遇到原方案沒覆蓋的設計選擇時，缺少更強模型兜底。對於需求清晰、無需反覆決策的任務，它仍是最直接的選擇。

並行多 Agent 對標分析：Google 明確說明，Orchestrator 在一條會話裏只維持一個 Agent，依靠多模型交接完成不同階段。如果需要多個 Agent 同時處理子任務或互相審查，應選擇 Subagents、Swarm、Boost 或 Teamwork 等功能。兩者解決的是不同問題，一個是”單任務內部怎麼分工”，一個是”要不要增加 Agent 數量”。

如何在 Antigravity 中使用 Orchestrator

Orchestrator 模式與套餐對應關係

在 Antigravity App 中，打開對話輸入框附近的模型選擇菜單，選擇 Orchestrator （Carbon） 或 Orchestrator （Argon） 即可。在 Antigravity CLI 中，官方給出的示例如下（以下語法引自官方文檔，本文未做本地實測）：

# 查看當前賬號可用的模型
agy models

# 進入會話後使用 /model 選擇 Orchestrator

# 也可以在啓動時直接指定
agy -p "Add input validation to the signup form and run the tests." --model "Orchestrator (Argon)"

需要注意，Orchestrator 使用固定的思考配置，不能爲它單獨設置 Low、Medium、High 或 Extra 等檔位。如果需要自定義思考檔位，應切換到單獨模型。另外，發佈當天有用戶反饋模型選項可見但調用失敗、不同賬號開放時間不一致，這類情況更可能與逐步上線有關，遇到時可以稍後再試。

在自有 Agent 中復現規劃與執行分工

Orchestrator 是 Antigravity 的產品功能，但”強模型規劃、快模型執行、失敗兩次回交”的思路，完全可以在自己的 Agent 裏實現。下面是一個基於 OpenAI 兼容接口的極簡示例，模型名請以所用平臺的模型列表爲準：

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://api.apiyi.com/v1")

PLANNER = "your-reasoning-model"   # 規劃模型，以平臺模型列表爲準
EXECUTOR = "your-fast-model"       # 執行模型，以平臺模型列表爲準

def ask(model, system, user):
    r = client.chat.completions.create(model=model, messages=[
        {"role": "system", "content": system}, {"role": "user", "content": user}])
    return r.choices[0].message.content

plan = ask(PLANNER, "你是架構師，輸出分步實施方案。", "爲註冊表單增加輸入校驗")
print(ask(EXECUTOR, "嚴格按方案執行，只輸出代碼改動。", plan))

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

PLANNER = "your-reasoning-model"
EXECUTOR = "your-fast-model"
MAX_FAILS = 2  # 參考 Antigravity 文檔：驗證連續失敗兩次即回交規劃

def ask(model: str, system: str, user: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "system", "content": system},
                  {"role": "user", "content": user}],
    )
    return r.choices[0].message.content

def run_tests(patch: str) -> tuple[bool, str]:
    """替換爲你自己的構建與測試邏輯，返回 (是否通過, 日誌)"""
    raise NotImplementedError

def orchestrate(task: str, max_replans: int = 3) -> str:
    plan = ask(PLANNER, "你是規劃者，輸出分步方案及重新規劃條件。", task)
    for _ in range(max_replans):
        fails, log = 0, ""
        while fails < MAX_FAILS:
            patch = ask(EXECUTOR, "你是執行者，嚴格按方案修改代碼。",
                        f"方案：\n{plan}\n上次測試日誌：\n{log}")
            ok, log = run_tests(patch)
            if ok:
                return patch
            fails += 1
        # 連續失敗，交還規劃模型重新判斷
        plan = ask(PLANNER, "執行連續失敗，請根據日誌修訂方案。",
                   f"原任務：{task}\n原方案：{plan}\n失敗日誌：{log}")
    raise RuntimeError("多次重新規劃後仍未通過驗證")

🚀 快速上手建議：搭建這類”規劃 + 執行”原型時，建議通過 API易 apiyi.com 獲取免費測試額度。一個 API Key 可調用 OpenAI、Claude、Gemini 等主流模型，切換 PLANNER 與 EXECUTOR 只需改一個字符串，方便快速對比不同組合。

Antigravity Orchestrator 影響分析：哪些開發任務最適合

對開發者的影響

• 常規功能開發：規劃、實現、測試三段分工清晰，是 Orchestrator 最典型的場景。
• 多文件 Bug 修復：Planner 定位根因，Hydrogen 修改多個文件並跑測試驗證，失敗後再回交判斷。
• 中等複雜度重構：方案由規劃模型把控，大量具體改動交給執行模型，避免高端模型陷入機械編輯。
• 配額管理更主動：對訂閱用戶來說，用 Orchestrator 處理日常任務，可以把更多額度留給真正需要深度推理的工作。

對行業的影響

• “規劃者 + 執行者”成爲產品化模式：模型廠商開始把多模型協作直接做進開發工具，而不只是交給用戶自己編排。
• 評價指標多元化：成功率之外，配額消耗和完成時間會越來越多地出現在 Agent 工具的對比中。

Orchestrator 場景選型建議

常見問題 FAQ

Google Antigravity Orchestrator 核心要點 Key Takeaways

• 核心定義：單一 Agent 會話內，Carbon / Argon 規劃，Hydrogen 執行，動態交接。
• 關鍵機制：驗證連續失敗兩次等情況會交還規劃模型重新判斷。
• 官方數據：相比單獨 Carbon，配額 -24%，速度 +19%，成功表現接近。
• 正確解讀：配額消耗不等於賬單，測試基準版本兩份公告標記不一致。
• 使用門檻：Ultra 可用兩種模式，符合條件的 Pro 可用 Argon 模式。
• 上手方式：自建 Agent 可通過 API易 apiyi.com 統一接口復現分工思路。

總結

Google Antigravity Orchestrator 的核心要點：

1. 分工而非替換：不是用便宜模型替代昂貴模型，而是讓 Carbon / Argon 管判斷，Hydrogen 管執行。
2. 動態交接：執行中遇到異常會回到規劃階段，這是它區別於一次性模型路由的關鍵。
3. 官方收益：在成功表現接近 Carbon 的前提下，官方測試中配額減少 24%、速度提升 19%。
4. 按複雜度選型：常規多階段工程用 Orchestrator，深度架構用 Carbon / Argon，明確的日常任務用 Hydrogen。

對於大多數日常開發任務，Orchestrator 是兼顧質量和額度的合理默認選項。如果你想把同樣的思路用到自己的產品裏，推薦通過 API易 apiyi.com 快速驗證不同模型組合的效果，平臺提供免費額度和多模型統一接口。

📚 參考資料

1. Google Antigravity 官方博客：Gemini 4 Hydrogen and Orchestrator
2. 鏈接： antigravity.google/blog/gemini-4-hydrogen-in-google-antigravity

3. 說明： Orchestrator 發佈公告與 24% / 19% 官方測試數據，基準標記爲 Terminal-Bench 4.1

4. Google Antigravity 文檔：Choose a Model / Orchestrator

5. 鏈接： antigravity.google/docs/models

6. 說明： Planner / Executor 機制、重新規劃條件、CLI 示例與選型建議

7. Google 官方博客：Introducing Gemini 4 Hydrogen

8. 鏈接： blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-hydrogen

9. 說明： Hydrogen 發佈總覽，同一對比結果在此標記爲 Terminal-Bench 4.0

10. Google 中文官方公告：Gemini 4 Hydrogen

11. 鏈接： china.googleblog.com/2026/11/gemini-4-hydrogen.html

12. 說明： 中文發佈信息，基準版本同樣標記爲 4.0

13. Google AI Studio 價格頁：Gemini 系列 API 價格

14. 鏈接： aistudio.google.com/docs/pricing

15. 說明： Hydrogen、Carbon、Argon 標準 API 價格及調價時間節點

16. Antigravity 套餐與共享額度說明

17. 鏈接： antigravity.google/blog/changes-to-antigravity-plans
18. 說明： 訂閱套餐與配額體系

作者: API易 技術團隊
技術交流: 歡迎在 API易 網站首頁聯繫我們，更多資料可訪問 docs.apiyi.com 文檔中心

延伸閱讀

• Google Antigravity 推出 /swarm：AI 編程從單 Agent 執行走向多 Agent 團隊協作的 4 類角色解讀:解讀 Google Antigravity /swarm 預覽功能：Coordinator、Worker、Verifier、Monitor 如何分工協作，工作副本、可視化面板、額度消耗與權限邊界一次講清。
• Gemini 4 Carbon 用 /swarm 構建谷歌園區 3D 世界:拆解 Google 官方演示的鵜鶘騎 GBike 開放世界遊戲，看 Gemini 4 Carbon 如何藉助 Antigravity /swarm 協調多 Agent 完成三維資產、瀏覽器遊戲與聲音設計，以及它的邊界。
• 從歷史照片到交互式 3D：Gemini 4 Carbon 用一條提示詞重現埃菲爾鐵塔的建設過程:解讀 Google 埃菲爾鐵塔演示：Gemini 4 Carbon 如何藉助 Antigravity 的 /swarm 多 Agent 協作，把歷史照片和工程圖紙組織成可交互的 Three.js 三維展覽。
• 從“美國豆包”到頂級編程模型：Gemini 三年間經歷了什麼？12 個關鍵節點全解讀:梳理 Gemini 從 2023 年 1.0 到 2026 年 Gemini 4 Carbon 的 12 個關鍵節點，解讀多模態、長上下文、Thinking、工具調用到 Agentic Coding 的演進，以及它對開發者選型的影響。
• Gemini 4 Hydrogen 對比 Gemini 4 Carbon：日常怎麼選:從定位、思考檔位、上下文與輸出、價格和 Orchestrator 用法五個方面，說明 Gemini 4 Hydrogen 和 Gemini 4 Carbon 在日常使用中如何分工，以及 API易 目前可調用的型號。
• Gemini 4 Hydrogen 有多強？官方表10項贏7項:谷歌 2026-11-12 發佈 Gemini 4 Hydrogen：官方模型卡 10 項對比贏 7 項，相對 Gemini 3.8 Flash 快 2.5 倍、Terminal-Bench 4.1 從 18.2% 到 57%，並說明這些數字的口徑、價格與調用現狀。
• Gemini 4 Hydrogen 對比 Claude Sonnet 5.5：10項怎麼選:基於官方模型卡 10 項彙總和官方價格，對比 Gemini 4 Hydrogen 與 Claude Sonnet 5.5：Hydrogen 7 項領先且短提示更便宜，Sonnet 在終端、電腦操作、科學終端 3 項更高，附選型建議與 API易 接入說明。