「子 Agent 挂了怎么办？「 —— 你要讲清关键/增强任务分级、重试/跳过/降级策略
P1 · agent_architecture
🏷 标签：multi-agent, fault-tolerance, retry, degradation
1️⃣ 考察意图
面试官想考察你对多 Agent 系统在分布式环境下的容错工程能力，而非单纯背诵概念。刁钻点在于：子 Agent 故障不是“会不会挂”，而是“挂了后系统如何优雅地不崩、不丢数据、不阻塞主流程”。答好了能展示你对任务优先级建模、重试与幂等性、降级与人工兜底的实战理解，以及从单体 Agent 到多 Agent 协调的架构演进思维。
2️⃣ 标准答
核心思路：将子 Agent 任务按业务影响分级，对每级制定不同的故障处理策略，并配合监控与自动恢复。
1. 任务分级：关键 vs 增强
- 关键任务：失败会直接导致主流程中断或数据不一致。例如支付 Agent 的扣款、订单 Agent 的状态更新。必须保证最终成功或进入人工兜底。
- 增强任务：失败不影响主流程完整性，只影响体验或附加功能。例如推荐 Agent 的个性化排序、日志 Agent 的详细记录。可跳过或降级。
- 工程取舍：分级需要业务方明确“可接受的最差结果”。例如电商场景，库存扣减是关键的，但库存预占（锁库存）可降级为乐观锁重试，因为超卖风险小于订单失败风险。
2. 重试策略：指数退避 + 幂等性
- 关键任务：设置重试次数上限（通常 3-5 次），采用指数退避（如 1s、2s、4s、8s），避免雪崩。必须保证重试幂等：例如支付 Agent 用唯一请求 ID（UUID）去重，库存 Agent 用事务 ID 防止重复扣减。
- 增强任务：重试 1-2 次，间隔固定（如 500ms），失败即跳过。
- 实际坑：重试可能导致“惊群效应”——多个子 Agent 同时重试压垮下游。解法：加入随机抖动（jitter），在退避时间上加减 10-20% 随机值。例如退避 2s，实际等待 1.8-2.2s。
3. 跳过策略：熔断 + 降级
- 增强任务：连续失败 3 次后，熔断该子 Agent 调用（如 Hystrix 或 Sentinel 的熔断器），直接返回默认值（如空推荐列表、默认日志级别），并记录异常。熔断时间窗口（如 30s）后尝试半开恢复。
- 关键任务：不能跳过，但可降级。例如支付 Agent 失败后，降级为“异步重试队列 + 人工审核”。库存 Agent 失败后，降级为读取缓存中的库存快照（允许短暂不一致），并标记订单为“待确认”。
4. 降级策略：人工兜底 + 默认结果
- 关键任务降级：设计人工处理队列。例如支付 Agent 连续重试 5 次失败后，将订单推入“待人工处理”队列，并发送告警。人工审核后手动触发重试或退款。
- 增强任务降级：返回默认结果。例如推荐 Agent 失败，返回热门商品列表；日志 Agent 失败，降级为本地文件记录，后续异步上传。
- 工程取舍：降级策略需权衡一致性与可用性。支付场景强一致性优先，宁可人工处理也不允许重复扣款；推荐场景可用性优先，默认结果比无结果好。
5. 监控告警：健康检查 + 自动恢复
- 健康检查：每个子 Agent 暴露
/health端点，主 Agent 或协调器（如 Celery、Kubernetes Liveness Probe）定期探测（如 5s 间隔）。连续 3 次失败标记为“不健康”。 - 自动恢复：不健康子 Agent 触发重启（如 K8s 重启 Pod）或切换备用实例。恢复后自动重试挂起的任务。
- 告警：失败次数超过阈值（如 10 次/分钟）时，通过 PagerDuty/钉钉/邮件通知值班人员。告警需包含失败原因、影响范围、降级状态，避免噪音。
总结：分级是基础，重试保证关键任务最终成功，跳过/降级保证增强任务不阻塞主流程，监控告警兜底。核心是让系统在故障时仍能提供可接受的服务，而非追求 100% 可用性。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从任务分级、重试/跳过/降级策略、监控恢复三个层面回答。首先，将子 Agent 任务分为关键和增强两类，关键任务必须最终成功，增强任务可跳过。其次，关键任务用指数退避重试 + 幂等性保证，增强任务失败 3 次后熔断降级为默认值。最后，通过健康检查和自动恢复机制兜底。总结一句：核心是让系统在故障时优雅降级，而非崩溃。”
4️⃣ 高频追问 & 应对
追问 1：重试时如何保证幂等性？如果下游不支持幂等怎么办？
幂等性依赖唯一请求 ID（UUID），下游服务需在数据库或缓存中记录已处理的 ID。如果下游不支持，有两种解法：一是业务层去重，例如支付场景，用订单号+支付金额作为唯一键，在支付网关侧做去重；二是改用“补偿事务”，先执行操作，失败后通过反向操作（如退款）回滚，而非重试。工程取舍：业务去重增加代码复杂度，但避免依赖下游改造；补偿事务适合最终一致性场景，但需处理补偿失败的情况。
追问 2：如果所有子 Agent 都挂了，主 Agent 怎么办？
主 Agent 自身需有超时熔断机制。例如设置全局超时时间（如 30s），超时后直接返回“系统繁忙”或“稍后重试”给用户。同时，主 Agent 将整个请求上下文（包括失败原因）写入死信队列（如 Kafka/RabbitMQ），由后台定时任务重试或人工处理。关键点：主 Agent 不能无限等待，必须给用户一个明确反馈，避免请求堆积。
追问 3：如何设计降级策略的优先级？比如库存和支付同时失败，先降级哪个？
降级优先级取决于业务影响。通常支付失败影响最大（用户无法完成购买），库存失败次之（可能超卖但可后续处理）。设计时用决策树：先判断支付是否成功，失败则直接进入人工兜底；支付成功后，库存失败可降级为缓存数据。工程取舍：降级优先级需与业务方对齐，并写在配置中心（如 Apollo/Nacos），支持动态调整，避免硬编码。
5️⃣ 避坑 · 常见错误答法
- ❌ “所有子 Agent 失败都重试 3 次，不行就报错。” → ✅ “必须区分关键和增强任务，关键任务重试+降级，增强任务跳过+熔断，避免阻塞主流程。”
- ❌ “重试用固定间隔，比如 1 秒一次。” → ✅ “用指数退避 + 随机抖动，防止雪崩和惊群效应。”
- ❌ “降级就是返回空结果。” → ✅ “降级需返回业务可接受的默认值（如热门推荐、缓存数据），并记录异常，方便后续排查。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“检索 Agent 挂了怎么办”切入，说明如何将检索失败降级为 BM25 或缓存结果，重试时用指数退避避免压垮向量库。
- 如果你只做过传统 NLP：用“微服务熔断”类比，说明子 Agent 故障类似微服务调用失败，重试/降级策略可复用 Hystrix 或 Sentinel 的熔断器模式。
- 如果你是校招无项目：聚焦论文复现，例如 AutoGPT 或 MetaGPT 的故障处理设计，说明如何用任务队列（如 Celery）实现重试和降级，并给出 demo 代码片段。
7️⃣ 延伸阅读
- 《Building Microservices》第 11 章：Resilience Patterns（熔断、重试、超时）
- 《Designing Data-Intensive Applications》第 8 章：Faults and Partial Failures
- 论文：AutoGPT 的故障恢复机制（GitHub 源码分析）
- 工具：Hystrix 熔断器文档、Sentinel 降级策略
- 博客：Uber 的“Chaos Engineering for Microservices”实践