扣子平台怎么切换不同模型供应商通道，预置模型和自定义接入分别在哪里改、发布后要不要重新上线？

扣子切换模型供应商通道分两件事：在编排页的模型下拉框里换用哪家模型，以及把外部供应商接进来后在模型管理里添加并选用自定义模型；前者改完必须重新发布版本才会在线上生效，草稿状态的改动不影响已经发布的智能体。 扣子里的模型通道实际分两类，预置通道和自定义接入通道，两者的计费主体和限流规则完全不同。预置通道由平台统一提供，额度走平台侧的计费体系，供应商的稳定性由平台负责；自定义接入通道需要你自备供应商的 API Key，扣子只负责把请求调度过去，token 消耗记在你自己在供应商那边的账单上，限流和超时也要自己兜。 单个智能体换模型只在编排页的模型配置区操作，不涉及数据迁移，但提示词里针对旧模型写的格式约定要一起改。做法是打开智能体编排页，在模型选择处下拉切换，然后重点检查系统提示词里有没有写死输出格式、函数调用风格或特定的人设描述，换到另一家模型后这些约定经常失效，需要用测试对话逐条验证，尤其是要求输出 JSON 的意图。 工作流里的大模型节点是逐节点独立选模型的，同一个工作流可以前面用轻量模型做意图分类、后面用强模型做最终回复。这样切的好处是成本结构更可控，因为分类节点处理的 token 量往往比生成节点还大；但要注意节点之间传递的变量格式，换模型后如果某个节点不再稳定输出 JSON，后面依赖字段提取的节点会直接报错，排查时优先看节点试运行的原始输出。 把外部供应商接进扣子，走的是模型管理里的自定义模型入口，核心要填四类信息：接入协议、Base URL、API Key 和模型 ID。协议优先选 OpenAI 兼容，Base URL 一般要写到 /v1 这一层，模型 ID 必须用供应商侧真实的调用名而不是控制台里的展示名；此外还要声明最大上下文长度、是否支持 function calling、是否支持视觉输入和流式输出，这几项填错的表现分别是上下文截断、工具节点调用失败、图片理解节点不可用和首字延迟异常。保存前建议先用平台提供的连通性测试跑通一次。 多智能体模式下每个 Agent 可以绑定不同的模型，切换时要同步检查跳转条件，因为节点描述通常写成自然语言，换模型后意图解析的边界会变。稳妥的做法是给每个 Agent 单独指定模型，并把跳转条件写成明确的关键词或结构化判断，避免把路由决策完全交给模型自行理解，否则一个 Agent 换了模型可能连带影响整条对话链路的走向。 知识库的向量化模型和重排模型是另一条独立通道，切换它们会触发已建索引的重建，而不是简单换一个调用地址。原因是不同供应商的向量维度不同，旧索引和新查询向量不在同一个空间里，检索结果会明显跑偏，表现为原来能召回的知识条目突然消失；所以换 Embedding 之前要规划好重建窗口，把知识库重新向量化一遍再上线。 切模型对已经用 API 调用智能体的业务方是透明的，但线上行为不会自动跟随草稿变化，必须发布新版本。发布之后线上跑的是一个发布快照，旧版本仍然保留可用，出问题时可以直接回滚到旧版本继续对外服务；这也是为什么建议在业务低峰期做切换，并始终留一个验证过的旧版本作为兜底。 扣子本身不提供跨供应商的自动故障切换，供应商返回 429 或超时并不会自动落到另一家模型上。要解决这个问题只能自己加两层保护：一是在工作流里对模型节点做异常处理和分支兜底，失败时走规则回复或备用节点；二是在上游放一个统一网关，由网关决定请求落到哪家供应商，扣子这边只填网关地址，这样换供应商不用改平台配置。 切换模型前的对比测试应该用同一批真实对话样本，重点看四项指标：首字延迟、整体成功率、结构化输出的合规率，以及业务口径下的答对率。只比单价没有意义，因为客服场景里一次答错带来的转人工成本和用户流失，远高于两个通道之间的 token 差价；建议固定二三十条覆盖高频意图的用例，两个通道各跑一遍再决定去留。 最常见的几个坑集中在配置和发布两个环节：模型 ID 用了展示名、Base URL 少写路径层、上下文长度填得比供应商实际支持的大、function calling 未勾选导致工具节点失效、视觉模型被接到纯文本节点，以及改完忘记重新发布。这些问题的报错信息往往不指向根因，排查顺序应该是先看模型管理里的连通性测试结果，再看单个节点的试运行输出，最后才怀疑提示词。 稳妥的落地顺序是先在测试空间建两个配置一致、只换模型通道的智能体，用同一批用例跑通后再切生产。这样做的好处是问题范围被限制在模型通道本身，不会和知识库、插件、工作流的改动混在一起，定位成本最低，也方便在切换效果不理想时快速退回原通道。