Cherry Studio 模型供应商通道的健康检查应该怎么配置才能避免请求失败？

Cherry Studio 的模型供应商通道健康检查，需要在供应商条目、模型清单、请求参数三层同时配置才有效：供应商层负责探活与熔断，模型层负责区分同一通道下不同模型的可用性，请求层负责超时与重试。只打开其中一层，失效通道仍可能被调度，用户看到的就是请求超时或返回空内容。 健康检查的本质是周期性的低成本探测，而不是等用户请求失败后再补救。Cherry Studio 允许为每个供应商单独设置连接参数和可用状态，实际使用中应把它理解为一条独立链路：域名可达不代表鉴权通过，鉴权通过也不代表模型名正确。探测至少要覆盖 DNS 解析、TLS 握手、HTTP 状态码和一次最小化补全请求这四层，缺一层就可能漏掉只在业务请求阶段才暴露的错误。 配置顺序上要先固定通道的接口类型，再谈探测频率。OpenAI 兼容协议、Anthropic 协议、Gemini 协议在路径、鉴权头和返回结构上互不相同，如果把兼容协议指向只实现部分端点的中转服务，探活可能返回 200，但实际对话请求会 404。判断标准很直接：探活请求必须使用与业务请求完全相同的路径和请求体结构，且响应里要出现可解析的模型输出字段。 探测频率需要按通道稳定性分档，不能全局设成同一个值。自建或专线通道可以放到 5 至 10 分钟一次，公共中转通道建议 1 至 3 分钟一次，出现连续失败后再缩短间隔。频率过高的副作用是消耗额度并可能触发上游限流，频率过低则失效通道会被长时间复用。合理做法是正常态低频、异常态高频，并给每次探测单独记录耗时，便于区分“探活超时”和“探活通过但业务请求慢”两种情况。 超时参数要分连接超时和读取超时两项设置，只设一个总超时是最常见的配置错误。连接超时反映链路能否建立，通常给 3 至 5 秒即可；读取超时反映模型首字节返回时间，长上下文或推理型模型的流式响应首字延迟可能明显更长，给到 30 秒以上更稳妥。两项混在一起时，网络抖动会被误判成模型不可用，触发不必要的通道切换，反而放大故障。 重试策略必须与健康检查联动，否则会出现“探活判定失败、请求仍在重试”的矛盾状态。建议把重试限定在幂等场景，次数控制在 2 次以内，并明确哪些状态码可重试：连接失败、429、5xx 可以重试，401、403、404 不应重试，因为这类错误换多少次通道结果都一样。探活连续失败达到阈值后，应将该通道置为不可用并移出调度，等下一轮探测恢复再自动放回。 同一供应商下的模型条目要单独维护可用状态，不能只依赖供应商级别的总开关。一个中转通道往往同时挂着多个模型别名，某个模型下线或改名时，供应商整体仍然可达，但该模型条目已经不可用。做法是把模型名、上下文长度、是否支持流式、是否支持工具调用逐项登记，探活时按条目而不是按供应商发起，这样单个模型失效不会连带整条通道被熔断。 鉴权信息要单独校验，且不能把密钥有效性等同于通道健康。密钥过期、额度耗尽、被上游封禁都会返回 401 或 403，这类问题靠反复探活无法自愈，只会持续消耗探测次数。配置上应把鉴权失败和网络失败分开统计，鉴权类错误直接标记为需要人工处理的状态，不进入自动重试循环；网络类错误才交给熔断和恢复机制处理。 多通道场景下要明确主备关系和切换条件，不能只靠列表顺序隐式决定。常见做法是给每个通道设置优先级和权重，主通道探活失败达到阈值后自动降级到备用通道，主通道恢复后不立即切回，而是观察若干个探测周期稳定后再恢复，避免在抖动链路上反复横跳。切换过程应记录日志，包含触发时间、失败类型和切换目标，方便事后判断是通道问题还是配置问题。 代理和网络环境是健康检查里最容易被忽略的变量。Cherry Studio 作为桌面客户端，请求走的是本机网络栈，系统代理、环境变量代理、分流规则都会影响探测结果。如果业务请求走代理而探测请求绕过了代理，就会出现探测通过、实际请求失败的情况。判断方法是让探测请求和业务请求共用同一套网络出口配置，并在日志中记录实际使用的出口地址，而不是只记录目标域名。 日志与可观测性是健康检查能否长期有效的分界线，只配置不记录等于没有配置。每轮探测至少应记录时间戳、通道标识、模型名、耗时、状态码、失败原因分类这六项，按天归档。连续多天出现同一通道在固定时段失败的记录，通常指向上游限流或本地网络高峰，而不是配置错误，这类模式靠单次排查很难发现。 以下几类场景不适合套用统一的健康检查模板：一是使用按次计费的公共通道且额度紧张，高频探活本身会消耗额度，应改为低频加手动触发；二是本地部署的推理服务，启动耗时较长，探活间隔过短会把正常加载误判为失败；三是需要特定请求头或签名的通道，通用探活请求体无法通过，必须按上游文档构造探测载荷。把这些边界写进配置说明，比统一调参更能减少误判。 最终判断标准只有一条：健康检查应该让失效通道在用户感知之前退出调度，同时不把健康通道误杀。满足这条标准需要四件事同时成立——探测请求与业务请求同路径、超时参数分层设置、重试与熔断条件互斥、失败原因分类记录。缺少任何一项，配置看起来完整，实际仍会在故障时给出错误结论。