多 Agent 协作时，如何处理一个 Agent 失败的情况

多 Agent 协作时，如何处理一个 Agent 失败的情况

1️⃣ 考察意图

面试官想看你的容错设计能力。刁钻点在于：Agent 失败不是简单的"重试"，而是需要区分"瞬时故障"（网络超时）和"持久故障"（Agent 代码有 bug），以及处理"部分成功"（Agent 完成了 3/5 个子任务后崩溃）的复杂场景。答好了能展示你的分布式系统容错思维。

2️⃣ 标准答

Agent 失败处理采用"分类诊断 + 分级容错 + 状态恢复"三层架构。

1. 失败分类诊断

2. 分级容错策略

L1: 自动重试（瞬时故障）

• 机制：捕获异常 → 指数退避重试 → 最多 3 次
• 关键：幂等性——重试时确保操作不会重复执行（如发邮件只发一次）。用 idempotency_key 做去重
• 适用：网络超时、API 限流、临时不可用

L2: Agent 切换（持久故障）

• 机制：重试 3 次失败 → 标记 Agent 为 unhealthy → 从 Registry 查找同能力的备份 Agent → 传递上下文后继续执行
• 关键：上下文传递——切换时打包已完成的结果和待办事项，新 Agent 从断点继续而非从头开始
• 适用：Agent 进程崩溃、代码 bug、工具不可用

L3: 任务降级（复杂故障）

• 机制：切换 Agent 也失败 → 将任务拆分为更小的子任务 → 分配给多个 Agent 并行处理 → 合并结果
• 关键：任务拆分策略——按子任务边界拆分（如"写报告"拆为"写引言"+"写正文"+"写结论"），而非随意切割
• 适用：任务复杂度超过单个 Agent 能力、多 Agent 协作失败

L4: 熔断 + 人工介入（严重故障）

• 机制：连续 N 个任务失败 → 触发熔断（暂停所有同类任务）→ 告警通知人工介入 → 提供完整诊断报告
• 关键：熔断阈值——5 分钟内失败率 > 50% 或连续 3 个任务失败
• 适用：系统性故障（如 LLM API 大面积宕机）、Agent 代码有严重 bug

3. 状态恢复（Checkpoint 机制）

Agent 每完成一步都保存 Checkpoint 到持久化存储：

{ "task_id": "task_123", "agent_id": "agent_coder_01", "step": 3, "total_steps": 5, "completed_subtasks": ["写引言", "写正文"], "pending_subtasks": ["写结论", "格式检查"], "intermediate_results": {"intro": "...", "body": "..."}, "timestamp": "2025-01-15T10:30:00Z" }恢复流程：(1) 从存储加载最新 Checkpoint；(2) 跳过 completed_subtasks；(3) 从 pending_subtasks 的第一个开始继续执行。

4. 死锁检测与解除

多 Agent 系统可能形成循环等待（A 等 B 的结果 → B 等 C → C 等 A）：

• 检测：构建等待图（Wait-for Graph），如果图中有环则存在死锁。每 30 秒检查一次
• 解除：选择代价最小的 Agent 终止（如已做工作最少的），让其任务重新分配。通知用户"检测到死锁，已自动恢复"

3️⃣ 答题模板（30 秒电梯版）

"Agent 失败处理三层架构：分类诊断——区分瞬时故障（重试）、持久故障（切换Agent）、部分成功（Checkpoint恢复）、死锁（等待图检测）。分级容错——L1 自动重试（指数退避3次）、L2 Agent切换（传上下文给备份）、L3 任务降级（拆分子任务）、L4 熔断+人工介入。状态恢复——每步保存Checkpoint到Redis，恢复时跳过已完成步骤。死锁检测——等待图找环，终止代价最小的Agent。总结一句：容错不是'失败了重试'而是'分类诊断+分级处理+状态恢复'。"

4️⃣ 高频追问 & 应对

追问 1：Checkpoint 保存频率太高会影响性能，怎么平衡？

自适应 Checkpoint：(1) 按步骤保存——每个"关键步骤"后保存（如工具调用后、子任务完成后），而非每条 LLM 消息后。减少 50% 的 Checkpoint 次数；(2) 异步保存——Checkpoint 写入 Redis 是异步的，不阻塞 Agent 执行。用 write-behind cache 模式，先写内存再异步持久化；(3) 增量保存——只保存 state 的 diff（类似 Git），而非全量。实测：自适应 Checkpoint 的性能开销 <5%，恢复时间 <3s。

追问 2：Agent 输出格式正确但质量差（如代码能跑但写得烂），怎么检测和处理？

质量检测三层：(1) 自动检测——用 lint 工具（如 flake8、eslint）检查代码质量，用规则检查文档结构（如是否有引言/正文/结论）；(2) LLM 评审——用另一个 LLM 评估输出质量（"这段代码的可读性/正确性/效率如何？打分 1-5"），低于 3 分触发重写；(3) 对比基线——与历史高质量输出做 embedding 相似度比较，偏离基线 >30% 触发审查。处理：质量分 < 3 → Self-Reflection 重写一次；重写后仍 < 3 → 切换 Agent；切换后仍 < 3 → 降级为"草稿"并标记需人工审查。

追问 3：多 Agent 系统中，一个 Agent 的失败会不会导致"雪崩效应"？

可能。雪崩场景：Agent A 失败 → A 的任务重分配给 B → B 负载过载也失败 → B 的任务重分配给 C → 全系统崩溃。防御：(1) 熔断器——Agent 连续失败 3 次后暂停 5 分钟（冷却期），不立即重分配任务；(2) 负载上限——Agent 的 active_tasks 有硬上限（如 max 5），超过不分配新任务；(3) 降级而非重分配——系统过载时，非关键任务直接返回"系统繁忙请稍后"而非分配给已过载的 Agent；(4) 资源隔离——不同 Agent 运行在不同容器/进程中，一个 Agent crash 不影响其他 Agent。

5️⃣ 避坑 · 常见错误答法

• ❌ "失败了就重试" → ✅ "盲目重试对持久故障无效——如果是代码 bug，重试 100 次还是失败。需要先分类失败原因：瞬时故障重试，持久故障切换 Agent，系统性故障熔断。"
• ❌ "每个 Agent 都要有备份" → ✅ "全量备份成本高（2 倍资源）。生产实践：关键 Agent（如唯一能执行特定工具的）有备份，非关键 Agent（如多个同构代码 Agent）靠负载均衡自然冗余。"
• ❌ "Checkpoint 太占存储了" → ✅ "Checkpoint 用增量存储（只存 diff）+ TTL 过期（7 天后清理），单次 Checkpoint 约 1-5KB。1000 个任务的 Checkpoint 总量 < 5MB，存储成本可忽略。"

6️⃣ 简历呼应

• 如果你有分布式系统经验：从"容错设计"切入，描述你实现的 Checkpoint/熔断/故障转移机制，给出 MTTR（平均恢复时间）和可用性数据（如 99.9%）
• 如果你只做过单 Agent：用"单 Agent 的 try-catch vs 多 Agent 的分布式容错"切入，说明多 Agent 容错的核心挑战是"部分失败"和"状态一致性"
• 如果你是校招无项目：实现一个带 Checkpoint 和熔断机制的 3-Agent 系统，模拟 Agent 崩溃并测试恢复时间，写一篇博客
• "Designing Fault-Tolerant Multi-Agent Systems" (Ji et al., 2024)
• "Circuit Breakers in Distributed Systems" (Richardson, 2018)
• "Checkpoint/Restart for AI Workloads" (Kurt et al., 2023)