☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让Gemini API在连续提问中不忘记前几轮说了什么、确认过什么、用户偏好哪类格式，必须绕过“每次发请求就清空记忆”的默认行为，把上下文变成可携带、可验证、可裁剪的结构化数据。
用ChatSession自动管理对话历史
这是SDK层最省心的方式，适合本地脚本或单进程服务，无需手动拼接字符串。
第一步：初始化模型时明确指定支持聊天的版本，例如 【generative_models.GenerativeModel("gemini-1.5-flash-latest")】；用旧版模型（如gemini-pro）可能不兼容ChatSession内部消息序列协议。
第二步：调用 model.start_chat() 创建会话实例，该实例自带 messages 列表并自动维护 role 与 parts 的配对关系。
第三步：对同一 ChatSession 实例反复调用 send_message()，SDK会在每次调用前将历史消息注入请求体；注意不要在循环里反复调用 start_chat()，否则每轮都新建会话，历史直接归零。
手动拼接带角色标记的完整对话流
当你需要对接自定义后端、调试原始请求结构，或使用 curl / Postman 测试时，必须自己构造输入文本。
方法一：严格按“用户:”+“AI:”交替拼接，最新提问必须放在末尾。例如：“用户:帮我写个Python函数→AI:好的，这是函数代码→用户:改成支持异步”。漏掉任一轮、顺序错乱、或把最新问题插在中间，Gemini都会当成新对话处理。
方法二：用统一非字母数字分隔符（如 --- 或 === ）包裹每轮消息，再加角色前缀。例如：“---\n用户:昨天说的参数名是什么\n---\nAI:是batch_size\n---\n用户:改成learning_rate”。分隔符能显著降低模型误判段落边界的概率，尤其在中文长句混排时。
【关键前提：首条消息 role 必须为 user，且不能缺失】。如果第一行是“AI:您好”，Gemini会拒绝解析整个输入。
跨请求持久化会话状态
Web服务、HTTP API或长时间运行的任务中，ChatSession对象无法存活于两次请求之间，必须落地存储。
① 每次 send_message 后，立即调用 chat_session.history 获取当前 message 列表；
② 用 json.dumps() 序列化该列表，生成纯文本快照；
③ 以唯一 session_id 为 key，存入 Redis 或写入本地文件；
④ 下次请求到达时，反序列化该快照，传给 model.start_chat(history=loaded_history) —— 这一步必须显式传入 history 参数，否则 SDK 不会恢复旧记录。
这一步出错会导致所有历史丢失，且无报错提示；如果发现恢复后的会话仍从头开始，先检查 loaded_history 是否为空列表或格式错误。
动态压缩上下文防止超长截断
当对话超过20轮或含大段代码/日志时，原始历史必然超出token上限，硬拼会触发静默截断——Gemini不会报错，但会丢掉开头若干轮，导致指代失效、约束消失。
只保留三类内容：状态块（当前目标是否完成、下一步要做什么）、事实块（已确认的参数值、文件路径、用户明确说“不要这个”）、待确认块（“等你确认后再执行”“这个逻辑是否符合预期”）。其余寒暄、重复解释、试错过程全部舍弃。
压缩不是按轮次平均删减，而是按置信度过滤：用户主动重申的信息 > 模型推测的信息；带具体数值的描述 > 模糊形容词；出现在最近3轮内的实体 > 出现在第8轮的名词。
