长任务Agent失败后怎么继续而不是重来
长任务 Agent 不能只靠聊天记录恢复。它需要检查点、阶段状态、错误分类、外部副作用记录和可恢复队列。
长任务 Agent 最容易让人崩溃的时刻，不是它不会做事，而是它做到一半失败了。前面已经查完资料、写了一半文件、生成了几张图、跑过一次校验，突然接口超时、浏览器断开、进程退出、图片生成卡住、远端服务返回错误。你重新打开任务时，只剩一句尴尬的问题：它到底做到哪了？
如果 Agent 只能靠聊天记录恢复工作，它往往会从头解释一遍计划，甚至重复已经完成的步骤。对短任务来说，这只是浪费几分钟；对长任务来说，这会带来资料重复、文件覆盖、状态错乱、成本上升和审计困难。
长任务 Agent 要能继续，不是靠一句“请接着做”，而是靠可恢复队列：任务被拆成阶段，每个阶段有状态；重要产物有路径；外部调用有结果；失败有分类；继续执行时能从最后一个可信检查点开始。聊天记录可以帮助理解上下文，但它不能替代任务状态。
这篇文章讲的不是某一个框架的用法，而是一种工程思路：怎样让 Agent 长任务从“中断就重来”，变成“失败后能定位、能续跑、能追溯”。
聊天记录不是任务状态
很多 Agent 系统一开始只保存对话历史。OpenAI Agents SDK 的 Sessions 文档说明，Session memory 可以跨多次 agent run 自动维护会话历史，避免开发者手动处理历史消息。这对多轮对话很有用：用户刚才说了什么，Agent 上一轮回答了什么，都能保留下来。
但会话历史和任务状态不是一回事。
会话历史回答的是“我们刚才聊了什么”。任务状态回答的是“工作做到哪一步、哪些产物可信、哪些调用失败、下一步应该执行什么”。长任务失败后，需要恢复的是后者。
比如一个 Agent 正在生产一篇文章包。聊天记录里可能写着“我会查资料、写正文、生成图片、跑 dry-run”。但任务状态要更具体：资料来源文件在哪，正文是否写完，图片 manifest 是否有四条，哪张图失败，CSV 是否已经更新，dry-run 输出路径是什么，Personal OS 是否写回成功。没有这些状态，Agent 很难安全继续。
所以，长任务 Agent 的第一条原则是：聊天记录用于理解，任务状态用于恢复。
把长任务拆成可检查阶段
不可恢复的长任务，通常长得像一句大命令：“帮我完成这批内容生产”。一旦失败，系统只能猜。
可恢复的长任务，应该拆成阶段：
- 读取上下文；
- 确认任务行；
- 收集来源；
- 写正文包；
- 校验文件和字数；
- 生成图片；
- 检查 manifest 和接触表；
- 运行 dry-run；
- 更新队列和目标文档；
- 写回 Personal OS；
- 开始下一篇。
每个阶段都要有输入、输出、状态和证据路径。状态至少包括：pending、running、done、failed、skipped、needs_review。证据路径可以是文件、JSON、截图、日志、URL 或数据库记录。
一旦阶段化，失败就不再是“任务失败”，而是“某个阶段失败”。这两者差别很大。任务失败听起来像要重来；阶段失败意味着只要修那个阶段，然后从下一个可信点继续。
检查点要记录最小足够信息
LangGraph 的 Persistence 文档把持久化拆成两类：checkpointers 和 stores。Checkpointers 会把线程内图状态保存为检查点，用于短期、线程范围内的记忆、人工介入、时间旅行和容错；stores 则保存跨线程的长期数据，比如用户偏好、事实和共享知识。
这给 Agent 长任务一个直接启发：检查点不是把所有上下文都塞进去，而是保存恢复所需的最小状态。
一个文章生产任务的检查点，可以记录这些字段：
- task_id：任务唯一 ID；
- current_stage：当前阶段；
- completed_stages：已完成阶段列表；
- artifacts：重要产物路径；
- source_set：来源列表和采纳边界；
- image_status：每张图片的生成状态；
- dry_run_status：发布 dry-run 结果；
- queue_status：队列行当前状态；
- last_error：最近错误和分类；
- next_action：下一步应该做什么；
- updated_at：更新时间。
这些信息比完整聊天记录短得多，却更适合恢复。恢复时，Agent 不需要重读所有对话，只要读取检查点，核验重要产物，然后继续未完成阶段。
错误要先分类，再决定是否重试
很多系统失败后只有一个按钮：重试。长任务 Agent 不能这么粗糙。错误不同，处理方式也不同。
可以先把错误分成五类。
第一类，临时性错误。网络波动、接口限流、服务短暂不可用、图片生成排队。这类错误适合延迟重试。
第二类，输入错误。文件缺失、JSON 格式不对、必要字段为空、slug 冲突。这类错误要先修输入，不能盲目重试。
第三类，外部约束错误。平台规则阻断、权限不足、token 失效、目标服务拒绝。这类错误需要人或系统更新权限、配置或内容边界。
第四类，产物质量错误。字数不足、来源不够、图片不是 16:9、manifest 缺少 payload、文案命中风险词。这类错误要退回相应阶段重新生成或修改。
第五类，不可继续错误。任务定义冲突、用户目标改变、重要资料不可获得、已经产生不应继续扩散的内容。这类错误要暂停，并留下原因。
BullMQ 的 retrying failing jobs 文档说明，失败任务可以配置 attempts 和 backoff，重试时会按策略回到等待状态。这个思想适合 Agent 长任务：能重试的阶段才重试，不能重试的阶段先进入待处理状态。
重试要有退避，也要有上限
长任务里最糟糕的失败，不是一次失败，而是无限重试。比如图片接口排队，Agent 每 10 秒重试一次；或者某个 JSON 永远不合法，系统却不断重新跑发布脚本。这会消耗额度、污染日志，还可能把状态弄乱。
队列系统常用 backoff，也就是重试之间增加等待时间。第一次失败等 30 秒，第二次等 2 分钟，第三次等 10 分钟。对 Agent 来说，还要有阶段上限：某张图最多重试几次；dry-run 连续失败几次就暂停；同一错误重复出现时不再自动重试。
更重要的是，重试要保留上下文。一次图片生成失败后，不应该丢掉已经成功的三张图；一次 dry-run 失败后，不应该重写全文；一次 Personal OS 写回失败后，不应该把文章状态改回草稿。重试的单位越小，恢复越稳。
外部副作用要单独记录
长任务 Agent 最需要小心的，是外部副作用。写本地文件、更新 CSV、上传图片、创建帖子、发送邮件、写数据库、调用支付或工单系统，都属于副作用。它们一旦发生，就不能假装没有发生。
如果副作用没有记录，恢复时很容易重复执行。比如已经上传过图片，恢复后又上传一遍；已经更新过队列，恢复后又把状态改乱；已经创建过草稿，恢复后又创建一个同 slug 的草稿。
所以每个副作用都要记录：
- 操作类型；
- 目标系统；
- 输入摘要；
- 输出 ID 或路径；
- 是否可重复执行；
- 是否有撤销或恢复方式；
- 时间；
- 执行者。
Temporal 的 Durable Execution 文档强调，工作流可以保存执行历史，并在失败后继续执行；其 Python 错误处理文档也说明，Temporal 会通过重试和持久执行处理多类失败，并区分 workflow task failure 和 workflow execution failure。对 Agent 来说，不一定要使用 Temporal，但要学习这个观念：外部世界已经发生过的事，必须进入执行历史。
幂等性让续跑更安心
幂等性听起来像后端词，其实对 Agent 很实用。一个操作如果重复执行多次，结果仍然一致，就更适合续跑。
比如“用 article_id 更新 CSV 中这一行状态”比“追加一行状态记录”更容易幂等；“按 slug 覆盖同一篇草稿”比“每次创建新草稿”更容易幂等；“图片文件存在且 manifest 合格就跳过生成”比“每次都重新生成四张图”更适合长任务。
设计 Agent 步骤时，可以优先选择幂等操作：
- 用稳定 ID 命名任务和文件；
- 输出路径固定；
- 写入前检查已有产物；
- 更新时按 ID 定位；
- 上传时记录远端路径；
- 发布前先 dry-run；
- 正式动作前再确认状态。
有了这些约束，Agent 恢复时就不需要靠猜：它可以检查文件和记录，判断哪些步骤已经完成。
恢复流程要从核验开始
长任务恢复不要直接继续执行。第一步应该是核验。
核验包括四件事。
第一，读取最新检查点。确认当前阶段、完成阶段、错误类型和下一步。
第二，检查重要产物。文件是否存在，JSON 是否可解析，图片是否齐全，dry-run 输出是否存在。
第三，确认外部状态。远端草稿是否已创建，队列状态是否已更新，WikiWriteJob 是否完成。
第四，生成恢复计划。写清从哪个阶段继续、会跳过哪些已完成阶段、会重试哪些失败阶段、需要人确认什么。
这个恢复计划可以很短，但必须明确。没有恢复计划就继续执行，很容易把失败扩大。
人审和恢复队列要配合
长任务 Agent 不应该把所有失败都自动处理。有些失败需要人审。
比如来源不足，Agent 可以继续找资料；但如果多个来源冲突，就应该进入人审。比如图片文字太小，Agent 可以重生；但如果图像表达可能误导读者，就应该请人看。比如发布 dry-run 被内容规则阻断，Agent 可以改词；但如果涉及题材边界，就应该暂停。
恢复队列里可以有三种状态：agent_retry、human_review、blocked。agent_retry 表示 Agent 可以按策略继续；human_review 表示需要人判断；blocked 表示缺少外部条件，不能继续。
这比简单失败状态更清楚。团队一眼能看到哪些任务可以自动续跑，哪些任务需要编辑介入，哪些任务要等权限、资料或用户拍板。
一份长任务恢复记录清单
如果你正在设计长任务 Agent，可以从下面这些字段开始：
- article_id 或 task_id；
- slug 或稳定业务 ID；
- current_stage；
- completed_stages；
- pending_stage；
- artifact_paths；
- source_paths；
- image_manifest_path；
- dry_run_output_path；
- external_effects；
- last_error_type；
- last_error_message；
- retry_count；
- next_action；
- human_review_required；
- updated_at。
字段不必一开始就很复杂，但一定要能回答三个问题：做过什么，卡在哪里，接下来怎么继续。
结论：能恢复的 Agent，才适合做长任务
长任务 Agent 是否适合投入真实工作，不只在于会不会拆任务、会不会调用工具、会不会写文章或代码，还在于失败后能不能继续。现实里的长任务一定会遇到超时、限流、权限、坏输入、质量问题和外部服务波动。把这些都当成异常，而不是流程的一部分，系统就会脆弱。
可恢复队列的思路，是把长任务变成一串可检查、可记录、可续跑的阶段。检查点保存状态，错误分类决定动作，队列管理重试，副作用记录外部变化，幂等操作减少重复执行，人审节点处理需要判断的部分。
聊天记录让 Agent 记得对话；检查点和队列让 Agent 记得工作。对短任务来说，前者可能够用；对长任务来说，后者才是继续执行的基础。