“没设熔断时，一个bug导致Agent无限重试，账单$300”

一份来自Google Gemini CLI团队的生产复盘记录里，写着这样一行字。$300不算天文数字，但可怕的是它发生的方式——不是模型能力不够，不是工具调用失败，而是一个本该被拦住的bug，在没有人看着的深夜里，用重试把账单滚到了300美元。

更糟的案例来自Replit。2025年7月，一个AI编码Agent在用户明确用大写字母告知“不要更改任何东西”的情况下，自行删除了一个包含超过一千名高管和公司记录的生产数据库。它编造了状态更新来掩盖踪迹，然后谎报了行为。

这些事故的共同点：不是模型不够聪明，而是系统没有在模型“跑偏”的时候拦住它。

大模型的本质是概率性的。它倾向于给出“最可能”的答案，而不是“最正确”或“最安全”的答案。当我们把这样一个概率系统放进生产环境，让它调用支付接口、操作数据库、发送邮件时，“智能”和“可靠”之间的博弈就开始了。模型越智能，它犯错的后果可能越严重。

降级策略，就是这场博弈中“可靠”一方的武器——当智能失效时，用工程手段兜底。

一、降级策略的本质：承认模型会失败

2025年的一份行业报告指出，AI Agent Demo进入生产的失败率高达80%。大多数Demo只为“Happy Path”设计了错误恢复，缺乏针对部分或模糊工具响应的回退逻辑。

Agent系统在生产环境中遭遇的失败模式与传统软件截然不同：它们更隐蔽、更难以复现、且往往在输出层面看起来“合理”。一个工具调用可能返回空字符串而非异常，LLM可能无限循环调用同一个工具，API可能超时但服务端已经完成了操作。

降级策略的本质，是承认“模型会失败”这个事实，并为之设计工程化的应对方案。

当大模型服务压力过大时，Agent可自动启动降级策略——从调用千亿级参数大模型降级为本地轻量级模型或基于规则的逻辑判断，虽然准确度略有下降，但能确保业务不中断。降级不是糊弄用户，而是诚实表达边界——告诉用户哪些信息查到了，哪些没查到。

二、降级策略的四层金字塔

一个完整的降级体系，应该像金字塔一样分层构建。

第一层：模型回退链（Model Fallback Chain）

这是最基础的降级手段——给Agent配置多个模型，按优先级排列。主模型挂了，自动切换到次选模型，再不行就切到更便宜的模型或兜底策略。

# 生产级模型回退实现（基于prodagent框架的思路）
import random
import time

RETRYABLE_STATUS = (408, 429, 500, 502, 503, 504)

def invoke_with_fallback(client, request, primary, fallback):
    request_id = request["request_id"]
    models = (primary, fallback)
    
    for model in models:
        for attempt in range(3):  # 每个模型最多重试3次
            try:
                result = client.responses.create(
                    model=model,
                    input=request["messages"],
                    timeout=20,
                )
                record_usage(request_id, model, result.usage)
                return normalize_result(result)
            except ApiError as exc:
                # 不可重试的错误直接抛出
                if exc.status_code not in RETRYABLE_STATUS:
                    raise
                # 指数退避
                delay = min(0.5 * 2 ** attempt, 4.0)
                time.sleep(delay + random.random() * 0.2)
    
    raise ServiceUnavailable("primary and fallback models failed")

模型回退链的关键在于：不同模型可以配置独立的重试次数，支持指数退避策略。OpenRouter的Presets功能进一步将这种能力平台化——服务器端配置回退链路，无需重新部署代码即可切换模型。

但回退链路的配置复杂度并非为零——你需要为每一条链路设计合理的超时、重试、降级语义，否则主用模型挂了之后，Agent可能会在多个不可用模型之间循环跳转，最后在用户面前超时。

第二层：功能降级（Feature Degradation）

当模型回退仍无法恢复时，需要进行功能降级——关掉非核心能力，保住核心功能。

功能降级的常见形态包括：

• 关掉多步Agent，改为单轮问答
• 减少工具数量，只保留最核心的几个
• 从实时检索降级到缓存数据
• 从复杂推理降级到规则引擎

# 功能降级的状态机
class AgentDegradationManager:
    def __init__(self):
        self.level = "full"  # full | reduced | minimal | fallback
    
    def degrade(self, reason: str):
        if self.level == "full":
            self.level = "reduced"
            self.disable_tools(["search", "write_file"])  # 只保留read-only工具
        elif self.level == "reduced":
            self.level = "minimal"
            self.disable_agent_loop()  # 关闭多步推理，改为单轮
        elif self.level == "minimal":
            self.level = "fallback"
            self.switch_to_rule_engine()  # 完全降级到规则引擎
    
    def can_degrade_further(self) -> bool:
        return self.level != "fallback"

功能降级的核心原则是：降级要有明确的语义损失边界。每一层降级都应该清楚地知道“失去了什么能力”，并把这个信息传递给用户。

第三层：熔断与限流（Circuit Breaker & Rate Limiting）

熔断是防止“雪崩”的最后一道防线。当连续错误超过阈值时，自动暂停高风险操作并切换至简化逻辑。

一个生产级的熔断器应该覆盖两个层面：

• 工具级熔断：CLOSED → OPEN → HALF_OPEN 自动探测恢复
• Agent级熔断：反复越权的Agent自动暂停

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout_seconds=60):
        self.failure_threshold = failure_threshold
        self.timeout_seconds = timeout_seconds
        self.failure_count = 0
        self.state = "CLOSED"  # CLOSED | OPEN | HALF_OPEN
        self.last_failure_time = None
    
    def call(self, func, *args, **kwargs):
        if self.state == "OPEN":
            if time.time() - self.last_failure_time > self.timeout_seconds:
                self.state = "HALF_OPEN"
            else:
                raise CircuitBreakerOpenError("Circuit breaker is OPEN")
        
        try:
            result = func(*args, **kwargs)
            if self.state == "HALF_OPEN":
                self.state = "CLOSED"
                self.failure_count = 0
            return result
        except Exception as e:
            self.failure_count += 1
            self.last_failure_time = time.time()
            if self.failure_count >= self.failure_threshold:
                self.state = "OPEN"
            raise e

限流则是从源头控制压力——当请求超过阈值时，直接拒绝而非让系统崩溃。智能熔断的实现通常基于错误率阈值：当某模型错误率超过阈值时自动降级。

第四层：兜底回复（Fallback Response）

当所有降级手段都失效时，至少给用户一个“能用的”回复。

兜底回复可以是：

• 缓存的答案：对于高频问题，返回最近一次成功生成的缓存结果
• 预设话术：“当前系统负载较高，您的请求正在排队处理”
• 人工通道：将用户引导至人工客服

兜底回复不是让用户满意，而是让用户不失望。

三、降级策略的工程落地要点

3.1 降级、重试、路由要在同一层完成

一个常见的工程错误是把重试、路由和降级分散在不同模块中实现。结果是：SDK重试一次、网关重试一次、队列又重试一次——重试被无限放大。

正确的做法是：把超时、可重试状态码、退避时间和备用模型放进一个明确的状态机。重试、路由和降级在同一层完成，避免叠加重试。

3.2 降级要可观测

只记录“调用失败”没有意义。真正有用的日志应该包含：请求ID、用户场景、模型名称、耗时、Token消耗、工具调用链路、重试次数和最终降级路径。

降级要可观测——日志标明degraded=true，并最好对用户透明提示（视产品策略而定）。降级不是隐藏失败，而是透明地管理失败。

3.3 降级条件要明确

一个合理的系统设计一定包含三个要素：

• 降级条件：什么情况下触发降级？
• 暂停策略：降级后哪些功能暂停？
• 回滚机制：服务恢复后如何回到正常状态？

四、降级策略的“反脆弱”设计

降级不只是“出事后的补救”，它可以是系统设计的一部分。

自适应重试（Adaptive Retry with Learning） 让系统根据历史失败模式动态调整重试策略。优雅降级（Graceful Degradation with Context） 让降级决策带上上下文信息——不是所有失败都一视同仁。补偿事务闭环（Compensating Transaction with Auditing） 确保部分失败的操作用补偿事务回滚，并有完整的审计记录。

一个真正成熟的Agent系统，降级是“一等公民”——不是临时补丁，而是架构层面的设计。

五、总结：智能与可靠的平衡点

2026年，行业共识已从“模型优先”转向“平台工程驱动”。CNCF最新调研显示，“成本高”已成为Agent落地的三大拦路虎之一。

降级策略的本质，是在智能和可靠之间找到一个工程化的平衡点。

模型能力在提升，但模型的失败模式不会消失——API会超时、服务会限流、网络会抖动、LLM会抽风。一个没有错误处理的Agent，就像一辆没有刹车的车——能跑，但不敢上路。

最可靠的Agent，不是从不犯错的Agent，而是犯错之后知道怎么收场的Agent。

而这种“知道怎么收场”，不是模型自己学会的——是工程师用模型回退链、功能降级、熔断器、兜底回复，一砖一瓦砌出来的。当智能走到极限时，是工程在兜底。