Gemini 3.6 Flash 支持多轮对话，但“支持”不等于模型自动记住所有内容。多轮效果的瓶颈通常在请求侧：调用方是否把用户上一轮提问、模型上一轮回复、以及必要的提示词，拼接成完整会话上下文再交给模型生成。若只发送最新一条用户消息，模型拿到的就是独立的单轮请求。

Gemini 3.6 Flash 的多轮对话能力取决于消息序列是否完整。建议按“系统指令 + 用户/模型交替消息”组织请求，并配合上下文压缩策略。接口字段和上下文上限需结合环境确认。验证多轮是否生效，可先输入一个独特代号，再在后续提问中要求模型复述该代号。主要风险是历史过长导致早期信息被裁剪。

先拆解多轮生效的条件

要让 Gemini 3.6 Flash 在多轮问答中表现正常，需要满足三个条件：消息顺序正确、历史覆盖到关键信息、提示词允许模型参考前文。消息顺序是硬条件；历史覆盖度是工程取舍；提示词是引导手段。

构建消息数组：多轮对话的骨架

大部分生成式接口会使用类似 messages 的数组，记录每个 turn 的角色和正文。下面的结构可以直接作为请求体骨架，字段名应与实际 SDK 对齐：

[
  {
    "role": "system",
    "content": "你是一名技术问答助手，回答应简洁且有示例。"
  },
  {
    "role": "user",
    "content": "什么是上下文窗口？"
  },
  {
    "role": "model",
    "content": "上下文窗口是模型一次能读取的 token 范围，包括历史消息和当前输入。"
  },
  {
    "role": "user",
    "content": "请用一句话总结刚才的定义。"
  }
]

发送这个数组时，模型应能根据第三条消息里的“刚才的定义”定位到上下文窗口。若模型答非所问，先检查 role 顺序，确认用户的下一轮提问紧跟在上一轮 model 回复之后。

控制上下文长度，防止早期内容被截断

多轮会话越深，累积的 token 越多。Gemini 3.6 Flash 同样有上下文窗口上限，接近上限时较早的消息可能被自动裁剪。建议采取三种策略：一是做摘要替换，把前几轮内容压缩成一句话放进 system 或第一条 user 消息；二是限制完整历史轮数，只保留最近 N 轮，更早的内容用“此前已讨论过”代替；三是主动去掉与当前主题无关的历史消息。这样能降低截断概率，但代价是细节可能丢失。

用提示词把模型注意力拉回历史

有时历史消息还在，但模型并没有优先读取。可以在最新一轮用户消息中明确要求它先复述或引用前文。例如：

请先复述你刚才对上下文窗口的定义，再回答它和 token 限制的关系。

这种“显式引用”会促使模型回到之前的消息里查找信息。适合用于多轮问答的调试阶段，不能完全替代长度控制。

验证多轮是否真的生效

简单的验证流程能快速暴露拼接问题：

1. 第一轮告诉模型“我的测试代号是 Alpha-2025，后续问题都会用到它”。
2. 第二轮问“我的测试代号是什么”。模型应回答 Alpha-2025。
3. 第三轮修改自己的输入，再问“如果你的回答与最早信息冲突，以哪个为准”。模型应能指出冲突。

若第三步模型没有反应，优先检查消息数组是否按顺序提交，或在请求前是否被外部逻辑清空。