长任务 Agent 怎样暂停和恢复：检查点必须对应真实业务结果

设备巡检演练分成接收记录、核对缺项、整理异常、生成报告、提交维修工单和通知负责人。每个阶段有明确输入与完成条件。报告生成完成，并不代表工单已经受理；通知文本生成完成，也不代表负责人已经收到。

LangGraph 的中断文档要求用检查点保存状态，并通过同一线程标识恢复任务。生产需要持久的检查点存储。文档同时提醒，恢复会重新运行中断所在节点开头的代码。本文的巡检状态与业务请求表是独立设计，可用于其他持久任务系统。

选择检查点位置时考虑实际代价和外部影响。耗时检索结束后保存资料引用，人工等待前保存候选，外部提交前后记录动作状态。没有必要把每一句模型输出都做成一个业务阶段。

不要把秘密值放进检查点。保存受控凭证引用，恢复时重新取得合法访问能力。检查点也含业务资料和摘要，需要按任务权限保护，设置保留和清理规则。文件存在不等于任何人都能拿来恢复任务。

动作记录可以采用准备、提交中、已完成、明确失败和结果未知等状态，具体名称由系统约定。“节点跑完”仅描述程序，无法代替外部服务的完成证据。每个状态变化保存相关业务标识，方便查询。

提交前先记录稳定的业务请求标识，提交后保存外部响应与对象编号。若响应丢失，将状态标记为未知，恢复时按请求标识或业务对象查询。外部系统不支持查询时，需转入人工核对或明确的异常流程，不能让模型猜测是否成功。

同一个动作发生重试时沿用对应的标识，业务参数改变则表达为新的意图，不能混在旧重试里。动作记录的持久化与外部提交之间通常存在失败窗口，要在设计和测试中明确面对它。

并发恢复需要服务端执行约束：恢复者通过条件更新或任务租约取得执行权，旧进程与并发恢复请求不能覆盖新状态。任务锁或租约必须与版本校验共同工作，外部执行前仍检查当前执行资格；仅保存 version 字段不能阻止陈旧进程继续写入。

AWS 的幂等 API 文章说明，调用方提供的请求标识可帮助服务识别重复意图；相同标识却不同参数要单独处理。它也讨论幂等记录与业务变更保持一致的重要性。给调用加一个 requestId 字段，只有服务端真正执行去重和一致性规则时才有作用。

在维修工单演练中，首次请求和重试都带同一个请求标识，服务返回相同业务含义的结果，或能够查到同一工单。需要定义标识范围、有效期限和相同标识参数不一致的处理方式，避免隔了很久又被当作新请求。

暂停前后的写入、通知和附件上传都要考虑重复执行。把副作用放在独立节点更易理解，但进程可能在提交后、保存结果前失败，仍需幂等接口或查询核对。检查点恢复本身不能承诺分布式系统中的所有副作用恰好一次。

每次演练检查外部对象数量和内容，而非只看程序有没有报错。状态恢复正常却出现两张维修工单，说明任务仍不能安全恢复。保留失败点、配置版本和实际结果，让维护人员可以复现。

人工等待需记录等待谁、等待什么、何时超时和超时后做什么。框架可以无限等待，业务不能默认无限等待：设备状态、负责人和资料版本都会变化。恢复时核对这些条件，过期候选按规则重新确认。

取消任务要有可检查的标记，执行服务在下一次有影响的动作前验证。已完成的工单不会因取消标记消失；需要调用业务撤销流程，记录是否可撤销及失败后的接管人。补偿动作也可能失败，应有独立状态。

部署新版本时，先确认旧检查点能否被新流程解释。对于无法兼容的状态，保留旧执行版本或提供受控迁移，避免直接从新版本的同名节点继续。恢复页面要显示实际任务状态，而不是沿用用户打开时的旧进度。

可以先为一条流程建立持久状态表和动作表，使用隔离业务接口验证重启恢复，再按需要引入框架。状态记录、权限校验和幂等契约仍需由团队落实，不能因为安装了框架就省略。

这一方法适合耗时检索、批量整理、人工等待和外部写入结合的任务。简单的一次性公开问答可以轻量处理。先从一个可查询结果的外部动作开始，明确恢复与接管路径，再扩展到多个系统。