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,請按照下列步驟操作:
- 更新模型 ID:將 API 呼叫中的模型字串變更為
gemini-3.6-flash。 - 配合新的 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) 分隔。
- 移除溫度、Top-K 和 Top-P:從酬載中移除這些自訂參數。雖然不會擲回錯誤,但模型會完全忽略這些內容。請改用
- 因應工作流程變化:
- 如果應用程式依賴多輪對話迴圈,請測試工作流程,確保模型的新步驟簡潔性不會觸發過早結束。
- 如果建構前端或基本指令碼代理,請監控模型是否因偏好預先程式化檢查,而產生不必要的探索性
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() 呼叫,以及模型想進行的實際函式呼叫。