Gemini Interactions API 怎样保存多轮会话状态

Gemini Interactions API 的多轮状态可以交给服务端保存：取出上一轮完成响应的 id，下一轮把它放进 previous_interaction_id。应用仍要持久化“业务会话对应哪个最新 ID”，并在每轮重新传入需要的系统指令、工具和生成参数。保存 ID 不等于永久保存聊天记录，也不会自动解决多用户隔离和并发覆盖。

官方地址：https://ai.google.dev/gemini-api/docs/interactions-overview

用会话游标引用服务端历史

可以把这种模式称为“服务端历史＋应用游标”。服务端保存 Interaction 对象及相关上下文；业务系统保存一个会话游标，用来定位该业务会话最近一次完成的交互。新一轮只提交新的输入和前驱 ID，服务端据此查找历史，无须应用每轮重新拼接完整对话。

这里的“最近”指当前分支已经确认完成并被应用接受的记录。不要把正在生成的任务 ID 直接当作已完成回答，也不要把另一条业务会话的 ID 拼进当前对话。Interaction ID 是上下文引用，不是用户身份凭证。

确定适合保存的状态和使用压力

当业务是持续的文案协作、客服辅助或研究追问，应用希望进程重启后还能继续同一个分支时，保存游标很合适。比如“活动文案工作台”第一次要求围绕海边书店设计活动，第二次继续要求缩短文案，前驱 ID 就能表达这两轮的上下文关系。

如果业务要求独立掌握完整记录，仍需另存自己的业务消息。一个前驱 ID 无法替代审计日志、用户账号和完整的数据保留策略。

用 Python 保存并恢复最近的 Interaction ID

下面是单用户、单进程的本地教学例子。先安装官方 google-genai SDK；官方概览列出的 Python Interactions 支持起点为 2.3.0。设置环境变量 GEMINI_API_KEY，模型通过 GEMINI_MODEL 指定为当前项目可以使用且支持 Interactions 的模型，不把模型名称写死在业务状态中。

# 安装官方 SDK；密钥通过运行环境注入，不写进文件
python -m pip install --upgrade google-genai

将下面程序保存为 conversation.py。首次运行不带前驱；再次运行读取已保存 ID。输入示例是本次原创，程序没有在本文中实际调用收费接口，模型回答也不预先假定。

import json
import os
from pathlib import Path
from google import genai

STATE = Path("bookshop-session.json")
CONFIG = "你是活动文案助手。保持中文回答，不虚构活动日期和价格。"

def ask(message):
    # 本地文件只适合一个业务会话；线上必须按用户和会话分开
    previous = None
    if STATE.exists():
        saved = json.loads(STATE.read_text(encoding="utf-8"))
        previous = saved["last_interaction_id"]

    params = {
        "model": os.environ["GEMINI_MODEL"],
        "input": message,
        "store": True,
        "system_instruction": CONFIG,
    }
    if previous:
        params["previous_interaction_id"] = previous

    # 请求失败不更新游标；超时不代表服务端必然没有创建记录
    client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
    result = client.interactions.create(**params)
    if result.status != "completed" or not result.id:
        raise RuntimeError("本轮尚未正常完成，保留旧游标")

    # 临时文件替换减少半写文件；这不构成跨进程并发锁
    temporary = STATE.with_suffix(".tmp")
    temporary.write_text(
        json.dumps({"last_interaction_id": result.id}, ensure_ascii=False),
        encoding="utf-8",
    )
    temporary.replace(STATE)
    return result.output_text

if __name__ == "__main__":
    # 每次输入新问题；例如先问海边书店活动，再追问精简文案
    print(ask(input("本轮问题：")))

第一次可以输入“为海边书店设计一个周末阅读活动，只写活动主题和三项内容”，下一次输入“保留刚才主题，把三项内容缩短为每项十个字以内”。程序从文件恢复的应该是第一次成功完成后的 ID。观察是否保留主题是使用时的结果判断，不能把模型文字一致性当成持久化系统的唯一证明。

示例遇到网络异常或文件损坏会直接报错，不自动开始新会话掩盖问题。保存文件失败时应保留本轮已获得的响应 ID供业务恢复，避免误以为旧游标仍是唯一有效状态；正式系统应把响应记录与会话游标更新纳入同一业务事务。

排除配置继承与并发覆盖两个反例

第一个反例是第一轮传了 system_instruction，后续只传前驱。官方说明前驱保留的是输入输出历史，tools、system_instruction、generation_config 都只适用于当前 Interaction。示例把系统指令放在每轮参数里；有工具或生成配置时也应由应用每轮明确组装。

第二个反例是两个请求同时读取相同的旧 ID。它们都引用同一前驱，却分别生成新记录，形成两个分支；最后一次写数据库会掩盖另一个分支。文件替换只能减少半写，不会把这两个响应自动合并。

业务端可以为每个会话保存 revision，更新时要求旧版本号仍然匹配，成功后递增；冲突响应应保存为独立记录，交由用户选择分支或重新组织输入。若产品只允许线性对话，更直接的做法是让同一会话同一时刻只有一个在途请求。

处理保留期限和不确定失败的后果

官方文档说明默认 store=true。当前概览列出的保留期为付费层 55 天、免费层 1 天；付费项目还可配置较短的保留窗口，因此实际恢复能力要按项目设置决定。记录被删除或过期后，本地还保存着 ID 也不能保证继续使用。

设置 store=false 会阻止把该交互作为后续轮次的前驱使用，而且与后台执行不兼容。需要无状态模式时，应由应用在后续请求中提交完整且格式正确的会话历史，不能只发送最新一句话并期待服务端凭空记住。

超时属于“不确定结果”：不能仅因客户端没收到响应就认定服务端没有创建交互。不要在通用异常处理里无限重试或静默清空游标；记录业务请求状态，把重复提交和分支选择交给明确的恢复流程。服务端历史也不意味着可以无限增长而忽略模型上下文限制或成本。

用判断清单选择有状态或无状态

• 是否将游标绑定到经过授权的用户与业务会话，而不是使用全局 ID？
• 是否只在本轮完成后推进游标，并记录保存失败和不确定请求？
• 是否每轮重传系统指令、工具与生成配置？
• 是否为并发提交选择串行处理或版本冲突机制？
• 是否在项目保留期之外另有业务消息恢复方案？

重启应用为什么仍然失忆？先区分游标没有持久化、读错业务会话、前驱已过期与本轮配置遗漏。不要把所有问题都归为模型不记得。

能否换模型继续？需要后续模型支持历史输出对应的输入模态，尤其是包含图片、音频等内容的会话；保存了 ID 不会绕过模型能力限制。

ID 是否能当永久聊天备份？不能。它更适合当前服务端保留窗口内的上下文引用，长期备份应由业务系统按需求保存。

官方参数与保留规则：https://ai.google.dev/gemini-api/docs/interactions-overview；接口资源说明：https://ai.google.dev/api/interactions-api。