Gemini 3.7 Flash 刚发布：我更在意的不是跑分，而是 $0.75 输入价把 Agent 成本线往下压了一截

8 月 13 日，Google 发布了 Gemini 3.7 Flash。

如果只看发布稿，很容易把注意力放在几组提升数字上：FrontierCode 1.1 从 34.4% 提到 43.6%，DeepSWE v1.1 从 49.0% 提到 65.3%，AutomationBench 从 17.0% 提到 30.4%。

这些数字当然重要。

但我看完之后，真正让我觉得值得写一篇的，不是“又一个模型跑分涨了”，而是另外一件事：

Google 正在把一个明显偏 Agent、偏 Coding、偏 Workflow 的模型，压到 $0.75 / 1M 输入 Token、$3.75 / 1M 输出 Token。

这个价格只到 2026 年 12 月 31 日，之后会涨到 $1.50 / $7.50。可即便按明年的价格算，它仍然在逼着很多原本“默认上旗舰模型”的 Agent 架构重新算账。

我不准备把这篇写成又一篇参数表。更值得讨论的是：Flash 这个定位，已经不是“便宜模型负责简单问答”了。

先算一笔最朴素的账

假设一个企业内部 Agent，每次任务平均消耗：

输入：40K Token
输出：8K Token

这并不夸张。只要用了系统提示词、检索上下文、工具定义、几轮工具回传和少量历史消息，40K 输入很容易就到了。

按 Gemini 3.7 Flash 当前价格：

输入成本：0.04 × $0.75 = $0.03
输出成本：0.008 × $3.75 = $0.03
一次任务约：$0.06

一天 10 万次任务，大约就是：

$6,000 / 天

听起来仍然不少。

但如果旧架构把同样任务全部扔给高价旗舰模型，成本差距会被快速放大。尤其是多 Agent 场景，一次用户请求背后可能是：

Router
→ Planner
→ 3 个 Sub-Agent
→ Reviewer
→ Final Answer

所以我现在看模型价格，不太看“每百万 Token 多少钱”这一个数字，而是看：

单任务成功成本
=
一次成功任务需要多少调用
× 每次调用 Token
× 模型价格
× 重试率

这才是 Agent 真正该算的成本。

Flash 正在抬高“便宜模型”的任务上限

过去做模型分层，常见思路是：

小模型：分类、抽取、改写、简单 Tool Calling
旗舰模型：复杂规划、Coding、多工具、长任务

这种分层到 2026 年越来越不准确。

Google 在 3.7 Flash 的发布说明里，重点强调的是软件工程、Debugging、Issue Resolution、长流程 Agent、企业 Workflow Automation、Web Development 和 PDF 知识工作。

更准确的理解是：

Flash 正在争夺大量原本必须用旗舰模型才能放心做的中高难度任务。

这会直接改变模型路由设计。

以前常写：

if task_complex:
    use_frontier_model()
else:
    use_small_model()

现在更合理的做法是：

先用高性价比模型跑
↓
检测不确定性、失败信号、风险
↓
必要时升级旗舰模型

也就是“升级式路由”，而不是“复杂任务预判式路由”。

为什么我更关注 AutomationBench 30.4%

Google 官方给出的数据里，Gemini 3.7 Flash 在 AutomationBench 上从 17.0% 提升到 30.4%。

30.4% 并不是一个看起来“无敌”的数字。

恰恰因为不高，我反而觉得它更有参考价值。企业 Agent 真正难的是：

看懂目标
→选择工具
→调用正确参数
→处理工具返回
→继续下一步
→完成任务

任何一个环节出错，最终都算失败。

所以这类端到端 Workflow Benchmark，通常比“回答一道知识题”更能暴露真实问题。

30.4% 也提醒了一件事：即使是 2026 年的新模型，复杂业务 Agent 仍然远没有到可以“模型自己跑，工程不用管”的阶段。

如果系统里有订单、付款、CRM、数据写入、审批、删除、权限变更，仍然需要应用层状态机、幂等、审批、预算和回滚。

模型更强，只是让语义决策更可靠，不会替你补上分布式系统。

Coding 数据的意义，也不是“可以不用程序员了”

Google 公布：

FrontierCode 1.1：34.4% → 43.6%
DeepSWE v1.1：49.0% → 65.3%

我会把它理解成：

同样价格档位下，Flash 可承担的 Coding Agent 子任务更多了。

以前可能只敢让便宜模型做文件定位、简单修复、生成测试、API 调用示例。现在可以开始试多文件改动、Issue Resolution、小型 Feature、自动 Debug、代码 Review 前置检查。

但我不会直接把核心仓库全交给它。

Coding Agent 最容易出现的不是“代码完全不会写”，而是：

改了不该改的文件
测试没跑全
依赖版本假设错误
边界条件漏掉
局部看起来正确，系统行为变了

所以模型能力提升以后，工程上最该做的是扩大自动化测试和权限沙箱，而不是放松控制。

价格很诱人，但这个日期一定要写进预算表

Gemini 3.7 Flash 的 $0.75 / $3.75 是 introductory price。

截止：

2026-12-31

从 2027-01-01 开始变成：

$1.50 / 1M input
$7.50 / 1M output

也就是直接翻倍。

这类价格最容易制造一个隐形坑：8 月做 PoC 时 ROI 很漂亮，年底上线大规模流量，第二年预算突然变样。

所以现在做成本模型，我建议直接做两套：

pricing:
  current:
    input_per_million: 0.75
    output_per_million: 3.75
  2027:
    input_per_million: 1.50
    output_per_million: 7.50

预算评审看 2027 价格，不要只拿促销期价格。

我会把 3.7 Flash 放在哪一层

第一层，大量日常任务：分类、信息抽取、RAG 回答、文档总结、常规代码修改、多数工具调用、普通工作流。

第二层，失败升级。出现这些信号才升级：

低置信
结构连续失败
工具调用循环
多个证据冲突
高风险
Reviewer不通过
用户明确要求深度推理

第三层，旗舰模型：高复杂规划、长周期 Coding、模糊需求、高价值决策辅助、最终 Review、异常恢复。

不要让 LLM 自己说“我觉得这个任务很难，请升级模型”。模型很容易滥用升级。可以把升级条件做成程序：

def should_escalate(result, trace):
    if trace.tool_call_count > 8:
        return True
    if trace.retry_count >= 2:
        return True
    if result.confidence < 0.72:
        return True
    if trace.has_blocking_conflict:
        return True
    if trace.risk_level in {"HIGH", "CRITICAL"}:
        return True
    return False

一个月后，你就能从数据里回答：到底哪些任务真的需要旗舰模型？

最后说一个我不太赞同的观点

每次 Flash 一类模型升级，都有人问“旗舰模型是不是没必要了”。

我不这么看。

真正发生的是模型层级在整体上移：

昨天的旗舰能力
逐渐变成今天的工作马能力

旗舰模型仍然有价值，只是它不应该被拿来处理所有请求。

Gemini 3.7 Flash 这次最值得关注的地方，就在这里：它不是单纯让模型更便宜，而是在扩大“便宜模型能完成的任务集合”。

如果你的 Agent 系统还只有一个 model 配置项，没有路由、升级、预算和失败回退，这次反而是一个很好的重构节点。

更多企业级 AI 应用、Agent、RAG 与模型工程化内容，我会继续整理在 智元界：

https://www.zyentor.com/