企业官网建设流程全解析

用 Gemini 3.7 Flash 搭一个能干活的 Agent：从第一次调用到生产级架构

Google 在 2026 年 8 月 13 日发布了 Gemini 3.7 Flash，官方给它的定位是"面向编程和智能体的工作马模型"（workhorse model for coding and agents）。发布距上一代 3.6 Flash 只有三周，输入价格砍半到 $0.75/百万 token，模型 IDgemini-3.7-flash已经 GA。

版本号看着不起眼，但它是目前把"Agent 循环"这条路走得最完整的模型之一：可调的思考力度、服务端托管的多轮状态、原生工具调用、外加一个可以直接调用的托管 Agent。这篇文章只讲一条主线——怎么用 3.7 Flash 从零搭出一个 Agent，并把它带到生产环境。内容按六层递进，每一层都建立在前一层之上，代码全部来自官方文档，可以直接运行。

第一层：跑通第一次调用

环境准备只有两步：pip install google-genai（注意版本要1.55.0 以上，Interactions API 是从这个版本开始支持的），然后去 Google AI Studio 申请一个 API Key，放到环境变量GEMINI_API_KEY里。

fromgoogleimportgenai client=genai.Client()# 自动读取 GEMINI_API_KEYinteraction=client.interactions.create(model="gemini-3.7-flash",input="写一个 three.js 脚本，渲染一个写实的 3D 黑洞")print(interaction.output_text)

这里有个新的 API 形态值得注意：入口不是熟悉的generate_content，而是interactions.create。这是 Google 主推的 Interactions API，把"一次模型交互"做成服务端资源。它和generateContent的关系后面第六层会详细说，先记住两点：

• 返回对象上有便捷属性output_text、output_image、output_audio，直接拿最终结果；
• 对象内部还有一个steps时间线，记录了模型的思考、工具调用、中间结果，调试 Agent 时非常有用。

不依赖 SDK 的话，REST 也一样：

curl"https://generativelanguage.googleapis.com/v1beta/interactions"\-H"x-goog-api-key:$GEMINI_API_KEY"\-H'Content-Type: application/json'\-XPOST\-d'{ "model": "gemini-3.7-flash", "input": "写一个 three.js 脚本，渲染一个写实的 3D 黑洞" }'

跑通这一步，你已经有了一个 1M token 上下文、最大 64K 输出的模型。下面开始把它变成 Agent。

第二层：thinking_level——这个模型唯一的"旋钮"

用过老版 Gemini API 的人第一件事可能是调temperature。在 3.x 系列上这条路走不通了：temperature、top_p、top_k、candidate_count这些采样参数全部移除，传了直接报错。取而代之的是一个语义更直白的参数——thinking_level，三档：

interaction=client.interactions.create(model="gemini-3.7-flash",input="分析这段支付重试逻辑中的竞态条件，并安全地重写事务锁",generation_config={"thinking_level":"high"# 攻坚任务拉满})

为什么砍掉采样参数？因为推理模型的输出质量主要不靠采样分布控制，而靠"花多少算力思考"。与其让开发者对着 temperature 玄学调参，不如给一个含义明确的旋钮。这个设计带来的实际好处是：一个模型通过分档就能覆盖过去"小模型走量 + 大模型攻坚"的组合，路由逻辑写在代码里就行，第六层会用到这一点。

第三层：多轮对话，别再自己拼历史了

搭 Agent 绕不开多轮。传统做法是把历史消息在客户端拼成一个越滚越大的 messages 数组，每轮请求都全量重发。Interactions API 提供了另一种方式：对话状态存在服务端，客户端只传一个 ID。

# 第一轮first=client.interactions.create(model="gemini-3.7-flash",input="我的项目是个 Spring Boot 2.7 的单体应用，最近启动要 3 分钟")# 第二轮：只传 ID，不用重发任何历史second=client.interactions.create(model="gemini-3.7-flash",input="先从日志分析入手，给我具体的排查命令",previous_interaction_id=first.id)

两种模式的对比：

这里有三个官方文档里写了、但很容易踩的细节：

1.previous_interaction_id只继承对话历史，其它参数每轮要重传。tools、system_instruction、generation_config都是 interaction 级的，不在历史里。也就是说你在第一轮配好了工具和系统指令，第二轮忘了传，模型会"失忆"——不是忘了对话，而是忘了自己有什么工具、是什么角色。这是用服务端状态最容易踩的坑。

2. 留存期有边界。服务端默认存储所有 Interaction（store=true）：付费层保留 55 天，免费层只有 1 天。超过保留期的 ID 无法续接对话。如果你的 Agent 会话可能跨越很长时间，要么自己做 checkpoint，要么把关键上下文显式写进新请求。

3.store=false与两个功能互斥。出于合规不想让 Google 存数据时可以设store=false，但这样就不能再用previous_interaction_id（服务端没历史可取），也不能用background=true后台执行。鱼和熊掌要选好。

第四层：接上工具，让它真正干活

前三层还是"聊天"。Agent 的分界线是工具调用：模型决定调用什么函数，你的代码执行它，把结果喂回去，模型继续思考，直到给出最终答案。这个循环跑起来，模型才变成 Agent。

流程是这样的：

官方对 DeepSWE v1.1 基准的说明可以直接映射到这张图上：3.6 Flash 在真实开源仓库里自主修 issue 的成功率是 49.0%，3.7 Flash 提到 65.3%。这个基准考察的正是上图循环的完整能力——读代码、定位、改代码、跑测试、根据报错再来一轮。提升最大的部分官方归因于 “reducing failed agent loops”，即循环卡死的次数变少了。做过 Agent 的人都知道，卡死循环（反复调同一个工具、在两步之间横跳、提前放弃）才是最痛的问题，比单轮智力不足痛得多。

写工具调用时，官方文档的几条硬性规范：

• 函数执行结果回传时，FunctionResponse里必须带call_id和name（generateContent路径下强制）。call_id来自模型发的function_call，用来把结果和调用配对，缺了会直接报错；
• 多模态资源（比如函数返回的图片）要放在 response payload 内部，不要外挂；
• 内联指令之间用\n\n分隔；
• 遇到Malformed_Function_Call报错，先检查工具调用前是否有多余文本，官方有专门的 pre-tool text 要求和对应 workaround。

另外一个很多人关心的能力现状：Gemini 3 目前还不支持远程 MCP（官方文档明确写了 coming soon）。想接 MCP 工具的，现阶段只能把 MCP server 的能力包一层本地函数再做工具声明。

第五层：把整个循环外包——Antigravity 托管 Agent

第四层的循环是自己搭的。3.7 Flash 同时支持另一条路：循环本身也交给 Google。调用时不传model，改传agent，任务会在远端环境里自主执行——这正是发布当天官方把 Antigravity Agent 默认模型切到 3.7 Flash 的原因。

interaction=client.interactions.create(agent="antigravity-preview-05-2026",input=("审计 https://web.dev 的性能、Core Web Vitals 和 SEO。""分别用 Mobile 和 Desktop 两种策略查询 PageSpeed Insights API，""用 Google 搜索检查 site:web.dev 的收录情况，""输出一张并排的评分表，按优先级列出修复建议。"),environment="remote",)

这段代码执行时发生的事：

自建循环（第四层）和托管 Agent（第五层）怎么选：

还有一条官方文档里比较冷门但很实用的玩法：Agent 和模型可以在同一个对话里混用。比如先用 Deep Research Agent（同样通过agent参数调用）做一轮资料收集，拿到interaction.id后，用previous_interaction_id接一个普通的gemini-3.7-flash调用做总结和重排版。重活脏活给 Agent，精细排版给模型，中间只需要传一个 ID。

第六层：上生产前的三件事

6.1 先算清 token 账

Agent 的成本结构和聊天完全不同。每轮循环都要把上下文重新喂一遍，输入 token 是绝对大头。以一个中等复杂度的编码任务为例（典型消耗约 50 万输入 + 5 万输出 token）：

两个直接影响架构的结论：第一，介绍价 12 月 31 日到期后翻倍（$1.50/$7.50），做预算必须按 2027 年原价算，现在的半价当红利看；第二，既然输入是大头，凡是能降输入的手段收益都大——第三层说的previous_interaction_id命中隐式缓存就是官方明确建议的降本手段。

6.2 分层路由：把三档思考力度当三个模型用

结合第二层的thinking_level和价格，一个可直接落地的生产架构：

路由规则不用复杂，任务类型加一个失败重试计数就够。关键是把"失败或超时自动升档"做进去——3.7 Flash 在 low 档解决不了的问题，先升 medium，再不行才动用贵的旗舰模型。这样大部分流量被 $0.75 的价格承接，贵的模型只花在刀刃上。

6.3 稳定性：Interactions API 还是 beta

官方文档目前的原话是：Interactions API 处于 beta，schema 可能发生破坏性变更，生产工作负载建议继续使用标准的generateContentAPI。所以现实的做法是：

• 新项目、内部工具、快速验证：直接上 Interactions API，开发体验好得多；
• 对外生产服务：模型用gemini-3.7-flash，接口走generateContent（模型本身是 GA 的，只是 API 形态的选择）；等 Interactions API 转正再迁移；
• 两条路线的差异点记住几个就够：Interactions 暂不支持 Batch API、显式缓存（隐式缓存有）、Python 的自动函数调用和 video_metadata；迁移时采参数清理见下面清单。

从旧模型迁移的清理清单（官方迁移指南的浓缩版，按顺序过一遍）：

• 全仓库搜索temperature/top_p/top_k/candidate_count，删干净，传了就报错；
• thinking_budget（数字）替换为thinking_level（字符串枚举）；
• 多轮对话统一改用previous_interaction_id，删掉预填充模型回复的写法；
• generateContent路径下检查每个FunctionResponse都带call_id和name；
• Python SDK 升到 1.55.0+，JS SDK 升到 1.33.0+；
• 成本模型按 2027 年价格重算。

写在最后

把六层串起来回看：第一次调用（跑通）→ thinking_level（调速）→ 服务端状态（管历史）→ 工具循环（变 Agent）→ 托管 Agent（外包循环）→ 分层路由与成本（进生产）。3.7 Flash 这个模型的价值不在单项参数，而在于这条链路上每一环都有官方一等公民的支持，且价格低到可以放心让它在循环里反复跑。

介绍价到年底，试错成本正处于最低点。如果你手头有一个一直想自动化的多步骤任务，现在是用真实负载验证这条链路的好时机——官方基准（DeepSWE 65.3%、AutomationBench 30.4%）终究是别人的数字，自己的任务跑一遍才有发言权。

参考（均为官方一手来源）

• Introducing Gemini 3.7 Flash — Google 官方发布，2026-08-13
• What’s new in Gemini 3.7 Flash — Gemini API 官方文档，2026-08-26 更新
• Interactions API 总览 — 官方文档
• Gemini 3.7 Flash 模型卡 — Google DeepMind
• DeepSWE v1.1 榜单 — Datacurve
• AutomationBench — Zapier 官方博客
• Google Antigravity