一个已经在线的客服 Agent 仍绑定即将停用的旧模型时，可以按四步迁移：在 ZGI 的"模型渠道"中接入并测试替代模型，先给旧配置跑一份基线，再只修改 Agent 草稿中的模型，用同一批客服问题重新测试，结果通过后创建新的发布版本。
场景只看一个会查询产品知识、回答售后问题并在必要时转人工的客服 Agent。最需要防的有三类变化：回复漏掉关键条件、原本应该追问时直接下结论、工具或转人工流程没有按预期触发。只确认新模型能返回一段文字，覆盖不了这些风险。
GitHub 曾把多款 Copilot 模型的停用日定在 2026 年 9 月 1 日，并要求受影响的工作流和集成改用受支持模型。供应方给出截止日后，迁移动作要落到一个仍在运行的应用上；下面这套步骤不需要一次改完整个平台。
概念示意图：一个客服 Agent 从替代渠道验证到新版本发布的五个操作。
先把替代模型渠道跑通
进入 ZGI 的"模型渠道"，点击"添加渠道"。依次选择服务商，填写 API 密钥和 API 基础地址，勾选替代模型，再设置渠道优先级与权重；优先级数字越小，选路顺序越靠前，同一优先级内按权重分流。
保存前先点"检测连接"，确认代表模型、密钥、地址和协议能完成一次真实调用。渠道创建后，再用"模型测试"选择目标模型，查看成功、失败和耗时。这个结果只能证明调用链路可用，客服回复、工具参数和业务判断仍要回到 Agent 测试。
留住线上版本，只改草稿
切换前先打开这个 Agent 的"批量测试"，用当前旧模型执行一次已启用的问题，留下基线批次。测试问题库可以手动录入"问题内容"和"预期结果"，也可以按核心问题、扩展问法、模糊问题和人工介入四类整理；历史测试批次会保留，重新测试不会覆盖旧结果。
基线完成后回到 Agent 编辑页，在"模型"区域把草稿切到替代模型，知识库、工作流、Skills 和工具绑定先保持不变。线上调用继续使用最新发布版本，所以草稿可以单独修改和验证。若新模型不支持旧参数，记录实际调整项，避免把模型变化和配置变化混在一次测试里。
用原问题库重新测试
回到"批量测试"，直接对基线批次点"重新测试"，或新建测试并选择同一组已启用问题。客服场景至少要覆盖正常回答、换一种说法、信息不完整时追问、知识库无答案时转人工；涉及工具的用例，还应在预期结果中写清应否调用以及关键参数。
结果页会汇总通过、不通过和需复核，并保留每道题的响应输出、AI 评分原因和分析建议。连接失败先回到模型渠道检查路由；回答内容漂移再调整 Prompt 或预期结果；工具没有触发时检查模型能力、工具定义和用例输入。付款、退款执行或账号变更等高风险动作仍需人工复核，不能只看 AI 评分。
通过后发布，问题出现时这样退
验收通过后，为当前草稿创建新的发布版本，在版本名称和描述中写明替代模型与测试批次。正式流量开始使用新版本后，继续观察模型服务错误、转人工比例、工具失败和客服抽检结果；一旦出现停止信号，先暂停自动处理或切到另一条已验证的受支持模型路径。
ZGI 的"发布版本"可以预览历史快照，并把选中的版本恢复到当前草稿。这个动作不会自动替换线上版本，恢复后仍需重新发布；如果旧模型已经停用，恢复旧配置也无法让调用恢复。模型网关会先检查授权，并可为同一模型选择最多三条 Provider 路径，在某条调用失败后尝试后续路径，但这种故障切换不能证明两个不同模型的回答和工具行为等价。
今天可以先选一个低风险客服 Agent：跑旧模型基线，接好替代渠道，切草稿，重新测试，再发布一个带说明的新版本。完成这条闭环后，再按同样方法处理其他 Agent，比先做一份全平台迁移清单更容易发现真实问题。
GitHub：github.com/zgiai/zgi
Gitee：gitee.com/zgiai/zgi