Circuit Breaker：服务连续报错时，为什么要主动断路？
TL;DR
Circuit Breaker 通过 Closed、Open、Half-Open 状态限制持续故障的远程调用，防止重试把局部问题扩大成级联故障。本文解释它与超时、重试、限流和降级的关系，以及 Agent 调用外部工具时的用法。
Circuit Breaker 通过 Closed、Open、Half-Open 状态限制持续故障的远程调用，防止重试把局部问题扩大成级联故障。本文解释它与超时、重试、限流和降级的关系，以及 Agent 调用外部工具时的用法。
调用远程服务时，失败不一定是瞬间发生的。依赖服务可能持续超时、返回错误，或者正在恢复但还没有能力接收更多请求。如果客户端仍然不断重试，就会把局部故障扩大成级联故障。Circuit Breaker，中文常译为“熔断器”或“断路器”，就是在依赖明显不健康时主动停止调用。
三种状态
Closed 状态下，请求正常通过，断路器统计近期失败。当失败次数或比例超过阈值，状态切换为 Open，后续请求会快速失败、返回缓存或走降级逻辑，不再等待一个大概率超时的远程调用。
经过一段冷却时间后，断路器进入 Half-Open，只放行少量试探请求。如果试探成功，说明依赖可能恢复，回到 Closed；如果再次失败，则重新 Open。这种状态机让恢复过程受到控制，而不是突然把全部流量重新压给刚恢复的服务。
它和重试的关系
重试假设故障可能是短暂的，希望下一次成功；熔断器假设故障已经持续，应该暂时停止尝试。两者可以组合，但重试必须尊重熔断状态，否则每个请求内部重复几次，系统整体仍可能过载。
断路器也不是越敏感越好。阈值太低会把偶发网络抖动当成故障，阈值太高又会错过保护窗口。还要区分业务错误和基础设施错误：参数校验失败通常不应该通过重试解决。
AI Agent 为什么需要它
Agent 往往会调用多个模型、搜索服务和外部 API。没有熔断机制时，一个不可用工具可能让整个任务反复等待。成熟设计会为不同依赖设置独立断路器，记录状态变化，并为非核心工具准备有限降级路径。
读者应该记住
Circuit Breaker 的核心不是“遇到错误就拒绝”，而是用状态机限制故障扩散，并给依赖留出恢复空间。它应该和超时、重试、限流及降级策略一起设计。
