一个依赖慢下来，可能拖住很多正常任务
假设企业AI助手每次回答都要调用外部检索服务。该服务持续失败后，新的请求仍不断进入，每个任务都等待、超时、重试。虽然单个任务设置了次数限制，整个系统依然可能堆积大量等待中的工作。这里讨论的是假设场景，不代表任何具体服务当前存在故障。
这时需要解决的不是再给每个任务一次机会，而是判断共享依赖是否暂时不值得继续调用。断路器是一种可选设计：当失败达到约定条件，短时间阻止继续访问，并通过受控方式观察恢复。它不负责修好对方系统，也不能代替任务状态、异常处理和业务补偿。
先确定坏的是一条数据，还是一类依赖
格式错误、权限不足、资源不存在和服务暂时不可用，处理方式不应混在一起。一条输入本身无效，反复等待不会让它变正确；某个账号失去权限，也未必意味着其他账号都不可用。若把所有失败都算作共享故障，可能误伤原本能够正常处理的请求。
可以先按依赖目标、操作类型和错误类别记录证据，再决定在哪个范围暂停。是否需要按租户、地区或功能拆分，要看实际故障隔离边界。划得太宽会让局部问题影响更多业务，划得太细则可能看不到共同依赖的持续异常。设计需要有理由，而不是直接复制一个默认配置。
业务团队也应参与区分哪些失败必须显式处理。例如权限失效需要修复授权，额度问题可能需要负责人决策，数据错误要回到输入方。断路提示不能把这些原因统统写成“系统忙”。原因不同，下一步负责的人和能够采取的措施也不同。
暂停与恢复，都需要明确条件
Microsoft的模式说明把断路过程描述为正常放行、暂停访问和有限试探等状态。本文引用这一基本机制，不把文档中的示例参数当成所有AI项目的标准。实际阈值应结合流量、可接受等待和依赖恢复特点确定，并记录为什么作出这种选择。
暂停期间，调用方应尽快得到可解释的状态，而不是再进入另一层无限重试。若上层仍不断重复请求，断路器只是把等待搬了位置。需要检查各层重试配置，让它们理解当前依赖处于暂停状态，并按业务约定结束、延期或转人工。
恢复时也不应一下放回全部积压。可以允许有限的试探请求，在证据满足条件后逐步恢复；试探继续失败则回到暂停。具体并发和观察条件需要测试。单次健康检查成功未必代表真实业务请求可用，探测应尽量覆盖关键依赖路径，同时避免造成真实业务副作用。
降级方案必须仍然说真话
某些只读任务可以显示已有缓存或暂时减少非核心功能，但应注明信息时间与限制。需要实时数据的判断，不应悄悄用旧资料替代；需要外部系统确认的动作，也不能为了页面看起来顺畅而显示成功。降级是改变可提供的服务，不是隐藏失败。
切换到另一模型或提供方也不是纯技术按钮。输出能力、数据处理边界、费用和业务规则可能不同，需要事先评估并获得适用授权。没有准备好的替代方案时，明确告知暂时无法完成、保留任务并给出后续入口，比临时把数据送往未知服务更可靠。
用户界面可以说明哪一步不可用、已经完成哪些内容、是否会自动继续，以及能否安全再次提交。别让用户面对一个没有上下文的错误码，也别诱导他不断点击重试。如果重试可能产生重复动作，页面和后台都需要相应保护，不能只靠用户小心操作。
把积压任务的去向也设计进去
暂停访问以后，原本等待的任务如何处理，是交付方案的一部分。可以按业务允许的方式延期、结束或进入人工队列，但必须可追踪。不要在依赖恢复后无条件把所有旧任务重新执行，因为其中部分可能已经过时、被取消或由人工完成。
恢复前重新检查任务状态、输入版本和动作条件，能避免系统“补做”已经不需要的事情。如果任务涉及写入，应先确认先前尝试有没有留下结果。断路器控制是否调用依赖，并不证明前一次调用没有生效，这个不确定性仍然需要独立处理。
维护记录还应回答是谁触发了暂停、观察到什么错误、何时允许试探、如何判断恢复。可以记录聚合指标与必要任务标识，不必复制所有请求正文。这样运营人员能够理解故障影响范围，也不会为了排查一次依赖问题而制造过量敏感日志。
用故障演练检验它有没有帮上忙
在测试环境模拟持续失败，确认触发后实际调用量受到限制；模拟短暂失败，确认不会轻易让正常业务长期停摆；恢复依赖后，观察试探是否有限、状态是否正确回到正常。还要检查多个服务实例的行为，避免每个实例都独立大量探测，合起来仍压垮依赖。
业务验收同时看用户状态：任务没有被误写为成功，积压有去向，恢复后没有重复动作，人工处理能够找到证据。如果现有平台已经提供可靠的隔离与恢复机制，应先评估是否足够，不必为了多一个架构名词再叠一层复杂状态。
上线后也要复核配置是否适合新流量。请求数量变化、依赖拆分或业务优先级调整，都可能改变原先阈值的意义。把配置、观察记录和回退方式放进交接文档，后续维护者才有能力判断应继续等待、强制暂停还是恢复，而不是只能重启系统碰运气。
断路器有价值的地方，是在共享故障发生时限制影响、保留清楚状态并有序恢复。企业AI项目不需要把每一次失败都包装成自动解决；需要的是系统知道什么时候不该再试，以及暂停以后如何把事情交代明白。
要点总结
- 视故障和现有基础设施而定。重试关注再次尝试，断路器关注持续故障期间限制调用，未必每个项目都需要叠加。
- 不应默认如此。应按已验证的恢复条件和负载情况受控恢复。
- 只有业务允许且明确标注范围时才可提供替代结果，不能把旧数据或未执行动作伪装成完成。
参考来源说明
本文提出可供业务团队评估的方法，示例不代表真实客户项目。官方资料仅用于核对对应技术机制，站内服务页用于了解业务范围，不作为效果证明。