ZGI Agent：修改配置时，怎样稳住线上版本？

Agent 上线后，团队仍会调整提示词、模型参数、知识绑定和工作流。想让这些编辑不直接干扰线上任务，需要把修改留在草稿区，验收通过后再生成新的发布快照。每次发布都应留下可复现的配置基线，线上问题才能回到具体版本排查。

ZGI Agent 的发布流程会保存 Agent 配置快照和启用的记忆槽配置。团队可以查看已发布版本，也可以把选定版本恢复到草稿继续检查。面向用户的 Web App 没有可用发布版本时会拒绝执行，避免把尚未完成的草稿直接暴露给业务使用者。

概念示意图：草稿通过检查后形成发布快照，历史版本可恢复到草稿继续验证。

提示词只占 Agent 配置的一部分。在 ZGI 中，一次运行还会组合模型参数、Skill、知识数据集、数据库绑定、Workflow 和记忆。编辑其中任何一项，都可能改变回答内容、工具权限或流程走向。

知识库更新最容易被忽略。Agent 配置没有变化，绑定的数据集却新增了文件，检索结果便可能不同。工作流采用跟随最新版本的策略时，节点和输入契约也可能变化。模型路由调整后，同一问题的表达、工具选择和耗时仍有波动。发布快照提供配置锚点，外部依赖的版本和更新时间还要单独记录。

发现新版本异常时，可以把较早的发布快照恢复到草稿，重新运行回归用例，再决定下一次发布内容。这条路径适合找出提示词、绑定项或模型参数的差异，也能减少人工重建旧配置时的遗漏。

已经发出的通知、创建的工单和写入的数据不会随配置恢复而消失。此类动作需要业务接口提供唯一标识、执行回执和补偿流程。版本管理处理 Agent 配置，外部副作用仍由对应业务系统管理。排查时把 run_id、发布版本和业务回执关联起来，才能确定问题发生在哪一次运行。

回归集不必一开始就很大，先从高频任务和高风险动作中选十到二十条。样本要覆盖正常问题、缺少参数、过期资料、无权限用户、工具失败和人工拒绝。旧版本与新草稿分别运行，逐项比较最终答案、引用来源、工具参数、流程分支和失败位置。

新版本通过后再发布，并记录修改人、修改时间、依赖版本和已知差异。出现异常时，先找到对应发布快照，再检查当时使用的知识版本、Workflow 策略和模型路由。排查范围会沿着版本记录逐步缩小，不会把所有变化都归到一句"模型不稳定"。

准备调整线上 Agent 时，可以先做一个小动作：从现有业务问题中挑十条，保存当前版本的答案与执行记录，再改一项配置。新草稿跑完同一组问题后，团队很快就能看清这次修改影响了哪里，也能决定它是否适合发布。