Gemini 3.6 Flash 開發人員指南

Gemini 3.6 Flash 是 Gemini 3 系列中速度快、成本效益高的強大模型,這款模型旨在提供接近專業級代理能力的功能,同時兼顧效能和價值。現在,開發人員可透過 Gemini API 使用,企業則可透過 Gemini Enterprise Agent Platform 使用,且已正式發布 (GA)。

本文將介紹 3.6 Flash 的新功能、在 Gemini 模型系列中的定位、如何遷移至 3.6 Flash,以及使用 3.6 Flash 的快速入門指南。

它在 Gemini 系列中扮演什麼角色?

Gemini 3.6 Flash 是 Gemini 3 系列的主要代理式主力模型,這款模型填補了深度推論 Pro 模型和高處理量 Flash-Lite 模型之間的差距,相較於 Gemini 3.5 Flash,3.6 Flash 在多步驟工具協調、全端程式碼重構和視覺推論方面的品質顯著提升,同時使用更少的詞元和推論回合。以 Flash 的速度和價格,提供接近 Pro 級別的功能。

模型規格和比較

下表比較 3.6 Flash、3.5 Flash 和 3.1 Pro 的部分規格:

Gemini 3.6 Flash Gemini 3.5 Flash Gemini 3.1 Pro
模型 ID gemini-3.6-flash gemini-3.5-flash gemini-3.1-pro-preview
發布階段 正式發布版 正式發布版 預覽
輸入類型 文字、圖片、音訊、影片 文字、圖片、音訊、影片 文字、圖片、音訊、影片
輸出類型 文字 文字 文字
脈絡窗口 1,048,576 1,048,576 1,048,576
輸出詞元長度上限 65,536 65,536 65,536
支援的地區 全域、 多區域 全球、 多區域、 美洲、 歐洲、 亞太地區 全球
支援的思考程度 MINIMAL、LOW、MEDIUM、HIGH
(預設:MEDIUM)
MINIMAL、LOW、MEDIUM、HIGH
(預設:MEDIUM)
LOW、MEDIUM、HIGH
(預設:HIGH)
主要焦點 高效率的 Agentic Workflows、多步驟自動化調度管理,以及全端程式設計 平衡任務、工具呼叫和中階推論 深度推論、高複雜度任務

如需支援的功能、工具和用量選項完整清單,請參閱 3.6 Flash 模型頁面。

Gemini 3.6 Flash 有哪些新功能?

3.6 Flash 經過最佳化,可執行多步驟自動化調度管理、全端程式碼重構和一般推理,詞元效率明顯優於前代。

功能和效能更新

以下是 3.6 Flash 與先前模型相比,在功能和效能方面的異動清單:

  • 減少權杖和對話輪數:與 3.5 Flash 相比,消耗的權杖數量較少,且能以較少的推論步驟和對話輪數完成多步驟工作流程。
  • 提升程式碼生成品質:在應用程式建構、原型設計和 IDE 代理環境中,生成更簡潔的程式碼,降低編譯失敗率和修訂率。
  • 減少動作偏誤:解決唯讀診斷工作,不會進行未經要求的編輯工作區作業,也不會過早變更狀態。
  • 多模態和空間推理:提升圖表解讀、視覺藍圖轉換,以及多元素網頁版面配置生成等方面的效能。
  • 電腦使用支援:支援做為代理 UI 自動化的內建工具。
  • UI 樣式偏好:更擅長建立功能性程式碼,但人類評估人員指出,他們偏好使用先前的模型來呈現前端和視覺版面配置。提供明確的設計規範,即可減輕這類影響。

行為和 API 參數異動

以下是 3.6 Flash 與先前模型相比,行為和 API 參數的異動清單:

  • 步驟精簡度:推論步驟比 3.5 Flash 少。雖然這能縮短延遲時間,並降低程式碼重構和工具工作流程的成本,但如果需要較長的疊代鏈,可能會導致長時間的多輪對話提早結束。
  • 預先程式化檢查:偏好執行診斷程式碼指令碼 (execute_code),在變更狀態前檢查問題,頻率高於 3.5 Flash。雖然這項功能可提高複雜後端重構作業的診斷準確度,但有時可能會在簡單的前端網頁和指令碼工作中,執行額外的探索式檢查步驟,而舊版會直接生成程式碼。
  • 預設工作量:沿用 3.5 Flash 推出的中等預設工作量。
  • 不覆寫取樣:系統不再支援 temperature、top-k 或 top-p 參數的自訂值。API 介面會忽略自訂值設定。請改用 thinking_level 或結構化 JSON 結構定義,控管輸出內容的確定性。
  • 頻率和出現次數處罰限制:系統不再支援這些參數的自訂值。現在設定這些項目會擲回有效的 API 錯誤。
  • 如果最後一個輸入回合的角色為「Model」,則不支援 API 要求。
  • 系統會捨棄對話記錄中的空白輪流發言。
  • 現在,無效的思考簽章會產生錯誤。
  • 嚴格函式呼叫:FunctionResponse 必須與前一個 FunctionCall 的 id、name 和執行次數完全相符。直接在函式回覆文字中附加行內指令,並以兩個換行符 (\n\n) 分隔。

快速入門導覽課程

開始之前,請先使用應用程式預設憑證 (ADC) 或 API 金鑰,在 Agent Platform 進行驗證。詳情請參閱「開始使用 Gemini Enterprise Agent Platform」。

在下列程式碼區塊中,將 PROJECT_ID 替換為您的專案 ID。

安裝

確認您使用的是最新版 google-genai SDK:

pip install --upgrade google-genai

基本要求

Python

from google import genai

client = genai.Client(enterprise=True, project="PROJECT_ID", location="global")

response = client.models.generate_content(
  model="gemini-3.6-flash",
  contents="How does AI work?",
)
print(response.text)

REST

curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/global/publishers/google/models/gemini-3.6-flash:generateContent \
-d '{
  "contents": {
    "role": "USER",
    "parts": { "text": "Why is the sky blue?" },
  },
}'

從 3.5 Flash 或 3.1 Pro 遷移至 3.6 Flash

如要從 3.5 Flash 或 3.1 Pro 遷移至 3.6 Flash,請按照下列步驟操作:

  1. 更新模型 ID:將 API 呼叫中的模型字串變更為 gemini-3.6-flash。
  2. 配合新的 Gemini 3 系列 API 規則調整程式碼:Gemini 3.6 Flash 嚴格執行 Gemini 3 系列建立的參數規則和 API 慣例:
    • 移除溫度、Top-K 和 Top-P:從酬載中移除這些自訂參數。雖然不會擲回錯誤,但模型會完全忽略這些內容。請改用 thinking_level 參數或 json_schema 結構化輸出內容,控制輸出內容的確定性。
    • 移除頻率和存在懲罰:移除頻率或存在懲罰的所有自訂設定,避免 API 呼叫擲回執行階段錯誤。
    • 確保整合的即時通訊功能不會嘗試預先填入模型:檢查訊息記錄陣列,確保 API 酬載結尾不是空白的使用者或模型對話。如果記錄陣列中的最後一個物件是「model」角色 (GenerateContent API) 或「model_output」類型 (Interactions API),請重組序列,避免觸發嚴格的驗證錯誤。
    • 使用 thinking_level:移除已淘汰的 thinking_budget 參數,改用 thinking_level。
    • 強制執行嚴格的函式呼叫慣例:FunctionResponse 必須嚴格符合前一個 FunctionCall 的 id、name 和執行次數。如需附加內嵌指令,請直接放在函式回覆文字中,並以兩個換行符號 (\n\n) 分隔。
  3. 因應工作流程變化:
    • 如果應用程式依賴多輪對話迴圈,請測試工作流程,確保模型的新步驟簡潔性不會觸發過早結束。
    • 如果建構前端或基本指令碼代理,請監控模型是否因偏好預先程式化檢查,而產生不必要的探索性 execute_code 呼叫。

工具前文字規定的解決方法

如果提示要求模型在呼叫工具前,先輸出結構化文字 (XLM、YAML、Json 等) (例如 <UPDATE>...</UPDATE>),工具呼叫有時可能會失敗,並顯示 Malformed_Function_Call 錯誤。如要解決這個問題,請採用下列任一解決方法:

  • (建議) 指示模型將工具前附註放在專屬的 update() 函式呼叫中,而非原始文字。如需詳細的導入操作說明,請參閱下一節。
  • 指示模型以 Markdown 標題 (例如 # UPDATE、## PLAN) 撰寫筆記,而非結構化文字。
  • 請勿要求模型在工具呼叫前輸出文字。

建議解決方案:將工作筆記包裝在專屬的函式呼叫中

原始指令:

Before calling a tool, in every response you MUST first output a single
`<UPDATE>` part as specified, don't skip this part or any of required sub-tags
within `<UPDATE>`.

請使用更新後的指令:

Before calling any other tool, in every response you MUST first call `update`
with all required parameters (previous_step, plan, next_step, external).

更新客戶要求中所有參照舊版 <UPDATE> XML 格式的部分。然後為更新函式新增對應的函式宣告:

{
  "name": "update",
  "description": "Update working notes (previous step analysis, plan, next step, external note).",
  "parameters": {
    "type": "OBJECT",
    "properties": {
      "previous_step": {
        "type": "STRING",
        "description": "Key findings and outcomes since the previous step."
      },
      "plan": {
        "type": "STRING",
        "description": "The current status of the plan."
      },
      "next_step": {
        "type": "STRING",
        "description": "Brief explanation of the immediate next action according to the plan."
      },
      "external": {
        "type": "STRING",
        "description": "A short, plain-language note shown to the User about what you are ABOUT TO DO next."
      }
    },
    "required": [
      "previous_step",
      "plan",
      "next_step",
      "external"
    ]
  }
}

模型會在同一個步驟中進行兩次呼叫:取代結構化 XML 的 update() 呼叫,以及模型想進行的實際函式呼叫。

其他資源