Gemini API 多轮对话怎样保存历史消息

Gemini API 的多轮对话不会因为请求来自同一个 API Key 就自动记住上下文。要保存历史消息，先决定状态放在哪里：新项目可以保存 Interactions API 返回的 interaction_id，下一轮用 previous_interaction_id 续接；如果仍使用 generateContent，就必须由应用或 SDK 保存每轮的 user/model 内容，并在下一次请求中按顺序提交。

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

为什么只发最新问题会“失忆”

一次请求里的上下文只来自本次请求。把“继续刚才的方案”单独发送给模型时，模型看不到“刚才”对应的消息。历史保存还要按用户会话隔离：不能把所有访客消息放进同一个数组，也不能只保留模型回复而丢掉用户问题。

当前官方文档把 Interactions API 作为新项目的推荐方向；它可以由服务端管理多轮状态。generateContent 的多轮方式则是把完整会话放进 contents，或使用 SDK 的 chat 辅助对象。

新项目优先保存 interaction_id

服务端状态模式的关键不是把整段对话塞进自己的表，而是保存每个业务会话对应的最后一个交互标识。下面示例把第一次交互得到的 id 交给下一轮：

import os
from google import genai

def ask_twice():
    # API Key 从环境变量读取，避免把凭据写进源码。
    client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

    first = client.interactions.create(
        model="gemini-3.8-flash",
        input="我在设计一个两步审批流程，请先给出数据结构。",
    )
    # 生产环境应把 first.id 写入当前业务会话的记录。
    second = client.interactions.create(
        model="gemini-3.8-flash",
        input="沿用刚才的数据结构，再补充超时处理。",
        previous_interaction_id=first.id,
    )
    return first.id, second.output_text

真实应用通常维护 session_id -> last_interaction_id 映射。第二次调用成功后，再把新的交互 id 覆盖旧值；并发请求要按会话加锁或排队，避免两个请求同时以同一个旧 id 续接。

generateContent 怎样自己保存 history

如果项目仍使用 generateContent，可以用 SDK 的 chat 辅助对象收集历史，也可以自己保存消息。辅助对象适合单进程短会话；需要跨进程、重启恢复或审计时，建议把规范化消息写入数据库，再按顺序组装请求。

from google import genai
from google.genai import types

def ask_with_history(client, model, history, question):
    # history 中的 role 只使用 user 或 model，并保持原始顺序。
    contents = [
        types.Content(
            role=message["role"],
            parts=[types.Part.from_text(text=message["text"])],
        )
        for message in history
    ]
    # 当前问题必须作为最后一条 user 消息加入上下文。
    contents.append(
        types.Content(
            role="user",
            parts=[types.Part.from_text(text=question)],
        )
    )
    response = client.models.generate_content(model=model, contents=contents)
    return response.text

调用成功后，把 {"role":"user","text":question} 和 {"role":"model","text":response.text} 一起落库。下一轮读取同一 session_id 的消息，才能让模型看到完整上下文。

会话恢复时要控制哪些边界

• 隔离：查询历史时必须带业务会话或用户标识，不能用全局列表。
• 长度：历史越长，请求成本和上下文压力越高；达到应用阈值后保留最近几轮，并把更早内容压缩成摘要。
• 一致性：先写用户消息，拿到模型回复后再写模型消息；失败请求不要伪造一条模型回复。
• 恢复：服务端状态模式保存最后一个 interaction id；自管模式保存 role、text 和顺序，必要时额外保存模型名。

如果只是单进程演示，client.chats.create() 和 chat.get_history() 足够直观；如果是多实例服务，优先把会话状态放进可共享存储，并在请求边界做并发控制。

常见问题

只保存模型回复可以吗？不建议。模型回复依赖对应的用户问题，缺少 user 消息会让后续上下文不完整。

每次都提交全部 history 吗？使用 generateContent 时需要提交模型应看到的上下文；历史过长时应按业务规则截断或摘要，而不是无限追加。