Agent 的配置变化要经过保存、测试和发布，线上入口读取的配置范围也需要单独确认。开发者在草稿里改了模型、知识或 Workflow，测试页面可以立即看到变化；已发布入口仍可能继续使用上一版。两边表现不同，并不一定是模型随机性造成的。
概念示意图：配置从草稿经过测试和发布，最终由线上入口读取对应版本。
先确认修改发生在哪个版本
排查时记录 Agent 标识、Workflow 版本、模型配置、知识绑定和修改时间。随后分别在测试入口与已发布入口执行同一条任务，保存输入、调用工具、引用资料和最终结果。只比较回答文字，很难定位到底是模型、知识还是流程版本不同。
已发布入口有自己的读取范围
企业常见网页、内部应用、API 和计划任务等多个入口。它们可能共用 Agent 名称，却使用不同的发布版本、身份和输入契约。一个入口已经更新，另一个入口仍指向旧配置，就会出现"只有某个渠道没变化"。
| 检查对象 | 需要确认 | 典型差异 |
|---|---|---|
| 草稿配置 | 最近修改是否保存 | 测试页能看到新规则 |
| 已发布版本 | 发布动作与版本标识 | 线上仍使用上一版 |
| 入口绑定 | Web、API 或内部应用读取哪版 | 不同入口表现不一致 |
| 会话记录 | 是否延续旧对话和状态 | 新规则被旧上下文干扰 |
会话也可能保留旧现场
同一个会话包含历史消息、任务状态和前一轮工具结果。配置发布后，旧会话继续运行时，模型仍可能看到此前的上下文。测试新版本时，建议新建会话，再用相同输入复测；新会话正确、旧会话异常，排查重点就落在会话迁移和状态恢复。
ZGI 运行记录可以帮助对版本
ZGI 的 Workflow 运行记录保留版本、节点状态、输入输出和事件信息。团队可以用它对照一次测试运行和一次线上运行：两次是否读取了同一版 Workflow，模型与知识绑定是否一致，工具参数和节点路径有没有变化。
运行记录适合帮助定位差异，不能替代发布流程本身。企业仍需要明确谁负责发布、哪些样本必须通过、发现问题后如何暂停入口，以及旧版本保留多久。涉及外部写入的 Agent，还要在发布前验证权限、审批和回执。
发布前做一次最小对照
准备三条固定任务：一条正常流程、一条触发分支的流程、一条会调用外部工具的流程。发布前后分别从目标入口运行，比较版本标识、知识引用、工具参数、节点状态和业务结果。出现差异时，先确定发生在哪一层，再修改对应配置。
当草稿、已发布版本、入口绑定和会话现场都能被单独核对，线上"还是旧的"就有了明确的排查路线。ZGI 负责把 Agent、Workflow 和运行记录放进同一条链路，团队仍需为自己的发布节奏和验收门槛作出安排。
版本对照也应覆盖资源变化。模型供应商、知识库文件、Skill 依赖和外部工具契约都可能在发布后发生变化。把这些依赖与版本标识一起写入验收记录，出现差异时才能判断是发布遗漏，还是运行环境已经改变。