OpenAI Responses API 上下文压缩怎么做：阈值、状态传递与验收
长对话接近上下文上限时，Compaction 可把早期状态压缩为不可读的加密条目；接入时必须区分服务端阈值压缩与独立 compact 端点，并按官方方式传递输出。
长对话和 Agent 任务不断累积消息、工具结果与失败分支，最终会挤占上下文。OpenAI Responses API 的 Compaction 会把早期状态压缩成更少 token 的加密条目，并把关键状态带到下一轮。这个条目是不可读的机器状态，不能当成用户摘要展示，也不能自行编辑后再传回。
先选择哪种压缩方式
- 服务端阈值压缩：在普通 Responses 请求里配置
context_management与compact_threshold，跨过阈值时自动触发，不需要单独调用 compact 端点。 - 独立 compact 端点：应用明确决定何时压缩，把完整上下文发送到
/responses/compact，再用返回内容继续下一次请求。 - 两种方式都要求压缩前的输入仍能放进模型上下文；不要等到请求已经超限才补救。
直接来源：OpenAI Compaction 官方指南。
状态应该怎样继续传递
使用无状态 input 数组串联时，应把响应输出连同 compaction item 一起追加到下一轮。出现最新 compaction item 后，可以丢弃它之前的旧项目以减少请求体和长尾延迟。若使用 previous_response_id 串联，只发送新的用户消息并继续传递 response ID，不要手工裁剪服务端状态。
独立 compact 端点返回的窗口可能同时包含加密 compaction item 和保留的近期项目。官方要求把返回输出视为下一轮的规范上下文，按原样传入，不能只摘取其中一个条目。
实施顺序
- 先记录当前典型会话的输入 token、工具结果大小、失败重试次数和质量基线。
- 选择低于模型硬上限、又能保留足够近期原文的压缩阈值，并为不同任务类型分别配置。
- 保存每次压缩发生的 response ID、输入 token、压缩后 token、模型和任务阶段，不记录完整敏感内容。
- 在压缩前后执行同一组后续问题，核对用户约束、未完成事项、工具状态和关键事实是否仍能正确延续。
- 上线后监控压缩频率、失败率、延迟和任务返工率；异常时回退到上一次可验证的上下文策略。
隐私与质量边界
服务端压缩在 Responses 请求设置 store: false 时可用于 ZDR 友好流程；独立 compact 端点是无状态且 ZDR 友好的。具体合规仍应结合账号、区域与数据类型评审。压缩不是无损算法：过早压缩可能弱化精确措辞、数字、用户偏好和工具结果，因此不能只看 token 降幅。
如何验收
准备包含长对话、工具调用、纠错和未完成任务的固定测试集，分别在压缩前后追问关键约束、数字和下一步动作。验收必须同时满足：请求未超限、输出结构可解析、关键事实正确、工具调用没有重复执行、用户禁止事项仍被遵守。再重放一次相同压缩输出，确认应用不会重复写入结果或重复触发外部动作。