第一轮能回复，第二轮先检查历史怎么组装

用 AIGoCode 的 Gemini 原生接口完成第一次请求后，接入工作的下一步往往是连续对话。这里容易忽略的区别是：聊天气泡里显示的文字，只是返回内容的一部分；下一轮需要回传的历史内容，不应直接由这些展示字符串重新拼出来。

本文围绕“保存完整历史，再组装下一轮请求”展开。依据是 Gemini API 官方文档，讨论直接调用 generateContent 的应用层实现建议，不把第三方聊天工具内部的历史管理方式当成相同接口，也不声称已做本次生产对话实测。

先核对原生接口的字段与角色

文档的端点是 POST https://api.aigocode.dev/v1beta/models/{model}:generateContent。模型 ID 位于路径中，消息列表位于请求体的 contents，认证使用 x-goog-api-key。应选择支持 Gemini 原生接口并包含目标模型的分组，不能把另一种协议的地址、认证和消息字段混在一起。

多轮对话中，用户消息使用 user，模型回复使用 model。内容块放在 parts 列表，文本位于其中的 text。如果应用内部统一把 AI 回复叫作 assistant，需要在生成原生请求时按这里的角色约定转换；内部界面名称不等于发送给接口的字段值。

若尚未跑通第一次请求，可先从 AIGoCode 官网进入快速开始，再回到本文处理连续对话。不要一开始就同时调试鉴权、模型选择和历史保存三条路径。

将展示文本与可回传内容分开保存

官方文档要求从 candidates[].content.parts[] 读取正文文本，同时要求多轮时将历史依次放进 contents。这两条要求服务于不同任务：前者是显示回答，后者是组织后续请求。

建议应用保留两份用途不同的数据：一份用于界面显示，只提取需要展示的文本；另一份用于历史回传，保留所选回复对应的完整内容。这里的“两份”是逻辑职责划分，不要求你复制存储所有网络响应，也不指定数据库或缓存方案。

如果只保存聊天气泡文字，下次再用它重新构造内容块，就需要额外检查是否丢失了原返回内容中的其他字段。优先在接收回复时保存可回传内容，再从中生成展示文本，通常比事后从界面反推历史更容易核对。

thoughtSignature 随对应内容原样保留

文档明确说明：返回内容中的 thoughtSignature 等字段，应随对应内容原样保留，再传回后续请求。它不应该被当作无用的界面元数据直接删除，也不适合从另一轮内容中搬过来凑齐字段。

建议在自己的历史序列化流程里检查两处：一是接收后有没有只保留 text、丢掉其余返回字段；二是再次读取已保存历史时，有没有经过一轮“只允许文字字段”的转换。对于实际返回的 thoughtSignature，按对应内容保留原值与归属，不自行生成、翻译或改写。

这里不推导该字段的内部机制，也不宣称缺失后一定返回某个错误码。当前文档支持的是保留与回传要求，不能据此承诺所有模型每次都会返回该字段，或该字段能替代完整历史。

下一轮请求按时间顺序组装

根据文档，多轮对话应将历史内容依次放进 contents。在应用代码中，可以把待发送内容的组织顺序列成三步：先放已有的用户与模型历史；再核对模型历史使用 model；最后追加本轮用户输入。

发送前逐项比较“接收时保存的内容”与“本次准备回传的内容”，尤其关注内容顺序、角色、parts 以及随对应内容返回的字段。为了排错而做的比较，应使用无敏感业务内容的材料，并避免输出真实 Key 或完整私密对话。

这份检查表不意味着服务端会替应用自动保存历史，也不承诺无限轮对话、无限上下文或零额外消耗。它只帮助你确认应用是否按文档组织了下一次请求。

用两轮小对话核对自己的处理链

可以在自己的测试环境安排一组不含敏感信息的材料：第一轮给出一个简短约定，第二轮要求按该约定继续处理。检查重点不只是模型有没有答对，还包括第一轮完整内容是否保存、模型历史角色是否正确，以及第二轮请求是否确实包含所需历史。这是验证方法建议，不是本文已经取得的实测结果。

如果界面保留了上一轮回答，而发出的 contents 没有这段历史，先修正请求组装；如果历史存在，但回传内容只剩文本，继续检查保存与读取之间的字段过滤；如果请求材料符合文档，再根据真实错误信息排查其他原因。不要仅凭“模型好像忘了”就认定是 Key、分组或平台故障。

把这条链路走通后，再扩展长对话、历史裁剪等应用策略。扩展策略需要额外设计，不能用本文的两轮核对代替对应模型能力、实际用量和产品约束的检查。