同一句“整理项目交付流程”，Agent 两次给出的步骤可能不同。可以先比较两次运行的实际输入、检索资料、工具返回和模型设置，再核对差异是否改变了必需步骤或责任人。即使条件相同，生成的措辞与组织顺序也可能变化；关键事实需要回到资料中确认。

ZGI 是可自托管的 Agent Runtime，业务团队可以在工作空间组织模型、知识与工作流，并查看运行状态和步骤。围绕两次运行建立对比时，团队还需要决定哪些资料版本、输入条件和结果值得留存，才能为后续排查提供依据。

先看两次运行拿到了什么

用户看到的提问相同，模型接收到的内容未必完全相同，因为任务指令、此前对话和附加文件都可能参与本次运行。例如一次指定了“内部交付”，另一次保留了前文中的“对外交付”，两份流程说明自然可能侧重不同。排查时应检查实际传入了什么，而非只比较最后一句问题。

再看引用的资料是否一致。同一份手册可能被更新过。两次检索也可能命中不同段落，或者其中一次没有取得相关内容。对照文件来源、版本、检索范围和实际使用的片段，才能分清资料发生了变化，还是同一份资料被不同方式摘取。

如果 Agent 还查询业务系统，工具返回也会影响答案。查询的时间范围、项目编号和访问权限不一致，都可能改变可用信息；一次查询失败，另一次成功，模型收到的上下文也不同。需要留意空结果与调用失败的区别，不能把未查到的信息直接当作不存在。

模型和生成设置也值得记录：两次运行可能调用了不同模型版本，或使用了不同的生成参数，输出风格与选择的内容可能随之变化。部分模型支持固定随机种子来提高重复性，但这不能保证每次输出完全一致，更不能保证内容正确。

有时记录只保留了最终回答，没有留下当时使用的资料版本或工具结果。这种情况下可以先标出无法比较的部分，再用可访问的固定资料重新测试；补做的测试用于观察当前行为，不能充当过去那次运行的完整记录。留存原始内容前，应按团队的数据管理要求控制范围和访问权限。

再判断差异会不会影响使用

两份交付说明的语句不同，不一定代表任务出了问题。只要必要步骤、适用范围和责任人相同，先后顺序或表达方式的变化可能可以接受。团队应事先写清哪些内容必须一致，哪些可以保留表达空间，避免把逐字相同当成唯一标准。

如果一份说明遗漏了必要的交付确认，或把负责部门写成了另一个部门，就要回查对应资料。比较两份回答本身无法确定哪一份正确。应检查来源是否适用于该项目，以及答案有没有准确引用其中的要求。资料缺失或版本冲突时，把问题标为待确认，交给了解业务规则的人处理。

为了查清变化，可以选定同一任务和可复核的资料版本，保留模型版本、参数与验收项，然后多次运行。需要比较某项改动时，尽量只调整一个因素，再观察多次结果，而非根据两次输出就断定原因。重新测试涉及查询或发送等工具时，应使用只读或测试环境，避免重复触发真实业务动作。

验收应落到实际用途。项目交付流程说明可以核对是否覆盖所需材料、交接步骤和对应责任人，再逐项关联资料来源。若两份回答只是把同一要求写得详略不同，可以按使用场景选择；若出现资料不支持的新增要求，应先核实，不要直接加入流程。

比较记录不必默认保存所有原文。根据团队规则，可以记录任务标识、资料版本、调用结果和差异结论；需要保留详细内容时，再确定保存范围与查看权限。版本号或摘要有助于识别资料，但如果没有保留当时的内容，之后未必能完整重现那次运行。

GitHub：https://github.com/zgiai/zgi

Gitee：https://gitee.com/zgiai/zgi