Cherry Studio 怎么批量导入多个模型服务商的 API 密钥，有没有不用逐条手填的办法？

Cherry Studio 不提供一次性粘贴多条密钥的批量导入入口，能称得上批量的只有三条路：整体替换本机配置目录、用设置里的备份与恢复迁移、复制已跑通的服务商条目再改地址和密钥；这套做法成立的唯一前提是这些服务商都遵循同一套 OpenAI 兼容协议，如果目标是在客户端内部做多密钥轮询、额度分摊或失败自动切换，那不在 Cherry Studio 的职责范围内。 密钥和服务商地址保存在本机用户目录的应用数据里，请求由客户端从本机直连各家接口，不经过任何中间账号体系。批量操作前先找到这份数据：Windows 一般在 %APPDATA% 下的应用目录，macOS 一般在 ~/Library/Application Support 下的同名目录，具体路径以官方文档和实际安装位置为准。动手前把整个目录复制一份到别处，这是唯一能在改坏之后十分钟内恢复的手段。 真正稳的批量导入顺序是“先做一条样板，再按样板复制”，而不是先把十条密钥全贴进去再一起排查。原因很直接：地址、密钥、模型 ID 三处只要错一个，这条条目就连不通，十条一起错时你无法判断是格式问题还是密钥问题。做法是先把第一个服务商填完，手动拉一次模型列表，再发一句最短的测试对话确认返回正常。 界面内的“复制服务商”适合同一协议、不同地址的多家上游，这是最接近批量导入的原生操作。复制出来的条目要改三处：显示名称、接口地址、密钥，改完必须重新拉取模型列表，因为不同上游暴露的模型 ID 并不一致，沿用旧列表会出现选得到却调不通的情况。名称建议写成“用途-上游-序号”，后期排查时比看密钥前缀快得多。 同一家服务商持有多把密钥时，正确做法是建多个条目分别命名，而不是指望一个条目里塞多条密钥。客户端的一个服务商条目通常只对应一组地址与密钥，把多把密钥堆在同一个字段里只会得到鉴权失败。这种多条目方式换来的是手动切换，不带来自动分流，选型时要先接受这个前提。 设置里的备份与恢复是官方支持的批量迁移路径，适合换机和团队统一初始配置。在一台已经配好的机器上导出，在目标机器导入，服务商列表、模型选择等配置会一并带过去。代价是备份文件里通常含有明文密钥，因此这份文件不能当普通文档在群里传，导入完成后应立即删除临时副本。 直接编辑本地配置文件属于非官方路径，能用但要做好被版本升级打断的准备。不同版本之间配置文件的结构和字段名可能变化，跨版本复制旧文件会出现条目显示异常或密钥读不出来的情况。可行的做法是关闭应用后再改，改完启动进入设置逐条核对，升级大版本后重新按界面流程校验一遍，不要默认旧文件一定兼容。 批量导入后的验收标准不是“条目保存成功”，而是“每个条目都能拉到模型列表并完成一次最小请求”。保存成功只说明字段写进去了，不代表地址可达、密钥有效、模型 ID 存在。逐条点开模型列表看一眼，再各发一句测试对话，把失败的条目单独拎出来处理，比整体推倒重来省时间。 最常见的四个坑集中在地址和网络层：接口地址结尾是否带 /v1，各上游要求并不统一；模型 ID 的大小写和别名是否与服务商文档一致；本机系统代理或公司网络是否拦截了直连请求；流式输出开关在个别上游上会引发异常。这四项与密钥无关，但在批量导入时最容易被误判成密钥填错，排查时先验地址再验密钥。 安全边界要提前想清楚：把多把密钥集中在一台机器上，等于把多份权限集中在一个失窃点。可行的做法是给客户端单独申请带额度的子密钥而不是主密钥，备份文件不共享、不上传网盘，换机或人员变动时在服务商后台直接撤销旧密钥。客户端只负责发起请求，密钥的签发与回收仍要在上游控制台完成。 如果真实需求是“多把密钥自动轮询、按额度分摊、失败自动切下一把”，那就不该在 Cherry Studio 里找答案。这类调度属于网关或中转层的职责，客户端的一个条目对应一个固定地址，本身不做密钥池管理。常见替代方案是在前面加一层兼容接口的网关，客户端只填网关地址和一把访问密钥，再由网关侧配置多把上游密钥和切换策略。 判断清单可以压缩成三句：只需要几条固定配置、上游都兼容同一协议，就用“样板条目加复制”或备份恢复，十分钟内能完成；需要几十条且经常变动，就考虑维护一份配置目录模板，换机时整体替换；需要轮询、分摊、自动切换，就离开客户端层面，交给前置网关处理。把需求先归到这三类，再决定要不要动手改本机文件。