引言

在理想世界中，Agent的每个请求都能得到完美处理。但现实是，LLM API会限流、工具会超时、外部服务会宕机。当主路径不可用时，Agent需要有备选方案——这就是降级链（Fallback Chain）。

降级链的设计哲学是"逐步退化"——不是在失败时直接报错，而是尝试一系列替代方案，每一步都比上一步弱一些但仍然能提供价值。就像人类的处理方式：想不起来精确答案时，先给个近似答案；近似答案也没有时，至少给个方向。

一、降级链的核心原则

1.1 逐步退化

完美结果 → 良好结果 → 可用结果 → 基本结果 → 优雅失败

每一步降级都是可控的、有意的，而不是崩溃式的。

1.2 价值保留

每一步降级都应尽可能保留核心价值。用户问"帮我分析这份数据"，如果AI分析不可用，至少展示原始数据；如果展示也不行，至少告知用户数据已收到、稍后处理。

1.3 透明告知

降级时应告知用户当前状态，而不是假装一切正常：

"由于实时数据服务暂时不可用，以下分析基于最近缓存数据（更新于5分钟前）。"

1.4 可观测

每次降级都应该被记录和监控，用于发现系统性问题。

二、LLM降级链

2.1 模型降级链

GPT-4o / Claude Opus  →  GPT-4o-mini / Claude Sonnet  →  GPT-3.5 / Claude Haiku  →  规则引擎

第一级：最强模型，提供最佳质量 第二级：中等模型，质量略降但更快更便宜 第三级：轻量模型，保证基本功能 第四级：规则引擎，不依赖LLM

2.2 降级触发条件

class LLMFallbackChain:
    def __init__(self):
        self.chain = [
            {"model": "gpt-4o", "timeout": 30, "max_retries": 2},
            {"model": "gpt-4o-mini", "timeout": 15, "max_retries": 2},
            {"model": "gpt-3.5-turbo", "timeout": 10, "max_retries": 1},
            {"model": "rule_engine", "timeout": 1, "max_retries": 0},
        ]
    
    async def call(self, prompt, **kwargs):
        for i, config in enumerate(self.chain):
            try:
                if config["model"] == "rule_engine":
                    return await self.rule_engine_fallback(prompt)
                
                result = await self.call_llm(
                    model=config["model"],
                    prompt=prompt,
                    timeout=config["timeout"],
                    retries=config["max_retries"],
                    **kwargs
                )
                
                # 质量检查：如果结果质量不达标，降级
                if i < len(self.chain) - 1 and not self.quality_check(result):
                    logger.warning(f"Quality check failed for {config['model']}, falling back")
                    continue
                
                return result
                
            except (TimeoutError, RateLimitError, ServiceUnavailableError) as e:
                logger.warning(f"LLM {config['model']} failed: {e}, falling back")
                continue
        
        # 所有降级都失败
        return self.graceful_failure(prompt)

2.3 质量降级

不只是模型级别的降级，还可以在功能级别降级：

完整分析（多角度、深度分析）
  → 简化分析（单一角度、概要分析）
  → 关键信息提取（只提取要点）
  → 原始数据返回（不做任何处理）

三、工具降级链

3.1 数据源降级

实时数据库 → 缓存数据 → 历史快照 → 默认值

async def query_data(query_params):
    # 第一级：实时数据库
    try:
        return await realtime_db.query(query_params), "realtime"
    except ServiceUnavailableError:
        pass
    
    # 第二级：缓存
    cached = await cache.get(query_params.hash)
    if cached:
        return cached, "cached(5min ago)"
    
    # 第三级：历史快照
    snapshot = await snapshot_store.get_latest(query_params.table)
    if snapshot:
        return snapshot, "snapshot(1hour ago)"
    
    # 第四级：默认值
    return get_default_value(query_params), "default"

3.2 搜索降级

语义搜索（向量+关键词混合） → 关键词搜索 → 缓存热门结果 → 返回"无结果"

3.3 内容生成降级

AI生成（个性化内容） → 模板生成（规则化内容） → 静态内容 → 错误提示

四、多Agent降级

4.1 Agent替换

当主Agent不可用时，切换到备选Agent：

专家Agent（强推理、高Token消耗）
  → 通用Agent（中等推理、低消耗）
  → 简单Agent（规则化、无LLM）

4.2 Agent减少

多Agent协作场景下，减少参与Agent数量：

5个Agent协作（完整流程）→ 3个Agent协作（简化流程）→ 1个Agent（单步处理）

4.3 任务简化

完整任务：多步骤、多维度分析
  → 简化任务：核心步骤、单一维度
  → 最小任务：直接返回已有信息

五、降级决策

5.1 何时降级

降级应该在以下情况触发：

错误触发：主路径失败且重试耗尽 超时触发：主路径未在SLA内完成 负载触发：系统负载过高，主动降级保稳定 成本触发：Token消耗超出预算，切换到低成本方案

5.2 降级决策器

class FallbackDecisionMaker:
    def __init__(self):
        self.error_history = []
        self.current_load = 0
        self.token_budget = 100000
        self.token_used = 0
    
    def should_fallback(self, context):
        # 错误触发
        if context.error and context.retries_exhausted:
            return True, "error"
        
        # 超时触发
        if context.elapsed_time > context.sla:
            return True, "timeout"
        
        # 负载触发
        if self.current_load > 0.8:
            return True, "load"
        
        # 成本触发
        remaining_budget = self.token_budget - self.token_used
        if remaining_budget < self.estimate_tokens(context.request) * 3:
            return True, "cost"
        
        return False, None

5.3 降级恢复

当主路径恢复后，应该从降级状态恢复：

class FallbackManager:
    def __init__(self):
        self.fallback_active = False
        self.health_checker = HealthChecker()
    
    async def check_and_recover(self):
        if self.fallback_active:
            if await self.health_checker.is_healthy("primary"):
                # 逐步恢复：先发10%流量到主路径
                await self.traffic_manager.adjust_split(primary=0.1, fallback=0.9)
                
                # 观察一段时间
                await asyncio.sleep(60)
                
                if await self.health_checker.is_healthy("primary"):
                    # 继续增加
                    await self.traffic_manager.adjust_split(primary=0.5, fallback=0.5)
                    await asyncio.sleep(60)
                    
                    if await self.health_checker.is_healthy("primary"):
                        await self.traffic_manager.adjust_split(primary=1.0, fallback=0.0)
                        self.fallback_active = False

六、降级链测试

6.1 故障注入

主动注入故障，测试降级链是否正常工作：

  • 关闭LLM API，验证模型降级
  • 关闭数据库，验证数据源降级
  • 增加网络延迟，验证超时降级
  • 消耗Token预算，验证成本降级

6.2 降级演练

定期进行降级演练，确保降级链在实际故障时能正常工作：

  1. 在低峰期主动关闭主路径
  2. 观察降级链是否按预期触发
  3. 验证降级后的功能是否可用
  4. 验证恢复机制是否正常

6.3 降级指标

  • 降级触发率：多少比例的请求触发了降级
  • 降级成功率：降级后的请求成功率
  • 降级深度：平均降级到第几级
  • 降级延迟：降级决策+切换的额外延迟
  • 恢复时间：从降级到恢复的平均时间

七、用户体验设计

7.1 降级通知

⚠️ 实时数据服务暂时不可用，以下结果基于缓存数据。

💡 提示：AI深度分析暂时不可用，已为您展示基础分析结果。完整分析将在服务恢复后自动补全。

7.2 降级选项

给用户选择权：

AI分析服务当前负载较高，您可以选择：
1. 等待（预计2分钟）- 完整AI分析
2. 立即查看 - 基础数据分析
3. 稍后通知 - 服务恢复后发送结果

7.3 降级透明度

不要试图掩盖降级。用户更信任坦诚的系统而非假装完美的系统。

结语

降级链是Agent系统可靠性的最后一道防线。它不能替代高可用架构和容错设计，但能在最坏的情况下保证系统仍然可用。

好的降级链设计需要对业务有深刻理解——什么是核心价值、什么是可以牺牲的、什么是绝对不能丢失的。这些权衡决策是架构设计的精髓。

2026年的降级链正在向"自愈系统"方向演进——系统能够自动发现故障、自动选择最优降级策略、自动恢复到正常状态。这种"韧性工程"正在成为Agent基础设施的核心能力。

加入讨论

这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。

碳基与硅基的智慧碰撞，认知差异创造无限可能。