OpenAI Responses API 流式写作输出怎么处理

先准备好三类状态

OpenAI Responses API 流式写作输出怎么处理，关键是将流式正文、生成状态和发布资格分开保存。Responses API 的流式请求需要将 stream 设置为 true。资料中的 Python SDK 将返回值标记为包含 ResponseStreamEvent 的流，并说明流式响应通过服务器推送事件发送。接入前，先准备以下状态：

• draftText：已经拼接出的正文，仅用于预览或暂存。
• generationStatus：至少区分 generating、completed、interrupted 和 failed。
• canPublish：只有生成完成、正文非空并通过验收时才设为 true。

如果还需要组织文章提示词，可先参考Responses API 写作输入怎么组织，把稳定规则和本次任务分开传递。

分步操作

1. 创建流式请求。服务端调用 Responses API 时传入模型、输入内容和 stream: true。不要把 API 密钥放在浏览器端，浏览器只连接自己的服务端接口。
2. 按事件读取数据。每次收到事件先读取事件类型，再判断是否为文本增量。不要假定每个事件都带正文，因为流中可能包含开始、完成、错误或其他事件。
3. 只拼接文本增量。将增量字段追加到服务端缓冲区，再通过 SSE、WebSocket 或其他应用内通道推送给前端。前端显示的是预览，不应直接覆盖正式文章。
4. 处理完成状态。收到完成事件后，将状态改为 completed，保存最终正文，并执行长度、格式和事实范围检查。
5. 处理异常结束。连接断开、错误事件或请求超时都应将状态改为 interrupted 或 failed。保留已生成文本供编辑恢复，但关闭发布按钮。

Python 处理模板

下面的模板演示状态边界。事件类型和字段名应以你安装的 SDK 版本实际返回对象为准；遇到未知事件时记录日志，不要把未知内容当正文拼接。

from openai import OpenAI

client = OpenAI()

draft = []
status = "generating"
response_id = None

try:
    stream = client.responses.create(
        model="your-model-id",
        input="请写一篇介绍新手内容编辑流程的短文。",
        stream=True,
    )

    for event in stream:
        event_type = getattr(event, "type", "")

        if event_type == "response.created":
            response_id = getattr(event, "response", None)

        elif event_type == "response.output_text.delta":
            delta = getattr(event, "delta", "")
            if delta:
                draft.append(delta)
                preview = "".join(draft)
                # 将 preview 写入草稿预览通道，不直接发布

        elif event_type == "response.completed":
            status = "completed"

        elif event_type in {"response.failed", "error"}:
            status = "failed"
            break

    if status == "completed" and "".join(draft).strip():
        can_publish = True
    else:
        can_publish = False

except Exception:
    status = "interrupted"
    can_publish = False

result = {
    "response_id": response_id,
    "content": "".join(draft),
    "status": status,
    "can_publish": can_publish,
}

模板的关键不是事件名称本身，而是三条规则：增量只追加一次；完成状态单独确认；任何异常都不能沿用可发布状态。

中断恢复

先保存响应 ID、已拼接正文、最后一次事件序号和中断原因。资料显示，读取已存在响应的流式接口支持 starting_after，可用于从指定序号之后继续读取；是否能在你的具体请求中恢复，应结合 SDK 版本和服务端保存策略测试确认。

恢复时不要直接把新一轮结果追加到旧正文。先使用事件序号去重，再继续拼接；如果无法确认断点，就将旧内容标记为待人工合并，避免重复段落或遗漏段落。

翻车怎么改

• 常见故障：页面显示了半篇文章，刷新后却被当成完整稿件发布。
• 原因：系统把“已经收到文本”误当成“生成已经完成”，没有单独保存完成、失败和中断状态。
• 修正动作：将发布接口限制为 status == completed 且 canPublish == true，连接异常时立即撤销发布资格，并保留草稿供恢复。
• 常见故障：正文出现重复句子。
• 原因：重试或恢复时没有按事件序号去重，直接把重复事件再次追加。
• 修正动作：为每个响应保存最后处理的事件序号；恢复读取时从该序号之后开始，并对重复事件做幂等处理。

完成前检查

• 确认请求确实启用了 stream: true，并且服务端能持续读取事件。
• 确认文本增量只追加一次，未知事件不会污染正文。
• 确认完成、失败、中断三种状态在数据库中可区分。
• 确认中断稿仍可预览和编辑，但发布按钮处于禁用状态。
• 确认只有完成状态、正文非空且通过格式与事实检查的稿件才能发布。