Agent 任务跑到一半失败，处理方式不应只有“重新执行”。更稳妥的做法是先回答三个问题：哪些步骤已经完成，哪些产物可以使用，失败节点之后的输入是否仍然有效。只有这三点都能对上，才适合从断点继续；如果状态不清、产物不完整或外部动作已经产生副作用，应暂停并交给人工确认。
以整理一批客户反馈为例，Agent 可能已经完成文件读取、内容分类，却在生成汇总报告时遇到模型调用失败。重新读取和分类会浪费时间，也可能重复写入中间结果。使用 ZGI 这类可自托管的 Agent Runtime（智能体运行时）时，可以结合运行步骤、状态和结构化输出查看任务走到哪一层，再决定是继续、重做还是停止。
先确认断点是否真实存在
“失败”不能只看最后一条自然语言提示。需要把运行过程拆成可核对的步骤：输入是否读取完成，分类或检索是否有结果，模型是否返回，文件是否写入，通知是否发送。每个步骤都要有状态和对应产物，不能用整条任务的“处理中”覆盖所有细节。
对客户反馈任务，运行记录可以标出：12份文件中有10份完成解析，分类结果已经保存，汇总模型调用失败，通知步骤尚未开始。这个记录说明可以从汇总节点继续，但不能说明全部输入都已成功处理。若只看到“生成失败”，就无法判断前面的分类结果是否可复用。
断点还要考虑输入是否发生变化。用户在失败期间替换了文件、修改了统计范围，或者权限发生变化，旧产物就不能直接接着用。继续前至少保存输入清单、版本标识或时间范围；无法对应的产物标记为待确认，不要让模型自行猜测它们是否过期。
工具调用尤其需要确认副作用。读取、分类这类动作通常可以重试，发送通知、创建工单或修改数据库则可能已经影响外部系统。对后者，先查询是否已经生成结果，再决定继续还是补偿；不要因为没有收到完整回执，就假设动作没有发生。
再决定继续、重做还是暂停
继续运行的条件应写成明确规则：失败节点之前的必要步骤已完成，产物与当前输入匹配，失败节点没有产生未确认的外部副作用，后续步骤可以接收已有结果。满足这些条件，才从失败节点重新发起。
如果只有一部分输入完成，任务可以按文件逐项补跑，但交付时要说明覆盖范围。若中间产物格式不符合后续节点要求，就重做产生该产物的步骤，而不是把错误结果继续传下去。外部动作状态不明时，先暂停，保留任务上下文和待确认事项。
在 ZGI 的工作流中，模型调用、文件处理、数据库操作和通知都可以组织为执行步骤，运行结果可结合状态、步骤和结构化输出查看。具体的断点规则、幂等处理和人工接管仍需团队按业务配置，不能把“有运行日志”直接当成系统已经自动恢复。
一次恢复运行也要有自己的验收记录：沿用了哪些输入，跳过了哪些步骤，补跑了哪个节点，产生了哪些新文件，哪些外部动作经过了确认。恢复成功不等于原任务自动变成完成；还要重新检查最终产物和交付位置。
对 Agent 来说，断点续跑的关键不是保存一句“上次失败了”，而是保存可核对的步骤、输入和产物关系。任务失败后先定位，再判断能否复用，最后让继续运行带着明确边界开始，才能减少重复执行，也让每一次人工接管都有依据。
GitHub：github.com/zgiai/zgi
Gitee：gitee.com/zgiai/zgi
