一个工作流没有产出结果时，直接重跑往往只会得到另一个失败。更有效的排查方式，是把问题拆成输入、知识、模型、工具和人工确认五层，逐层确认哪一层出现异常。用 ZGI 管理 Agent Runtime 和工作流时，可以保留每次运行的节点状态，帮助团队定位失败点。
先看失败发生在哪一步
以"每晚整理客服工单"为例，流程包含读取文件、去重分类、生成摘要和写回知识资产。若结果为空，先确认输入文件是否真的进入流程；若分类完成但摘要失败，再检查模型输入长度和输出格式；若摘要正常却没有写回，检查目标知识资产的权限和节点配置。
建立可读的运行记录
每个节点至少记录四项：输入是否到达、使用的知识范围、执行状态和输出是否符合格式。失败信息不要只写"运行失败"，而要标记为资料缺失、权限不足、模型返回异常、工具连接失败或人工确认未完成。这样下一次处理时，可以直接从对应层开始。
可以给工作流增加一条约束：
每完成一个节点，输出状态、使用的输入和下一步条件。若节点失败，停止后续步骤，说明失败类型和建议检查项，不要生成看似完整的最终结果。
用最小输入复现
保留一份只有三条工单的测试资料，分别覆盖正常文本、空字段和冲突内容。先用最小输入运行，再逐步加入真实数据。如果最小输入正常，问题可能来自文件规模、字段格式或权限范围；如果最小输入也失败，再检查节点指令、模型配置和工具连接。
ZGI 在排查中的位置
ZGI 把知识资产、Skills、模型接入、Agent Runtime 和工作流放在同一工作区中，适合把每个节点的输入、执行和人工确认串起来。模型网关可以集中管理可用模型，但具体凭证、配额、工具连接和失败重试仍取决于部署配置。不要把一次成功重跑当成问题已经解决。
修复后怎样验收
修复一个节点后，先运行固定测试集，再运行一小批真实数据，最后检查写回结果。记录变更的节点、模型、知识版本和权限配置。若结果恢复，仍要保留失败样本，确认同类问题不会再次被吞掉。
工作流的可靠性来自可观察的中间状态。让每一步都能说明自己做了什么、为什么停下，团队才有机会持续改进。
GitHub：https://github.com/zgiai/zgi