智能体调用外部工具时，如果依赖服务迟迟不响应，等待的不只是当前任务：后续请求也可能继续进入，挤占系统资源。熔断与降级的作用，是在故障扩大前限制调用，并让业务转入可控的替代路径，而不是让智能体不断尝试直到给出结果。
熔断解决故障扩散
超时和熔断各有职责。超时为单次调用或整条任务设定等待边界，避免多轮推理与工具调用无限拖延；熔断则在依赖持续异常时，暂时停止向其发送新请求，减少故障向上下游传播。两者应分别覆盖任务整体和关键依赖，不能只给模型推理设置限制，却遗漏外部工具。
触发判断需要区分故障类型：网络抖动、调用超时和依赖不可用，适合纳入服务可用性判断；参数校验失败或权限不足，则应先检查请求和授权，不能简单归咎于依赖故障。熔断开启后，还需要有受控的恢复检查，确认依赖已恢复，再逐步放开调用，避免故障尚未消除就重新积压请求。
降级必须守住业务边界
熔断只决定“不再调用”，降级还要回答“接下来怎么办”。对于可以用明确规则处理的任务，可切换至传统规则引擎；当信息不足、规则无法覆盖或工具持续报错时，应暂停自动操作并转交人工。置信度不足可以作为回退信号，但不应单独承担关键业务的安全判断。
降级不能绕过原有权限和审批门禁。例如，涉及付款指令或系统权限变更时，依赖故障不应使系统自动放行；更安全的做法是保留建议、停止执行，等待人工复核。若故障发生在外部动作发出之后、结果返回之前，还应先核查动作是否已经生效，再决定是否重试或人工接管，避免重复操作。
验收时，应模拟推理超时、工具连续报错和依赖不可用，检查熔断是否按预期触发、任务是否进入指定回退路径，以及调用记录能否支持排查。恢复条件和人工承接责任也要预先明确，否则“已经降级”可能只是把故障转移给了无人处理的队列。