Gemini 3.6 Flash真正的升级，不是跑分：Google正在把Flash变成Agent执行引擎

程序员-小梁

772人浏览 · 2026-08-17 16:23:33

程序员-小梁 · 2026-08-17 16:23:33 发布

摘要：

Google最新一代Flash模型已经从“便宜、快”继续往Agent执行层推进。

Gemini 3.6 Flash不仅降低了输出Token成本，还把Computer Use、Code Execution、File Search、Function Calling和长上下文能力放进同一个模型。

真正值得开发者关注的，不只是Benchmark分数。

而是一个Flash级模型开始同时具备“看、想、查、调用工具、操作界面、持续执行”的能力。

本文从工程角度拆解Gemini 3.6 Flash为什么更像Agent Runtime的执行引擎，并用Python实现一个包含Task Profile、Model Router、Computer Use Gate、Token预算和Verifier的最小工作流。

FACT-001｜先把几个型号与组织信息说清楚

Google官方当前最新GA Flash模型是Gemini 3.6 Flash，模型ID为gemini-3.6-flash。

官方文档显示它支持100万Token输入上下文、64K输出、Computer Use、Code Execution、File Search、Function Calling、Structured Output、Search Grounding和Maps Grounding。

Google DeepMind官方About页面目前仍显示Demis Hassabis担任Google DeepMind CEO。

目前没有在Google或DeepMind官方页面中找到名为“SL2T”的正式产品发布页。

因此本文只基于当前Google官方已经发布并可验证的Gemini 3.6 Flash能力展开。

关键词：Gemini 3.6 Flash、Agent、Computer Use、Function Calling、File Search、Model Router、Token Efficiency、Multimodal

1. 3.6 Flash最重要的变化，不是“又快了一点”

Flash系列过去最明确的定位，是低延迟和高吞吐。

但Gemini 3.6 Flash已经明显不是单纯的“快速回答模型”。

Google官方给它的Best For里，直接包含：

Agentic Coding。

Advanced Reasoning。

Multimodal Understanding。

Long Context Understanding。

再叠加Computer Use、Code Execution和File Search以后，它已经具备一个Agent执行引擎所需要的大部分原生能力。

Gemini 3.6 Flash
  ├── Reasoning
  ├── 1M Context
  ├── Function Calling
  ├── File Search
  ├── Code Execution
  ├── Computer Use
  ├── Search Grounding
  ├── Maps Grounding
  └── Structured Output

这件事真正改变的是Agent架构。

2. 为什么Agent最需要的不是最高分，而是“每轮少走几步”

普通聊天只调用一次模型。

Agent不一样。

一个真实任务可能需要10次、30次甚至更多轮模型调用。

所以Agent成本真正敏感的不是单次Token价格。

而是整个Loop需要多少轮。

Google官方对3.6 Flash的一个重要描述是：

它比3.5 Flash用更少的推理步骤、对话轮次和工具调用完成多步任务。

这比单纯“单次更快”更重要。

Agent Total Cost
=
Model Cost Per Turn
× Number of Turns
+ Tool Cost
+ Retry Cost

如果一个模型每轮贵10%，但把30轮任务减少到15轮，整体反而可能更便宜。

3. 3.6 Flash的Token效率为什么值得单独看

Google官方数据显示，3.6 Flash相比3.5 Flash减少了约17%的输出Token使用量。

输出价格也从3.5 Flash的9美元/百万Token降到7.5美元/百万Token。

输入价格保持1.5美元/百万Token。

对于长任务Agent，这个变化会被循环放大。

def estimate_agent_cost(
    turns: int,
    input_tokens_per_turn: int,
    output_tokens_per_turn: int,
    input_price: float,
    output_price: float,
):
    input_cost = (
        turns
        * input_tokens_per_turn
        / 1_000_000
        * input_price
    )

    output_cost = (
        turns
        * output_tokens_per_turn
        / 1_000_000
        * output_price
    )

    return input_cost + output_cost

Agent真正应该统计的是Task Cost。

不是单次API Cost。

4. Computer Use进入Flash主力模型，意味着什么

Computer Use以前经常被单独做成一个专用模型。

现在3.6 Flash已经原生支持Computer Use。

这让Agent可以：

看网页。

识别UI。

点击按钮。

填写表单。

在浏览器、桌面或移动界面中执行动作。

从架构上看，它把两个原本分离的层合并了。

Before:

Reasoning Model
   ↓
Computer Use Model
   ↓
Browser / Desktop


Now:

Gemini 3.6 Flash
   ↓
Native Computer Use
   ↓
Browser / Desktop

模型切换减少以后，Agent上下文更容易保持一致。

5. 但Computer Use不能默认开放

能点击界面，也意味着能产生真实操作。

所以Computer Use必须先过Action Gate。

from dataclasses import dataclass
from enum import Enum


class ActionRisk(str, Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"


@dataclass
class UIAction:
    action: str
    target: str

    writes_data: bool
    financial: bool
    irreversible: bool


def classify_action(
    action: UIAction,
) -> ActionRisk:

    if (
        action.financial
        or action.irreversible
    ):
        return ActionRisk.HIGH

    if action.writes_data:
        return ActionRisk.MEDIUM

    return ActionRisk.LOW

只读浏览可以自动执行。

填写草稿可以进入中风险。

付款、删除、发布则应该要求确认。

CU-101｜COMPUTER_USE_WITHOUT_GATE

Computer Use可以产生真实外部动作，如果没有风险分级和人工确认，Agent错误会直接变成业务动作。

6. File Search + 1M Context，为什么会改变RAG设计

3.6 Flash支持100万Token上下文。

同时还支持File Search。

这并不意味着以后不用RAG。

恰恰相反。

更合理的设计是：

Small Context
→ Direct Context

Medium Knowledge Base
→ File Search

Large Enterprise Corpus
→ Retrieval + Metadata + Rerank

Very Long Task
→ Retrieval + 1M Context + Checkpoint

长上下文负责“容纳更多相关信息”。

检索负责“找到真正相关的信息”。

两者并不是替代关系。

7. 一个真正实用的Agent Router应该怎么写

如果平台同时拥有多个模型，就不应该所有任务都丢给同一个模型。

from dataclasses import dataclass


@dataclass
class TaskProfile:
    complexity: int

    needs_computer_use: bool

    needs_long_context: bool

    latency_sensitive: bool

    high_volume: bool


def route_model(
    task: TaskProfile,
):
    if (
        task.needs_computer_use
        or task.needs_long_context
    ):
        return "gemini-3.6-flash"

    if (
        task.high_volume
        and task.complexity <= 2
    ):
        return "low_cost_model"

    if task.complexity >= 4:
        return "frontier_model"

    return "gemini-3.6-flash"

这里的重点不是Gemini一定是默认模型。

而是它的能力应该被写进Model Registry。

8. Model Registry应该记录哪些东西

@dataclass
class ModelMeta:
    model_id: str

    modalities: set[str]

    context_window: int

    max_output_tokens: int

    supports_tools: bool

    supports_computer_use: bool

    supports_file_search: bool

    supports_code_execution: bool

    input_price: float

    output_price: float

    latency_class: str

如果没有Registry，模型能力就会散落在各种if-else里。

模型升级后整个系统都要修改。

REG-202｜HARDCODE_MODEL_CAPABILITY

模型名称、上下文、工具能力和价格全部写死在业务代码里，会让多模型平台很快失去可维护性。

9. 从官方Benchmark看，3.6 Flash真正强在哪里

Google官方公开的3.6 Flash结果非常有代表性。

Benchmark	Gemini 3.6 Flash	重点
SWE-Bench Pro	58.7%	真实软件工程
DeepSWE v1.1	49%	长周期开发任务
Terminal-Bench 2.1	78.0%	终端Agent
OSWorld-Verified	83.0%	Computer Use
CharXiv	85.2%	复杂图表推理

这些指标说明它最有优势的不是某一个单点。

而是Coding、Computer Use、多模态和长任务同时达到可用水平。

10. “接近GPT‑5.6 Terra”这种说法为什么不要直接写

不同厂商的Benchmark组合并不完全一致。

即使两个模型在某一项接近，也不能直接得出“整体接近”的结论。

OpenAI自己的GPT‑5.6官方页面也给出了Gemini 3.5 Flash和Terra的部分对比。

不同任务上的差距并不一致。

所以更可靠的做法是：

Don't ask:

Which model is stronger?


Ask:

Which model is better
for this task,
under this latency,
cost,
tool,
and context constraint?

这也是Model Router比模型排行榜更重要的原因。

11. 为什么500+模型平台特别需要这种路由

当平台只有5个模型时，用户可以自己选。

当平台聚合500+AI模型以后，让用户自己理解每个模型的：

上下文。

工具能力。

模态。

延迟。

价格。

已经不现实。

如果平台还同时有智能体、无限画布、AI漫剧和AI PPT，模型路由会进一步变成工作流路由。

User Goal
   ↓
Task Profiler
   ↓
Model Router
   ├── Gemini 3.6 Flash
   ├── Text Model
   ├── Vision Model
   ├── Video Model
   └── Audio Model
   ↓
Tool / Computer Use
   ↓
Verifier
   ↓
Final Deliverable

用户只描述目标。

系统自动选择最适合的模型、工具和执行方式。

12. 一个具体场景：用Gemini 3.6 Flash做“资料→分析→PPT”Agent

目标：
读取一批PDF和网页，
生成一份行业分析PPT

Step 1
File Search
→ 查找相关文件

Step 2
Gemini 3.6 Flash
→ 阅读文本、表格、图片

Step 3
Search Grounding
→ 补充外部信息

Step 4
Code Execution
→ 统计、计算、生成数据

Step 5
Structured Output
→ 输出PPT结构

Step 6
AI PPT
→ 生成完整演示文稿

Step 7
Verifier
→ 检查引用、数据和页数

这时候模型不再只是生成几段文字。

而是作为整个工作流的执行节点。