谷歌发布Gemini 3.6 Flash和3.5 Flash-Lite新模型，前者在复杂任务中性能更强且成本更低，后者速度最快、成本最低，均适用于生产环境。

好的，这是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删除了与主题无关的安装命令等重复内容。

文章核心内容重述：使用最新的 Gemini 模型

本文介绍了 Google 最新发布的 Gemini 3.6 Flash 和 Gemini 3.5 Flash-Lite 模型，它们已正式上线（GA），可用于生产环境。

新模型概览

• Gemini 3.6 Flash (gemini-3.6-flash): 在复杂代理和多模态任务上性能更强，同时减少了 Token 使用量，且价格低于 3.5 Flash。其定价为：输入 $1.50/百万 Token，输出 $7.50/百万 Token。
• Gemini 3.5 Flash-Lite (gemini-3.5-flash-lite): 3.5 系列中速度最快、成本最低的模型，在高吞吐量任务中表现优于前代 Flash-Lite。其定价为：输入 $0.30/百万 Token，输出 $2.50/百万 Token。

两个模型均支持 100 万 Token 的上下文窗口、最大 64k 的输出 Token、思考能力，以及包括“计算机使用”在内的全套内置工具。

Gemini 3.6 Flash 的新特性

• 减少 Token 和交互轮次：相比 3.5 Flash，能以更少的推理步骤、对话轮次和工具调用完成多步工作流，并减少执行循环。
• 改进的代码生成：能生成更高质量、可直接用于生产的代码，减少不必要的编辑和调试循环。
• 更强的指令遵循能力：在执行诊断任务时，减少不必要的文件更改。
• 强大的多模态与空间推理：在图表解读、视觉蓝图转换和多元素网页布局生成方面表现更佳。
• 偏好预先程序化检查：在执行更改前，更倾向于先运行诊断代码脚本，这提高了复杂任务的准确性，但可能在简单前端任务上增加探索步骤。
• 支持计算机使用：可作为原生工具用于代理式 UI 自动化。
• UI 样式偏好：更擅长生成功能性代码，但在视觉布局和样式方面，人工评估者更偏好早期模型。可通过提供明确的设计指南来改善。
• 默认思考强度：与 3.5 Flash 相同，默认为 medium。
• 价格降低：输出 Token 成本从 3.5 Flash 的 $9.00/百万降至 $7.50/百万。

Gemini 3.5 Flash-Lite 的新特性

• 降低任务执行延迟：在 3.5 系列中，对于高容量数据解析和文档提取，吞吐量最高。
• 增强的推理与多模态性能：是从 Gemini 2.5 Flash 迁移的强力选择，在推理任务（如 HLE）和多模态基准测试（如 CharXIV）上得分更高。
• 子代理编排与工具可靠性：提高了代码执行、搜索和 MCP 工作流中工具执行的可靠性。对于自主规划和复杂子代理任务，建议提高思考强度。
• 改进的文档理解：提高了文档解析和结构化数据提取的准确性。可根据文档复杂度，在 minimal 和 high 思考强度间进行实验。
• 交互式网页编码与表格数据处理：通过轻量级代码执行进行规划，在前端 JavaScript 和表格数据处理方面表现强劲。
• 聊天机器人与角色一致性：相比 Gemini 3.1 Flash-Lite，在多轮指令遵循和角色一致性方面更强。
• 支持计算机使用：可作为原生工具用于代理式 UI 自动化。

如何选择模型

• Gemini 3.6 Flash 适用于代码生成、空间/多模态推理和多步代理工作流。推荐从 Gemini 3.5 Flash、3 Flash（预览版）或 3.1 Pro 迁移。
• Gemini 3.5 Flash-Lite 适用于自主子代理执行、高容量数据分析和文档提取、结构化 JSON 解析。推荐从 Gemini 3.1 Flash-Lite 或 2.5 Flash 迁移。

重要的 API 变更

从这两个新模型开始，以下 API 变更将适用于它们及所有未来的 Gemini 模型：

1. 采样参数弃用：temperature、top_p 和 top_k 参数已被弃用。API 会忽略这些参数，并在未来的模型版本中返回错误。请从所有请求中移除这些参数。如需提高确定性，可通过系统指令为特定用例定义明确规则。
2. 预填充模型轮次验证：不再支持预填充模型轮次。如果请求中最后一个非空轮次是 model 轮次，API 将返回 400 错误。如果应用之前通过预填充模型轮次来抑制前言或强制 JSON 格式，应改用 system_instruction 或结构化输出。

迁移清单

迁移至 gemini-3.6-flash： - 更新模型 ID 为 gemini-3.6-flash。 - 移除弃用的采样参数（temperature, top_p, top_k），将 thinking_budget 替换为字符串枚举 thinking_level（设为 "medium" 或 "high"），并移除 candidate_count。 - 遵守轮次验证规则：使用服务端的 previous_interaction_id 来标准化多轮对话，并移除预填充的模型轮次。 - 审计函数调用：将多模态资产放在响应负载内，使用 \n\n 格式化内联指令。如果遇到 Malformed_Function_Call 错误，请参考相关文档。

迁移至 gemini-3.5-flash-lite： - 更新模型 ID 为 gemini-3.5-flash-lite。 - 配置思考强度：对于高容量提取、路由或分类任务，保持 thinking_level 为 "minimal"（默认）以获得最大吞吐量；对于涉及工具调用、代码执行或多步推理的自主子代理，设置为 "medium" 或 "high" 以防止工具过早终止。 - 移除弃用参数并验证函数调用，规则与迁移至 3.6 Flash 相同。

根据评论内容，主要围绕模型采样参数（temperature、topp、topk）的弃用展开讨论，观点存在分歧。以下是总结：

支持弃用的观点： - 这些参数对近几代模型基本无用，甚至降低性能（评论5："These have been basically useless... most of the time made the model perform worst"） - 参数令人困惑，简化是好事（评论7："thank god, these parameters are so confusing"） - 可能增加推理成本，影响推测解码准确性（评论9："These parameters can make speculative decoding less accurate increasing the inference cost"）

质疑或反对弃用的观点： - 系统指令替代方案效果存疑，可能不如topk/topp可靠（评论2："Is this guaranteed to work any better than top_k or top_p?"） - 弃用会减少多样性，影响多智能体研究（评论13："If my 5 parallel sub agents all produce the same conclusion I might as well have only ran one"） - 可能因RL训练对参数敏感导致模型脆弱（评论4："RL training being done with particular generation parameters makes models more brittle"）

其他推测： - 模型可能在推理时动态调整这些参数（评论8："They might be dynamically adjusting these at inference time"） - 防止用户对高温采样结果进行微调（评论8："They don't want you to fine-tune on high temperature completions"）