AI Agent 崩溃恢复：检查点持久化实战
AI Agent 处理一个复杂的多步骤任务需要多次 LLM 调用。如果中途进程崩溃——所有已完成的计算全部废弃，从头重来。
这不是假设场景。在生产环境中，进程崩溃的原因包括：OOM（内存溢出）、宿主机重启、部署更新、底层资源回收。
没有检查点恢复的成本
假设一个 5 步的 Agent 工作流，每步调用一次 LLM API：
步骤 1: 论文搜索（GPT-4o）→ ✅ 完成，话费 ¥0.006
步骤 2: 摘要提炼（DeepSeek）→ ✅ 完成，话费 ¥0.001
步骤 3: 趋势分析（Claude Sonnet）→ ✅ 完成，话费 ¥0.015
步骤 4: 报告生成（GPT-4o）→ 💥 崩溃！
无检查点：步骤 1-4 全部重新执行 = 额外 ¥0.022 + 额外 20s 延迟
有检查点：从步骤 4 最后一个检查点恢复 = 仅重做步骤 4
在批处理场景中，崩溃发生在第 90 步还是第 10 步，没有检查点的区别只是损失规模不同——崩溃在任何一步发生都会导致全部从头开始。
检查点恢复的工作原理
核心机制：在 Agent 执行的每个关键步骤后持久化当前状态。
Agent 开始运行
↓
步骤 1 → ✅ → 保存检查点（包含步骤 1 的输出）
↓
步骤 2 → ✅ → 保存检查点（包含步骤 1-2 的输出）
↓
步骤 3 → 💥 CRASH!
↓
Agent 恢复 → 从最后一个检查点加载 → 从步骤 3 继续执行
↓
步骤 3 → ✅ → 保存检查点
↓
...继续
检查点保存的内容
一个完整的检查点包含：
{
"checkpoint_id": "ckp_abc123",
"session_id": "session_xyz789",
"timestamp": "2026-06-21T10:30:00Z",
"step": 3,
"completed_steps": [
{"step": 1, "model": "gpt-4o", "output": "...", "cost": 0.006},
{"step": 2, "model": "deepseek-chat", "output": "...", "cost": 0.001}
],
"context": {
"original_input": "...",
"intermediate_results": {...}
},
"state": "partial"
}
关键设计：
- 检查点只保存已完成步骤的输出，不保存进行中的步骤状态（避免写一半崩溃导致数据不一致）
- 每个检查点有唯一 ID，支持幂等恢复
- 上下文（context）保留了初始入参和中间结果，确保恢复后的执行上下文完整
后端存储选型
| 存储 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 本地文件 | 零依赖、部署简单 | 进程崩溃后文件可能丢失 | 单机开发/测试 |
| Redis | 快、支持 TTL 自动过期 | 需要维护 Redis | 生产环境短任务 |
| 数据库 | 持久化、支持查询 | 写入延迟较高 | 需要审计的长任务 |
建议：开发阶段用本地文件，生产环境用 Redis。确保检查点存储和 Agent 不在同一个故障域——如果 Agent 因为磁盘满崩溃，存在同一磁盘的检查点也读不出来。
和自愈引擎的联动
检查点恢复不是独立功能——它应该和自愈引擎配合工作：
API 调用失败 → 自愈引擎（L1 重试 → L2 降级 → L3 切换）
├── 恢复成功 → 继续执行 → 保存检查点
└── 全部失败 → 保存当前状态到检查点 → 报告不可用
这样即使自愈引擎无法恢复（所有 Provider 全部不可用），Agent 也能在 Provider 恢复后从检查点继续执行，而不是完全重来。
实现注意事项
检查点写入性能：检查点写入通常在 1-5ms（本地文件）到 10-50ms（Redis）。不要在每次 LLM 调用后都写——只在关键步骤后写入（步骤边界）
检查点过期清理：设置 TTL（推荐 24h），避免磁盘/内存被过期检查点填满
敏感数据处理：检查点中如果包含用户隐私数据，建议加密存储或在保存前脱敏
序列化注意：检查点数据建议用 JSON 序列化，避免使用 pickle（版本兼容问题 + 安全风险）
NeuralBridge SDK 的检查点持久化模块支持本地文件/Redis/数据库三种后端，自动与级联自愈引擎联动。SDK 约 375 KB，仅依赖 httpx。兼容 Python 3.10–3.12，pip install neuralbridge-sdk 即可集成。
Top comments (0)