长任务如何重来：断点恢复与凭据解析

重跑不应该抹掉已经完成的工作

日报归纳需要处理许多事件。把所有输入塞进一次模型调用，容易同时碰到超时、输出长度和失败重试问题。历史维护中采用的改进，是分批归纳、限制并发，并把已经完成的批次保存下来。

现有模型引擎为输入内容、模型和批次参数计算指纹。恢复时先比对指纹，只有匹配的检查点才可复用。这个条件很关键：缓存文件存在，并不意味着它仍属于当前任务。换了输入或模型以后继续拼接旧结果，可能生成一份看起来完整、实际来源混杂的日报。

检查点通过临时文件和原子替换写入，减少中途中断留下半份文件的机会。失败后继续处理缺失批次，成功批次得以保留。历史记录中也保留了同输入重跑复用批次的验收，但耗时与完成数量只属于当时的数据规模，不能据此承诺未来任务速度。

为什么手动能跑，定时却找不到凭据

另一类故障来自运行环境。终端里的环境变量不一定会出现在定时任务启动的系统 Python 中。配置还可能保存的是 key_env，即凭据变量的名字，而不是凭据本身。若程序只读取直接配置的 api_key，就会误判凭据缺失并进入降级路径。

核对当前模型引擎，它会读取环境文件，再解析提供方配置所引用的环境变量；引擎内部使用 setdefault，保留已显式传入的值。这是引擎层的行为，不能假定每个外层包装器都有完全相同的加载规则。环境优先级应逐层检查，验证时也应使用实际定时任务的解释器与入口。

降级也要验收

包装脚本为模型、语义和本地路径分配预算，并预留外层调度时间。换用下一条路径之前，还会检查报告是否更新、日期是否匹配、篇幅和标记是否完整，避免把旧文件误当成本次成功。

这里还有一个实用细节：进程异常退出时，如果完整报告已经写出且通过校验，可以接受产物并明确说明恢复情况。反过来，进程正常结束但报告没有更新，仍应失败。

本文依据历史记录和整理时的代码，未触发新的模型调用。可恢复任务的核心，是让工作进度、输入身份和最终产物都有明确证据。