Agent 工程化挑战远大于普通 LLM 应用:多步骤执行中每一步工具调用都可能失败,错误会级联放大。核心工程原则:容错设计(每个工具必须有错误处理)+ 指数退避重试 + 超时控制 + 结果缓存 + 全链路监控。工业实践中,工具调用失败率目标 < 0.3%,P95 响应延迟目标 < 10s。
Agent 系统最容易出问题的模块
稳定性风险排序(从高到低):1. 工具调用层(最高风险)
- 网络超时(搜索 API、外部服务不稳定)
- 格式错误(LLM 返回非标准 JSON)
- Rate Limit(API 调用频率超限)
- 权限错误
2. 规划模块(中等风险)
- 任务分解不合理(步骤过多或过少)
- 意图识别错误
3. 记忆模块(低风险但影响质量)
- 上下文截断导致信息丢失
- 长期记忆检索不相关
完整容错机制实现
import asyncio async def call_tool_with_retry(tool_name: str, args: dict, max_retries: int = 3
) -> dict:
for attempt in range(max_retries):
try:
result = await asyncio.wait_for(
tools[tool_name](**args),
timeout=30.0 # 30 秒超时
)
return result
except asyncio.TimeoutError:
if attempt == max_retries - 1:
return {"success": False,
"error": "工具调用超时,请尝试其他方法"}
wait = 2 ** attempt # 指数退避:1s, 2s, 4s
await asyncio.sleep(wait)
except RateLimitError:
await asyncio.sleep(60) # Rate Limit 等待 1 分钟
continue
except Exception as e:
if attempt == max_retries - 1:
return {"success": False, "error": str(e)}
await asyncio.sleep(2 ** attempt)
return {"success": False, "error": "达到最大重试次数"}
三层缓存策略
class AgentCacheManager:# Layer 1: 搜索结果缓存(TTL 15 分钟)
async def get_search_cache(self, query: str):
key = f"search:{sha1(query)}"
return await self.redis.get(key)
# Layer 2: 网页内容缓存(TTL 1 小时)
async def get_page_cache(self, url: str):
key = f"page:{sha1(url)}"
return await self.redis.get(key)
# Layer 3: 最终答案缓存(FAQ 类 TTL 7 天)
async def get_answer_cache(self, question: str):
key = f"ans:{sha1(question)}"
return await self.redis.get(key)
关键监控指标
metrics = {
"tool_success_rate": "工具调用成功率(目标 > 99%)",
"avg_steps": "平均推理步数(异常增加说明 Agent 陷入循环)",
"p95_latency": "P95 响应延迟(目标 < 10s)",
"context_overflow_rate": "上下文溢出率(目标 < 1%)",
"answer_rate": "最终生成答案的比例(vs 超时终止)",
}
生产部署架构
接入层(Nginx + API Gateway + Rate Limit)-> 服务层(Agent Service x N + Redis Task Queue)
-> 模型层(vLLM Server x N,tensor_parallel_size=4)
-> 工具层(Search / Visit / Text2SQL / Code Sandbox + Result Cache)
-> 存储层(PostgreSQL 元数据 + Redis 缓存 + S3 文件 + Kafka 日志)
第 1 次重试等 1s,第 2 次等 2s,第 3 次等 4s(2^n)。避免在服务压力大时继续密集重试,是处理网络抖动和临时故障的标准做法。
通常设置 3 次。依据:系统稳定性要求(越高越少重试)+ 工具调用成本(API 按次收费需限制)+ 用户等待忍耐度。超过 3 次还失败通常说明是系统性问题,不是偶发故障,重试无意义。
tensor_parallel_size(多卡并行);enable_prefix_caching(System Prompt 固定时效果显著);enable_chunked_prefill(减少延迟抖动);max_num_seqs(最大并发请求数,通常设 32)。
Agent 执行用户生成的代码时,必须在隔离沙箱中运行(Docker 容器 + gVisor),限制网络访问、文件系统权限、CPU/内存使用上限,防止代码逃逸和资源耗尽攻击。
被问Agent 系统上线后遇到过什么问题,答:我们遇到过两个严重问题:① Agent 陷入循环:不断搜索相同关键词但没有进展,最终超时。排查发现是 Reflector 节点置信度阈值设 0.95 太高,导致永远「不够好。解决:阈值降到 0.83 + 加入重复检测(检测最近 5 步是否重复)+ 全局 max_steps=20 兜底。循环率从 8% 降到 0.5%。② 搜索 API 超时:高峰期 P95 超时率达 12%。解决:指数退避重试(最多 3 次)+ 搜索结果 Redis 缓存(TTL 15分钟,命中率 40%)。超时率降到 0.8%,平均延迟降低 35%。」