澳五机器人 如何基于Koog构建生产级多模型容灾方案
如何基于Koog构建生产级多模型容灾方案
基于 Koog 构建生产级多模型容灾方案
依托 Koog 原生的 MultiLLMPromptExecutor 多模型执行器抽象，结合断路器、健康探测、智能路由三大核心机制，可以搭建一套“故障自动切换、流量动态调度、用户完全无感知”的生产级多模型容灾体系，彻底避免单厂商大模型宕机、限流、配额耗尽导致的业务中断。
🏗️ 整体架构：四级分层容灾模型
生产环境建议采用四层分级容灾架构，在效果、成本、可用性之间找到最优平衡，避免所有鸡蛋放在一个厂商篮子里：
表格
层级 角色定位 模型选型参考 流量占比
L1 主模型 核心效果优先，承接大部分常规流量 GPT-4o / Claude 3.5 Sonnet / 通义千问Max 90%
L2 同厂商降级 同生态内低成本高可用模型，兼容性最好，切换几乎无感知 GPT-4o-mini / Claude 3 Haiku / 通义千问Plus 8%（预热流量）
L3 跨厂商容灾 完全异构厂商模型，规避单厂商整体故障风险 豆包Pro / 文心一言4.0 / DeepSeek V3 2%（预热流量）
L4 兜底模型 极端情况保底，保证核心功能可用 本地部署7B开源模型 / 零一万物Yi-Lightning 0%（仅故障时启用）
关键原则：备用模型必须始终保持少量预热流量，避免冷启动时模型上下文不熟悉、输出格式突变导致业务异常。
🧩 核心组件实现（基于Koog原生能力扩展）
Koog 的 MultiLLMPromptExecutor 原生支持多客户端注册，在此基础上仅需扩展三个核心模块即可完成生产级容灾能力，无需重写底层调用逻辑。
1. 健康探测与断路器模块
替代原生简单的失败重试，实现精细化故障判定，避免故障模型被反复调用拖慢整体性能：
kotlin
// 自定义断路器健康检查配置
val circuitBreakerConfig = CircuitBreakerConfig(
failureRateThreshold = 50f, // 错误率超过50%触发熔断
slowCallRateThreshold = 80f, // 慢调用占比超过80%触发熔断
slowCallDurationThreshold = Duration.ofSeconds(10), // 超过10秒判定为慢调用
waitDurationInOpenState = Duration.ofSeconds(30), // 熔断30秒后半开探测
permittedNumberOfCallsInHalfOpenState = 3 // 半开状态放3个探测请求
)
// 注册所有模型客户端并绑定断路器
val executor = multiLLMPromptExecutor {
// L1主模型
addClient(openAiClient(GPT_4O), priority = 10) {
weight = 90 // 90%流量权重
circuitBreaker = circuitBreakerConfig
healthCheck = { // 自定义健康探测逻辑：发简单ping请求
it.execute(prompt { user("ping") }).content.isNotBlank()
}
}
// L2同厂商降级
addClient(openAiClient(GPT_4O_MINI), priority = 20) {
weight = 8
circuitBreaker = circuitBreakerConfig
}
// L3跨厂商容灾
addClient(tongyiClient(QWEN_MAX), priority = 30) {
weight = 2
circuitBreaker = circuitBreakerConfig
}
// L4本地兜底
addClient(ollamaClient(LOCAL_7B), priority = 100) {
weight = 0
circuitBreaker = null // 本地模型无网络故障，不触发熔断
}
}
断路器会自动完成三个状态流转：
关闭状态：正常转发流量，统计错误率和延迟
打开状态：故障模型被暂时踢出可用池，所有流量自动转发到下一级优先级模型
半开状态：熔断冷却期结束后，放少量探测请求验证服务恢复情况，恢复正常则切回关闭状态
2. 智能路由策略配置
根据业务场景灵活配置路由规则，不同优先级任务自动分配到最合适的模型：
kotlin
val routingConfig = MultiLLMRoutingConfig(
// 默认优先级路由：主模型不可用时按优先级顺序降级
defaultStrategy = PriorityRoutingStrategy(),
// 针对简单任务自动路由到低成本模型
taskBasedRouting = mapOf(
"format_conversion" to CostFirstRoutingStrategy(), // 格式转换类任务优先选低成本模型
"complex_reasoning" to PriorityRoutingStrategy() // 复杂推理任务严格按优先级走高端模型
),
// 配额阈值控制：某模型当日配额剩余10%时自动切流
quotaProtection = true,
// 实时延迟感知：自动将流量调度到当前延迟最低的健康模型
latencyAwareRouting = true
)
executor.setRoutingConfig(routingConfig)
3. 结果一致性校验模块
跨模型切换时最容易出现的问题是输出格式、风格不一致，导致下游业务逻辑崩溃。Koog 原生支持结构化输出校验，切换模型时自动做结果校验：
kotlin
executor.addPostInterceptor { response, context ->
// 1. 格式校验：必须符合预定义JSON Schema
if (!response.matchesSchema(context.expectedSchema)) {
// 校验失败自动重试，或切换下一个模型重试
return@addPostInterceptor RetryWithNextModel()
}
// 2. 关键字段校验：核心业务字段不能为空
if (response.json.isNull("order_id") || response.json.isNull("amount")) {
return@addPostInterceptor RetryWithNextModel()
}
response
}
📊 生产级可观测与运维
容灾方案必须配套完整的可观测体系，否则故障切换时完全不可感知：
核心指标埋点：自动上报每个模型的请求成功率、P99延迟、Token消耗、熔断次数、降级切换次数，接入Grafana看板实时监控。
告警规则配置：当触发L3跨厂商降级、模型错误率超过30%、配额剩余不足20%时，自动发送企微/邮件告警，运维人员提前介入处理。
全链路Trace追踪：每个请求携带唯一TraceID，完整记录请求经过了哪些模型、触发了几次降级、最终由哪个模型返回结果，故障排查时可以一键回溯全链路。
定期故障演练：每周自动模拟主模型超时/5xx错误，验证降级逻辑是否正常生效，避免容灾预案长期不运行变成摆设。
⚠️ 生产避坑要点
避免厂商单点：L2/L3/L4降级模型必须选择完全不同的云厂商，不能所有模型都依赖同一个OpenAI生态，否则厂商整体服务故障时所有降级链路全部失效。
Prompt 兼容处理：不同模型对系统提示词的敏感度不同，建议在Prompt层做模型适配，针对不同厂商模型自动微调提示词格式，避免切换后输出效果大幅波动。
成本兜底控制：极端场景下所有云端模型都不可用时，本地兜底模型仅开放核心基础功能，避免复杂任务占用过多本地资源导致服务崩溃。
会话状态保持：多轮对话场景下，模型切换时需要自动将历史对话上下文做格式适配，避免切换模型后对话上下文断裂，影响用户体验。
这套方案落地后，可以实现99.99%的服务可用性，单模型故障时切换延迟控制在100ms以内，用户完全感知不到后端模型故障，同时可以通过智能路由将整体Token成本降低40%以上。
