ARTICLE / ai

AI Agent 可靠性工程:从错误恢复到优雅降级的生产级实践

构建一个 AI Agent 的 Demo 只需要 20 行代码——一个 while 循环加上 LLM 调用和工具接口。但将其部署到生产环境并可靠运行,复杂度会发生量级跃迁。这不是模型能力的问题,而是 Agent 系统在生产环境中遭遇的失败模式与传统软件截然不同:它们更隐蔽、更难以复现、且往往在输出层面看起来"完全正常"。

多 Agent 系统在生产环境中的故障率高达 41%-86.7%(MAST 研究,NeurIPS 2025),而 88% 的 AI Agent 项目甚至从未到达生产环境。这些数字揭示了一个残酷现实:可靠性工程不是 Agent 开发的附加项,而是决定成败的核心能力。本文将系统梳理 Agent 在生产环境中面临的失败模式,并给出从重试策略、熔断器、优雅降级到可观测性的完整可靠性工程方案。


1. 生产环境的残酷现实

1.1 复合错误概率:单步准确率 ≠ 端到端成功率

理解 Agent 可靠性,首先要建立一个反直觉的数学模型:Agent 工作流的成功率是每一步准确率的乘积,而非单步值本身

单步准确率5 步工作流10 步工作流20 步工作流
90%59%35%12%
95%77%60%36%
99%95%90%82%

一个看起来"95% 准确"的 Agent,在执行 10 步工作流时只有 60% 的端到端成功率。这意味着每 10 次任务执行就有 4 次会以某种形式失败。

这个数学事实意味着:即使模型本身非常优秀,Agent 系统也需要额外的可靠性机制来补偿复合错误概率

1.2 Agent 失败与传统软件失败的根本区别

传统软件的失败是确定性的——同一个输入产生同一个错误,日志里有明确的错误码,可以通过复现来修复。Agent 的失败则具有三个根本性差异:

┌──────────────────────────────────────────────────────────────┐
│              传统软件 vs AI Agent 失败模式对比                  │
├──────────────────┬──────────────────┬────────────────────────┤
│     维度          │   传统软件        │     AI Agent            │
├──────────────────┼──────────────────┼────────────────────────┤
│ 失败可见性        │ 显式错误/崩溃     │ 静默输出错误结果         │
│ 可复现性         │ 同输入同输出       │ 非确定性,难以复现        │
│ 失败时机          │ 通常是即时的       │ 可能在 N 步后延迟出现    │
│ 错误传播          │ 异常中断执行       │ 错误悄无声息地向下游传播  │
│ 诊断方式          │ 查看错误码和堆栈   │ 需要重建完整推理链        │
│ 成本信号          │ 固定成本/请求      │ 失控 Agent 可能烧掉 20x 成本│
└──────────────────┴──────────────────┴────────────────────────┘

1.3 生产环境七大失败模式

基于 2025-2026 年的生产实践数据,Agent 系统的主要失败模式可以归为七类:

失败模式严重程度发生频率典型表现
Tool 误用严重~31%调用错误工具、传入错误参数
上下文漂移~22%多步推理中偏离原始目标
幻觉级联~18%一步幻觉成为下一步的"事实"
无限循环~12%Agent 反复调用同一工具无进展
静默质量退化~10%输出格式正确但内容错误
成本爆炸~5%Token 消耗异常飙升
超时与限流~2%API 调用超时或被限流

其中最危险的是 静默质量退化:Agent 生成了一个格式完美、语气自信但内容完全错误的回答,而系统没有任何异常信号。


2. 错误分类体系

在设计可靠性机制之前,需要先建立错误分类体系。不同类型的错误需要不同的处理策略:

from enum import Enum
from dataclasses import dataclass
from typing import Optional

class ErrorCategory(Enum):
    INFRASTRUCTURE = "infrastructure"   # 网络超时、服务不可用、限流
    MODEL_OUTPUT = "model_output"       # 输出格式异常、空响应、幻觉
    LOGICAL = "logical"                 # 推理错误、目标漂移、上下文丢失
    SECURITY = "security"               # Prompt 注入、权限越界

@dataclass
class AgentError:
    category: ErrorCategory
    error_type: str
    message: str
    retryable: bool
    severity: str
    context: Optional[dict] = None

2.1 基础设施错误

基础设施错误来自 Agent 依赖的外部服务,特征是可重试且错误原因明确

  • 连接超时:LLM API 响应超过设定阈值
  • 限流(Rate Limit):API 返回 429 状态码
  • 服务不可用:API 返回 502/503/504
  • 网络不可达:DNS 解析失败或网络中断

基础设施错误是三类错误中最容易处理的——它们通常是暂时性的,通过重试和降级即可有效应对。

2.2 模型输出错误

模型输出错误是 Agent 独有的挑战,特征是模型"认为"自己回答正确但实际输出不符合要求

  • 格式异常:期望 JSON 但返回纯文本
  • 空响应:模型返回空内容或仅包含停止标记
  • 参数错误:Tool 调用的参数类型或值不符合 Schema
  • 幻觉调用:调用不存在的工具或编造 API 参数
def classify_model_error(response: dict, expected_schema: dict) -> AgentError:
    if not response.get("content"):
        return AgentError(
            category=ErrorCategory.MODEL_OUTPUT,
            error_type="empty_response",
            message="Model returned empty content",
            retryable=True,
            severity="medium"
        )
    if not validate_schema(response["content"], expected_schema):
        return AgentError(
            category=ErrorCategory.MODEL_OUTPUT,
            error_type="schema_violation",
            message="Output does not match expected schema",
            retryable=True,
            severity="medium"
        )
    return AgentError(
        category=ErrorCategory.MODEL_OUTPUT,
        error_type="unknown",
        message="Unspecified model output error",
        retryable=True,
        severity="low"
    )

2.3 逻辑错误

逻辑错误是最难检测和处理的,因为Agent 看起来运行正常但结果不正确

  • 目标漂移:Agent 在多步推理中偏离原始任务
  • 上下文丢失:长对话中早期信息被遗忘
  • 推理链断裂:中间步骤的推理错误导致最终结论错误

逻辑错误往往只能通过事后评估人工审查来发现。这也是可观测性在 Agent 系统中如此重要的原因——你需要完整重建推理链来定位问题。


3. 重试策略:带退避与抖动的智能重试

重试是应对暂时性故障的第一道防线,但朴素的重试策略比不重试更危险。立即重试一个限流请求会触发又一次限流;用相同 Prompt 重试一个格式错误的输出大概率得到相同的错误。

3.1 指数退避与抖动

import time
import random

def retry_with_backoff(
    func,
    max_retries: int = 3,
    base_delay: float = 1.0,
    max_delay: float = 60.0,
    jitter_factor: float = 0.3
):
    for attempt in range(max_retries + 1):
        try:
            return func()
        except Exception as e:
            if attempt == max_retries:
                raise
            delay = min(base_delay * (2 ** attempt), max_delay)
            jitter = random.uniform(0, jitter_factor * delay)
            time.sleep(delay + jitter)

关键设计要素

要素作用典型值
指数退避逐步增加等待时间base × 2^attempt
随机抖动防止多 Agent 同时重试造成雷群效应0.1-0.3 × delay
最大延迟避免单次等待时间过长30-60 秒
最大重试次数限制总等待时间3-5 次

3.2 基于错误类型的差异化重试

不同错误需要不同的重试策略:

class RetryStrategy:
    CONFIGS = {
        "timeout": {
            "max_retries": 3, "base_delay": 0.5, "max_delay": 5
        },
        "rate_limit": {
            "max_retries": 5, "base_delay": 60, "max_delay": 300
        },
        "server_error": {
            "max_retries": 2, "base_delay": 2, "max_delay": 10
        },
        "schema_violation": {
            "max_retries": 2, "base_delay": 0, "max_delay": 0
        },
        "auth_error": {
            "max_retries": 0
        },
    }

    @classmethod
    def get(cls, error_type: str) -> dict:
        return cls.CONFIGS.get(error_type, cls.CONFIGS["server_error"])

不同错误的重试逻辑

  • 超时:快速重试(0.5s 起),最多 3 次——可能是瞬时网络抖动
  • 限流:长时间等待(60s 起),最多 5 次——需要等待配额恢复
  • Schema 违规:立即重试但修改 Prompt——加入更明确的格式约束
  • 认证错误不重试,直接升级到人工——通常是配置问题

3.3 重试时的 Prompt 修改策略

对模型输出格式错误,单纯重试通常无效。更好的策略是在重试时修改 Prompt 以降低再次出错的概率

def build_retry_prompt(original_prompt: str, error: AgentError, attempt: int) -> str:
    if error.error_type == "schema_violation":
        return (
            f"{original_prompt}\n\n"
            f"【重要】你的上一次回复未符合要求的格式。"
            f"请严格按照以下 JSON Schema 输出:\n"
            f"{error.context.get('expected_schema')}\n"
            f"不要添加任何额外字段或文本说明。"
        )
    if error.error_type == "empty_response":
        return (
            f"{original_prompt}\n\n"
            f"【重要】请务必生成实际内容作为回复,"
            f"不要返回空内容。"
        )
    return original_prompt

重试不仅仅是"再做一次",而是"带着更明确的约束再做一次"。每次重试都应该比上一次更精确地约束模型的行为


4. 熔断器模式:防止级联故障

当某个 LLM 服务持续故障时,Agent 不应无限重试——这会浪费 Token 预算、增加延迟、并可能加剧下游服务的压力。熔断器(Circuit Breaker) 是分布式系统中的经典模式,在 Agent 系统中同样关键。

4.1 状态机设计

┌─────────────────────────────────────────────────────────────┐
│                   熔断器状态机                                │
│                                                             │
│  ┌──────────┐    失败超阈值    ┌──────────┐                 │
│  │  CLOSED   │ ──────────────→ │   OPEN   │                 │
│  │ (正常放行) │                 │ (拒绝请求)│                 │
│  └──────────┘                  └─────┬────┘                 │
│       ↑                              │                       │
│       │ 探测成功                      │ 冷却时间到期           │
│       │                              ▼                       │
│       │                        ┌────────────┐               │
│       └─────────────────────── │ HALF-OPEN  │               │
│         探测失败 → 回到 OPEN    │ (允许单次探测)│              │
│                                └────────────┘               │
└─────────────────────────────────────────────────────────────┘

4.2 生产级实现

import time
from enum import Enum

class CircuitState(Enum):
    CLOSED = "closed"
    OPEN = "open"
    HALF_OPEN = "half_open"

class LLMCircuitBreaker:
    def __init__(
        self,
        failure_threshold: int = 5,
        detection_window: float = 300,
        cooldown_period: float = 300,
        extended_cooldown: float = 900
    ):
        self.failure_threshold = failure_threshold
        self.detection_window = detection_window
        self.cooldown_period = cooldown_period
        self.extended_cooldown = extended_cooldown
        self.state = CircuitState.CLOSED
        self.failure_count = 0
        self.last_failure_time = 0
        self.last_state_change = time.time()
        self.consecutive_reopen_count = 0

    def can_execute(self) -> bool:
        if self.state == CircuitState.CLOSED:
            return True
        if self.state == CircuitState.OPEN:
            cooldown = (
                self.extended_cooldown
                if self.consecutive_reopen_count > 0
                else self.cooldown_period
            )
            if time.time() - self.last_state_change > cooldown:
                self.state = CircuitState.HALF_OPEN
                return True
            return False
        return True

    def record_success(self):
        self.failure_count = 0
        self.consecutive_reopen_count = 0
        if self.state != CircuitState.CLOSED:
            self.state = CircuitState.CLOSED
            self.last_state_change = time.time()

    def record_failure(self):
        now = time.time()
        if now - self.last_failure_time > self.detection_window:
            self.failure_count = 0
        self.failure_count += 1
        self.last_failure_time = now
        if self.failure_count >= self.failure_threshold:
            if self.state == CircuitState.HALF_OPEN:
                self.consecutive_reopen_count += 1
            self.state = CircuitState.OPEN
            self.last_state_change = now

4.3 关键设计决策

什么应该触发熔断? 只有基础设施错误应该触发熔断。业务逻辑错误(如 Schema 校验失败、参数错误)不应计入熔断器——它们表明的是请求问题而非服务问题。

错误类型是否计入熔断原因
连接超时✅ 是服务可能故障
HTTP 502/503✅ 是服务明确不可用
限流(429)✅ 是需要保护过载服务
HTTP 400/401❌ 否请求本身有问题
Schema 违规❌ 否模型输出问题
空响应❌ 否模型行为问题

4.4 自适应恢复

熔断器从 OPEN 恢复到 CLOSED 时,不应立即以全量流量冲击刚恢复的服务。渐进式恢复是最佳实践:

class AdaptiveRecovery:
    def __init__(self, max_workers: int = 10):
        self.max_workers = max_workers
        self.current_workers = 1
        self.scale_up_interval = 300

    def on_success(self):
        if self.current_workers < self.max_workers:
            self.current_workers = min(
                self.current_workers + 1,
                self.max_workers
            )

    def on_failure(self):
        self.current_workers = max(1, self.current_workers // 2)

    def get_concurrency(self) -> int:
        return self.current_workers

恢复后的服务是脆弱的。从 1 个并发开始,每 5 分钟增加 1 个,直到恢复正常水平——这比直接以全量流量冲击恢复中的服务要安全得多。


5. 优雅降级:多层回退策略

优雅降级(Graceful Degradation) 的核心哲学是:部分结果好于完全没有结果。Agent 系统需要为每个操作预设从"最优"到"最低可用"的多层执行路径。

5.1 降级层级设计

┌──────────────────────────────────────────────────────┐
│                   优雅降级层级                         │
│                                                      │
│  Level 1: 主路径(完整功能)                           │
│  ├─ 主力模型 + 完整上下文 + 全部工具                    │
│  │                                                   │
│  Level 2: 降级模型(功能降级)                         │
│  ├─ 备选模型 + 精简上下文 + 核心工具                    │
│  │                                                   │
│  Level 3: 缓存响应(数据复用)                         │
│  ├─ 基于语义相似度匹配的历史响应                        │
│  │                                                   │
│  Level 4: 规则引擎(最小可用)                         │
│  ├─ 基于模板的确定性响应                              │
│  │                                                   │
│  Level 5: 人工升级(兜底方案)                         │
│  └─ 转交人工处理 + 通知用户                           │
└──────────────────────────────────────────────────────┘

5.2 多层回退实现

class GracefulAgent:
    def __init__(self):
        self.primary_llm = LLMClient(model="claude-opus-4")
        self.fallback_llm = LLMClient(model="claude-sonnet-4")
        self.minimal_llm = LLMClient(model="claude-haiku")
        self.cache = SemanticCache()
        self.rule_engine = RuleEngine()

    async def process(self, user_input: str) -> str:
        try:
            return await self.primary_llm.generate(
                prompt=self._build_full_prompt(user_input),
                temperature=0.1
            )
        except (TimeoutError, RateLimitError):
            pass
        try:
            return await self.fallback_llm.generate(
                prompt=self._build_simple_prompt(user_input),
                temperature=0.2
            )
        except Exception:
            pass
        cached = await self.cache.find_similar(user_input)
        if cached:
            return self._adapt_cached_response(cached, user_input)
        template_result = self.rule_engine.process(user_input)
        if template_result:
            return template_result
        return await self._escalate_to_human(user_input)

5.3 模型级回退链

当主力模型不可用时,按照预设链路依次尝试备选模型:

主力模型回退模型 1回退模型 2最终兜底
GPT-4oGPT-4o-miniClaude Sonnet缓存/模板
Claude OpusClaude SonnetClaude Haiku缓存/模板
Gemini ProGemini FlashGPT-4o-mini缓存/模板

回退链的设计原则:回退到的模型必须与主力模型处于不同的故障域。如果它们共享同一个 API 端点或同一个基础设施,那么回退就没有意义。

5.4 成本与预算熔断

Agent 的 Token 消耗是弹性的——一个陷入循环的 Agent 可能消耗正常情况 20 倍的 Token。成本本身就是可靠性信号

class BudgetCircuitBreaker:
    def __init__(self, max_cost_per_task: float = 1.0):
        self.max_cost = max_cost_per_task
        self.current_cost = 0.0

    def check_budget(self, estimated_tokens: int, model: str) -> bool:
        estimated_cost = self._estimate_cost(estimated_tokens, model)
        if self.current_cost + estimated_cost > self.max_cost:
            raise BudgetExceededError(
                f"Task budget exceeded: {self.current_cost:.4f} "
                f"/ {self.max_cost:.4f}"
            )
        return True

    def record_usage(self, input_tokens: int, output_tokens: int, model: str):
        self.current_cost += self._calculate_cost(
            input_tokens, output_tokens, model
        )

6. 检查点与状态恢复

对于长时间运行的 Agent 任务(数分钟到数小时),检查点(Checkpointing) 是防止工作丢失的关键机制。

6.1 检查点策略

import json
import hashlib
from datetime import datetime

class AgentCheckpoint:
    def __init__(self, task_id: str, storage_path: str):
        self.task_id = task_id
        self.storage_path = storage_path

    def save(self, state: dict, step: int):
        checkpoint = {
            "task_id": self.task_id,
            "step": step,
            "state": state,
            "timestamp": datetime.utcnow().isoformat(),
            "checksum": hashlib.sha256(
                json.dumps(state, sort_keys=True).encode()
            ).hexdigest()
        }
        path = f"{self.storage_path}/{self.task_id}_step{step}.json"
        with open(path, "w") as f:
            json.dump(checkpoint, f)

    def load_latest(self) -> dict:
        import glob
        pattern = f"{self.storage_path}/{self.task_id}_step*.json"
        files = sorted(glob.glob(pattern))
        if not files:
            return None
        with open(files[-1]) as f:
            checkpoint = json.load(f)
        expected = hashlib.sha256(
            json.dumps(checkpoint["state"], sort_keys=True).encode()
        ).hexdigest()
        if checkpoint["checksum"] != expected:
            raise CheckpointCorruptionError("Checkpoint integrity check failed")
        return checkpoint

6.2 什么时候保存检查点

  • 每次成功完成一个子任务后
  • 每次成功调用一个外部工具后
  • 在 Agent 执行可能产生副作用的操作之前(如写数据库、发邮件)
  • 定期保存(如每 N 步或每 M 秒)

检查点的设计原则:从检查点恢复后重跑的成本,应该远低于从头开始的成本。对于一个已经执行了 20 步的 Agent 任务,从第 18 步的检查点恢复远比从第 1 步重新开始更高效。


7. 可观测性:比你想的更重要

Agent 系统的可观测性远比传统应用复杂——你需要追踪的不只是请求和响应,而是 Agent 的完整决策链

7.1 必须捕获的信号

信号用途采集方式
完整执行 Trace重建 Agent 的每一步决策OpenTelemetry GenAI Semantic Conventions
每步 Token 消耗检测 Prompt 膨胀和异常循环LLM API 响应的 usage 字段
Tool 调用日志诊断工具误用和参数错误结构化日志记录输入输出
每步延迟识别性能瓶颈Trace span 时间戳
成本归因检测成本异常飙升Token 数 × 模型单价
重试与降级触发评估系统韧性自定义事件指标

7.2 OpenTelemetry GenAI 标准

2026 年初,OpenTelemetry GenAI Semantic Conventions 达到稳定状态(1.29+)。gen_ai.* 命名空间为 LLM 调用定义了标准化的 Span 属性:

from opentelemetry import trace

tracer = trace.get_tracer("agent.reliability")

def traced_llm_call(prompt: str, model: str) -> str:
    with tracer.start_as_current_span("llm.generate") as span:
        span.set_attribute("gen_ai.system", "anthropic")
        span.set_attribute("gen_ai.request.model", model)
        response = llm_client.generate(prompt, model=model)
        span.set_attribute("gen_ai.usage.input_tokens", response.input_tokens)
        span.set_attribute("gen_ai.usage.output_tokens", response.output_tokens)
        span.set_attribute("gen_ai.response.finish_reason", response.finish_reason)
        return response.content

def traced_tool_call(tool_name: str, args: dict) -> dict:
    with tracer.start_as_current_span(f"tool.{tool_name}") as span:
        span.set_attribute("gen_ai.tool.name", tool_name)
        span.set_attribute("gen_ai.tool.call.id", generate_call_id())
        result = execute_tool(tool_name, args)
        span.set_attribute("gen_ai.tool.call.status", "success")
        return result

7.3 成本作为正确性信号

在 Agent 系统中,成本异常往往是系统行为异常的第一个可观测信号

  • 一个正常任务消耗 $0.02,突然某次消耗 $2.00 → 很可能陷入了循环
  • 某个 Tool 的延迟从 200ms 飙升到 5000ms → 服务可能正在降级
  • 某次调用的 Token 消耗是中位数的 50 倍 → 上下文可能失控膨胀

恢复但不记录日志,本质上只是在慢速遗忘。 每次故障、每次降级、每次重试都应该被结构化记录,这些数据是持续改进可靠性的唯一原料。

7.4 主流可观测性工具

工具定位特点
LangSmithLangChain/LangGraph 生态调试 UI完整 Trace 树、Playground 重放
Langfuse开源自托管 LLM 追踪全面的评估与人工反馈集成
Arize PhoenixOTEL 兼容的 ML 可观测性质量指标与漂移检测
OpenLIT开源 LLM 可观测性原生 OTel 支持、自动检测

8. Human-in-the-Loop:知道什么时候该停

最危险的 Agent 不是失败的 Agent,而是在关键决策上拒绝请求人工介入的 Agent。

8.1 升级触发条件

class HumanEscalationPolicy:
    ESCALATION_TRIGGERS = {
        "max_tool_failures": 3,
        "max_consecutive_retries": 5,
        "confidence_threshold": 0.4,
        "cost_multiplier": 10,
        "security_violation": True,
    }

    def should_escalate(self, agent_state: dict) -> bool:
        if agent_state["tool_failure_count"] >= self.ESCALATION_TRIGGERS["max_tool_failures"]:
            return True
        if agent_state["retry_count"] >= self.ESCALATION_TRIGGERS["max_consecutive_retries"]:
            return True
        if agent_state.get("confidence", 1.0) < self.ESCALATION_TRIGGERS["confidence_threshold"]:
            return True
        if agent_state["current_cost"] > agent_state["median_cost"] * self.ESCALATION_TRIGGERS["cost_multiplier"]:
            return True
        if agent_state.get("security_flag"):
            return True
        return False

8.2 该升级到人工的信号

  • 连续 3 次 Tool 调用失败 → Agent 可能对工具的理解有误
  • 累计重试超过 5 次 → 暂时性恢复无望
  • 任务成本超过中位数 10 倍 → Agent 很可能陷入循环
  • 涉及敏感操作(支付、删除、权限变更)→ 需要人工确认
  • 置信度低于 40% → Agent 自己都不确定答案是否正确

自主性是 Agent 的核心价值,但在不该自主的地方保持克制同样重要。生产级 Agent 系统应该把"什么时候交给人类"作为一个显式设计决策,而非事后补充。


9. 完整可靠性技术栈

将上述所有机制整合,一个生产级 Agent 系统的可靠性技术栈如下:

┌─────────────────────────────────────────────────────────────────┐
│                    Agent 可靠性技术栈                             │
├─────────────────────────────────────────────────────────────────┤
│  Layer 5: 可观测性与持续改进                                      │
│  ├─ OpenTelemetry GenAI Tracing                                 │
│  ├─ 成本归因与异常检测                                           │
│  └─ Trace → Dataset → Eval 闭环                                 │
├─────────────────────────────────────────────────────────────────┤
│  Layer 4: Human-in-the-Loop                                    │
│  ├─ 升级策略与触发条件                                           │
│  ├─ 置信度阈值                                                  │
│  └─ 敏感操作审批                                                │
├─────────────────────────────────────────────────────────────────┤
│  Layer 3: 优雅降级                                              │
│  ├─ 多层回退(模型→缓存→规则→人工)                               │
│  ├─ 成本预算熔断                                                │
│  └─ 检查点与状态恢复                                             │
├─────────────────────────────────────────────────────────────────┤
│  Layer 2: 熔断器                                                │
│  ├─ 三态状态机(CLOSED→OPEN→HALF_OPEN)                         │
│  ├─ 自适应恢复                                                  │
│  └─ 分域隔离                                                    │
├─────────────────────────────────────────────────────────────────┤
│  Layer 1: 智能重试                                              │
│  ├─ 指数退避 + 抖动                                             │
│  ├─ 错误类型差异化策略                                           │
│  └─ 重试时 Prompt 修改                                          │
└─────────────────────────────────────────────────────────────────┘

10. 总结与展望

AI Agent 的可靠性工程不是某个单一技术的堆叠,而是一套层层嵌套的防御体系

  • 理解失败:Agent 的失败模式与传统软件根本不同——静默错误、复合概率、非确定性是三大核心差异,只有理解这些才能设计有效的防御
  • 智能重试:不是"再试一次",而是"带着更精确约束再试一次"——错误分类、指数退避、抖动、Prompt 修改四者缺一不可
  • 熔断与降级:熔断器防止级联故障,优雅降级确保系统在任何条件下都能给出"部分但有用"的响应,而非彻底失败
  • 可观测性先行在你需要它之前就把可观测性建好——事后给一个正在运行的 Agent 补装追踪能力,比从一开始就正确构建要困难得多
  • 克制的自主性:最好的 Agent 系统知道什么时候该停下来交给人类,这不是能力不足的标志,而是工程成熟度的体现

未来,Agent 可靠性工程将向两个方向演进:一是自适应可靠性——Agent 自动根据运行时指标调整重试策略和降级阈值,而非依赖静态配置;二是可靠性即代码——将熔断器、降级策略、升级规则抽象为声明式配置,纳入 CI/CD 流水线进行版本管理和自动化测试。

参考资源