构建一个 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-4o | GPT-4o-mini | Claude Sonnet | 缓存/模板 |
| Claude Opus | Claude Sonnet | Claude Haiku | 缓存/模板 |
| Gemini Pro | Gemini Flash | GPT-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 主流可观测性工具
| 工具 | 定位 | 特点 |
|---|
| LangSmith | LangChain/LangGraph 生态调试 UI | 完整 Trace 树、Playground 重放 |
| Langfuse | 开源自托管 LLM 追踪 | 全面的评估与人工反馈集成 |
| Arize Phoenix | OTEL 兼容的 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 流水线进行版本管理和自动化测试。
参考资源