Gemini 3.5 Flash 是 Gemini 3 系列中速度最快、成本效益最高的模型。這款模型旨在提供接近專業級代理能力的功能,同時兼顧效能和價值。現在,開發人員可透過 Gemini API 使用,企業則可透過 Gemini Enterprise Agent Platform 使用,且已正式發布 (GA)。
本文說明 3.5 Flash 的新功能、適用時機、遷移方式,以及 3.5 Flash 的快速入門指南。
它在 Gemini 系列中扮演什麼角色?
下表比較 3.5 Flash、3.1 Pro 和 3.1 Flash-Lite 的部分規格:
| Gemini 3.5 Flash | Gemini 3.1 Pro | Gemini 3.1 Flash-Lite | |
|---|---|---|---|
| 模型 ID | gemini-3.5-flash |
gemini-3.1-pro-preview |
gemini-3.1-flash-lite |
| 發布階段 | 正式發布版 | 預覽 | 正式發布版 |
| 輸入類型 | 文字、圖片、音訊、影片 | 文字、圖片、音訊、影片 | 文字、圖片、音訊、影片 |
| 輸出類型 | 文字 | 文字 | 文字 |
| 脈絡窗口 | 1,048,576 | 1,048,576 | 1,048,576 |
| 輸出詞元長度上限 | 65,536 | 65,536 | 65,536 |
| 支援的地區 | 全球、 多區域、 美洲、 歐洲、 亞太地區 | 全球 | 全域、 多區域 |
| 支援的思考程度 |
MINIMAL、LOW、MEDIUM、HIGH(預設: MEDIUM)
|
LOW、MEDIUM、HIGH(預設值: HIGH)
|
MINIMAL、LOW、MEDIUM、HIGH(預設: MINIMAL)
|
| 主要焦點 | 平衡任務、工具呼叫和中級推理 | 深入推論、高複雜度任務 | 大量、預算有限且對延遲時間有嚴格要求的任務 |
如需支援的功能、工具和用量選項完整清單,請參閱 3.5 Flash 模型頁面。
用途細項
建議的 Agentic Workflows 策略採用分層做法,可最佳化品質、速度和成本:
- Gemini Pro:保留給需要深入推論的高複雜度認知型工作,例如初步的根本規劃、解決複雜問題、困難的程式設計,以及做出重大決策。
- Gemini Flash:做為執行工作、呼叫工具和中間推論步驟的主要「主力」,在效能和效率之間取得最佳平衡。
- Gemini Flash Lite:適用於高資料量、低延遲的預先處理和結構化工作,速度和成本是首要考量,例如意圖路徑、資料擷取、標記和分類。
Gemini 3.5 Flash 有哪些新功能?
Gemini 3.5 Flash 為 Gemini 模型系列帶來以下變化和改良:
- 持續提供頂尖效能:這是 Google 最聰明的 Flash 模型,專為大規模代理功能和程式設計工作打造。
- 代理式執行:大規模部署子代理、解決問題,以及快速代理式迴圈。
- 提升程式碼品質:透過反覆的程式碼編寫週期、快速探索和原型設計,測試替代路徑並動態探索解決方案。
- 長程:大規模使用多步驟工作流程和工具。
- 思維保留:模型會在多輪對話中自動保留中間的推論過程。不需要變更 API。
- 新的預設思考程度:預設思考程度已從
HIGH變更為MEDIUM。 - 提升
LOW思考能力:對於步驟較少的程式碼和代理功能工作,現在的低思考程度大幅提升,以較低的延遲時間和成本提供高品質服務。
詳情請參閱「主要異動」一節。
快速入門導覽課程
開始之前,請先使用應用程式預設憑證 (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.5-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.5-flash:generateContent \
-d '{
"contents": {
"role": "USER",
"parts": { "text": "Why is the sky blue?" },
},
}'
主要異動
本節將進一步說明 Gemini 3.5 Flash 的下列變更:
新的預設思考程度
Gemini 3 模型現在預設為MEDIUM思考等級,Gemini 3 Flash 預先發布版則為HIGH。「思考程度」MEDIUM可針對各種任務產生優異結果,同時速度更快,成本效益也更高。
支援的思考程度如下:
MINIMAL:適用於大多數查詢的「不思考」設定。模型可能會以極簡方式思考,以處理寫程式等複雜工作。將聊天或高處理量應用程式的延遲時間降至最低。LOW:以較低成本快速完成大多數任務的輕量推理。MEDIUM:(預設) 適合大多數需要推理的任務。HIGH:盡量發揮推理能力,以提升工作成效。模型生成第一個權杖的時間可能會比MEDIUM設定長,但輸出內容會更詳盡。
舉例來說,如果模型需要分多個步驟推論,請使用 HIGH 解決邏輯謎題、數學應用題或棘手情境:
from google import genai
from google.genai import types
client = genai.Client()
response = client.models.generate_content(
model="gemini-3.5-flash",
contents="A farmer has chickens and rabbits. There are 35 heads and 94 legs. How many chickens and how many rabbits does he have? Show your step-by-step logic.",
config=types.GenerateContentConfig(
thinking_config=types.ThinkingConfig(
thinking_level=types.ThinkingLevel.HIGH
)
),
)
print(response.text)
thinking_level 參數為選用項目。如果省略此設定,3.5 Flash 會使用預設設定 (MEDIUM)。
保留想法
模型會自動在多輪對話中保留中間推論結果。如果對話記錄中包含推論脈絡,系統會自動沿用,進而提升複雜多步驟工作的效能,例如反覆偵錯和程式碼重構。不需要變更 API。
系統現在預設會保留先前回合的內容。服務不再從對話脈絡中清除想法記錄,再傳遞給模型。
傳送對話記錄時,請與先前的對話保持一致:要麼包含完整脈絡 (想法、函式呼叫、回覆),要麼完全省略。部分情境可能會降低模型效能。
已淘汰:取樣參數
建議不要再對 Gemini 3 模型使用下列取樣參數:
temperaturetop_ptop_k
模型會自行管理取樣,以獲得最佳結果。從所有要求中移除這些參數。為確保確定性,請根據特定用途定義系統指令,並明確制定規則。
已淘汰:thinking_budget
所有 Gemini 3 模型都不再支援原始數值 thinking_budget 參數。請改用 thinking_level 字串列舉。
# ⚠️ Before (not recommended)
config = types.GenerateContentConfig(
thinking_config=types.ThinkingConfig(thinking_budget=7500)
)
# ✅ After
config = types.GenerateContentConfig(
thinking_config=types.ThinkingConfig(thinking_level="MEDIUM")
)
最佳做法
本節說明使用 3.5 Flash 的下列最佳做法:
針對函式呼叫使用嚴格的回應比對
如果回應不符,模型通常會傳回空白回應,並顯示 finish_reason: STOP。請務必遵守下列慣例:
- 包含
id:每個FunctionResponse都必須包含對應FunctionCall中的id。 - 比對
name:回應中的name必須與呼叫中的name相符。 - 相符次數:針對收到的每個
FunctionCall,傳回正好一個FunctionResponse。
以下程式碼是正確的函式呼叫範例:
# ✅ Include matching id and name in the function response
final_response = client.models.generate_content(
model="gemini-3.5-flash",
config=config,
contents=[
*previous_contents,
response.candidates[0].content,
types.Content(role="user", parts=[
types.Part.from_function_response(
name=tool_call.name,
response={"result": result},
id=tool_call.id,
)
]),
],
)
在函式回覆 parts 中加入多模態內容
在函式回應以外提供圖片,可能會導致模型出現非預期的行為,例如洩漏想法,並降低回覆品質。請按照「函式呼叫簡介」一文中的建議操作,在傳送至模型的回覆部分中加入多模態內容。模型可以在下一個回合處理這類多模態內容,生成更周全的回覆。
例如:
# ✅ Include multimodal content in the function response
final_response = client.models.generate_content(
model="gemini-3.5-flash",
config=config,
contents=[
*previous_contents,
response.candidates[0].content,
types.Content(role="user", parts=[
types.Part.from_function_response(
name=tool_call.name,
response={
"result": "instrument.jpg",
"image": base64_image_data,
},
id=tool_call.id,
)
]),
],
)
在函式回應中使用內嵌指令
如果提供平台指令和函式回覆做為後續parts,可能會導致模型出現非預期的行為,例如洩漏想法,並降低回覆品質。請改為在函式回應文字結尾附加這段文字,並以兩個換行符號分隔。
例如:
# ✅ Append inline instructions to the end of the function response separated by two newlines
result_text = f"{json.dumps(result)}\n\n<your inline instructions>"
final_response = client.models.generate_content(
model="gemini-3.5-flash",
config=config,
contents=[
*previous_contents,
response.candidates[0].content,
types.Content(role="user", parts=[
types.Part.from_function_response(
name=tool_call.name,
response={"result": result_text},
id=tool_call.id,
)
]),
],
)
減少不必要的工具呼叫
如果工具呼叫次數過多,可以採取以下兩種方法盡量減少:
- 降低思考程度:思考程度越高,模型就越會使用工具探索及驗證,因此降低思考程度可以減少工具呼叫次數。
新增系統指令:如果調整思考層級後,過度使用工具的情況仍未改善,請考慮使用限制工具用量的提示。例如:
You have a limited action budget of <n> tool calls. Use them efficiently.
從 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呼叫。
工具前文字規定解決方法
如果提示詞要求模型在進行工具呼叫前,立即輸出結構化文字 (XML、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() 呼叫,以及模型想進行的實際函式呼叫。