Gemini 3.6 Flash 是 Gemini 3 系列中一款高速、经济高效的强大模型。该模型旨在提供接近 Gemini Pro 的智能体功能,同时不影响性能或价值,现在已面向使用 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 在多步工具编排、全栈代码重构和视觉推理方面的质量显著提高,同时使用的 token 和推理轮次更少。 它以 Flash 的速度和价格提供接近 Gemini 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 |
| 发布阶段 | GA | GA | 预览 |
| 输入类型 | 文本、图片、音频、视频 | 文本、图片、音频、视频 | 文本、图片、音频、视频 |
| 输出类型 | 文本 | 文本 | 文本 |
| 上下文窗口 | 1,048,576 | 1,048,576 | 1,048,576 |
| 输出 token 长度上限 | 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 针对多步编排、全栈代码重构和一般推理进行了优化,token 效率比之前的版本显著提高。
功能和性能更新
以下是 3.6 Flash 相较于之前版本在功能和性能方面的变化列表:
- 减少 token 和轮次:与 3.5 Flash 相比,消耗的 token 更少,完成多步 工作流所需的推理步骤和对话轮次更少。
- 改进的代码生成:在应用构建、原型设计和 IDE 智能体环境中,生成的代码更简洁, 编译失败率和修订率更低。
- 减少操作偏差:解决只读诊断任务,而不会进行 未经请求的工作区修改或过早地改变状态。
- 多模态和空间推理:在图表 解读、视觉蓝图转换和多元素网页布局 生成方面提供更好的性能。
- 支持计算机使用:作为智能体界面 自动化的内置工具提供支持。
- 界面样式偏好:更擅长创建功能代码,但人工评估人员指出,他们更喜欢之前的模型进行前端呈现和图文并茂。可以通过提供明确的设计指南来缓解这种情况。
行为和 API 参数变更
以下是 3.6 Flash 相较于之前版本在行为和 API 参数方面的变化列表:
- 步骤简洁性:使用的推理步骤比 3.5 Flash 更少。虽然这减少了代码重构和工具工作流的延迟时间和费用,但可能会导致在需要更长迭代链的扩展多轮对话后续操作中提前退出。
- 预先进行程序化检查:与 3.5 Flash 相比,更倾向于运行诊断代码脚本
(
execute_code) 来检查问题,然后再更频繁地改变状态。虽然这提高了复杂后端重构的诊断准确性,但有时可能会导致在简单的前端网页和脚本任务上运行额外的探索性检查步骤,而之前的版本会直接生成代码。 - 默认工作量:沿用了中等默认工作量级别 ,该级别在 3.5 Flash 中引入。
- 没有采样替换:不再支持
temperature、top-k或top-p参数的自定义值。在 API 界面中,设置自定义值将被忽略。请改用thinking_level或结构化 JSON 架构来控制输出确定性。 - 频率和存在惩罚限制:不再支持这些 参数的自定义值。现在,设置这些参数将抛出活跃的 API 错误。
- 不支持最后一个输入轮次的角色为“模型”的 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必须与前面的FunctionCallid、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() 调用,以及它想要进行的实际函数调用。