批量生成蒸馏数据时，一个status字段通常不够。任务是否完成、某次请求是否成功、脚本这一轮是否正常退出，是三件不同的事。把它们混进一张表，重试后就容易覆盖历史，程序崩溃后也很难判断哪些任务可以重新领取。

三类记录解决三个问题

任务表回答“这一条输入最后怎么样了”。可以保存item_id、输入版本、目标模型、最终状态、已接受结果和数据集去向。尝试表回答“每一次调用发生了什么”，保存尝试序号、请求时间、响应状态、请求标识、错误分类和本次消耗。运行表则记录某次脚本启动的代码版本、配置、开始结束时间和进程身份。

三张表不一定必须采用这些英文名称，也不要求所有项目照搬字段。设计时只需保证任务不会因一次失败被永久判死，尝试历史不会被下一次重试覆盖，运行失败也不会把已经提交的成功结果变回未知。

任务状态可以包括待处理、执行中、待核对、成功、可重试失败、需人工处理和永久失败。状态变化要满足允许的方向。例如成功状态不能被普通工作线程直接改回待处理，待核对任务也不能在没有证据时自动重发。数据库约束和条件更新能拦住一部分并发冲突。

租约是分布式领取任务的一种选择

工作线程领取任务时可以写入lease_owner和lease_expires_at。租约有效期间，其他线程不能领取；线程崩溃后，租约到期，恢复程序可以重新安排任务。领取和写入租约需要通过事务或数据库支持的原子操作完成，否则两个线程可能同时拿到同一条记录。单进程小任务也可以采用更简单的队列，不必为了形式增加租约字段。

执行完成后，线程用任务ID、当前状态和租约持有者作为条件提交结果。更新失败说明租约已经失效或状态被其他流程改变，线程不能直接覆盖。这个细节看起来麻烦，却能避免迟到响应把较新的结果冲掉。

租约时间应结合真实响应分布设置，太短会让仍在运行的任务被重复领取，太长则拖慢故障恢复。可以让工作线程定期续租，并记录尾部延迟。具体秒数由项目实测决定，不适合套用固定值。

失败恢复从未知状态开始

网络超时、进程被终止或数据库提交失败后，任务可能处于未知状态。恢复程序先检查本地是否已经保存响应，再结合供应商实际提供的请求标识或调用记录核对。只有确认没有可接受结果，才进入新的尝试。

错误还要分类。认证、权限和参数错误通常需要人工修配置；429和部分临时服务故障可按当前接口说明有限重试；内容验收失败应进入数据质量流程。将所有异常统一捕获后重试，会掩盖程序错误，也可能形成请求风暴。

恢复测试不能只靠阅读代码。可以在请求前、响应后、数据库提交前和导出过程中主动终止程序，再检查任务是否丢失、重复或被错误标成成功。状态机经过这些离线故障测试，才有资格承担更大的批量任务。

平台日志与本地状态互相补充

147AI可以作为多模型统一API候选入口，调用记录可辅助核对模型和消耗。它解决不了本地任务属于哪个数据集、内容是否验收通过、租约是否过期等问题。团队应把平台可见的请求信息关联到自己的item_id和尝试记录，同时以当前页面和API接口文档确认实际字段。

状态机还要处理人工介入。永久失败不一定意味着永远放弃，有些任务修正输入后可以创建新版本；需人工处理也不应由工作线程自行改回待执行。可以让人工操作产生一条审计记录，再由调度程序根据批准结果创建新尝试。这样手工修复不会绕过原有状态约束。

数据导出也应纳入状态设计。任务调用成功、内容验收通过、进入某个数据集版本，分别属于不同阶段。只有最后一个阶段完成，训练脚本才读取该记录。发现验收器错误时，团队可以撤销受影响的数据集发布状态，同时保留教师原始响应，不必重新调用全部任务。

一个可靠的状态机不追求状态越多越专业。它只需保证每次变化有证据，重复执行不会破坏已完成结果，异常退出后仍能解释任务处于哪里。做到这三点，断点续跑才不是一句口号。