Gemini 3.8 六周三更，我反而不敢自动升级

Gemini 3.7 Flash 发布才三周，3.8 就来了。

把时间再往前拨一点，这是 Google 六周内放出的第三个 Flash 版本。3.7 Flash 还没来得及在很多团队里坐稳，下一班车已经进站。

六周，三更。

Google 的发布公告里，Gemini 3.8 Flash 的定位很直接，长周期软件工程、智能体任务、专业领域多步推理。促销价继续沿用 3.7，每百万输入 Token 0.75 美元，输出 Token 3.75 美元。到了 2027 年 1 月 1 日，两项价格都会翻倍。

跑分也挺亮。DeepSWE v1.1 上，3.8 Flash 得到 73.7%，3.7 是 65.3%。Vals Finance Agent V2 从 59.0% 涨到 61.4%，Harvey 法律智能体评测从 8.8% 涨到 10.0%。

好家伙，价格没动，分数往上抬，版本号还热乎着。

最顺手的动作当然是把生产配置里的 gemini-3.7-flash 改成 gemini-3.8-flash，然后等账单和成功率一起变好。

我自己的判断却刚好相反。Google 更新得越快，生产团队越不能把模型升级做成一次字符串替换。

真正要升级的，是模型外面的发布系统。

图，3.8 Flash 在多项任务上高于 3.7，但不同评测的领先幅度差异很大，来源 Google

模型 ID 不是配置项，它是一份会漂移的依赖

程序员对升级依赖并不陌生。数据库驱动从 4.2 升到 4.3，你会看变更日志，会跑测试，会留回滚版本。很少有人敢在周五下班前把核心依赖改成 latest，提交完就去赶地铁。

模型却经常被当成另一种东西。

控制台弹出新品，排行榜多了几分，团队把默认模型一换，所有 Agent 第二天一起吃新版本。代码没有改，接口也还能返回 200，看起来像无事发生。

偏偏最麻烦的变化，都藏在 200 里面。

同一个提示词，新模型可能更愿意调用工具，也可能在调用前多想几步。它可能更少漏掉边界条件，却把原来 40 秒的任务跑成 70 秒。它可能更擅长修复复杂 Bug，同时更爱改动任务范围之外的文件。输出 JSON 仍然合法，字段里的分布已经换了。

Gemini 3.8 Flash 的模型卡还把其中一项代价写得很坦白。复杂任务里，模型会增加推理步骤并反复调用工具，高 effort 档位可能消耗更多 Token。若应用更看重计算效率，Google 建议降低 effort，或者继续使用 3.7 Flash。

这句话比榜单更接近生产环境。

它告诉你，3.8 的提升不是凭空掉下来的。模型愿意多干活，任务成功率可能上去，单次调用量、工具轮数、尾延迟和超时概率也可能跟着变。官网表格上的单价相同，不代表一张真实工单的价格相同。

再看 DeepSWE 那张图，3.8 Flash 的 73.7% 确实很强，和 Claude Opus 5 的 74.0% 已经站得很近。可到了 Terminal-bench 4.0，官方总表给出的 3.8 成绩是 19.1%，Opus 5 是 51.8%。OSWorld 2.0 上，3.8 是 59.0%，Opus 5 是 75.4%。

不是谁算错了，而是任务不一样。

一个模型在长周期代码题里接近第一，不会自动变成你家客服 Agent、报表 Agent、采购 Agent 的第一。平均分很适合做候选池，自己的任务集才有资格决定默认值。

这里还有一个经常被忽略的小坑，公开表格里的分数不是同一种单位。DeepSWE 看长周期软件工程任务能不能端到端完成，Terminal-bench 更偏终端里的通用 Agent 能力，OSWorld 测的是跨应用电脑操作。把三列加起来算平均值，看着科学，实际像把百米、游泳和举重的成绩算成一个总秒数。

Google 的评测方法页也给了一个很朴素的提醒。不同模型可能使用不同 effort 档位、工具配置和批量方式，部分第三方模型的结果来自供应商或公开榜单。图能告诉你候选模型大概站在哪儿，不能替你签生产验收单。

图，3.8 Flash 位于 DeepSWE 的高通过率低成本区域，来源 Google 与 Datacurve AI

六周三更以后，升级得像一趟发布列车

如果团队已经在用 Gemini 3.7，我会把 3.8 当成一个候选版本，而不是一个通知弹窗。

这俩词看着只差一点，工程动作完全不同。

候选版本先拿不到全量流量。它要在和稳定版本相同的输入、工具权限、超时预算里跑一遍。评测也不能只盯最终答案，要同时记下任务成功率、工具调用次数、输入输出 Token、P50 和 P95 延迟、重试次数、人工接管率，以及安全策略拒绝了多少本该完成的任务。

很多朋友可能会觉得，搞这么多列是不是太重了。

坦率讲，一个只负责润色文案的小功能，确实没必要造航空母舰。可 Agent 一旦能写数据库、发消息、改权限、触发支付，升级成本就不再由模型调用费决定，而是由一次错误动作能伤到多深决定。

可以从一份很小的假设配置开始。

model_rollout:
  stable: gemini-3.7-flash
  candidate: gemini-3.8-flash
  candidate_traffic: 5
  rollback_on:
    task_success_drop: 0.03
    p95_latency_increase: 0.20
    human_takeover_increase: 0.05

这些阈值不是行业标准，只是把判断写进系统的示例。真正的数值要按业务风险和历史波动来定。重点在于，稳定版和候选版必须同时存在，回滚条件必须在切流量前写好。

版本也别只记一个名字。每次请求至少留下模型 ID、effort 档位、系统提示词哈希、工具描述哈希、评测数据版本和应用提交号。哪天成功率突然掉了，团队能回答到底是模型换了、提示词换了、工具 schema 换了，还是业务数据自己长歪了。

不留这些信息，事故复盘会变成一场大型猜谜。供应商说模型没动，应用同学说代码没动，平台同学说网关也没动，最后所有人一起看着曲线往下掉。棒棒的，系统里每样东西都有版本，偏偏真正做决定的那颗脑子只留下一个商品名。

然后拿真实任务的脱敏副本做离线对照。三十到一百条就能起步，里面要混入正常请求、边界请求、工具失败、空结果、长上下文和需要模型主动停手的场景。每条任务固定输入，外部数据做快照，随机性参数保持一致，至少重复跑几次。

别把公开榜单抄进自己的验收表就算完事。你家的 Agent 会遇到缺字段的工单、过期链接、返回半截的 API、突然变更的权限。公开评测替你筛掉明显不合适的模型，筛不掉你自己的烂现场。

评测时也别只看最后答案。Agent 的危险和浪费，很多都发生在答案出现之前。

同样一条修 Bug 任务，两个版本都可能把测试跑绿。稳定版读了六个文件，改了两个文件，跑了三条命令。候选版读了整个仓库，顺手升级依赖，申请了一次外网访问，失败后又重试五次。若验收只盯最终 diff，两边都是一分。若把轨迹、权限和成本一起算，差别已经大到不能装没看见。

所以每条样本最好同时有三种检查。确定性检查负责测试、JSON schema、文件范围和权限边界。语义检查负责答案是否完整、引用是否对应、措辞是否满足业务要求。轨迹检查负责工具调用顺序、失败重试、无效读取和副作用。前两项告诉你事情做对没有，后一项告诉你它是怎么把事情做对的。

失败样本也不要只留一个红叉。把它分成理解错任务、选错工具、工具返回后没纠正、格式不合格、越权动作、超时和成本超标。平均成功率从 82% 涨到 86% 很漂亮，如果新增的 4% 来自文案任务，代价却是支付确认场景多了一次越权尝试，这个升级还是不能放行。

离线过线后，再给候选版 5% 的影子流量或灰度流量。影子模式只读，不执行真实副作用，适合先看答案质量和工具选择。灰度模式才让少量真实任务交给新模型，同时保留熔断器和旧版本。

灰度期间，别只盯全站总成功率。按任务类型、工具、输入长度和风险等级拆开看。新模型可能让短任务变快，却让长上下文的 P95 延迟飙高。也可能把代码任务做得更稳，同时在结构化输出里增加少量尾部错误。总平均会把这些尖刺抹平，用户不会。

回滚开关还要真的演练一次。不是写在文档里，也不是看着配置觉得能切，而是在不影响真实用户的环境里，把候选流量切回稳定版，确认会话状态、缓存键和重试队列不会把旧任务继续送给新模型。真正出问题时，没人有空现场研究路由器为什么还记着上一代。

厉害了也好，榜首也好，过不了自己的错误预算，就回去继续当候选。

这套流程最值钱的地方不是挡住 3.8，而是让下一次 3.9、4.0 或别家的新模型到来时，团队不用重新开一场拍脑袋会议。发布列车已经铺好轨道，谁想上车，按同一套票检。

还有价格。

3.8 和 3.7 现在的 0.75 美元输入价、3.75 美元输出价都带着「促销」两个字。官方脚注写得很清楚，2026 年 12 月 31 日到期，第二天变成 1.50 美元和 7.50 美元。若团队只用九月账单评估年度成本，模型能力没退步，预算会在元旦先表演一次翻倍。

更麻烦的是 Agent 不是一次问答。它会读上下文、调工具、把结果塞回来、继续推理，再失败重试。高 effort 多转几轮，单价翻倍就会沿着整条轨迹放大。上线评审里最好同时放当前价和标准价两列，再用真实任务的 Token 分布算一遍，不要拿每百万 Token 的海报数字代替每张工单的成本。

Cyber 版本更强，边界也更窄

这次发布还有一个容易把注意力吸走的版本，Gemini 3.8 Flash Cyber。

它在 CWE-Bench 自动修补评测上的 pass@1 是 47.2%，领先前沿模型为 47.8%。Google 还称，Chrome 安全团队用它生成的正确漏洞补丁数量，是最佳大型商业模型的 2.6 倍。Wiz 的内部渗透测试里，它的召回率高 7.5% 至 9.7%，成本低 2.3 至 5.2 倍。

有点子牛逼。

但这组结果不能被压成一句「便宜模型快追平安全专家」。CWE-Bench 是外部评测，Wiz 数据来自合作伙伴内部基准，覆盖二十种语言、成功率超过 70% 的那组结果则来自 Google 内部评测。三个口径都有价值，不能揉成一个万能胜率。

更关键的边界写在获取方式里。Flash Cyber 不是普通开发者在 AI Studio 里点一下就能用的通用模型。它通过 Fairwind Program 向受信任的防御团队开放，防护限制也比普通 3.8 Flash 更宽松。

所以生产团队看到 Cyber 的高分，下一步不是偷偷把安全扫描全交出去，而是先确认三个问题。代码能不能进入这套受控环境，模型能不能只拿到修补所需的最小权限，补丁能不能经过确定性测试和人工审核再合入。

图，Flash Cyber 的 47.2% 接近最高通过率，但该版本只向受信任防御团队开放，来源 Google

模型能找到漏洞，不等于它应该直接拿到发布密钥。

这块需要注意一下，能力边界和权限边界从来不是同一条线。能力越强，最小权限、审计日志、隔离环境和回滚机制越不能省。把自动补丁生成和自动上线绑在一起，省下的是十分钟审核，赌上的是整条供应链。

回到六周三更。

Google 把 Flash 的进步压进了越来越短的发布周期。对开发者当然是好事，便宜模型正在追上过去只有大模型才能做的长任务。可模型厂商的发版速度，不该直接变成你生产环境的变更速度。

模型可以三周换一代。

你的系统得决定，哪一代有资格留下来。