扣子的智能体要换模型供应商该在哪一层改，为什么改完线上客服还是旧模型在答？

扣子平台切换模型供应商通道是分三层的，并不存在一个一键全局开关：账号级在模型管理里决定开通了哪些供应商通道，智能体级在编排页的模型选择处决定当前对话用哪一家，工作流级则在每个大模型节点上单独绑定；三层作用域不同，改错层就会出现「配置明明改了、对话没变」。这条规则适用于用扣子搭客服接待、知识库问答和自动化流程的团队；只改模型名而不重新发布到线上渠道，对外服务仍是旧版本在跑。 账号级通道决定「有哪些可选」，但不决定「现在用哪个」。在模型管理里，平台列出已支持的自研模型与第三方供应商模型，需要哪一家就先完成开通与授权，智能体编辑页的模型下拉里才会出现对应条目；如果下拉里找不到某个供应商，八成不是编辑器的问题，而是账号层没有开通或当前角色没有模型权限。具体可开通的供应商清单与权限划分，以官方说明为准。 智能体级切换是客服场景里最常动的一层。打开智能体编排页，在模型配置处先选供应商、再选具体模型版本，保存后只是草稿态变更，还要把智能体重新发布到网站、公众号、API 等对应渠道，线上才真正换过去；很多「换了没反应」的案例，都是草稿已改、发布没做，或者发布到了 A 渠道而线上跑的是 B 渠道。 工作流节点级是唯一能做到「同一个流程混用多家」的地方。每个大模型节点都带独立的模型选择，可以前段用轻量模型做意图分类和槽位抽取，后段用强模型生成对外回复，从而在不牺牲接待质量的前提下压成本；代价是节点越多，跨供应商的提示词兼容性问题越集中，需要在测试阶段逐个节点对齐。 平台没有上架的模型，靠自定义通道补。扣子专业版支持以 OpenAI 兼容协议添加自定义模型通道，需要填服务地址、密钥、模型名称与上下文长度等基础参数，填错模型名或把上下文长度写得比真实上限更大，表现是调用报错或长对话中途截断；这类接入能力与参数项在不同版本存在差异，以官方说明为准。 切换模型后率先出问题的往往不是回答质量，而是工具调用。插件、函数调用、结构化输出这些能力，各家模型的实现成熟度不同，原来能稳定触发的工具在新模型上可能不触发、参数格式对不上，或者把该调用工具的场景直接改写成自然语言回复；上线前应把客服最关键的几个动作（查订单、转人工、提交工单）逐条回归，而不是只看闲聊效果。 知识库问答的召回环节不随对话模型切换而改变。文档切分与向量化用的是独立的嵌入模型配置，换对话模型只改变「拿到召回片段后怎么组织回答」，所以会出现「答案风格变了、但答非所问依旧」的情况；如果问题本身是召回不准，要先动嵌入模型与切分策略，且重建索引后旧向量不会自动迁移。 系统提示词要按目标模型重写，不能原样搬。不同供应商对系统指令与用户消息的权重处理不同，同样一段角色设定、话术边界和拒答规则，在 A 模型上约束得住，在 B 模型上可能被用户一句话绕开；客服场景涉及价格、售后承诺、合规话术，换模型时应把「禁止承诺的内容」单独抽成一节强约束，并配一组对抗性问法验证。 上线顺序建议是草稿态对比、测试渠道验证、小流量灰度、再全量。同一条客服话术准备两套模型配置，用同一批真实问题各跑一遍，比较工具触发率、答非所问比例、平均响应时延和单次对话 token 消耗；灰度阶段保留一键切回旧模型的路径，因为供应商侧的限流、超时和地域网络抖动，往往在上量之后才暴露。 计费口径会随供应商一起变，不能只看单价。多数模型按输入与输出 token 分别计价，长系统提示词与知识库召回片段都计入输入侧，同一段客服对话换一家模型成本可能差出数倍；若平台侧有缓存命中机制，重复的开场白与固定话术能被复用，切换模型后缓存是否继续生效需要单独确认，采购前按真实对话样本估算比按官网单价拍脑袋可靠。 排障时可以按固定顺序看四件事。下拉里没有供应商，查账号开通与角色权限；改了不生效，查是否重新发布、发布到了哪个渠道、该渠道是否绑定了另一个智能体；偶发超时与报错，查供应商侧并发配额与网络；回答质量突然下滑，查工具调用是否失效、提示词是否需要针对新模型调整。按这个顺序排查，比反复重配模型省时间。 这套分层切换并非对所有团队都适用。使用受限版本、仅能调用平台内置模型的账号，无法自行接入外部供应商通道；对数据存放地域、日志留存和内容审核有硬性要求的业务，还需要在接入前确认该通道的合规边界与数据处理方式。涉及具体版本能力、可接入供应商范围与参数上限，均以官方说明为准，不要以他人截图里的配置项当作通用前提。