消息历史由谁保存
Chat Completions 每次请求只看到本次发送的messages。复用同一个 SDK 客户端或 API Key,并不会自动把上一次的消息加入请求。
一个普通文本会话按顺序发送:用户问题、模型回复、下一条用户问题。不同用户和不同会话的历史要分开保存;同一会话并发提交时,应固定本次历史快照,避免回复顺序错乱。
两轮完整示例
先按 Python SDK安装依赖并设置三个环境变量,选择支持 Chat Completions 的普通文本模型。保存为conversation.py,运行 python conversation.py。示例会发起两次真实请求,第二次携带第一次返回的文本。
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
提示词缓存 · 推理模型 · 上下文管理