ZGI：长任务中断后，怎样从原节点继续长任务恢复需要保存任务编号、节点状态、输入输出、外部回执和等待条件。系统先确认最后

长任务中断后，安全恢复依赖一个明确检查点：哪些节点已经完成，哪些外部动作已经生效，当前在等待什么，下一步允许怎样重试。只保存聊天记录无法回答这些问题。任务需要独立状态和业务回执，恢复时先核对最后一次已确认结果，再决定继续、重跑或转人工。

ZGI 的 Workflow Runtime 可以运行和停止流程，并提供节点调试、运行日志与执行链路查询。团队可以用这些记录定位任务停在哪一步。要从原节点继续，还需要在流程设计中保存关键输入输出，并让数据库、消息或业务接口返回可查询的操作标识。

等待用户补充资料或等待负责人审批时，任务处于暂停状态，当前节点和等待条件都很清楚。工具返回明确错误时，可以按照预设规则重试或结束。更棘手的情况是请求已经发出，连接随后超时，系统无法判断外部动作有没有完成。

结果未知时直接重跑，很容易重复发送通知、创建两张工单或写入两条数据。外部系统如果支持幂等键，可以用同一个操作标识提交；如果只支持结果查询，就先检查业务对象是否已经生成。恢复策略需要服从下游系统的实际能力。

一个可用的检查点通常包含任务编号、当前节点、节点输入、结构化输出、外部操作标识、重试次数和等待条件。文件任务还要保存文件位置与处理版本，审批任务要保存审查对象和当前状态。日志负责说明发生过什么，状态负责告诉程序下一步可以做什么。

以合同材料处理为例，流程先解析文件，再检索条款、生成风险摘要、等待法务确认，最后写入项目记录。如果任务停在人工确认阶段，恢复时不应重新解析全部文件。系统读取已完成节点的结果和文件版本，确认材料没有变化，再回到等待节点。若材料已经替换，前面的分析结果随之失效，流程需要从新的文件检查点开始。

在 ZGI 中，可以通过 Workflow 节点和运行日志定位失败位置，把需要跨节点使用的结果写入稳定变量或业务数据。涉及数据库写入、消息发送和外部接口的节点，还要保存下游回执。运行记录能够帮助排查，真正的恢复边界仍由状态保存、下游查询和重试规则共同决定。

上线前可以主动在文件解析后、工具调用中、审批等待时和最终写入前停止任务。重新启动后检查它是否找回正确节点，已经完成的动作有没有重复，旧输入是否仍然有效，人工处理是否能接管结果未知的情况。

长任务恢复没有统一的“继续”按钮可以覆盖所有业务。先划出检查点，再为每类副作用设计查询和重试路径，任务中断才不会变成整条流程从头再来。