Gemini Interactions API 多轮状态怎么接：previous_interaction_id 与 store=false 的边界

把旧的 Gemini 多轮调用迁到 Interactions API 时，最容易踩的坑不是请求格式，而是误以为“接上上一轮 ID，就会继承上一轮全部设置”。实际上，previous_interaction_id 主要复用已保存的对话历史；工具、系统指令和生成参数仍属于当前 Interaction，需要在新请求里重新声明。

Interaction 把一轮请求变成可引用资源

Google 把一次完整输入、工具调用结果和模型输出组织成一个 Interaction。调用 interactions.create 后得到 interaction.id，下一轮把它放进 previous_interaction_id，服务端就能取回之前的对话历史。这个模型对长对话很省事：客户端不必每次重传所有消息，状态链也有清晰的资源标识。

多轮状态只继承历史，不继承本轮配置

把 Interaction A 的 interaction.id 交给 Interaction B，只能说明“沿用对话历史”。tools、system_instruction、generation_config 都是本轮配置；缺少其中一项，第二轮行为就可能和第一轮不同。这里别急着把差异归因于模型漂移，先比对请求体。

{
  "model": "gemini-3.7-flash",
  "input": "继续整理上一轮结果",
  "previous_interaction_id": "",
  "tools": [{"function_declarations": []}],
  "system_instruction": "保持中文并给出依据",
  "generation_config": {"temperature": 0.2}
}

store=false 是隐私与能力的取舍开关

默认的 store=true 会保存 Interaction，因而可以继续使用 previous_interaction_id、background=true，并在 AI Studio Logs 中查看已存 Interaction。若改成 store=false，当前请求仍能完成，但后续不能再引用这一轮，也不能把它作为后台任务保存。

无存储模式下，客户端需要把完整历史连同当前请求一起发送。这样更容易把数据生命周期控制在自己的系统里，代价是请求体更大、会话拼接和审计都要自己负责。两种模式没有绝对优劣，关键看业务是否需要服务端续接，以及内部合规策略是否允许保存交互。

迁移时用三项指标做验收

第一项是历史连续性：第二轮能否准确引用第一轮给出的业务事实。第二项是配置一致性：记录每轮使用的工具清单、系统指令版本和温度，避免“历史接上了，能力却丢了”。第三项是缓存观察：官方文档说明状态式和无状态式请求都支持隐式缓存，可从响应用量里的 total_cached_tokens 判断是否命中；它只能证明前缀被复用，不能代替答案质量评估。

我更建议先给少量会话灰度迁移。若历史引用正确、工具调用未缺失、隐私策略也通过，再扩大流量；一旦关闭存储，就把完整历史拼装、大小限制和日志脱敏列入同一份上线清单。

常见问题

用了 previous_interaction_id，还要重复传 tools 吗？

要。它保留的是对话历史，不会自动继承工具、系统指令和生成配置。

store=false 还能享受隐式缓存吗？

可以。官方说明状态式和无状态式对话都支持隐式缓存，但无状态请求仍需自行提交完整历史，并通过 total_cached_tokens 核对命中情况。