第一轮能回答，第二轮却忘了刚才说过什么

你准备把一个纯文本对话模块从 Chat Completions 换到 Anthropic Messages，或者让应用分别支持两种格式。先保留一段最小的两轮对话，检查历史消息如何进入下一次请求，再处理更多内容类型。

AIGoCode 两份协议文档都要求按顺序传入历史消息和本轮输入。它们都使用 messages，但这不能证明整份请求体和响应可以直接互换。本文只处理纯文本历史的组织；首次替换问候语可先看业务输入改写指南，系统指令的跨协议迁移应另外核对。

用三条消息确定第二轮请求应该包含什么

下面是一段应用测试数据，不是模型的实际返回，也不保证真实模型会按示例回答：第一轮用户说“项目代号暂定蓝桥”，模型示例回复“已记下项目代号”；第二轮用户问“刚才的项目代号是什么”。

对这段纯文本历史，两种接口的第二轮消息列表都应按真实对话顺序组织为：

真正集成时，第2条应来自自己的实际响应，不能把上面的示例回复写死。发送前可以用无敏感内容的本地样本核对这三条记录的顺序，避免只发送最后一个问题，或把助手回复误标成用户消息。

这是应用组装历史的建议，不是 AIGoCode 自动替你保存会话的承诺。本文也不根据接口返回的 ID 推断可以省略历史或调用另一种会话续接机制。

先按各自响应结构取出纯文本，再保存历史

Chat Completions 普通文本回复读取 choices[0].message.content；Anthropic 则遍历 content，读取 type 为 text 的文本块。不要把 Chat 的整份 choices 对象当成一条 Anthropic 消息的 content，也不要在 Anthropic 返回后继续沿 choices[0] 查文字。

对于本文限定的纯文本分支，可以在自己的程序里先保存角色和文本，再由各接口的构造逻辑生成消息列表。保存模型回复前，确认读到的是本轮响应的真实文本，而非界面里额外添加的“回答完成”等提示语。

如果响应含工具调用或其他内容块，就已经超出这个最小文本分支。Anthropic 文档明确其他内容块按各自 type 处理；Chat 文档要求工具调用按 tool_calls 处理。不要把所有非文本内容直接丢掉，再称为完整历史迁移。应为这些类型另建保留与回传逻辑，并根据已核实的协议资料验证。

同名 messages 之外还有必须重新核对的字段

Chat 文档把系统提示放在模型支持的 system 或 developer 消息中；Anthropic 的 system 位于请求体顶层。迁移时先把业务对话历史与系统指令分开，不能将原来的系统消息原封不动混入只接受 user、assistant 的示例列表。

Anthropic 页面另列 max_tokens 为建议填写的最大输出 Token 数。应按目标任务核对该参数，而不是因为两边都叫 messages 就只换 URL。不要把文档示例的数值当作模型能力上限或账户额度。

直接调用的配置也要逐项匹配：Chat 使用 /v1/chat/completions 与 Bearer 认证；Anthropic 使用 /v1/messages 与 x-api-key。选择包含目标模型且支持外接调用的分组，不能把历史结构整理正确当成认证与模型也已验收。

用两个检查分开验收历史组装和实际回答

先在本地检查请求数据：第二轮的三条文本消息是否齐全、顺序是否正确、角色是否匹配，系统指令是否进入目标协议正确的位置。这个检查不需要为了凑样本额外发起模型请求，也不能证明接口已可用。

再在确实需要的正常调用中检查实际结果：记录所用协议和模型，确认第二轮是否能依据已传入的信息回答。若回答偏离，先查看实际发送的历史，而不是立刻下结论“模型没有记忆”。只发送最后一句、抓错响应字段、保存了界面占位语，都是可由应用记录核对的现象。

排错记录只保留必要且脱敏的样本；不要分享 Key、认证头或不适合外发的完整业务对话。本文没有执行真实模型请求，不把这份本地检查方案写成已通过的服务验收。

当这个两轮纯文本分支稳定后，再逐项扩展流式、工具调用或多模态内容。每次扩展都保留原始结构的核对点，避免“能显示一段文字”掩盖历史在下一轮已经丢失。