模型選擇器與系統模型
根據 Google 官方 Models 文件解釋 Antigravity reasoning model、模型選擇器、sticky 選擇邏輯和不可自定義的系統模型。
Antigravity 的模型體系分兩層：使用者可以在 conversation prompt box 下方的 model selector 裡選擇核心 reasoning model；同時，產品內部還會使用一些不可自定義的系統模型來支撐圖片生成、browser subagent、checkpointing、上下文總結和程式碼庫語義搜尋。
這意味著你不能只看“當前聊天框選了哪個模型”。一個 Agent 任務裡，核心推理、瀏覽器操作、圖片生成、摘要、搜尋可能由不同模型或工具鏈協同完成。
核驗日期：本篇按 2026-05-06 官方 Models 文件重寫。模型名稱和可用性屬於高波動資訊，後續以 antigravity.google/docs/models 當前頁面為準。
閱讀目標：讀完本章，你應該能區分“我能手動選擇的 reasoning model”和“Antigravity 內部自動呼叫的系統模型”，並知道什麼時候應該取消任務後重新選擇模型。
1. Reasoning model 是 Agent 的主推理模型
官方 Models 文件把 core reasoning model 描述為 Antigravity Agent 的核心推理模型，來自 Google Vertex Model Garden。使用者可以在 conversation prompt box 下方的 model selector drop down 中選擇。
截至本篇核驗時，官方頁面列出的 reasoning model 包括：
- Gemini 3.1 Pro (high)
- Gemini 3.1 Pro (low)
- Gemini 3 Flash
- Claude Sonnet 4.6 (thinking)
- Claude Opus 4.6 (thinking)
- GPT-OSS-120b
這些名稱不要死記。你要建立的是選擇邏輯：
| 任務型別 | 選擇思路 |
|---|---|
| 簡單解釋、區域性小改 | 優先速度和額度消耗 |
| 跨檔案實現、複雜重構 | 優先推理穩定性和程式碼能力 |
| 需要計劃審查 | 優先能穩定產出 plan 和 artifacts 的模型 |
| 長時間 agent 任務 | 關注 rate limit、quota 和任務拆分 |
| UI 或多模態任務 | 同時關注 browser subagent 與 artifact 驗收 |
flowchart TD
Task["新任務"] --> Scope["判斷任務範圍"]
Scope --> Selector["選擇 core reasoning model"]
Selector --> Turn["當前 user turn 執行"]
Turn --> Sticky["同一 conversation 內保持 sticky"]
Turn --> Tools["Browser / image / summary / semantic search 由系統模型協同"]
Tools --> Review["用 artifacts、diff 和測試驗收"]2. 模型選擇是 conversation 內 sticky 的
官方文件說明，reasoning model 的選擇在同一個 conversation 的使用者訊息之間保持 sticky。
更關鍵的是：如果你在 Agent 正在執行時切換模型，當前 user turn 會繼續使用之前選中的模型，直到它完成當前步驟，或者你取消當前執行。
實操影響很直接：
- 不要以為執行中切模型會立刻改變當前任務。
- 複雜任務開始前先選好模型。
- 如果模型選錯，取消當前執行，再重新發起。
- 長任務最好在 prompt 裡寫清楚任務邊界，避免浪費高配模型額度。
错误理解：运行到一半切模型，当前步骤马上变强。
正确理解：切换通常影响后续 user message，不会自动替换当前正在执行的 turn。3. 模型選擇器怎麼用
第一次使用時，按任務難度選，不要總是選最高規格。
| 場景 | 建議 |
|---|---|
| 只讀解釋專案結構 | 用較快模型即可 |
| 補文件、整理 README | 用中等模型，保留人工審查 |
| 修復雜 bug | 用更強 reasoning model，要求先寫計劃 |
| 設計跨模組方案 | 用 Planning 模式和更強模型 |
| 遷移或批次轉換 | 先用低成本模型試跑，再人工抽查 |
如果任務失敗，不要第一反應就換最高模型。先檢查：
- prompt 是否給了清晰目標。
- workspace 是否完整。
- 許可權是否阻止了必要命令。
- artifact review 是否提前中斷。
- rate limit 或 quota 是否耗盡。
4. 附加模型不可自定義
官方 Models 文件列出一些產品內部使用的 additional models，並明確這些不是使用者可自定義的。
| 模型 | 官方用途 |
|---|---|
| Nano Banana Pro 2 | Agent 需要生成 UI mockup、網頁/應用圖片、系統或架構圖等生成式圖片任務 |
| Gemini 2.5 Pro UI Checkpoint | Browser subagent 執行點選、滾動、填寫輸入等瀏覽器動作 |
| Gemini 2.5 Flash | 後臺 checkpointing 和 context summarization |
| Gemini 2.5 Flash Lite | 程式碼庫語義搜尋工具 |
這解釋了一個常見現象：你選擇了某個 reasoning model，但瀏覽器動作、總結、搜尋或圖片生成的表現仍然受內部模型影響。使用者能控制的是核心 reasoning model、任務模式、許可權和審查，不是產品堆疊裡每一個內部模型。
深讀：為什麼“選了模型”不等於控制了整套系統
Antigravity 的 Agent 任務不是單一聊天模型在連續輸出。官方 Models 文件把可選的 core reasoning model 和 additional models 分開列出，說明產品內部會按場景呼叫不同模型能力。
對使用者來說，最容易誤判的是把“模型選擇器”當成全域性開關。實際更穩的理解是：你選擇的是主推理模型，它負責規劃、解釋和呼叫工具；而瀏覽器點選、圖片生成、上下文總結、程式碼語義搜尋這類能力，仍然可能由產品內建模型承擔。
所以除錯一個失敗任務時，不要只問“是不是模型不夠強”。更應該檢查任務是否拆得過大、許可權是否卡住、artifact review 是否需要人工確認、quota 是否耗盡，以及最終 diff 和測試是否能證明結果可用。
5. 不要把模型列表當教程核心
模型列表會變化。真正應該教給使用者的是：
- 複雜任務開始前先選模型。
- 執行中切換不一定影響當前 turn。
- quota 和 rate limits 會影響可用性。
- Browser、image、summary、semantic search 可能由附加模型完成。
- 任務質量仍要靠 plan、artifacts、diff、測試和人工審查驗證。
高配模型不是許可權邊界。即使選擇最強 reasoning model，也不能跳過 terminal review、artifact review、browser allowlist 和 Git diff。
6. 一個實用的選擇模板
發起任務前可以先寫：
这个任务涉及 4 个文件以内，需要先读代码、提出计划、等待我确认后再改。
请使用 Planning 模式。
如果当前模型不适合，请先说明原因，不要直接执行。如果是簡單任務：
这是一个局部文案修改任务。
可以用 Fast 模式，只修改指定文件。
完成后给出 diff，不要运行部署命令。模型選擇不是一次性決定，而是和任務拆分一起做：簡單任務不要浪費複雜模型，複雜任務不要省掉計劃審查。
本章自檢
完成本章後，用這 3 個問題檢查自己是否真正理解：
- 為什麼執行中的任務切換模型，不一定會影響當前正在執行的 user turn？
- 使用者能手動控制哪些模型相關設定，哪些 additional models 不能自定義？
- 為什麼選擇更強 reasoning model，也不能跳過許可權、artifact review、diff 和測試？
透過標準：你能用自己的話解釋 Antigravity 的“雙層模型結構”，並能在發起任務前先選模型、定邊界、安排驗收方式。
官方來源
- Google Antigravity Models —— 官方列出 reasoning model、sticky model selection 和 additional models。
- Google Antigravity Plans —— 官方說明 quota、rate limits 和 AI credits 會影響模型可用性。