Gemini 3.7 Flash 的 Intelligence Index 56 分：当「工作马」超过旗舰模型，企业选型逻辑如何变化？

2026 年 8 月 13 日，Google 正式发布 Gemini 3.7 Flash，官方博客的定位是「our most intelligent workhorse model」——最智能的工作马。 「工作马」这个词不是谦辞，而是对 Flash 系列产品定位的准确描述：Flash 一直承担高吞吐、低成本的规模化推理任务，与承担复杂推理的 Pro 系列、承担极致性能的 Ultra 系列形成层级分工。这次发布真正值得注意的，不是「又一个 Flash 版本」，而是三个信号同时出现：综合智能指数超越前代 Pro、思考深度从「模型属性」变成「可调参数」、定价降到同档模型的中位数以下。

先看最硬的数据。 Artificial Analysis 的 Intelligence Index 给 Gemini 3.7 Flash 打了 56 分，在 188 个模型中排名第 17，中位数是 34；同榜单上 Gemini 3.1 Pro Preview 是 48 分。这意味着一个「工作马」模型的综合智能得分，第一次超过了同品牌的前代旗舰。Artificial Analysis 的评价是「amongst the leading models in intelligence and well priced」——在智能维度领先，同时定价有竞争力。

再看定价。 官方公布 introductory price：$0.75/1M input tokens、$3.75/1M output tokens，有效期到 2026 年 12 月 31 日；从 2027 年 1 月 1 日起恢复 $1.50/$7.50。Google Cloud 定价页确认了这一安排，并注明 3.6 Flash 同样享受此 introductory price。而 Artificial Analysis 显示同档推理模型 input 中位数是 $1.71、output 中位数是 $10.00——3.7 Flash 的定价只有中位数的四成左右。

对企业读者来说，这个组合意味着什么？ 综合智能接近旗舰、单价接近 Flash-Lite 档位的模型出现，让「按层级选模型」的旧直觉失效。接下来的章节会逐项拆解：56 分是怎么来的、提升集中在哪里、thinking_level 如何改变路由逻辑、以及哪些任务仍然不适合交给它。

Artificial Analysis Intelligence Index 是一个综合评测，覆盖推理、知识、数学和编码四个维度，用加权方式合成一个可横向比较的分数。 它不测量单一任务，而是试图回答「这个模型整体上有多聪明」。Gemini 3.7 Flash 得分 56，超过中位数 34 超过 22 分，排名 17/188，也超过了 Gemini 3.1 Pro Preview 的 48 分。这是 Flash 系列首次在综合智能指数上超过同品牌 Pro 系列——在此之前，Flash 和 Pro 的边界是清晰的：Flash 适合大规模、低成本、中等性能的场景；Pro 适合复杂推理、高风险决策、高性能的场景。

这个超越不是偶然的。 从官方博客披露的 benchmark 看，3.7 Flash 相对 3.6 Flash 的提升集中在编码与知识工作：FrontierCode 1.1 Main 从 34.4% 到 43.6%，DeepSWE v1.1 从 49.0% 到 65.3%，WebDev Arena Elo 从 1538 到 1588，GDP.pdf 从 22.0% 到 34.0%，AutomationBench 从 17.0% 到 30.4%。这些定向优化的累积效果，使得 3.7 Flash 在综合指数上超过了前一代的 Pro。

还有一个容易被忽略的指标：输出精简度（verbosity）。 Artificial Analysis 显示 3.7 Flash 在 Intelligence Index 评测中平均输出 64M tokens，低于中位数 71M——它比同档模型更「话少」。对成本模型来说，输出精简度直接决定 output token 账单；对延迟来说，更少的输出意味着更快的首 token 时间。Artificial Analysis 对 3.7 Flash 的结论是「is a reasoning model」——它使用 extended thinking（扩展思考）在给出答案前先推理，这解释了为什么它的综合指数能到 56 分：它不是靠「背诵」而是靠「推理」得分。

但这不意味着 3.7 Flash 在所有场景上都优于 3.1 Pro。 Intelligence Index 是一个加权综合指标，它掩盖了不同维度的性能差异。3.7 Flash 在编码（FrontierCode、DeepSWE）和 Web 开发（WebDev Arena）上提升显著，但 GDP.pdf 34.0% 意味着处理复杂多页 PDF 时仍有约三分之二的失败率，AutomationBench 30.4% 意味着真实商业工作流只能正确完成约三分之一。对于企业选型来说，综合得分不能替代按任务类型的性能评估。

从 3.6 Flash 到 3.7 Flash 的提升，集中在编码和 Agent 能力上，而不是通用知识或推理能力。 官方博客给出的五组数据可以按「测试内容」分成三类：代码生成与修复（FrontierCode、DeepSWE）、Web 开发（WebDev Arena）、知识密集任务（GDP.pdf、AutomationBench）。三类的提升幅度并不均匀——编码和 Web 开发提升显著，知识密集任务的绝对得分仍然较低。

提升模式说明 3.7 Flash 的改进集中在「已经相对成熟的领域」，而非「尚未解决的难题」。 官方博客提到，3.7 Flash「better adapts to roadblocks, clarifies intent when needed, and follows instructions with greater fidelity」——这些描述指向的是「调试和修复」能力，而不是「一次生成完美代码」的能力。DeepSWE 的提升幅度（+16.3pp）高于 FrontierCode（+9.2pp），进一步验证了这个判断：模型在遇到错误时更擅长分析原因并修复，而不是在第一次尝试时就写出完美代码。

对于 Agent 场景来说，这个改进模式特别重要。 Agent 工作流通常是「生成代码 → 运行 → 修复错误」的迭代循环，而不是「一次性生成完整功能」。官方博客展示了三个内部用例：用 3.7 Flash orchestrate sub-agents（编排子代理）、配合 Nano Banana 实时生成 3D 游戏资产、以及用「3 agent graph loop」训练机器人多模态理解——这些场景都需要模型在多轮迭代中不断调整和优化。

一个值得单独说明的维度是「首次通过率」。 FrontierCode 1.1 Main 测试的是「第一次尝试就生成生产级代码」的能力，3.7 Flash 从 34.4% 提到 43.6%——这意味着在 100 次编码任务里，约 44 次不需要人工返工或模型自我修复。这个数字对成本模型的影响是直接的：首次通过率越高，Agent 迭代轮次越少，token 消耗和延迟越低。DeepSWE v1.1 更贴近真实开发者的日常——它测的是「面对一个带 issue 的真实代码仓库，能不能修复并跑通测试」，65.3% 意味着三分之二的真实 issue 可以在一次任务内解决。

3.7 Flash 最明显的短板，在知识密集、需要多步处理的任务上。 GDP.pdf 是测试「模型能否处理复杂文档」的评测：输入是财务报表、法规文件这类结构复杂、图文混排的多页 PDF，输出是提取、理解与回答。3.7 Flash 从 22.0% 提升到 34.0%，但 34.0% 的绝对得分意味着：处理这类文档时，仍有约三分之二的失败率。AutomationBench 是测试「模型能否完成真实商业工作流」的评测，3.7 Flash 从 17.0% 提升到 30.4%，同样只完成了约三分之一。

这两个数字对企业选型的含义非常直接： 如果你的业务涉及「读一份几十页的招股书并回答问题」「跑完一个跨系统的报销流程」这类任务，3.7 Flash 目前还不是可靠的选择——即使它的综合指数已经超过 3.1 Pro。综合指数的加权方式会稀释单项短板：编码 43.6%、Web 开发 1588 Elo 这些高分项，会把文档处理 34.0% 这样的低分项「平均」掉。

这也是为什么「只看 Intelligence Index 选模型」是危险的。 指数适合做横向初筛，不适合做任务级决策。负责任的做法是把指数当信号、把任务级 benchmark 当证据：先确定你的任务属于哪一类（代码？文档？工作流？对话？），再在那一类的 benchmark 上对比候选模型。

具体到落地，可以建立一个「任务 → benchmark → 通过阈值」的映射表。 例如：代码辅助任务看 FrontierCode/DeepSWE，通过阈值设为 50%；文档理解任务看 GDP.pdf，通过阈值设为 60%——如果模型只有 34%，直接排除；工作流自动化看 AutomationBench，通过阈值设为 50%——如果模型只有 30.4%，保留在观察名单而不是进入生产。没有这样的映射，企业很容易被「56 分」这个综合数字误导，把不适合的模型推上线。

Gemini 3.7 Flash 引入了 thinking_level 参数，允许开发者控制模型的「思考深度」。 Google Cloud 文档明确列出 3.7 Flash 支持的取值：LOW、MEDIUM（默认）、HIGH。这里有一个容易踩的坑：文档特别注明 MINIMAL 在 3.7 Flash 上不可用——显式设置 thinking_level="MINIMAL" 会直接返回 API validation error。3.6 Flash 时期的文档示例用 MINIMAL 演示「最浅思考」，但 3.7 Flash 的思考机制重构后，最低档是 LOW。

thinking_level 的工程价值在于：它改变了「模型路由」的实现方式。 在此之前，模型路由（model routing）是在多个模型之间切换——简单任务用 Flash，复杂任务用 Pro。现在，可以在同一个模型内部调整思考深度——简单任务用 thinking_level=LOW，复杂任务用 thinking_level=HIGH。Google Cloud 文档对 3.7 Flash 的定位描述是「bridging the gap between deep-reasoning Pro models and high-throughput Flash-Lite models」——正好卡在深度推理与高吞吐之间。这简化了模型路由的逻辑，也使得「思考深度」成为一个可以按任务动态调整的参数，而不是固定的模型属性。

从工程实现上看，动态调整带来的收益和代价是并存的。 收益是路由逻辑简化：不再需要维护两套模型接入（Flash + Pro），一套 API、一套鉴权、一套监控；代价是监控维度增加——原来用「模型名」区分负载特征，现在必须记录每个请求的 thinking_level，否则无法解释延迟和成本波动。推荐的做法是把 thinking_level 写进 trace 的 span attribute，与模型名并列，作为成本归因的第二个维度。

但 thinking_level 也带来了新的工程挑战。 第一，不同 thinking_level 的 token 消耗差异尚未公开——如果 HIGH 的推理 token 是 LOW 的 3 倍，动态调整的成本效益需要重新计算。第二，思考深度的最优值取决于任务复杂度，但任务复杂度的自动识别本身就是一个难题——系统错误判断时，要么思考深度不足（性能下降），要么过度（成本浪费）。第三，thinking_level 与 temperature、top_p 等传统采样参数的关系尚未明确——是替代关系还是正交关系？这些问题需要在生产实践中逐步解答。

定价策略值得单独拆解，因为它直接影响企业的成本模型。 Gemini 3.7 Flash 的 introductory price 是 $0.75/1M input tokens 和 $3.75/1M output tokens，有效期到 2026 年 12 月 31 日；从 2027 年 1 月 1 日起，价格恢复到 $1.50/1M input 和 $7.50/1M output——正好翻倍。Google 官方博客和 Google Cloud 定价页都确认了这一安排，并注明 3.6 Flash 同样享受此 introductory price。

和同档模型比，这个定价非常有竞争力。 Artificial Analysis 显示，同档推理模型的 input 价格中位数是 $1.71、output 价格中位数是 $10.00；3.7 Flash 的 input 定价只有中位数的 44%，output 定价只有 37.5%。也就是说，即使按 2027 年的恢复价 $1.50/$7.50 计算，3.7 Flash 仍然低于中位数。Artificial Analysis 的成本排名是 43/188——在「每单位智能的成本」上进入前四分之一。

还有一个容易被忽略的细节：缓存折扣。 Artificial Analysis 显示 3.7 Flash 的 cache hit 价格是 $0.40/1M input tokens，折扣约 90%；在 Agent 场景里，工具描述、系统提示和对话历史通常会重复命中缓存，实际成本会显著低于按原始 input 价估算的结果。Artificial Analysis 用一个 7:2:1（cache hit/input/output）的混合比例估算，综合成本约 $0.58/1M tokens。如果你的负载以长对话、固定工具集为主，按这个混合价做预算比按 $0.75 更接近真实。

可用性方面有一个细节值得注意。 官方博客宣布 Gemini Spark（个人 AI 代理，AI Pro/Ultra 订阅，覆盖 160+ 国家）从发布当天起使用 3.7 Flash；同时 3.7 Flash 通过 API 面向开发者开放，模型 ID 是 gemini-3.7-flash。这意味着消费级入口（Spark）和开发者入口（API）同步切换，企业可以立即通过 API 评估，不需要等产品灰度。做成本预算时要特别注意： 当前的成本优势是暂时的——基于 2026 年价格做的 ROI 测算，在 2027 年 1 月 1 日之后会翻倍，预算应该直接按恢复价计算。

3.7 Flash 的发布，使得企业选型逻辑从「选择模型层级」（Flash vs Pro vs Ultra）转向「选择任务适配」（这个任务适合哪个模型 + 什么 thinking_level）。 在此之前，Flash 和 Pro 的边界是清晰的：Flash 适合大规模、低成本、中等性能的场景；Pro 适合复杂推理、高风险决策、高性能的场景。现在，3.7 Flash 在 Intelligence Index 上超过 3.1 Pro，但这个超越是综合得分——在具体任务上，两者的性能差异仍然存在。

推荐的选型策略是： 第一，按任务类型评估性能，而不是按模型层级。编码辅助、Web 开发、简单对话、客服自动化——这些任务用 3.7 Flash 是性价比最高的选择。复杂文档处理、多步推理、高风险决策——这些任务仍然需要等待 3.5 Pro 发布或使用 Ultra。第二，对于需要动态调整思考深度的任务，使用 thinking_level 参数而不是模型路由。简单任务用 LOW，复杂任务用 HIGH，避免在多个模型之间切换的复杂性。第三，持续监控 Intelligence Index 和任务特定 benchmark 的更新——模型能力的边界在快速变化，今天的选型决策可能在三个月后就需要调整。

给技术决策者一份可执行的核对清单： ① 把「成本/百万 token」从「按模型层级预算」改成「按任务单价预算」，并在 2027-01-01 后用恢复价重算；② 在接入层支持 thinking_level 透传，默认 MEDIUM，为后续 A/B 测试留接口；③ 为每类任务建立 benchmark 通过阈值，而不是用综合指数做唯一依据；④ 迁移自 3.6 Flash 的代码先排查是否硬编码了 MINIMAL；⑤ 把 3.7 Flash 的 GDP.pdf/AutomationBench 短板写进风险登记册，标记「文档类/工作流类任务不可用」。这五条不依赖任何内部信息，全部基于官方博客、Cloud 文档和 Artificial Analysis 的公开数据即可执行。

需要提醒的是： 3.7 Flash 的思考机制在 3.7 Flash 上只有 LOW/MEDIUM/HIGH 三档，且默认是 MEDIUM。如果你的系统此前在 3.6 Flash 上设置了 thinking_level="MINIMAL" 追求最低延迟，迁移到 3.7 Flash 时必须先改成 LOW，否则 API 直接报错。这是迁移清单里最容易漏掉的一项。

局限一：综合指数会掩盖单项短板。 Intelligence Index 56 分是由推理、知识、数学、编码四个维度加权合成的。3.7 Flash 的编码和 Web 开发表现亮眼，但 GDP.pdf 34.0%、AutomationBench 30.4% 说明：涉及复杂文档和真实工作流的任务，失败率仍在三分之二左右。指数适合横向初筛，不适合任务级决策。

局限二：thinking_level 的成本与性能关系尚未公开。 Google Cloud 文档只列出 LOW/MEDIUM/HIGH 三个取值和默认值，没有披露不同档位的推理 token 消耗比例。在生产中，HIGH 档位的 token 消耗可能是 LOW 的 2-3 倍，但换来多少任务成功率提升，没有官方数据可依。企业只能通过 A/B 测试自测——这本身是有成本的。

局限三：thinking_level=MINIMAL 的迁移陷阱。 3.6 Flash 文档中的示例使用 MINIMAL，但 3.7 Flash 的受支持取值是 LOW/MEDIUM/HIGH，显式设置 MINIMAL 会返回 API validation error。任何从 3.6 Flash 迁移的代码，如果硬编码了 MINIMAL，必须在迁移时同步修改。

局限四：Agent 完成复杂工作流仍然不可靠。 AutomationBench 30.4% 意味着在真实商业工作流中，3.7 Flash 只能正确完成约三分之一的任务。即使它在调试和修复上大幅进步，多步、跨系统、需要长期记忆的工作流仍然是未解决的问题。把关键业务工作流全部交给模型自主执行，风险仍然很高。

局限五：数据时效与评测口径。 Artificial Analysis 的 56 分基于发布初期的评测，随着模型迭代和评测集更新，排名会变化；Google 官方博客的 benchmark 数字是厂商自测口径，与第三方复测可能存在偏差。企业决策时应以发布后 2-4 周内的第三方复测为准，不要只依赖发布日的厂商数据。

Gemini 3.7 Flash 的发布，标志着模型层级边界开始模糊化。 在此之前，Flash 和 Pro 的边界是清晰的——Flash 是工作马，Pro 是旗舰。现在，3.7 Flash 在 Intelligence Index 上超过 3.1 Pro，思考深度可以通过 thinking_level 在同一个模型内调节，定价低于同档中位数。模型层级（Flash/Pro/Ultra）仍然有意义，但它的含义从「性能等级」转向「成本与吞吐等级」——Flash 是最便宜的，Pro 是中等价位的，Ultra 是最贵的。性能差异将通过 thinking_level 和任务特定优化来实现，而不是通过模型层级。

对于开发者来说，这意味着： 第一，不要假设「Pro 一定比 Flash 好」——在具体任务上评估性能，而不是按模型层级做决策。第二，学习使用 thinking_level 参数——它将成为模型路由的重要替代方案，但要注意 3.7 Flash 只支持 LOW/MEDIUM/HIGH。第三，持续监控模型能力的边界——模型能力的快速变化，意味着今天的选型决策可能在三个月后就需要调整。

对于 Google 来说，3.7 Flash 的发布是一个信号： Flash 系列不再只是「低成本、中等性能」的工作马，而是「低成本、高性能」的主力模型。这个定位变化，可能会影响未来 Flash 和 Pro 的迭代策略——Flash 的迭代速度可能加快，Pro 的迭代速度可能放缓（专注于 Flash 未能解决的难题，比如复杂文档和长程工作流）。对企业的实际含义是：选型时的默认假设应该从「贵的就是好的」转向「在任务 benchmark 上验证过的才是好的」——而 3.7 Flash 恰好是检验这套新方法论的第一个样本：指数很高，但短板明确，一切都要回到你的具体任务去验证。

• Introducing Gemini 3.7 Flash: our most intelligent workhorse model — Google 官方博客，2026-08-13。包含 FrontierCode 1.1 Main（43.6% vs 34.4%）、DeepSWE v1.1（65.3% vs 49.0%）、WebDev Arena Elo（1588 vs 1538）、GDP.pdf（34.0% vs 22.0%）、AutomationBench（30.4% vs 17.0%）与 introductory price 说明。
• Gemini 3.7 Flash — Artificial Analysis — 独立评测机构，2026-08。Intelligence Index 56 分、排名 17/188、中位数 34；定价 $0.75/$3.75，同档中位数 $1.71/$10.00。
• Gemini 3.7 Flash — Google Cloud Documentation — Google Cloud 官方文档，2026-08-13 更新。thinking_level 支持 LOW/MEDIUM（默认）/HIGH，MINIMAL 不可用；模型 ID gemini-3.7-flash。
• Artificial Analysis — Models Leaderboard — 独立评测机构。Gemini 3.1 Pro Preview 48 分 vs Gemini 3.7 Flash 56/53 分。
• Gemini API pricing — Google Cloud — Google Cloud 定价页。3.7 Flash 与 3.6 Flash introductory price $0.75/$3.75 至 2026-12-31，2027-01-01 起 $1.50/$7.50。