长任务的工程化：进度、预算与中断恢复

用智能体跑长任务（几小时到十几小时）和跑几十秒的小任务是两类问题。前者失败的方式几乎都不是"模型不够聪明"，而是跑到一半断了、额度用完了、或者第二天发现跑的是错的方向。

一、进度必须落盘

会话里说"已经处理了 1.2 万条"没有意义——会话一断，这个状态就不存在了。我要求所有长任务维护一份外部状态文件（任务表或日志）：做到哪一步、哪些完成、哪些失败、失败原因是什么。

好处不只是"能续跑"，还包括：可以随时从外部观察进度，而不必去翻会话记录。

续跑的实现方式比想象中简单：以"幂等"为前提。如果每个处理单元都有唯一标识（例如内容哈希），重跑时天然会跳过已完成的，就不需要复杂的断点逻辑。断网、重启、额度耗尽之后，重新启动即可，不需要人工判断从哪继续。

长任务最容易在两种地方翻车：

应对办法是提前估算并留出余量：给并发设上限、把高峰任务拆到多个时段、把"必做"和"可延后"的任务分开。混合引擎（本地算力打底 + 云端补充）也是这个思路：本地算力未必快，但它是稳定的、不计次数的。

我给自己和智能体都定了同一套反馈规范：超过一分钟的任务，开始前给出预估时长；执行中定期报告进度；失败要说清楚失败在哪一步、已完成了多少。这条规范的价值在于：避免"跑了一整晚，早上发现白跑"。

跨设备、跨天、跨额度周期执行任务时，中断不是异常而是正常路径。因此设计时默认"随时可能被打断"：状态在外部、操作幂等、结果可验证。这三点做到了，长任务就变成"可以分很多次把它做完"，而不是"必须一口气成功"。

长任务真正考验的不是智能体的能力上限，而是流程的健壮性。把人会犯的错误（忘记做到哪、重复劳动、凭感觉判断完成）在流程层面消掉，比期待模型更聪明有效得多。