Gemini 3.6 Flash 的关键不只是更强：Agent 成本开始由有效任务而不是 token 单价决定
Gemini 3.6 Flash 最值得注意的地方，不是某个榜单又涨了几个点，而是 Google 把“更少输出 token”“更长上下文”“工具调用”和“长任务编码”同时放进了 Flash 级模型的产品位置。
这意味着模型选型的单位正在变化。聊天时代按一次回答比较质量和价格，Agent 时代要按一次被验证的完整任务，统计模型调用、工具等待、失败重跑和人工审查的总成本。
先把官方数字放回正确语境
Google 公布的结果显示，3.6 Flash 相比 3.5 Flash 在多项 Agent 场景上提升：DeepSWE v1.1 从 37% 到 49%，OSWorld-Verified 从 78.4% 到 83.0%，MLE-Bench 从 49.7% 到 63.9%。其 1M 上下文 MRCR 指标也从 26.6% 提升到 54.0%。官方同时给出更低的输出价格，并强调相对上一代减少输出 token。
这些数字能说明方向，不能直接替代业务结论，原因至少有四个：
- benchmark 的仓库、工具和权限环境与你的生产环境不同；
- 成功率是聚合值，无法表示关键任务的尾部风险；
- 长上下文检索得分提升，不等于把全部资料塞进 1M token 就最经济；
- 工具调用场景的端到端耗时，往往被网络、沙箱启动和外部 API 主导。
正确做法不是忽略榜单，而是把榜单当作提出实验假设的起点。
Token 效率为什么比 token 单价更重要
一次 Agent 任务的成本可以拆成：
总成本 = 输入 token + 输出 token + 工具与沙箱 + 失败重跑 + 人工审查
便宜模型如果多绕三轮、产生更长的解释、频繁调用错误工具，最终可能更贵；贵模型如果一次形成正确计划并减少返工，反而降低任务成本。
因此模型选型至少要记录五个分母：
| 指标 | 它真正回答什么 |
|---|---|
| 每次尝试成本 | 单轮有多便宜 |
| 一次完成率 | 多少任务不需要重跑 |
| 每个通过任务成本 | 得到一个被验证结果要花多少 |
| 人工分钟数 | 省下的机器成本是否转嫁给 reviewer |
| P95 完成时间 | 长尾任务是否拖垮队列和体验 |
“输出 token 减少”只有在答案仍然完整、工具参数正确、验证通过时才有价值。过度压缩导致遗漏约束，节省的是账单，增加的是返工。
1M 上下文不是检索系统的替代品
3.6 Flash 的长上下文能力显著提升，但 1M token 仍然应该被视为上限，不是默认输入尺寸。大上下文会带来更高首 token 延迟、更多无关信息、证据冲突和缓存失效。
生产系统更适合分层装载：
- 固定指令层：权限、输出契约、不可违反的规则。
- 任务工作集：本轮真正相关的文件、issue 和日志。
- 按需检索层：Agent 通过工具拉取进一步证据。
- 外部状态层：进度、决策和失败记录，不依赖对话保留。
长上下文的最好用途是处理不可轻易切碎的整体，例如跨文件迁移、长合同证据定位、视频与文档的联合理解；对结构清晰的代码库，先构建项目地图再按需读取，通常更稳也更便宜。
Flash 模型适合做执行层，但不应该包办所有节点
更合理的 Agent 图不是“所有请求都发给一个最强模型”，而是按风险路由：
| 节点 | 默认模型策略 | 升级条件 |
|---|---|---|
| 分类、抽取、格式化 | Flash / 低推理 | 置信度低或结构校验失败 |
| 常规代码修改 | Flash + 工具 + 测试 | 跨架构、跨服务或连续失败 |
| 方案设计 | 高推理模型 | 关键约束仍不确定时转人工 |
| 独立复核 | 不同上下文或不同模型 | 高风险变更增加确定性检查 |
| 最终发布 | 确定性门控 | 不允许模型单独决定 |
Flash 的优势在高频循环。真正节省成本的方式，是让它承担可验证、可回滚的执行，把昂贵推理留给少数影响路径，而不是为了追求模型统一让每个节点都过度配置。
自建评测应该怎样设计
建议从 30–50 个真实任务构建 shadow evaluation，任务按风险和长度分层：
- 短任务：单文件修复、结构化抽取、常规查询；
- 中任务：跨模块修改、工具链运行、证据型研究；
- 长任务：迁移、调试、端到端应用修改；
- 高风险任务：权限、安全、财务、生产操作，只做建议或沙箱演练。
每个任务预先冻结验收器，记录模型版本、prompt 版本、工具版本和随机性参数。至少统计：一次通过率、最终通过率、工具错误率、回滚次数、总 token、wall-clock 时间、人工分钟数和严重失败数。
尤其要防止“评测器跟着模型一起优化”。如果每次换模型都修改验收标准，就无法判断进步来自模型还是尺子。
迁移 3.5 Flash 时最容易忽略的三件事
第一，输出更短可能改变下游解析。不能只做语义 spot check，要跑真实 schema、代码块、引用和工具参数验证。
第二，长上下文能力改善可能让团队放松上下文治理。短期感觉省事，长期会让 prompt 包不断膨胀。应该保留检索命中率和有效上下文比例指标。
第三，Agent benchmark 提升可能诱导扩大权限。模型更强不代表权限模型可以更松。写生产、付款、删除、对外发送仍然需要最小权限、幂等键和人工门槛。
真正值得关注的是有效任务密度
Flash 模型的竞争终点不是每秒吐出多少 token，而是单位时间和单位预算内，产出多少被独立验证、无需返工的结果。
Gemini 3.6 Flash 提供了一组有吸引力的新起点：更强的长任务能力、更高的长上下文保持率、更好的工具使用和更低的输出成本。但生产收益不会从模型卡自动流入系统。只有模型路由、上下文治理、验证器和成本观测同时存在，token 效率才会变成业务效率。