OpenAI Responses API 怎样在 store=false 时保留加密推理上下文

把 Responses API 设置为 store=false 后，很多人会误以为模型只能处理一次请求。实际边界是：服务端不替调用方保存 response，但调用方仍可保留返回的完整 output item，在下一次请求中原样回放，其中就包括 reasoning item 里的 encrypted_content。这样可以在无状态或 Zero Data Retention 场景下延续可用的推理上下文。

官方资料：https://developers.openai.com/api/docs/guides/reasoning

这里的“保留”不是读取或解密模型的原始推理文本，而是保存 API 返回的 opaque item。文章只讨论这条保存与回放链路，不展开工具调用事件分类、结构化输出或普通多轮状态设计。

store=false 为什么仍能保留推理上下文

先把两个概念分开：store=false 控制服务端是否保存这次 response；上下文连续性则取决于下一次请求有没有拿到上一轮需要的输入项。无状态模式下，响应的 output 数组仍可能包含类型为 reasoning 的项目，项目里带有用于后续请求的 encrypted_content。

这个字段应当被当作不透明数据处理。应用可以将完整 item 序列化后放入自己的短期上下文仓库，或跟随业务会话加密保存；不应把它当作可展示的思维过程，也不应自行修改其中的字符串。

先保留完整 output，而不是只抄 encrypted_content

最稳妥的做法是保留 SDK 返回的完整 output item，再用 SDK 提供的转换方法把它们放回下一次 Responses 输入。只拷贝一个字段容易丢掉 item 的类型、标识或其它上下文信息，也会让后续请求的形状和服务端返回形状不一致。

import OpenAI from "openai";
import { toResponseInputItems } from "openai/lib/responses/ResponseInputItems";

const client = new OpenAI();

const history = [
  {
    role: "user",
    content: "请把这段技术需求拆成三个可执行的实现约束。",
  },
];

const first = await client.responses.create({
  // store=false 让调用方负责保存后续需要的响应项。
  model: "gpt-6.1-sol",
  store: false,
  input: history,
  reasoning: { context: "current_turn" },
});

// 原样转换完整 output，保留 reasoning item 及其 encrypted_content。
history.push(...toResponseInputItems(first.output));
history.push({
  role: "user",
  content: "现在根据这些约束给出接口字段草案。",
});

const second = await client.responses.create({
  // all_turns 允许兼容模型使用历史 reasoning 上下文。
  model: "gpt-6.1-sol",
  store: false,
  input: history,
  reasoning: { context: "all_turns" },
});

console.log(second.output_text);

示例里的模型名只表示一个支持该能力的 reasoning 模型占位，项目应替换为自己账号可用且属于兼容模型家族的模型。关键不在于手写 encrypted_content，而在于把 first.output 转成可回放输入，再追加新的用户消息。

把历史项回放到下一次请求

回放时保持顺序很重要：先放入上一轮响应产生的输入项，再追加新的用户消息。第一轮可以使用 current_turn；当下一轮需要让模型使用更早的可用 reasoning 上下文时，再显式设置 reasoning.context 为 all_turns。

如果业务要把历史写入数据库，建议把整个响应项作为受控 JSON 保存，并对会话标识、访问权限和生命周期做隔离。不要只保存一段看起来像随机字符串的字段，更不要在日志中打印完整加密内容。

三个容易混淆的边界

• 无状态不等于无上下文。它意味着服务端不替你保存 response，调用方仍要保存下一轮所需的输入项。
• 加密字段不等于可读推理。encrypted_content 是供模型继续使用的 opaque 数据，不应展示给用户或尝试自行解密。
• 上下文有模型兼容范围。持久化 reasoning 只能在兼容的模型家族之间复用；切换到不兼容的模型时，不能假设旧 reasoning 一定会被继续使用。

另外，store=false 只解决服务端 response 存储边界，不会自动替应用清理自己的数据库、缓存或日志。真正需要零数据保留时，还要把调用方保存链路纳入同一套生命周期策略。

常见问题

需要手动把 encrypted_content 放进 include 吗？

当前 Responses 文档说明，reasoning item 默认会带 encrypted content；兼容场景仍可看到 reasoning.encrypted_content 这个 include 名称。写回放代码时优先保留完整 output item，不要围绕单个字段做脆弱拼装。

为什么不能把 reasoning.summary 当成完整上下文？

summary 是给调用方看的摘要信息，不等同于模型继续生成所需的加密 reasoning item。需要保持上下文连续性时，应回放 API 返回的完整 output item。

store=false 下能否使用 previous_response_id？

本文不把它作为无状态保存方案。若目标是由调用方掌控数据生命周期，就按完整 output item 回放的方式组织请求，并明确自己的保存与清理边界。

小结

Responses API 的无状态模式把责任从服务端转给调用方：设置 store=false，保留完整 output，把其中的 reasoning item 原样转换并回放，再追加新的用户消息。只要把 encrypted_content 当作不透明上下文、遵守模型兼容范围，并同步治理自有存储，就能在零数据保留约束下维持需要的推理连续性。