ZGI 运行日志：还原任务与节点状态

运行日志需要回答四个问题：哪一次任务出了问题，执行停在哪个节点，该节点收到了什么，随后留下了什么结果。只保存最终报错，团队很难判断问题来自上游输入、当前节点、权限限制还是外部接口。任务级记录用于缩小范围，节点级记录用于重建执行顺序。

ZGI 为工作流运行和节点执行提供分层记录。任务层可以查看工作流、状态、耗时和输出；进入某次运行后，还能按节点检查节点标识、类型、顺序、前序节点、状态、耗时、完成时间、错误以及可用的输入输出。排查从一次运行逐步落到一个节点，信息不会只停在最终回答上。

这类记录对长流程尤其重要。一个材料处理任务可能依次经过文件读取、知识检索、模型整理、条件判断和数据库写入。页面只提示"执行失败"时，每一段都有嫌疑；节点状态连起来后，可以先找到第一个异常节点，再向前核对输入，向后确认哪些动作尚未发生。

任务记录先确定影响范围

任务级记录适合回答"哪次运行需要处理"。状态可以区分进行中、完成和失败，耗时帮助发现明显卡顿，工作流标识用于确认调用了哪条流程，输出则能判断任务是否已经产生可用结果。批量任务同时报错时，先按时间、状态和工作流范围筛选，比从大量节点日志里逐条翻找更快。

任务记录还要和业务回执一起看。工作流显示失败，外部系统可能已经收到请求；工作流显示完成，写入的数据也可能未通过业务校验。对数据库写入、通知和支付类动作，应保存可查询的业务标识，在重试前确认外部结果，避免重复执行。

排查节点时，先找到第一个状态异常或耗时明显偏离的节点。随后查看前序节点的输出能否满足当前输入，字段名、数据类型和空值是否符合约定。当前节点有明确错误时，再结合节点类型处理：检索节点检查候选与权限过滤，模型节点检查输入长度和模型调用，HTTP 节点检查响应码与超时，写入节点检查绑定范围和业务校验。

错误发生后的节点也要看。它们可能处于未执行、跳过或等待状态，能够帮助判断影响范围。若下游节点已经执行，重跑策略需要考虑副作用；若流程停在人工审批或问答节点，等待状态属于正常控制路径，不能直接归类为故障。

ZGI 的节点记录保留前序节点标识、执行顺序和可用的过程数据，适合沿链路回看。日志可以提供排查证据，根因仍需结合具体节点、外部系统回执和部署环境确认。自动诊断给出的解释也应保留为排查线索，不直接替代复现。

输入和输出可能带有合同文本、用户信息、数据库字段或工具返回。运行日志的查看权限需要跟随工作区角色和业务范围，展示页面对密钥、令牌与敏感字段做遮盖。留存周期也应按排障和审计需求设置，避免长期保存所有完整正文。

上线前可以主动注入三类故障：让一个接口超时，提交一份缺少字段的输入，再使用无权访问资源的账号执行。逐次检查任务状态、首个异常节点、错误信息和下游执行情况。日志能够回答这几项，团队才具备可重复的排查入口。