扣子平台配置自定义模型供应商 API 时，Base URL、模型 ID 和密钥要怎么填，才能让智能体稳定调用？

扣子平台配置模型供应商 API 的正确顺序是：进入工作空间的模型管理，添加自定义供应商，依次填 Base URL、API Key、模型 ID，连通性测试通过后，再到智能体或工作流节点里选用该模型；任何一步填错都会以调用失败或模型不可选的形式暴露。这套流程的适用前提是供应商对外提供兼容通用协议的接口；私有化部署、协议被改写或只提供自有 SDK 的服务，前三步能填完，但测试会卡在协议解析环节，需要先加适配层。 Base URL 要填到协议版本根路径，不要填完整的对话补全地址。原因是扣子会在你填的地址后自行拼接具体端点，多写一段就会变成重复路径而返回 404；常见做法是填到以 /v1 结尾的根地址，再用 curl 打一次模型列表接口，确认路径和鉴权都通，然后才粘进平台。带端口、带二级路径的自建服务尤其要核对，反向代理常把路径前缀改掉。 给扣子用的 API Key 应当单独签发，不要复用后台主密钥。调试期会产生大量无效请求和重试，独立密钥可以绑定额度上限和来源白名单，出问题只影响这一条链路，也便于按工作空间核算消耗；密钥轮换时只需在供应商侧新增一把，把旧钥保留一段时间观察是否还有调用，再停用。 模型 ID 要逐字复制供应商模型清单里的名称，大小写和版本后缀都不能凭记忆写。填错的表现通常是请求直接返回模型不存在，而不是返回内容为空，排查时先比对清单再怀疑网络；带日期版本号的服务，还要确认所选版本是否已下线，部分供应商会保留旧版一段时间后静默停用。 不支持流式输出的供应商，会让默认开启流式的对话节点表现为有请求、无返回。扣子的对话节点通常按流式接收增量内容，供应商若只返回整包响应，前端就会一直等不到首段文本；解决办法是在供应商侧确认支持流式事件，或在工作流节点里关闭流式开关，代价是首字延迟变长。 需要智能体自主调用工具的场景，供应商必须支持函数调用能力，这是硬门槛。查订单、查库存、转人工这类动作，依赖模型输出结构化的工具调用指令，再由平台执行；供应商不支持时，可行的替代是把这些动作改成工作流里的显式检索节点和条件分支，由流程而不是模型决定何时触发，稳定性更高但灵活性下降。 多轮对话能否稳定，取决于模型上下文窗口是否大于系统提示词、知识库召回片段和历史轮次的总和。总量超出窗口后，平台会按策略截断，表现就是答非所问或忘记前几轮说过的条件；做法是给保留的历史轮次设上限，长会话做摘要压缩，知识库召回条数控制在必要范围，把省下来的窗口留给当前问题。 连通性测试通过并不等于业务可用，它只验证鉴权与网络通断。上线前应当用一批真实问题跑一轮压测，记录首段响应时间、完整响应时间、错误码分布，把限流错误和服务器错误分开统计；推理型模型首包常在数秒以上，超时时间要按实测值设定，设得过短会把正常请求误判为失败并触发无效重试。 生产环境的智能体建议配置备用模型，而不是只挂一个供应商。连续出现限流或超时时按阈值切换到备用模型，可以把一次故障的影响控制在单轮对话内；切换逻辑放在工作流前置判断更划算，否则每次请求都要先走一次失败调用再重试，延迟和成本都会翻倍。 成本由输入 token 和输出 token 按各自单价累加，长系统提示词和知识库片段会显著抬高输入侧开销。可压缩的地方有三处：固定说明只保留必要约束，召回片段做去重和截断，历史轮次改为摘要；按周统计每千次对话的 token 消耗，再决定是否调整模型档位，比凭感觉换模型更可靠。 密钥不能出现在提示词、变量默认值或对外分享的智能体配置里。工作流发布前要逐项检查变量是否被透出到前端，密钥只保存在平台的密钥管理中；涉及用户个人信息的对话，还要向供应商确认请求数据是否会被用于训练，日志留存周期按内部要求设定，避免调试日志长期堆积。 如果场景只是单轮问答、知识库检索和固定话术，平台内置模型已经够用，自建供应商带来的协议适配与运维成本并不划算。判断是否值得接入，看两条：是否需要内置模型不具备的特定能力，比如超长上下文、特定语种或私有化部署；成本是否已高到需要精细控制。两条都不成立时，把精力放在提示词和知识库质量上回报更高。