OpenAI Responses API 后台模式怎么用：轮询、取消与断线续传
长推理任务容易超过客户端或代理超时；Background mode 可让任务在连接断开后继续执行，但必须正确保存 response ID、判断终态并处理数据保留边界。
Responses API 的 Background mode 面向需要数分钟完成的长任务。请求设置 background: true 后，客户端可以保存 response ID，再通过查询接口轮询状态；这样即使原始 HTTP 连接断开，任务仍可继续执行。它解决的是连接可靠性，不会自动解决重复提交、结果入库或权限隔离。
接入前先记录哪些状态
- 业务任务 ID 与 OpenAI response ID 的唯一映射。
- 提交时间、模型、提示词版本和发起用户，但不记录完整 API Key。
- 最近一次状态、轮询次数、下次允许轮询时间和取消原因。
- 终态结果的哈希、入库时间以及是否已经向用户交付。
直接来源：OpenAI Background mode 官方指南。
状态机与终态判断
官方示例要求在状态为 queued 或 in_progress 时继续轮询；离开这两个状态后，任务已经进入终态。业务代码不能把“不是 in_progress”直接当成成功，应分别处理 completed、failed、cancelled 或 incomplete 等结果，并保存可读的失败原因。
取消正在执行的后台响应应调用取消端点。官方说明重复取消具有幂等性，会返回最终 Response 对象；但业务侧仍需防止多个工作人员或重试任务重复发送用户通知、重复退款或重复写入结果。
可靠的实现步骤
- 创建任务时先生成业务幂等键，再提交
background: true请求。 - 拿到 response ID 后立即持久化；如果没有保存成功，不向用户宣称任务已受理。
- 轮询使用退避与随机抖动，并设置总时长和最大次数，避免固定高频请求。
- 检测到终态后，以事务或唯一约束确保结果只入库一次，再更新用户可见状态。
- 用户取消时同时记录本地取消意图并调用上游取消；若任务已经完成，应按实际终态处理。
断线续传和数据保留边界
需要恢复流式事件时，创建请求必须同时设置 background: true 与 stream: true，并保存非 keepalive 事件的 sequence_number；断线后用 starting_after 从已确认游标继续。后台流的首 token 延迟可能高于普通同步流，因此短对话不应为了“异步”而全部切换。
即使设置 store: false，后台执行和轮询仍可能需要临时保存响应数据。涉及零数据保留或严格合规要求时，应按账号策略和官方最新说明单独评审，不能只看一个请求参数。
如何做故障验收
在测试环境提交一个可控长任务，分别模拟客户端断线、重复轮询、重复取消和结果入库进程重启。确认任务只产生一份业务结果，用户只收到一次终态通知，失败状态不会被误写成成功。若使用流式恢复，再主动断开连接并从最后一个已保存的 sequence_number 续传，检查事件不丢失也不重复处理。