OpenAI Agents API 找回会话 ≠ 业务成功：跨境卖家用 Codex 管店须自建审计与外部校验
Responses API 的 previous_response_id 能让 Agent 跨调用续上上下文，看起来像“记得住事”。但会话能找回，只说明这轮对话没断，不说明它替你改的价格、发的货、回的消息是对的。跨境卖家把管店交给 Agent，缺的是审计和外部校验这两条腿。
会话状态是能找回来的，但保质期只有 30 天
按 OpenAI 官方文档（Conversation state 一页）的说明，Response 对象默认保存 30 天，可在 dashboard 日志页查看或通过 API 取回；创建 Response 时把 store 设为 false 可以关闭这一行为。文档同时写明：Conversation 对象及其中的 item 不受 30 天 TTL 约束，任何附着到 conversation 上的 response，其 item 会随之持久保存。
链式续接的机制是 previous_response_id：新建 response 时传入上一轮的 id，服务端会自动加载那段状态、拼到新输入前面，你不需要手工维护消息数组。文档也提醒了一个容易被忽略的成本细节：即使用了 previous_response_id，链上所有先前的输入 token 仍会按输入 token 计费。
社区讨论里还暴露了一个更现实的坑。有开发者在官方论坛指出，文档写“默认保存 30 天”，但实际并未按预期清理，且当时缺少列出、查询和删除这些记录的 API 入口；也有人提醒，服务端会话如果遇到组织被封、余额为负等情况，访问权可能直接消失。这些是用户侧反馈，不是官方承诺，但足以说明一件事：把业务连续性押在平台的会话存储上，风险敞口不小。
用 store=false 链式续接，会直接报错
如果你为了数据合规选择 store=false，链式续接就会撞墙。据公开的技术资料整理，previous_response_id 依赖 store 为 true（即默认值）；一旦 store=false 还去传 previous_response_id，服务端因为找不到上一条 response 会直接报错。要在无状态模式下保留推理链，需要显式用 include: ["reasoning.encrypted_content"] 传递加密推理内容。
这条路还有两个约束。第一，推理 item 必须随轮次携带。在带工具调用的多轮流程里，丢掉 input 里的 reasoning item 会造成可测量的准确率下降——公开资料引用的 cookbook 口径约为 3%，在难度较高的编码类任务上更大。第二，加密内容与模型快照绑定：reasoning.encrypted_content 只在生成它的那个确切模型快照下有效，从中途换模型会让这段内容失效，且报错信息很不友好（只提示 invalid encrypted content）。跨链跑任务时，把模型 ID 钉住是硬要求。
另外，后台模式（background: true）与零数据留存（ZDR）的兼容性此前有过修正：ZDR 项目下后台请求以 store=false 运行，但数据仍会在磁盘上停留约 10 分钟以便轮询，之后删除——除非显式传了 store: true。这 10 分钟的残留留存，是需要和合规负责人确认的点，而不是一个可以直接忽略的细节。
官方数据控制表里，哪些端点不留状态
OpenAI 的《Data controls in the OpenAI platform》给了逐端点的对照表，这张表值得逐行看。Responses API（/v1/responses）默认 30 天应用状态留存，或当 store 设为 true 时启用；启用 ZDR 的组织，store 参数会被强制视为 false，即使请求里写了 true。Conversations 与 conversations/items 的应用状态留存是“直到删除”。
文档同时给出几个容易踩的边界：后台模式为支持轮询会把响应数据写盘约 10 分钟；音频输出为支持多轮会保留约 1 小时；托管 Shell 和 Code Interpreter 使用的托管容器在存活期间可能把临时状态写到容器文件系统，容器过期或被删除时清除；远程 MCP server 属第三方服务，发过去的数据受对方留存政策约束。还有一条容易被忽略：开启服务端 compaction 后，store="false" 时不保留任何数据。
把这些拼起来看，结论很清楚——会话可恢复，不等于数据可控，更不等于业务结果可验证。
管店场景：审计与外部校验要自己建
把 Agent 用在跨境店铺上，典型任务是改价格、调库存、处理客服话术、生成广告文案。这些动作的共性是有外部后果，而且大多不可回滚——价格改错会直接产生真实订单。会话层能证明“这轮对话还在”，证明不了“这个价格改动是经过授权的”。
真正需要落地的有三层。第一层是审计日志，记录每次工具调用了什么、查询了哪些数据、做出了什么判断、写入的参数是什么。这一层不能依赖平台日志的 30 天窗口，要落到自己的库里，字段至少包含时间、会话链 id、动作类型、参数快照、执行结果。第二层是外部校验，把 Agent 的输出拿到系统之外对一遍——改价前后拉一次店铺真实价格快照做差异比对，文案发出前过一遍平台规则校验，涉及金额的操作走一次独立的一致性检查。第三层是权限与白名单，把 Agent 能触达的接口收窄到必要范围，网络访问按组织级和请求级两层白名单收紧，凭证不要以明文暴露给模型。
还有一点关于模型选择：管店这类任务，模型的可复现性和行为稳定性比聪明程度更重要。可考虑把模型 ID 钉死在链路上，避免中途切换导致加密推理内容失效，也避免同一任务在不同快照下给出不一致的动作。
注意事项
第一，别把平台的 30 天留存当成你的审计能力。30 天之后 response 消失，任何依赖该 id 的客户端都会拿到 404。审计数据必须落到自己的存储里，这是合规与追责的最低要求。
第二，明确区分“无状态续接”和“有状态续接”两套架构。如果业务涉及敏感数据需要 ZDR，就必须按 store=false 加 reasoning.encrypted_content 的方式设计链路，并接受模型 ID 不能中途更换的限制。这两条要写进技术方案，不能靠运行时摸索。
第三，给 Agent 的动作装上一道闸。涉及价格、库存、资金、对外消息的操作，默认走人工确认或走独立系统的二次校验，不要让会话的连续性替你背业务正确性的锅。会话能找回，只说明它还记得；对不对，得另外一套系统说了算。
FAQ
Q：用 previous_response_id 续接会话，是不是就等于业务行为可追溯了？
A：不是。它只保证模型侧还能读到上一轮上下文。response 默认保存 30 天，到期后依赖该 id 的调用会失败；而且它记录的是对话与推理过程，不构成对外的业务审计凭证。涉及价格、库存等实际动作的追溯，需要自建日志。
Q：我们启用了零数据留存，还能用会话续接功能吗？
A：可以，但方式不同。ZDR 组织下 store 参数会被强制视为 false，此时不能靠 previous_response_id 传递状态，需要改用 include: ["reasoning.encrypted_content"] 显式携带加密推理内容。同时要注意该加密内容与生成它的模型快照绑定，链路中途不要更换模型。
Q：会话状态到底存多久？
A：按官方文档，Response 对象默认保存 30 天，可通过 store 设为 false 关闭保存；Conversation 对象及其 item 不受 30 天 TTL 限制，附着其上的 response 的 item 会随之持久保存。此外，后台模式为支持轮询会额外写盘约 10 分钟，音频输出保留约 1 小时。具体政策以 OpenAI 官方数据控制文档为准。
参考来源
- OpenAI Developers 文档：《Conversation state》（Responses API 会话状态与 30 天留存说明）
- OpenAI 平台文档：《Data controls in the OpenAI platform》（逐端点数据留存对照表）
- OpenAI 开发者社区：《Data retention for model response - need clarification》
- OpenAI Developers 博客：《Shell + Skills + Compaction: Tips for Long-Running Agents》
- Hivebook：《OpenAI Responses API — Stateful Conversations》（previous_response_id 与 store 参数相关注意事项整理）