CCSwitch 多模型接口怎么做健康探测？从探活到降级切换
CCSwitch 同时接入多个 AI 模型接口时，应把健康探测、真实样本、超时阈值和降级条件分开设计，避免只看端口通就误判可用。
真实问题
CCSwitch 的多个 profile 看起来都能保存，但“配置存在”不等于“接口可用”。一次开发者 AI 调用故障中，备用 profile 的 base_url 可以建立连接，健康页也返回 200，真正发送模型请求时却提示模型不存在。团队误以为备用方案已经准备好，切换后反而让排错更慢。
在永沃云枢的 https://ai.jn83.com 相关 AI API 接入场景里，更可靠的做法是把探活分成网络探活、协议探活和业务样本三层。Codex 接入可以生成探测脚本和报告，但不能用一个简单的“端口通”替代真实调用验证。
适用场景
适用于多供应商、多模型、主备路由、团队共用 CCSwitch 配置、办公自动化和代码助手。只要调用失败后需要自动或人工切换，就应该提前定义健康状态。对高成本模型，可以用短输入样本；对长上下文或视觉模型，则需要额外准备对应能力的样本。
“GPT 中转”是新手常用搜索词，更规范的说法是 AI 模型接口接入与调用管理。真正要管理的是 profile 的端点、模型能力、额度、延迟和失败后的处理，而不是一个模糊的可用标签。
操作步骤
第一步，给每个 profile 建立状态字段：enabled、network_ok、protocol_ok、sample_ok、last_checked、failure_reason。第二步，做网络探活，只验证 DNS、TLS 和端口，不把结果当作模型可用。第三步，做协议探活，发送最小合法请求，确认鉴权、路径、请求格式和响应结构正确。第四步，做业务样本，使用固定提示词检查文本、结构化输出或视觉输入能力是否符合预期。
第五步，设置健康阈值，例如连续两次协议失败才标记 unhealthy，单次慢响应只记录 degraded。第六步，定义降级矩阵：哪些场景可以从大模型切到小模型，哪些场景必须停止而不能静默切换。第七步，切换后记录原 profile、目标 profile、触发原因、请求 ID 和结果，避免出现“已经切换但无人知道”的状态。
排错路径
如果网络探活成功、协议探活失败，优先查 base_url、路径版本、鉴权头和代理重写。如果协议探活成功、业务样本失败，检查模型名、能力参数、上下文长度和输出格式。如果主备都失败，查看是否共享同一个上游、同一个额度池或同一个代理出口，避免把同一故障误判成两个独立故障。
如果切换后延迟突然升高，检查备用模型是否需要更长的排队时间；如果输出质量变化明显，比较固定样本而不是凭一条自然语言回复判断。CCSwitch 配置排查时还要确认当前生效 profile，不能只看配置文件里排在最前面的名字。
常见问题 / 避坑
问：健康检查越频繁越好吗？不一定，频繁探测会增加调用量，还可能触发限流。问：只调用 models 列表接口可以吗？不能完全代表生成接口可用。问：降级是否应该自动发生？低风险问答可以自动，高风险写入、对外通知和结构化任务应先经过策略判断。问：备用模型要和主模型完全一致吗？不必，但必须明确能力差异，并在用户界面或日志里可追踪。
检查清单
检查每个 profile 有网络、协议、样本三层状态；检查探测使用固定样本并记录版本；检查失败原因可读；检查主备不共享同一单点故障；检查降级矩阵区分低风险和高风险任务；检查切换有冷却时间和恢复条件；检查日志记录 profile、模型、请求 ID 和延迟；检查 Codex 生成的探测脚本不会输出真实 Key。
探测结果还要设置保留周期，至少能看到最近几次失败和恢复，而不是只保留当前绿色状态。对文本模型，可以记录响应是否为空、是否被截断、是否返回预期字段；对视觉或长上下文模型，则要把输入类型和样本版本一并写入报告。这样更换模型接口或调整 CCSwitch 配置后，才能分辨是能力差异、配置变化还是上游故障。
验收与复盘
上线前分别模拟鉴权失效、模型名错误、429、慢响应和上游完全不可达，观察系统是否给出正确状态，是否按策略切换，是否避免循环切换。恢复后再验证主 profile 能否回切，不能因为备用可用就一直停留在备用。复盘时把每次切换的业务影响、额外成本和用户提示写下来，下一次调整 CCSwitch 配置或 AI 模型接口时，才能基于证据而不是印象。