导致 AI Agent 失效的 7 个关键错误
你的 AI agent 在测试阶段表现出色，既快速又准确。然而，当你将其部署到生产环境时，用户突然开始报告超时和错误。
构建具有韧性的 AI agent 不仅仅需要优秀的逻辑代码。你必须为生产环境中复杂的现实情况做好准备。
以下是导致 AI agent 失效的 7 个错误以及它们的解决方法。
- 忽视外部 API 故障 开发者通常假设 API 调用总能成功。但事实并非如此。网络请求可能会因为超时或速率限制（rate limits）而失败。
- 将所有调用封装在
try-catch块中。 - 为每个请求设置特定的超时值。
- 添加带有指数退避（exponential backoff）机制的重试逻辑。
- 对故障服务使用熔断器（circuit breakers）。
- 将故障视为二元对立 许多开发者认为系统要么正常工作，要么彻底失败。但实际上，系统的某些部分可能会失效，而其他部分仍保持在线。
- 设计多层降级（fallback）策略。
- 定义功能降级后的状态。
- 利用可用组件继续处理请求。
- 日志记录和可见性不足 如果日志记录过于简略，在发生故障时你将无从下手。你无法修复看不见的问题。
- 使用不同的日志级别，如
INFO和ERROR。 - 使用请求 ID（request IDs）来追踪用户路径。
- 追踪响应时间的百分位数（p50, p95, p99）。
- 为错误率激增设置告警。
- 只测试“快乐路径”（Happy Paths） 如果你只测试成功的运行情况，你的 agent 将无法从压力中恢复。
- 使用混沌工程（chaos engineering）来测试依赖项的失效。
- 模拟网络延迟和超时。
- 使用格式错误的数据进行测试。
- 进行超出预期容量的负载测试。
- 丢失 Agent 状态 如果 agent 在未保存进度的情况下崩溃，它将丢失所有上下文。
- 在关键里程碑处保存状态检查点（checkpoint）。
- 使用幂等操作（idempotent operations）来防止重复操作。
- 存储足够的上下文以恢复工作流。
- 硬编码配置 将超时时间和 API 端点直接写在代码中会导致更新缓慢。
- 将配置移至环境变量中。
- 使用特性开关（feature flags）来控制新行为。
- 使阈值可调，而无需重新部署代码。
- 通用的错误处理 对所有错误都使用相同的修复方案是错误的。验证错误（validation error）所需的响应与网络超时完全不同。
- 将可重试错误与永久性错误区分开来。
- 重试速率限制等瞬时问题。
- 不要重试身份验证失败等永久性问题。
韧性在于编写能够预见现实情况的代码。首先，对照这七个陷阱来评估你当前的智能体。