AI Agent 长任务如何断点续跑？保存状态并避免重复执行

一项研究或交付任务可能在浏览器关闭、执行进程重启后继续，也可能隔夜等人审批。给 Agent 说一句“接着上次做”，不能保证它知道哪些对象已经完成、哪个工具调用仍未确认、现在还允许谁继续。应用需要一份持久、可查询的任务状态，明确下一步的边界。

本文处理的是同一业务任务的计划暂停与续跑。Agent 循环护栏决定运行中的下一步能否继续；长对话压缩检查缩短模型上下文后是否丢失决定与证据；Agent 恢复手册处理事故后的影响、补偿和人工接管。本页关注普通暂停或换执行者时，怎样凭已保存的事实安全重入。若某次续跑发生争议，可再用单次执行轨迹复核查它在哪个交接点偏离。

先分开五类状态

状态面	它回答的问题	应以哪里为准
对话或 Session 历史	下一轮模型可能看到哪些消息和工具返回？	会话存储或供应方会话；它是上下文，不是业务步骤完成回执。
执行检查点	运行框架能从哪个步骤、哪些变量与待执行分支继续？	持久检查点或事件历史，以及稳定的任务游标。
业务进度	哪些输入对象已通过复核，输出是什么版本，还有哪些未做？	应用持有、关联来源与产物 ID 的进度台账。
外部效果	发布、预订或其他写入在目标系统中真的生效了吗？	目标系统的权威记录，并与操作编号关联。
人工批准	谁在什么时限和规则下批准了哪个具体动作与版本？	经过身份验证、由服务端持有的决策记录，不能只靠对话摘要。

OpenAI Agents SDK 的 Session 管理跨运行的对话历史，等待审批的运行另有可序列化的 RunState。LangGraph 也区分单线程检查点与跨线程资料 Store。只保存一个会话 ID 并不能证明进程重启后任务还可恢复。需要选持久存储，规定访问与保留期限；真实密级原文和密钥也不该塞进本站保存在浏览器中的空白工作表。

在运行框架支持的边界提交进度

给业务任务分配稳定的 task_id，每次实际执行另用 attempt_id。状态中写入检查点 ID 或事件游标、工作流与状态结构版本、已验收产物的位置、逐对象完成状态、下一合法步骤、累计预算、截止时间、取消状态，以及所用来源版本。大文件使用受控位置和校验值，不要每次把全文复制进对话快照。把“已确认”“进行中”“结果未知”分开；重启不能让未完的一项自动变成完成。

具体保存时机取决于框架。LangGraph 在 super-step 边界保存完整图状态；其 exit 模式无法保护运行中途遭遇进程崩溃的步骤，async 写入存在较小的丢失窗口，sync 则在进入下一步前完成写入，代价是额外耗时。内存版 Saver 在进程重启后也不保留记录。平行节点有的成功、有的失败时，它可保存已成功节点的 pending writes，但这不等于从任意代码行恢复。根据可承受的丢失范围选配置，并在边界前后真正杀掉测试进程验证。

重放模型调用也不能假定会生成同一句话。LangGraph 从旧检查点重放时，后续节点的 LLM 调用和 API 请求会再次执行；从人工中断恢复时，所在节点会从头开始，中断前的代码也会再运行。需要保持稳定的决定和已验收产物，应写入持久业务状态；可能产生外部效果的动作须另有可安全重入的协议。Temporal 通过事件历史恢复工作流进度，但 Activity 在外部函数已经被调用、执行者随后崩溃时仍可能按策略重试。框架记录的进度和外部系统的真实变化不是同一件事。

给外部写入单独建操作台账

在工具提交不可随意重复的动作前，先持久记录业务对象、获批准的参数指纹、操作或幂等键、目标系统及预期结果。发送前再持久转为发送中，调用结束后记录响应和可向目标系统查询的编号。至少区分待执行、发送中、已确认、明确拒绝、结果未知。若目标系统已接受请求，而本地尚未记录成功就退出，台账可能仍显示“发送中”；若发送状态转移也丢失，甚至可能还显示“待执行”。凡是可能已发出的动作，都保守视为结果未知，先用操作编号或业务键核对远端记录。只有确定此前未执行，或目标系统对同一参数和键确实保证安全去重，才可再次提交。

检查点与外部服务通常不能作为一笔原子事务一起提交。不能因为某运行框架宣称“只执行一次”，就推断另一家 API 丢了响应时也不会重复写。把每种工具的键有效期、参数变化规则、并发处理、权威查询路径及无法判断时的负责人，写进工具调用契约。远端状态查不清时暂停交人，不以 Agent 上一次说“成功了”或超时报错来猜测。

让旧审批重新过门，并限制单一接手者

按本文的严格策略，隔夜审批只针对某一次工具调用及其准确参数，不是“继续整个项目”的永久许可。保存审批者、决定、草稿或参数版本、策略版本、允许范围、有效期与时间。草稿、目标对象、权限规则、请求者身份或任务期限一旦变化，就重新走相应关卡。OpenAI Agents SDK 也支持 always_approve=True，可让同一工具后续调用继续沿用批准；这里应关闭这种宽泛模式，或在应用层逐次核对调用参数和版本。SDK 可在 RunState 中保存待审批调用与决策，但官方文档提醒：反序列化不会认证状态快照或提交它的人。服务端须从可信存储取自己的状态，验证审批者身份与权限，并原子地消费待决项后再继续；不能让浏览器提交一份替换过的完整 RunState。

任务本身也应从“暂停”到“恢复中”完成一次带所有者校验的原子转移，并记录新的尝试号或租约，避免两个 worker 同时从同一检查点写出结果。第二次点击“续跑”应找到已有尝试或显示处理中，不应开启另一份执行。租约过期时，旧 worker 仍可能活着；只在写入前检查所有权会有竞态。应在提交关口强制核对带隔离作用的所有者世代号或版本；若外部目标不支持这种核对，就经由单一且验证占用者的写入代理，或依赖目标对该操作已验证的去重保证。已取消和已过期任务应阻止新动作。长时间保存的状态可能遇到 Agent、工具结构或 SDK 改版，所以还要记录版本；不兼容时迁移或交人审阅，不盲目反序列化并执行。

用现时证据决定下一步

重启时按稳定任务 ID 读取服务端状态，检查完整性、结构版本、来源和产物版本，以及当前身份能否继续访问。先对账所有结果未知的外部操作，再选择下一次写入。审批必须适用于当前参数；经过时间、模型轮次、工具尝试、Token 和费用预算也必须沿用累计值，不能因为换进程就清零。最后确认任务未取消、未到期、也未已完成，才把允许执行的下一步与受控资料位置交给新执行者。

至少用合成任务测试四个故障窗口：检查点提交前崩溃、提交确认后崩溃、远端写入已接收但本地回执丢失、两次续跑请求同时到达。还要让旧 worker 的租约到期但进程仍活着，再由新 worker 接手，验证旧 worker 的提交在目标写入关口被隔离机制拒绝或安全去重。另加一条来源改版或审批内容变化的测试。逐项记录目标系统的真实对象数、Agent 续跑后的动作，以及是否重复了已经确认的步骤。下方表格的结果格留空，待实际演练填入；只看到模型能接话并不算验证通过。

案例：档案照片编目跨过进程重启

设想一个虚构档案馆，让 Agent 为一组历史照片起草可搜索说明。每张照片有来源编号和文件校验值；Agent 草拟说明后，编目员接受或修改，才把该照片标为完成。某个 worker 在生成一张照片的草稿时退出，之前已有若干照片通过验收。

续跑状态要把已验收照片 ID、产物版本与正在处理的照片分开保存。重启后先核对源文件校验值，再按受控位置加载已验收说明；这些已完成项不应重复花模型调用，也不能把半截草稿当成通过。若某张照片隔夜被替换，只暂停该项重新核对，不把无关已完成项一并抹掉。实际完成数量和复跑结果应在演练后填写，不由案例预设。

案例：博物馆展签隔夜等待发布

另一个虚构任务中，Agent 起草展品说明，准备写入内容管理系统前暂停，请策展人审批。审批针对指定展签草稿版本和目标页面。第二天一位同事改正了草稿中的日期；旧批准不能覆盖这份新版本。接手的 worker 要比对批准时的参数指纹和当前内容，并重新请求决策。

另一项故障探针让 CMS 接受发布请求，但 worker 没收到响应。保存的操作键维持“结果未知”，直到查询 CMS 的权威记录；重新打开 Agent 或再次点击批准，都不应直接生成第二个页面。若目标系统无法确定效果，就保持暂停并交给明确负责人。这里描述的是试验预期，并不声称已经发生这些实测结果。

填写续跑状态契约

下方工作台可记录任务与尝试编号、持久检查点、来源及产物版本、逐对象进度、审批绑定、外部操作状态、累计限制、单一接手关卡和故障窗口测试。它会把草稿保存在当前浏览器，并提供复制与 TXT 导出。请只填虚构编号和受控证据位置；真实序列化运行状态、凭据、受限文件与审批记录必须留在获授权的服务端。

不适用边界

一次请求内就能完成的简短只读任务，可能无需持久化工作流。这份契约也不替代事故中需要补偿与接管的恢复手册、模型上下文压缩后的事实测试，或有争议运行的逐事件复盘。不同框架、版本和执行模式的保证并不一样；只有选定运行环境和目标系统已经验证的边界与状态转移，才能作为实际续跑依据。