Agent 上线后，团队仍会调整提示词、模型参数、知识绑定和工作流。想让这些编辑不直接干扰线上任务，需要把修改留在草稿区，验收通过后再生成新的发布快照。每次发布都应留下可复现的配置基线，线上问题才能回到具体版本排查。
ZGI Agent 的发布流程会保存 Agent 配置快照和启用的记忆槽配置。团队可以查看已发布版本，也可以把选定版本恢复到草稿继续检查。面向用户的 Web App 没有可用发布版本时会拒绝执行，避免把尚未完成的草稿直接暴露给业务使用者。
概念示意图：草稿通过检查后形成发布快照，历史版本可恢复到草稿继续验证。
一次修改会牵动哪些运行依赖
提示词只占 Agent 配置的一部分。在 ZGI 中，一次运行还会组合模型参数、Skill、知识数据集、数据库绑定、Workflow 和记忆。编辑其中任何一项，都可能改变回答内容、工具权限或流程走向。
知识库更新最容易被忽略。Agent 配置没有变化，绑定的数据集却新增了文件，检索结果便可能不同。工作流采用跟随最新版本的策略时，节点和输入契约也可能变化。模型路由调整后，同一问题的表达、工具选择和耗时仍有波动。发布快照提供配置锚点，外部依赖的版本和更新时间还要单独记录。
| 发布检查项 | 需要保留的内容 | 验收方式 |
|---|---|---|
| 指令与模型 | 系统提示、模型参数、路由范围 | 固定问题对照旧版本 |
| Skill 与 Workflow | 启用项、版本策略、输入契约 | 运行成功与失败样本 |
| 知识 | 数据集绑定、资料版本、更新时间 | 核对引用片段与文件版本 |
| 数据库 | 可读表、可写表、账号权限 | 分别执行读取和越权用例 |
| 记忆 | 启用槽位、适用对象、长度限制 | 跨用户和跨会话检查 |
恢复旧配置解决不了已经发生的动作
发现新版本异常时，可以把较早的发布快照恢复到草稿，重新运行回归用例，再决定下一次发布内容。这条路径适合找出提示词、绑定项或模型参数的差异，也能减少人工重建旧配置时的遗漏。
已经发出的通知、创建的工单和写入的数据不会随配置恢复而消失。此类动作需要业务接口提供唯一标识、执行回执和补偿流程。版本管理处理 Agent 配置，外部副作用仍由对应业务系统管理。排查时把 run_id、发布版本和业务回执关联起来，才能确定问题发生在哪一次运行。
用固定用例守住发布入口
回归集不必一开始就很大，先从高频任务和高风险动作中选十到二十条。样本要覆盖正常问题、缺少参数、过期资料、无权限用户、工具失败和人工拒绝。旧版本与新草稿分别运行，逐项比较最终答案、引用来源、工具参数、流程分支和失败位置。
新版本通过后再发布，并记录修改人、修改时间、依赖版本和已知差异。出现异常时，先找到对应发布快照，再检查当时使用的知识版本、Workflow 策略和模型路由。排查范围会沿着版本记录逐步缩小，不会把所有变化都归到一句"模型不稳定"。
准备调整线上 Agent 时，可以先做一个小动作：从现有业务问题中挑十条，保存当前版本的答案与执行记录，再改一项配置。新草稿跑完同一组问题后，团队很快就能看清这次修改影响了哪里，也能决定它是否适合发布。
GitHub：https://github.com/zgiai/zgi