OpenAI Responses API 写作结果怎么保存和复用响应记录

准备

先明确两层记录：第一层是 Responses API 返回的响应对象，第二层是你自己的内容任务归档。资料中的 SDK 定义显示，创建响应时可以传入 store，其含义是是否保存生成的模型响应，以便之后通过 API 获取；响应对象可以通过 response_id 重新检索。这个服务端记录不能代替你的业务数据库，因为任务标题、操作者、发布状态和审核结论仍需要由应用自行维护。

• 准备 OpenAI Python SDK、API 密钥和一个可写入的数据库表或 JSON 存储。
• 为每次生成建立唯一的业务任务 ID，例如 writing_task_20260827_001。
• 决定是否保存完整原始响应。若响应可能包含敏感资料，先按团队的数据保留规则脱敏或限制访问。
• 将生成状态与发布状态分开，例如 completed 只表示模型响应完成，不表示文章已经审核或发布。

分步操作

第 1 步：创建响应时明确设置 store

不要依赖调用方对默认行为的猜测。需要后续通过响应 ID 获取内容时，显式传入 store=True，并立即读取返回对象的 ID。下面示例使用非流式调用，便于先建立最小可追溯流程。

from openai import OpenAI

client = OpenAI()

task_id = "writing_task_20260827_001"
response = client.responses.create(
    model="gpt-4.1",
    instructions="你是内容编辑，只根据输入资料写作，不补充未提供的事实。",
    input="请把以下产品资料整理成一篇面向新手的使用说明：\n产品名称：示例工具\n功能：文本整理",
    store=True,
    metadata={"task_id": task_id, "flow": "article_draft"}
)

response_id = response.id
print({"task_id": task_id, "response_id": response_id})

资料确认了 metadata 可附加到响应对象，并且最多可设置 16 组键值对，键和值都有长度限制。建议只放短的业务标识，不要把整篇提示词或敏感原文塞进元数据。

第 2 步：在自己的系统保存任务快照

服务端响应 ID 只解决“如何找到这次响应”，不能完整表达一次内容任务的业务上下文。至少保存下面这些字段：

• task_id：业务任务 ID。
• response_id：Responses API 返回的响应 ID。
• model：实际请求使用的模型标识。
• instructions 与 input：本次请求使用的规则和任务材料。
• request_options：如 store、max_output_tokens、temperature 等实际参数。
• response_json：原始响应快照，按权限和保留策略保存。
• output_text：提取出的可编辑正文。
• generation_status、review_status、publish_status：三个互相独立的状态。

record = {
    "task_id": task_id,
    "response_id": response.id,
    "model": "gpt-4.1",
    "store": True,
    "instructions": "你是内容编辑，只根据输入资料写作，不补充未提供的事实。",
    "input": "请把以下产品资料整理成一篇面向新手的使用说明：产品名称：示例工具；功能：文本整理",
    "response_json": response.model_dump(),
    "output_text": response.output_text,
    "generation_status": "completed",
    "review_status": "pending",
    "publish_status": "draft"
}

# 替换为你的数据库写入函数
save_writing_record(record)

写入数据库时，建议对 task_id 和 response_id 建立索引，并把每次改稿作为新版本记录，而不是覆盖原始响应。这样审核人员可以区分“模型原始结果”和“编辑后的发布稿”。

第 3 步：用 response_id 重新取得响应

当编辑再次打开任务，或者异步任务完成后需要补拉结果，可以调用 retrieve。资料中的 SDK 将该方法映射到按响应 ID 获取响应的接口，并要求传入非空的 response_id。

saved = load_writing_record(task_id)
response_id = saved["response_id"]

latest_response = client.responses.retrieve(response_id)

updated = {
    "task_id": task_id,
    "response_id": response_id,
    "response_json": latest_response.model_dump(),
    "output_text": latest_response.output_text,
    "generation_status": "completed"
}
update_writing_record(updated)

重新取得后仍要检查返回内容是否存在、正文是否完整，以及本地记录是否需要更新。不要把“retrieve 调用成功”直接当成“文章可以发布”。

第 4 步：复用记录进行多轮改稿

如果改稿只是延续同一写作上下文，可以保存上一轮的响应 ID，并在下一次创建响应时传入 previous_response_id。资料明确说明，该参数用于创建多轮上下文，且不能与 conversation 同时使用。

revision = client.responses.create(
    model="gpt-4.1",
    previous_response_id=saved["response_id"],
    instructions="只调整段落顺序和表达清晰度，不新增资料中没有的事实。",
    input="请把上一版改成三段，并保留原有条件说明。",
    store=True,
    metadata={"task_id": task_id, "revision": "v2"}
)

save_writing_record({
    "task_id": task_id,
    "parent_response_id": saved["response_id"],
    "response_id": revision.id,
    "response_json": revision.model_dump(),
    "output_text": revision.output_text,
    "generation_status": "completed",
    "review_status": "pending",
    "publish_status": "draft"
})

上一轮的 instructions 不会自动带到使用 previous_response_id 的下一轮请求中，所以每次改稿都要重新写清本轮规则。若你需要严格复现某个版本，也要在本地记录中保存本轮完整输入和 instructions。

对于需要结构化字段的写作后台，可以参考OpenAI Responses API 写作结果怎么做结构化检查，把标题、正文、标签和审核字段统一转换后再进入发布流程。

可复制的归档模板

下面的 JSON 模板适合用作数据库字段设计或任务日志格式。实际系统可以增加租户、操作者、权限和删除时间等字段。

{
  "task_id": "writing_task_20260827_001",
  "parent_response_id": null,
  "response_id": "resp_example",
  "model": "gpt-4.1",
  "request": {
    "store": true,
    "instructions": "只根据资料写作，不补充未确认事实。",
    "input": "请生成产品使用说明。",
    "max_output_tokens": 1200,
    "temperature": 0.2
  },
  "response_json": {},
  "output_text": "",
  "generation_status": "completed",
  "review_status": "pending",
  "publish_status": "draft",
  "created_at": "2026-08-27T05:21:07Z"
}

如果只想降低存储量，可以把正文和必要字段作为长期记录，同时按权限保存原始响应快照。但这属于你的归档策略，不能据此推断服务端响应会永久保留。需要长期审计时，应以自己的存储和保留规则为准。

翻车怎么改

故障一：本地只有文章正文，没有 response_id

原因：调用成功后只保存了 response.output_text，没有保存响应对象中的 ID，后续无法用 retrieve 定位原始响应。

修正动作：在收到响应后同一次事务写入 response.id、原始响应快照和正文；若数据库写入失败，不要把任务标记为完成，应进入可重试状态。

故障二：设置了 store，却找不到完整业务记录

原因：store 只对应模型响应是否可通过 API 取得，不会自动保存你的操作者、审核结论、发布状态和内部任务编号。

修正动作：为每次请求建立本地任务记录，把 task_id 与 response_id 绑定，并分别维护生成、审核、发布三个状态。

故障三：改稿后覆盖了原始版本

原因：所有版本共用一条数据库记录，导致无法判断哪些内容来自原始响应，哪些内容是人工修改或第二轮生成。

修正动作：每次改稿新增版本行，保存 parent_response_id、新的 response_id、完整输入和修改原因，发布时只引用通过审核的版本。

故障四：retrieve 成功但正文仍不完整

原因：请求返回或读取成功不等于内容满足你的格式和事实要求，模型结果仍需由应用侧检查。

修正动作：先检查响应状态、正文是否为空、必需字段是否存在，再执行敏感词、事实边界、HTML 安全和人工审核检查。

完成前检查

1. 确认每条内容任务都有唯一的 task_id 和非空 response_id。
2. 确认创建请求是否显式传入了符合数据策略的 store 值，并将实际参数写入本地记录。
3. 确认原始输入、instructions、模型、关键参数、原始响应快照和提取正文能够关联查询。
4. 确认改稿没有覆盖原始版本，版本之间保存了父响应关系。
5. 确认生成完成、审核通过和允许发布是不同状态，未审核内容不会进入自动发布。
6. 确认日志、数据库和后台展示不会泄露 API 密钥或未经授权的原始资料。
7. 随机抽取一条任务，用本地 response_id 执行一次 retrieve，并核对返回结果与归档版本是否一致。