ZGI Workflow 的失败任务回放不能直接等同于重新点击运行。完整回放需要保存原始输入、Workflow 定义版本、模型路由与参数、Skill 和工具依赖、节点状态以及外部系统回执并为会写数据、发消息或创建工单的节点准备隔离或替代出口。缺少其中任何一层新的运行结果都可能来自不同条件无法证明原故障已经复现。ZGI 作为可自托管的 Agent Runtime可以把 Workflow、模型路由、Skills 和受控执行放在同一运行关系中。Workflow 运行记录能够保留 run 与 node 的状态、输入输出、错误和时间信息这些记录适合定位回放起点。它们仍不等于一份自动生成的完整快照外部接口版本、数据库当时的数据和业务系统回执还要由接入层一并保存。运行记录和运行快照差在哪里运行记录回答的是任务走过哪些节点、在哪里失败。运行快照还要回答当时究竟使用了哪一套条件。一次模型调用失败重新运行时如果已经切换模型、修改提示词或刷新知识库即使流程这次成功也无法判断原问题来自模型、数据还是配置变化。需要冻结的内容回放时解决的问题缺失后的风险原始输入与文件摘要输入是否与失败现场一致用新输入覆盖原问题Workflow 定义版本节点和分支是否发生变化实际跑了另一条流程模型路由与参数模型行为是否可比较结果变化无法归因Skill、工具与接口版本执行动作是否保持一致依赖升级改变结果节点状态与外部回执动作是否已经产生业务结果重放造成重复写入概念示意图把输入、流程版本、模型配置、执行依赖和外部回执组合成可回放快照。回放要分成三个安全层级只读回放适合检索、分类和生成类节点保留原输入并重新计算结果。替身回放把 CRM、邮箱、工单和数据库写入替换成测试端点验证参数和分支但不触碰真实业务。受控重放只用于已经确认幂等键、业务编号和补偿规则的动作并在执行前查询外部系统确认原任务没有留下有效结果。这一步很容易被忽略。HTTP 超时只说明调用方没有及时收到响应无法证明目标系统没有完成动作。回放前若不检查外部结果标识一条失败任务可能生成第二份文件、第二张工单或第二次通知。Workflow 负责保存和推进执行状态业务系统仍要负责唯一编号、去重和最终结果确认。完整回放可以按原 run 建立一个 replay bundle里面保存输入快照、配置版本、节点时间线、外部回执摘要和允许重放的节点范围。回放时从第一个异常节点之前开始对成功节点使用已保存输出对失败节点重新执行再逐项比较路径、参数、结果和错误是否变化。只有变化能够对应到一项明确修复回放才有诊断价值。用失败样本守住下一次修改修复完成后不要丢掉这份快照。把失败任务脱敏后放进回归样本库记录期望路径、允许变化的字段和必须保持的业务结果。下次修改 Workflow、模型路由或 Skill 时同一份样本可以再次运行帮助团队判断旧故障是否重新出现。落地时先选一条没有真实写入风险的失败任务检查能否在十分钟内找齐输入、流程版本、模型配置、节点状态和外部回执。五类信息能够对应起来再进入隔离回放。找不齐的部分就是当前运行链最需要补的快照能力。GitHubhttps://github.com/zgiai/zgiGiteehttps://gitee.com/zgiai/zgi