OpenAI Batch API 取消任务后怎么收口：cancelling、cancelled 与部分结果处理

批量任务已经跑了一段时间，业务方突然要求停止，最容易犯的错是把“发出取消请求”当成“所有结果都没了”。OpenAI Batch API 的取消路径通常先进入 cancelling，最终变成 cancelled；这时已成功的请求和失败的请求仍要分别从结果文件与计数中收口。

取消 Batch 不等于回滚整批。正确做法是等待终态，再按 output_file_id、error_file_id 和 request_counts 盘点已经完成的行。

先把取消动作和终态分开看

Batch API 的取消接口是对 /v1/batches/{batch_id}/cancel 发起 POST。接口返回后，任务可能处在 cancelling，服务端还在收尾；只有读到 cancelled，本轮取消才算收口。文档中的批次对象同时提供 output_file_id、error_file_id 和 request_counts，它们比一个布尔值更适合做最终盘点。

这里的判断很简单：看到 cancelling，继续查询同一个 batch_id；看到 cancelled，保存返回对象并转入结果文件处理。不要在过渡态重复发取消请求，也不要把取消中的批次当成可安全重建的空任务。

取消后的第一张清单：状态、计数和两个文件

收口时建议把批次对象原样落盘，再抽取下面几组字段。request_counts.total 是输入请求总数，completed 和 failed 用来校验处理规模；output_file_id 指向成功输出，error_file_id 指向错误行。字段为空时不要猜测，先保留原始响应并记录本次读取时间。

不要用 total - completed 直接当成“可重跑数量”。剩余行里可能包含失败请求，也可能包含因为取消而没有机会处理的请求，必须继续看输出文件和错误文件中的 custom_id。

用 custom_id 把部分成功结果分流

Batch 输入是 JSONL，每行都有开发者提供的唯一 custom_id。取消后的处理可以按三路分流：在输出文件中的标记为已成功，在错误文件中的标记为已失败，两个文件都没有出现的标记为未收口。最后一类才是下一批真正需要考虑的候选。

{"custom_id":"invoice-0007","status_code":200,"response":{"body":{"id":"resp_7"}}}
{"custom_id":"invoice-0008","error":{"code":"rate_limit_exceeded","message":"temporary limit"}}

实际读取时不要依赖文件行顺序。用 custom_id 建索引，再和原始 JSONL 的集合做差集；这样即使结果文件乱序，也能避免把已成功的 invoice-0007 重复塞进下一批。

下一批怎么重跑才不会重复扣处理量

重跑前先生成一份结果快照，至少包含原始 custom_id、结果类别、对应文件标识和重跑原因。新的 JSONL 只放“未收口”或经过人工确认需要重试的行；已经成功的行不重放，已明确失败的行也不要无条件重放，先看错误是否具备可恢复性。

如果业务必须保证最终完整，可为每次重跑增加批次前缀，例如 retry-20260829-invoice-0008，同时保留原始 custom_id 到业务单号的映射。这样既能识别重跑次数，也不会让一个取消批次的部分结果被覆盖。

常见问题：取消后的三个边界

看到 cancelling 就可以重新创建吗？

不建议。此时原批次仍在收尾，结果文件和计数可能还会变化。至少等到 cancelled，再读取最终对象。

cancelled 是否代表没有任何成功请求？

不是。取消是批次状态，不是逐行结果。是否有成功行，要看 output_file_id 和输出内容。

失败文件里的行都应该重试吗？

不应该。先按错误码区分临时限制、参数错误和业务拒绝；只有可恢复错误才进入重试集合。

一张可执行的收口表

• 状态：同一个 batch_id 查询到 cancelled。
• 结果：保存批次对象，记录 output_file_id 和 error_file_id。
• 对账：用 custom_id 覆盖成功、失败、未收口三类集合。
• 重跑：只生成未收口或明确允许重试的 JSONL 行。
• 复核：让 request_counts 与三类集合总量互相解释。

取消操作真正完成的标志，不是按钮返回得有多快，而是状态进入 cancelled 后，结果文件和请求计数能够解释每一行输入。把这一步做成固定收口流程，下一次遇到临时停批时，已经完成的工作就不会被误删，未完成的工作也不会被重复处理。