Batch 结果不保序。按位置匹配（第一条结果 = 第一条请求）是错的。custom_id 是把结果和请求匹配起来的唯一可靠机制。
设计可追溯性
好的 custom_id 自包含且信息丰富：
batch-20260327-003_doc-INV-4521这编码了：batch 日期、batch 编号、文档类型和文档 ID。几个月后出故障时，光看 custom_id 就知道该查什么。
选择性失败恢复
1,000 个请求中 60 个失败了——只重新提交这 60 个，不是整个 batch。用 custom_id 识别哪些请求失败了，按错误类型修复根因，创建一个只包含修复后请求的恢复 batch。
重新提交全部 1,000 个浪费了 940 个已成功的 API 调用的预算。
Batch 不支持多轮 Tool Calling
每个 batch 请求是一个单独的消息-响应对。模型可能返回 tool_use 内容块，但这些工具调用在 batch 内永远无法执行——没有机制把工具结果喂回去。多轮 agentic 工作流必须用同步 API。
一个研究流水线把 2/3 的工作负载改用 batch 处理单轮提取阶段，同时把多轮 tool calling 编排留在同步上，省了 50%。
一句话总结： 设计自包含可追溯的 custom_id，用它做选择性失败重试，永远不要假设结果有序——按位置匹配会无声地损坏你的数据。