自动化越深入核心业务，平台一旦停摆的影响就越大——月末结账跑一半、跨行资金归集中断、千个机器人集体掉线，都是企业扛不住的事故。因此，企业级智能体自动化平台不能只讲"能跑"，还要讲"跑不断"。容灾与业务连续性（BCP），是平台进入生产核心前的必答题。在 RPA+AI 架构下，既要保证 iS-RPA（执行机器人）的高可用，也要保证决策层 Magical Automator（自动化魔术师）服务的连续性。
一、高可用不是"加台机器"这么简单
高可用要让单点故障不中断业务。关键设计包括：控制面与执行面分离，执行节点无状态可随时接管；任务可续跑，中断后从断点恢复而非重头再来；多副本与负载均衡，流量自动绕过故障节点。某股份制银行把 500 余个流程在 35 个以上部门复用，规模之下仍能稳定，离不开底层的弹性与多租户隔离设计。
二、故障转移要快、要可验证
故障转移分两层：
执行层：某个机器人节点挂了，任务漂移到健康节点，业务无感；
模型层：推理服务异常时，可降级到规则或备用模型，保证关键动作不中断。
某保险集团黑灯工厂的监控看板配合虚拟运行环境，让运行事件实时可见，场景从 80 个扩展到 150 个仍稳，正是"看得见、切得动"的体现。
三、演练比建设更重要
容灾能力"配完即忘"是大忌。建议定期做故障注入演练：主动关掉一个节点、掐断一条链路，验证转移是否真生效、数据是否零丢失。只有演练过的容灾，才叫容灾。
四、业务连续性视角
落到业务：要明确"哪些流程不可中断"（如资金归集、监管报送），给它们优先的可用等级与优先调度；其余流程可在资源紧张时降级。某全国性保险集团的蜂巢模式以任务队列承载海量请求，靠幂等重试保证中断后不重复、不遗漏。
五、度量与持续改进
容灾能力要用指标说话：恢复时间目标（RTO）、恢复点目标（RPO）、年故障次数、演练通过率。建议把这些指标纳入平台运行看板，定期复盘。某全国性保险集团的蜂巢模式以任务队列承载海量请求，靠幂等重试保证中断后不重复、不遗漏——这种"可度量、可演练"的思路，是业务连续性的底层保障。
六、组织保障与责任划分
容灾不是纯技术问题，要落到责任。建议明确三件事：一是"谁定义不可中断流程"，由业务方拍板，而非技术方自定；二是"谁来做故障注入演练"，纳入常规运维节奏，而非出事才想；三是"指标谁来看"，把 RTO、RPO、演练通过率挂到运行看板并设置负责人。
很多团队把容灾写成文档却从不动手验证，结果真出故障时转移不生效。要避免这点，演练必须常态化、场景化：模拟节点宕机、网络分区、模型服务不可用，逐一验证转移与降级是否真生效。某全国性保险集团的蜂巢模式以任务队列承载海量请求，靠幂等重试保证中断后不重复、不遗漏——这种"平时练、急时用"的机制，是业务连续性的底气。
落地检查清单
控制面与执行面是否分离、节点是否无状态
任务是否支持断点续跑而非重头再来
执行层与模型层是否都有故障转移
是否定期做故障注入演练
关键流程是否设优先可用等级
