Batch任务凌晨就提交，为什么仍错过08:00？把截止、兜底和去重补上
凌晨提交了一批AI摘要，08:00打开页面却发现任务还没完成。遇到这种情况，先确认程序有没有把“提交成功”当成“结果可用”：Batch是异步执行方式，拿到任务编号，并不代表已经生成了所有可交付的结果。
如果内容有明确截止时间，需要在提交之外补三件事：观察任务状态和逐条结果、提前准备兜底、处理晚到结果的重复交付。单纯把轮询改得更频繁，不能让服务端一定赶上你的时间表。
先查任务状态，再查单条结果
以Amazon Bedrock为例，官方文档说明，Batch输入从S3读取，完成后的输出再到S3获取。监控文档还提供了任务状态与处理进度查询，也可以用EventBridge接收状态变化通知。
图：AWS官方Batch监控文档。这里是文档页面，不是已创建付费任务的控制台截图。
| 看到的现象 | 接下来检查什么 |
|---|---|
| 提交接口已返回任务编号 | 把编号保存下来，查询该任务当前状态；不要直接生成“全部完成”记录 |
| 任务已经处理了一部分输入 | 检查成功、失败和未处理记录；处理过的数量不等于可交付的成功数 |
| 输出目录已有文件 | 按记录标识核对成功结果和错误，不能按文件出现就判断整批成功 |
| 已到自己的交付时间，任务仍未结束 | 执行预先设计的截止策略，记录哪些条目使用了兜底 |
不要依赖输出的行顺序和输入一一对应。给每条记录保留稳定标识，把结果重新关联回原任务；同一条内容的Batch请求、同步重试和预备稿都沿用同一个逻辑任务标识。
Bedrock输出中的recordId用于关联记录，单条内容可能包含modelOutput或错误。汇总文件里的processedRecordCount包含成功和错误记录，要结合successRecordCount、errorRecordCount判断，不能把“处理过”直接算成“成功”。
截止时间和服务端超时是两件事
假设08:00必须交付，不能把08:00同时设成“开始考虑兜底”的时刻。可以按实际需要安排07:45检查状态、07:50切换尚未完成的条目、07:58冻结本次内容。具体留多久，要看兜底执行和最终检查的实际耗时。
服务端的任务超时或完成窗口是另一套规则。它不会因为你本地设置了08:00截止，就自动承诺提前完成；不同供应商、模型、地区和接口的限制也不能混用。
兜底可以是已经准备好的短版内容、上一份仍有效的资料，或者有预算且来得及执行的同步请求。同步请求同样可能限流或失败，不能把“切换同步接口”写成必定按时完成。
三条任务怎样处理
下面用本地教学模拟演示截止决策：所有任务00:10提交，A在07:20完成，B在08:05才完成，C尚未完成。示例中fallback表示选择已经准备好的替代内容，没有实际调用Batch或同步模型接口。
| 任务 | 模拟完成时间 | 08:00交付选择 | 晚到结果怎么处理 |
|---|---|---|---|
| A | 07:20 | 使用Batch结果 | 同一任务不再重复交付 |
| B | 08:05 | 使用预备内容 | 记录迟到，不覆盖已发内容 |
| C | 未完成 | 使用预备内容 | 后续到达时仍按任务标识判断 |
from datetime import datetime def dt(hm): return datetime.fromisoformat('2026-10-30T' + hm + ':00+08:00') deadline = dt('08:00') completed = {'A': dt('07:20'), 'B': dt('08:05'), 'C': None} published = {} def publish_once(task_id, source): if task_id in published: print(f'{task_id}: duplicate {source} -> ignored') return published[task_id] = source print(f'{task_id}: {source} -> published') for task_id, finished_at in completed.items(): ready = finished_at is not None and finished_at <= deadline publish_once(task_id, 'batch' if ready else 'fallback') # B的Batch结果后来到达，不能再交付一次。 publish_once('B', 'late_batch')图：上述相同决策逻辑的Python实际运行结果，数据为教学模拟。A使用batch，B、C使用fallback，B晚到时显示ignored；published在这里是程序记录的交付选择，没有向任何外部平台发文。
示例只用单进程内存字典说明逻辑，重启后会丢失，也不能处理并发竞争。正式系统需要持久化任务状态，并用唯一约束或原子更新保证一个逻辑任务只选中一次交付结果。
取消、重试和晚到结果不要混成一条线
准备切换兜底时，把Batch任务标识、逻辑条目标识和当前状态保存下来。是否请求停止任务，要按所选服务的停止能力处理；发出停止请求之后，仍要核对服务端状态，不能直接记成任务已停或费用一定为零。
AWS停止任务文档明确说明，已经处理的token仍会计费。因此，取消用于控制后续执行，不等于撤销已经产生的用量。
有的任务只需记录迟到结果，供下一期采用；有的任务需要在允许的时间内更新。两种情况都应明确版本和替换规则，避免Batch晚到后自动覆盖已经人工修正的内容。
截止前重点检查仍未获得可用结果的条目，截止后重点检查是否重复交付、是否误覆盖。这样即使一批任务没有赶上，也能知道哪些内容已经交付、来自哪条路径、后续结果应该怎样处理。
来源：AWS官方《Batch推理概述》《监控Batch任务》《读取Batch结果》与《停止Batch任务》。