Gemini 3.5 Flash 强调长任务执行，应用架构会怎样变化

Gemini 3.5 Flash 把重点放在复杂、多步骤、持续时间更长的智能体任务上。对应用团队来说，真正的变化不是把模型 ID 换成 gemini-3.5-flash，而是把“一次请求拿到一次答案”改造成“一个任务可以暂停、恢复、限制权限并留下审计记录”的执行系统。

先分清长任务能力解决了什么

Google 在 Gemini 3.5 Flash 的官方说明中，把它定位为适合复杂多步骤智能体工作流和编码任务的稳定模型。开发者文档给出的稳定模型 ID 是 gemini-3.5-flash，支持 100 万 token 输入上下文与最多 65K 输出，并提供 minimal、low、medium、high 四档 thinking level。官方入口可查看 Gemini 3.5 新能力说明。

这些能力能让模型在一次任务里看到更多资料、保持更多推理线索并协调多个工具，但它们没有替应用保存订单状态、权限策略或外部系统的提交结果。进程重启、网络超时、重复回调和人工等待依然属于应用层问题。因此，长任务不能只写成一个更大的 Prompt，而应有独立的任务记录。

用一个最小任务记录承接持久状态

可以先做一个小项目：让模型分析一个代码仓库，依次生成风险清单、修改建议和验收摘要。无论模型执行多少步，数据库里始终只有一条权威任务记录。聊天历史是模型上下文，任务记录才是业务事实。

from dataclasses import dataclass, field
from typing import Any

@dataclass
class TaskRecord:
    task_id: str
    status: str = "queued"
    current_stage: str = "scan"
    policy_version: str = "v1"
    token_budget: int = 120_000
    deadline_at: str = ""
    checkpoint: dict[str, Any] = field(default_factory=dict)
    audit_log: list[str] = field(default_factory=list)

    def can_continue(self) -> bool:
        # 只有运行态任务才能继续，取消和完成状态都必须停止。
        return self.status in {"queued", "running", "waiting_approval"}

task_id 用于幂等，policy_version 固定本次任务采用的工具和权限规则，token_budget 与 deadline_at 防止任务无限运行，checkpoint 保存可恢复结果，audit_log 记录每次状态变化。业务字段越明确，越不需要从一长串对话里猜测任务到了哪一步。

Worker 每次只执行一个受限阶段

长任务最容易失控的地方，是把分析、写文件、调用外部接口和提交结果全部交给一次模型循环。更稳妥的最小写法是：Worker 读取任务记录，只执行当前阶段允许的工具，生成检查点后再推进状态。

ALLOWED_TOOLS = {
    "scan": {"read_repo", "search_symbols"},
    "plan": {"read_repo", "write_checkpoint"},
    "apply": {"read_repo", "write_patch"},
}

def run_one_stage(task: TaskRecord, requested_tool: str) -> None:
    # 阶段白名单把模型建议与真正可执行的能力分开。
    if requested_tool not in ALLOWED_TOOLS.get(task.current_stage, set()):
        raise PermissionError("当前阶段不允许调用该工具")

    # 幂等键用于抵御队列重复投递，不能只依赖自然语言提示。
    idempotency_key = f"{task.task_id}:{task.current_stage}"
    task.audit_log.append(f"start:{idempotency_key}")

    # 这里只表示持久化边界，真实项目应在事务中保存检查点和状态。
    task.checkpoint[task.current_stage] = {"idempotency_key": idempotency_key}
    task.status = "running"

读取仓库、搜索符号通常是低风险动作；写补丁、发消息、创建订单或发布内容则是外部副作用。后者不能因为模型“认为可以”就直接执行。把它们放进审批队列，并把批准人、批准时间、参数摘要写入审计记录，才能让长任务可追责。

恢复上下文时不要只保存最后一段文字

Gemini 3.5 文档说明，thinking 默认开启；对于无状态的多轮 GenerateContent 调用，应把完整且未经修改的历史以及 thought signature 一并传回，官方 SDK 会自动处理这部分细节。这意味着自建调度器不能随意删改历史消息，也不能只存最后一次模型输出。

一个实用的检查点至少包含三层：业务层保存 current_stage 和批准状态；模型层保存可继续调用的完整会话历史；工具层保存已经完成的幂等键和外部结果 ID。恢复时先读任务记录，再重建模型上下文，最后跳过已经提交成功的工具动作。这样即使 Worker 被重启，也不会再次发送同一封通知或重复创建同一条资源。

耗时操作用事件通知代替高频轮询

Google 已为 Gemini API 的长耗时任务提供 Webhook 机制，完成后向指定地址发送 POST 通知，适合 Deep Research、长视频生成和 Batch 等可能持续数分钟甚至更久的任务。官方介绍见 Event-driven webhooks。

应用侧可把回调接收器设计成很薄的一层：先按官方要求验证请求，再根据事件 ID 去重，只更新任务记录并投递内部事件，不在回调线程里继续跑完整智能体。若某种调用没有回调能力，再退回带指数退避和上限的轮询。无论采用哪种方式，超时都只代表“本次等待结束”，不能直接推断远端任务失败。

把审批、预算和审计放在模型之外

长任务可能连续调用多种工具，因此治理字段不能藏在 Prompt 中。下面这组字段可以形成最小控制面：

用四组场景完成验收

这个小项目不需要先追求全自动。能通过下面四组验收，才说明架构真正适合长任务：

1. 恢复：在 plan 阶段强制停止 Worker，重启后从同一检查点继续，不重新扫描已经确认的输入。
2. 重复投递：把同一队列消息发送两次，系统只执行一次外部工具动作，第二次只记录幂等命中。
3. 预算中止：把预算设为很小，任务应进入可解释的暂停状态，并保留已完成结果，而不是丢失整条会话。
4. 审批：写补丁或发送通知前进入 waiting_approval，未批准时不能越过边界，批准后才继续。

这四项比单纯观察“模型回答是否聪明”更重要。Gemini 3.5 Flash 提供了更适合长周期、多步骤工作的模型能力，但可恢复性、权限、事件处理和副作用安全仍然是应用架构的责任。

常见问题

100 万上下文能替代检查点数据库吗？

不能。上下文解决模型本轮能看到什么，检查点解决应用重启、重复投递、审批等待和外部结果追踪，两者不是同一层能力。

thinking level 应该固定为 high 吗？

不建议。官方提供多档 thinking level，简单分类和格式化任务可用较低档，复杂规划再提高。它不能与旧的 thinking_budget 同时设置，否则会返回 400 错误。

Webhook 是否意味着完全不用轮询？

只有支持回调的长耗时接口才适合直接使用 Webhook。其他调用仍可采用有上限的退避轮询，并统一写回同一套任务状态。

模型能否自动批准写文件或发布操作？

不应由模型自行扩大权限。高影响动作应由应用策略和明确授权决定，模型只提供建议或待审批参数。

参考：Gemini 3.5 Flash 官方发布说明、Gemini API 开发者文档与 Google 的事件驱动 Webhook 介绍。本文架构图均为原创静态说明图，不是产品截图或运行证据。