智能体面试准备七十智能体级联故障防护、熔断与自愈工程引言本篇是「工程实战深化」系列的第 70 篇智能体线也是本批收官篇。前面六十八讲了多智能体一致性与冲突消解——多个角色如何不吵架、达成共识。但生产里比「意见不一」更致命的是「一个环节挂了整条链路跟着崩」级联故障。智能体系统天然是多组件串联规划→检索→工具→反思→生成任一环节失败都会向下游传播加上「重试风暴」还会反向打爆上游。本篇把级联故障的防护讲透熔断、降级、隔离、自愈四件套辅以混沌工程验证。建议和六十八一致性、五十八多智能体容错、六十二工具沙箱、六十三人在回路一起看。1. 级联失败是怎么发生的正常: A ──▶ B ──▶ C ──▶ D (各就各位) 故障传播: B 失败 ──▶ C 拿到错误输入 ──▶ C 也错 ──▶ D 产出垃圾 (错误被放大而非被拦截) 重试风暴: B 超时 ──▶ A 重试 ×5 ──▶ B 更忙 ──▶ B 雪崩 ──▶ 拖垮 B 依赖的 E (失败反向放大, 波及无关组件)两类传播错误传播横向下游拿错误/残缺输入产出更错结果错误放大。资源传播纵向重试风暴、队列堆积把上游/共享依赖打爆波及无关链路。根因组件间缺乏「失败边界」——失败被默认「透传」没有拦截、没有降级、没有隔离。2. 熔断Circuit Breaker先断后探当某组件错误率超阈值熔断它直接短路失败避免无谓重试和雪崩过一阵半开探测恢复则闭合。状态机: Closed ──错误率阈值──▶ Open (直接失败, 不调用) ▲ │ │ │ 冷却时间到 │ ▼ └────探测成功──── Half-Open ──探测失败──▶ Open (放少量请求试探) 参数: 错误率阈值、窗口大小、冷却时间、半开放量classCircuitBreaker:def__init__(self,fail_threshold0.5,cooldown30):self.stateclosed;self.fails0;self.total0self.cooldowncooldown;self.opened_at0defcall(self,fn,*a,**k):ifself.stateopen:iftime.time()-self.opened_atself.cooldown:self.statehalf_open# 到冷却期, 半开探测else:raiseCircuitOpen(熔断中, 直接失败)try:rfn(*a,**k)self._on_success();returnrexceptException:self._on_fail();raisedef_on_fail(self):self.fails1;self.total1ifself.statehalf_open:self.stateopen;self.opened_attime.time()elifself.fails/max(1,self.total)0.5:self.stateopen;self.opened_attime.time()def_on_success(self):ifself.statehalf_open:self.stateclosed;self.failsself.total0else:self.total13. 降级Degradation失败也要给结果熔断后是「直接失败」但用户体验上往往要「给个还能用的结果」——降级降级策略做法例子缓存兜底返回上次成功结果检索失败时回退历史答案默认/静态返回安全默认值分类失败时标「待人工」能力收缩关掉非核心步骤反思失败就直接出初稿人工兜底转人工呼应六十三高风险操作交 HITL降级原则核心链路保、非核心舍不确定就交人别瞎编呼应六十安全。4. 隔离Bulkhead故障别扩散用资源/队列隔离把组件「分舱」一个舱漏水不沉船无隔离: 所有 Agent 共用一个工具线程池 → 一个慢工具占满 → 全卡 隔离: 按租户/按任务类型分线程池 各自超时 ┌─ pool_A (高优) ─┐ ├─ pool_B (普通) ─┤ 互不影响 └─ pool_C (工具X) ─┘实现手段独立线程池/协程组、每工具单独超时与并发上限、关键组件物理/逻辑隔离呼应六十二沙箱。5. 自愈Self-Healing断点续跑 重路由熔断降级是「止损」自愈是「恢复」让任务从失败点继续而不是整体重来。检查点续跑呼应二十二/六十三任务关键节点存状态失败后从最近检查点重跑不从头。重路由某子 Agent/工具不可用自动换等价实现如换模型、换检索源。状态回滚写了半成品外部状态自愈前先回滚到一致点呼应五十八灰度回滚。重试退避指数退避 抖动避免重试风暴重试带「是否幂等」判断。# 伪代码带自愈的 Agent 步骤执行defrun_step(step,state,checkpoints):forattemptinrange(1,4):try:ifbreaker[step.tool].is_open():# 熔断中returndegrade(step)# 降级兜底resultcall_tool(step.tool,state)checkpoints.save(step.id,state)# 成功即存检查点returnresultexceptTransientError:# 可重试瞬时错time.sleep(backoff(attempt))# 指数退避抖动continueexceptFatalError:altfind_alternative(step.tool)# 重路由等价实现ifalt:returncall_tool(alt,state)returndegrade(step)# 无替代→降级returndegrade(step)# 重试耗尽→降级6. 监控与混沌工程验证韧性防护不能靠「写了就信」要主动打指标各组件错误率、延迟 P99、熔断开启次数、降级触发率、重试率。混沌演练随机杀子 Agent、注入超时/异常/网络抖动看系统是否按设计熔断/降级/自愈不雪崩。演练即常态把混沌测试纳入回归呼应五十六评测门禁每次改链路都重跑。混沌工程闭环: 假设杀掉检索Agent, 系统降级不崩 │ 注入故障 ▼ 观测: 是否触发熔断? 是否降级? 主链路是否存活? │ 不符预期 ▼ 修防护逻辑 → 再演练7. 与一致性、可信性的关系一致性六十八解决「多角色意见冲突」是正确性问题。级联防护本篇解决「单点失败扩散」是可用性问题。两者正交一致性再好一个组件崩溃没防护照样全崩防护再全角色结论互相矛盾也交不出正确结果。生产系统两者都要。面试速答级联失败两类错误横向传播下游拿错输入产更错和资源纵向传播重试风暴打爆共享依赖。熔断三状态Closed正常→ Open错误率超阈直接失败→ Half-Open冷却后放少量探测成则闭合、败则回 Open。熔断和降级区别熔断是「断掉防雪崩」降级是「断了还给用户一个能用的结果」。隔离为什么重要分舱线程池/超时/并发上限让单组件故障不扩散到整条链路。自愈怎么做检查点续跑 重路由等价实现 状态回滚 指数退避重试避免整体重来。怎么验证防护有效混沌工程注入故障观测是否按设计熔断/降级/自愈、不雪崩并纳入回归。高频追问清单熔断错误率窗口怎么设太小会误触吗滑动窗口最小样本量样本不足不判定避免偶发误熔断半开探测放多少请求合适少量如 1~3 个验证恢复即闭合避免刚开就放流量再崩降级返回缓存结果会不会返回过时错误答案会故缓存带 TTL来源标注高风险场景降级转人工而非缓存重试风暴怎么从根上防熔断 指数退避 每工具并发上限 调用方限流四重叠加多智能体下熔断粒度按 Agent 还是按工具建议按「工具/依赖」粒度Agent 内多工具可独立熔断更细更稳自愈的重路由怎么保证等价不引入新问题维护等价实现清单接口契约校验切换后跑轻量冒烟测试再继续
智能体面试准备（七十）：智能体级联故障防护、熔断与自愈工程
智能体面试准备七十智能体级联故障防护、熔断与自愈工程引言本篇是「工程实战深化」系列的第 70 篇智能体线也是本批收官篇。前面六十八讲了多智能体一致性与冲突消解——多个角色如何不吵架、达成共识。但生产里比「意见不一」更致命的是「一个环节挂了整条链路跟着崩」级联故障。智能体系统天然是多组件串联规划→检索→工具→反思→生成任一环节失败都会向下游传播加上「重试风暴」还会反向打爆上游。本篇把级联故障的防护讲透熔断、降级、隔离、自愈四件套辅以混沌工程验证。建议和六十八一致性、五十八多智能体容错、六十二工具沙箱、六十三人在回路一起看。1. 级联失败是怎么发生的正常: A ──▶ B ──▶ C ──▶ D (各就各位) 故障传播: B 失败 ──▶ C 拿到错误输入 ──▶ C 也错 ──▶ D 产出垃圾 (错误被放大而非被拦截) 重试风暴: B 超时 ──▶ A 重试 ×5 ──▶ B 更忙 ──▶ B 雪崩 ──▶ 拖垮 B 依赖的 E (失败反向放大, 波及无关组件)两类传播错误传播横向下游拿错误/残缺输入产出更错结果错误放大。资源传播纵向重试风暴、队列堆积把上游/共享依赖打爆波及无关链路。根因组件间缺乏「失败边界」——失败被默认「透传」没有拦截、没有降级、没有隔离。2. 熔断Circuit Breaker先断后探当某组件错误率超阈值熔断它直接短路失败避免无谓重试和雪崩过一阵半开探测恢复则闭合。状态机: Closed ──错误率阈值──▶ Open (直接失败, 不调用) ▲ │ │ │ 冷却时间到 │ ▼ └────探测成功──── Half-Open ──探测失败──▶ Open (放少量请求试探) 参数: 错误率阈值、窗口大小、冷却时间、半开放量classCircuitBreaker:def__init__(self,fail_threshold0.5,cooldown30):self.stateclosed;self.fails0;self.total0self.cooldowncooldown;self.opened_at0defcall(self,fn,*a,**k):ifself.stateopen:iftime.time()-self.opened_atself.cooldown:self.statehalf_open# 到冷却期, 半开探测else:raiseCircuitOpen(熔断中, 直接失败)try:rfn(*a,**k)self._on_success();returnrexceptException:self._on_fail();raisedef_on_fail(self):self.fails1;self.total1ifself.statehalf_open:self.stateopen;self.opened_attime.time()elifself.fails/max(1,self.total)0.5:self.stateopen;self.opened_attime.time()def_on_success(self):ifself.statehalf_open:self.stateclosed;self.failsself.total0else:self.total13. 降级Degradation失败也要给结果熔断后是「直接失败」但用户体验上往往要「给个还能用的结果」——降级降级策略做法例子缓存兜底返回上次成功结果检索失败时回退历史答案默认/静态返回安全默认值分类失败时标「待人工」能力收缩关掉非核心步骤反思失败就直接出初稿人工兜底转人工呼应六十三高风险操作交 HITL降级原则核心链路保、非核心舍不确定就交人别瞎编呼应六十安全。4. 隔离Bulkhead故障别扩散用资源/队列隔离把组件「分舱」一个舱漏水不沉船无隔离: 所有 Agent 共用一个工具线程池 → 一个慢工具占满 → 全卡 隔离: 按租户/按任务类型分线程池 各自超时 ┌─ pool_A (高优) ─┐ ├─ pool_B (普通) ─┤ 互不影响 └─ pool_C (工具X) ─┘实现手段独立线程池/协程组、每工具单独超时与并发上限、关键组件物理/逻辑隔离呼应六十二沙箱。5. 自愈Self-Healing断点续跑 重路由熔断降级是「止损」自愈是「恢复」让任务从失败点继续而不是整体重来。检查点续跑呼应二十二/六十三任务关键节点存状态失败后从最近检查点重跑不从头。重路由某子 Agent/工具不可用自动换等价实现如换模型、换检索源。状态回滚写了半成品外部状态自愈前先回滚到一致点呼应五十八灰度回滚。重试退避指数退避 抖动避免重试风暴重试带「是否幂等」判断。# 伪代码带自愈的 Agent 步骤执行defrun_step(step,state,checkpoints):forattemptinrange(1,4):try:ifbreaker[step.tool].is_open():# 熔断中returndegrade(step)# 降级兜底resultcall_tool(step.tool,state)checkpoints.save(step.id,state)# 成功即存检查点returnresultexceptTransientError:# 可重试瞬时错time.sleep(backoff(attempt))# 指数退避抖动continueexceptFatalError:altfind_alternative(step.tool)# 重路由等价实现ifalt:returncall_tool(alt,state)returndegrade(step)# 无替代→降级returndegrade(step)# 重试耗尽→降级6. 监控与混沌工程验证韧性防护不能靠「写了就信」要主动打指标各组件错误率、延迟 P99、熔断开启次数、降级触发率、重试率。混沌演练随机杀子 Agent、注入超时/异常/网络抖动看系统是否按设计熔断/降级/自愈不雪崩。演练即常态把混沌测试纳入回归呼应五十六评测门禁每次改链路都重跑。混沌工程闭环: 假设杀掉检索Agent, 系统降级不崩 │ 注入故障 ▼ 观测: 是否触发熔断? 是否降级? 主链路是否存活? │ 不符预期 ▼ 修防护逻辑 → 再演练7. 与一致性、可信性的关系一致性六十八解决「多角色意见冲突」是正确性问题。级联防护本篇解决「单点失败扩散」是可用性问题。两者正交一致性再好一个组件崩溃没防护照样全崩防护再全角色结论互相矛盾也交不出正确结果。生产系统两者都要。面试速答级联失败两类错误横向传播下游拿错输入产更错和资源纵向传播重试风暴打爆共享依赖。熔断三状态Closed正常→ Open错误率超阈直接失败→ Half-Open冷却后放少量探测成则闭合、败则回 Open。熔断和降级区别熔断是「断掉防雪崩」降级是「断了还给用户一个能用的结果」。隔离为什么重要分舱线程池/超时/并发上限让单组件故障不扩散到整条链路。自愈怎么做检查点续跑 重路由等价实现 状态回滚 指数退避重试避免整体重来。怎么验证防护有效混沌工程注入故障观测是否按设计熔断/降级/自愈、不雪崩并纳入回归。高频追问清单熔断错误率窗口怎么设太小会误触吗滑动窗口最小样本量样本不足不判定避免偶发误熔断半开探测放多少请求合适少量如 1~3 个验证恢复即闭合避免刚开就放流量再崩降级返回缓存结果会不会返回过时错误答案会故缓存带 TTL来源标注高风险场景降级转人工而非缓存重试风暴怎么从根上防熔断 指数退避 每工具并发上限 调用方限流四重叠加多智能体下熔断粒度按 Agent 还是按工具建议按「工具/依赖」粒度Agent 内多工具可独立熔断更细更稳自愈的重路由怎么保证等价不引入新问题维护等价实现清单接口契约校验切换后跑轻量冒烟测试再继续