跳转到主要内容

消息历史由谁保存

Chat Completions 每次请求只看到本次发送的 messages。复用同一个 SDK 客户端或 API Key,并不会自动把上一次的消息加入请求。 一个普通文本会话按顺序发送:用户问题、模型回复、下一条用户问题。不同用户和不同会话的历史要分开保存;同一会话并发提交时,应固定本次历史快照,避免回复顺序错乱。

两轮完整示例

先按 Python SDK安装依赖并设置三个环境变量,选择支持 Chat Completions 的普通文本模型。保存为 conversation.py,运行 python conversation.py。示例会发起两次真实请求,第二次携带第一次返回的文本。
此例仅处理普通文本,并在拒答、截断或工具调用时停止。带工具调用的会话必须保留完整的 assistant 工具调用和对应工具结果;需要推理字段或其他协议扩展的模型,也应按其协议保存必要字段,不能只复制 content。参见工具调用。

控制上下文长度

发送前检查目标模型的上下文上限,为当前输入和回复留出空间。历史越长,每次请求携带的数据越多。可保留最近的完整轮次,并对更早的内容做业务允许的摘要;摘要可能丢失细节,不能代替必须精确保留的原文。 不要把工具调用与它的结果拆开裁剪,也不要为了缩短历史而移除应用必要的系统指令。收到上下文超限错误时,先调整历史,再重试;直接重发同一负载通常无法解决。

Responses 的会话状态

Responses 可以由调用方在 input 中显式携带必要上下文。使用 previous_response_id 则依赖渠道的响应保存、ID 可见性和路由行为,需要部署管理员确认;不要混用来自其他服务或其他渠道的响应 ID。 后续请求中的系统指令、工具定义等,应按所用模型和协议要求重新提供,不要把响应关联当作“所有配置自动继承”。详见 Responses 参考。

Python:Responses 显式维护历史

保存为 responses-conversation.py,按 Python SDK配置后运行 python responses-conversation.py。每轮重新发送 instructions 和完整历史,不使用 previous_response_id,不依赖服务端保存上一轮响应。 此例要求渠道支持 Responses 输入项重放、store: false 和 include: ["reasoning.encrypted_content"]。需要推理上下文的模型必须保留响应中的相关项目;如果渠道不支持这些字段或无法返回模型所需状态,请先确认兼容方案,不能仅删除推理项来绕过错误。store: false 不承诺网关或上游的日志保留策略。
每轮先验证完成状态、非空文本和拒答,再将整个 output 加入历史。测试覆盖推理项、加密内容及消息 phase 的保留;不只复制 output_text。任一轮失败就停止,不把失败响应加入下一轮。第一轮已打印的完整回复仍保留。 参考:OpenAI 会话状态说明。 Read in English 提示词缓存 · 推理模型 · 上下文管理