Responses 返回 incomplete 时，怎样阻止半份 JSON 被当成完整结果

一段 JSON 以右花括号结束，不代表响应已经完成。模型可能先写出一个合法对象，但响应生命周期仍是 incomplete；也可能在中途截断，连语法都不完整。客户端需要先判断信封状态，再检查正文，不能让“能解析”替代“已完成”。

生命周期是第一道闸门

本文只让 completed 状态进入业务 JSON 与字段校验。incomplete 保存原因和安全样本，failed 保存失败信息，其余未知或非终态同样不可用。状态值来自 Responses 协议；本文 accepted 等内部判定是应用自己的合同，不是新增的 API 生命周期。

官方资料给出 incomplete 及其详情的处理方式。调用方要按当前响应读取原因，不能把所有未完成都断言为输出预算太小；缺少原因时保留未知，不凭最后一个字符补推。即使计划稍后重试，也应先把当前记录明确标成不可用。

语法完整的反例更重要

附件有 completed 加合法对象、incomplete 加半截对象、incomplete 加已经闭合的对象，以及 failed 四种信封。只有第一项能输出业务结果。第二与第三都应在解析之前被闸门挡住，说明逻辑依赖状态而不是括号形状。第四项也不能从残留正文里抢救一个成功对象。

失败反例是 text.endswith('}') 后直接入库。字符串里的花括号、尾随空白或多个输出块都会让这种判断失真。另一种先解析再补状态的流程，可能已经触发工具写入才发现未完成，因此顺序本身需要测试，不能只看最终返回值。

待处置记录要能复查

台账记录请求标识、生命周期、详情及正文摘要，业务结果字段留空并说明原因。这里的空是“不可采用”，不是模型确认没有数据。若系统同时统计业务成功率和协议完成率，应分别计算，避免把一次未完成解析成“查无记录”，掩盖可靠性问题。

接收到完整状态以后还要防止错误 Schema、重复键和业务不一致。完成闸门只是必要条件，不能把它写成充分条件。本文简化业务对象为包含明确值的小结构，真实项目应在其后连接现有类型与语义检查器。

是否重新请求、缩小任务或人工检查，要在更上层决定，并评估重复副作用。本例不发重试、不提交工具动作，也不调用实际 Responses 接口。离线参考结果只证明客户端按合成信封阻止了半份结果入库，不能据此评价模型完成率或平台可用性。对生产数据补测时应保存真实信封，而不是只复制聊天里显示的一段文本。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a019.json，离线检查器 a019.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a019.py。

一手资料1；一手资料2。资料核对日期：2026-10-24。