Cherry Studio 里模型供应商的通道健康检查该怎么配置，才能让「检查通过」等于「真的能对话」？

Cherry Studio 的模型供应商通道健康检查，本质是把「地址可达、鉴权有效、模型可调用」三件事分开验证；只点一次检查拿到通过结果，只说明地址格式和密钥格式没写错，不代表流式输出、长上下文和高并发场景下通道仍然可用。适用对象是自己填 API 地址和密钥的第三方供应商条目，不适用于客户端内置、无需填写密钥的官方直连通道。 健康检查要按三层拆开看，而不是当成一个开关。网络层看 DNS 解析、TLS 握手和代理是否放行；鉴权层看返回的是 401 还是 403；模型层看模型列表接口和对话补全接口是否同时可用。三层里任何一层失败，检查结果都会表现为失败，但排查方向完全不同，先分层再动手能省掉大半无效尝试。 API 地址的写法是最高频的失败原因。多数兼容协议的供应商要求地址写到版本前缀为止，不带结尾斜杠，也不要把对话接口的完整路径粘进地址框；把完整路径填进去，检查通常直接返回 404，而密钥其实是对的。配置时先只填到域名加版本号这一级，再交给检查去验证。 鉴权头与供应商类型不匹配，会被误判成密钥失效。同样一串密钥，按 Bearer 方式放在 Authorization 头里能通过，按自定义头方式发送就可能返回 401；反过来选错供应商类型，正确的密钥也过不了检查。碰到 401 先核对供应商类型和鉴权方式，再去怀疑密钥本身是否过期或被禁用。 模型列表能拉取成功，不等于目标模型能调用。拉列表验证的只是列表类接口，对话接口可能因为账号权限、额度耗尽或地区限制而失败，所以拿到列表之后必须对准备实际使用的那个模型单独发一次最小请求。把检查范围缩小到「我接下来真要用的模型」，比验证整个列表有意义得多。 检查请求应该用最小补全，而不是完整对话。健康检查只需要判断通道是否通，把输入压到几个 token、输出上限压到最小，可以避免长上下文带来的首字延迟把正常通道误判为超时。超时阈值也要区分流式与非流式：非流式的短请求用默认值通常够用，流式长回答则要单独设更宽的等待窗口。 报错码要整理成一张对照表再动手排查。401 指向密钥无效或鉴权方式错误，403 指向权限或地区限制，404 指向路径写错或模型名不存在，429 指向调用频率或额度触顶，5xx 与连接超时则属于上游不稳定。这五类原因的处理动作完全不同，混在一起猜只会反复改配置。 检查通过但对话失败，问题多半出在参数与解析层。输出上限超过模型允许值、温度参数越界、返回体不是标准的兼容结构、流式分块解析异常，都会出现通道显示健康、实际回答为空或直接报错的情况。遇到这种现象不要再改地址和密钥，转去核对请求参数和响应的数据结构。 多通道冗余要落到配置层，而不是靠记忆切换。同一供应商配两条不同接入地址，或者主备两家供应商，把常用模型名做一次重定向，一条通道检查失败时按顺序切到另一条，比事后逐条排查更省时间。冗余的价值在于切换动作是预先写好的，而不是故障发生时才临时找备用密钥。 健康检查应当变成定时巡检，而不是装好之后的仪式。把检查频率、失败重试次数、判定为故障的连续失败次数固定下来，并记录每次失败的响应码与耗时，才能把偶发抖动和真实故障区分开。只看单次结果，很容易把上游一次瞬时超时当成永久故障，反复修改本来正确的配置。 密钥与日志的边界要在配置阶段就定好。巡检记录只保留响应码、耗时、模型名和请求时间，不保留明文密钥；桌面端本地保存的密钥不要随配置文件一起导出外发。通道检查本身会携带密钥发起请求，所以检查动作的日志留存范围要和密钥管理策略一起考虑。 不是所有供应商条目都适用同一套检查逻辑。本地部署的无密钥推理服务只需验证端口是否监听、模型是否加载，鉴权环节可以跳过；走企业内网代理的通道要先确认代理放行目标域名，否则检查会一直超时，而密钥和模型名都是对的。区分这两类场景，比把检查阈值调宽更有效。