很多团队第一次谈 AI agent 容灾时，想到的还是熟悉的 Web 系统语言：数据库备份、服务多活、DNS 切流、跨区部署。这些当然都重要，但它们只回答了“服务还能不能起得来”，没有回答 AI agent 最棘手的那部分问题：当一个 run 已经跑到中途，手里拿着 session、artifact、外部副作用和人工 review 状态时，如果某个区域真的挂了，系统到底该怎么继续，而不是简单重启一轮。
AI agent 的 regional failover 之所以比普通应用更难，是因为它不是 stateless request。它有尚未完成的计划、尚未落地的副作用、尚未归档的中间产物，还有可能卡在外部回调或人工审批边界。你如果把容灾理解成“把流量切到另一个区”，系统表面上也许恢复得很快，但正在执行的任务很可能已经失去了上下文连续性。这样的平台看起来可用，实际上只是把故障从基础设施层转移到了执行语义层。
所以 AI agent 的 disaster recovery 真正要解决的，是跨区后这次 run 是否还能被系统继续理解。只要这个问题没回答清楚，所谓 failover 很容易只是换了地方继续混乱。
建议配合 AI agent Session Store 设计、AI agent Harness 崩溃恢复与 Wake 流程、AI agent 多执行环境路由 和 AI agent Data Residency 与 Regional Placement 一起看。
先别把故障切分成“服务级”，先看 run 级损伤
| 故障位置 | 对普通 Web 应用意味着什么 | 对 AI agent 额外意味着什么 |
|---|---|---|
| 控制面故障 | 新请求无法调度 | 正在运行的 run 失去状态推进器 |
| Session Store 故障 | 数据暂时读不到 | wake、resume、审计和补偿全失去锚点 |
| Runner 区域故障 | 某类任务暂时不可执行 | 浏览器上下文、文件状态和副作用冻结边界失真 |
| 对外依赖区域故障 | 某些调用失败 | 可能触发跨区 fallback，引发 residency 和权限问题 |
这张表的重点是：AI agent 容灾不能只盯服务健康，因为真正被破坏的是“正在进行中的任务语义”。
真正危险的是“半失败”：新任务能跑，旧任务却醒不过来
平台发生区域故障后，团队最容易被一个表面好消息迷惑：新任务已经能在备用区跑起来了。可如果旧任务还醒不过来，问题其实没有真正结束。因为企业客户最看重的，往往不是“现在又能发新请求了”，而是“昨天做到一半的那批任务还能不能继续”。
这就是 why failover 必须先回答 resume boundary：
- 哪些 run 可以原位继续
- 哪些 run 只能从最近 checkpoint 恢复
- 哪些 run 因副作用状态不明，必须进入人工确认
一旦这层边界不清，备用区恢复得越快，平台反而越容易把历史任务遗留成一片看不见的债务。
跨区 failover 最怕“状态复制到了，解释没复制到”
很多平台会做 session 数据复制、artifact 归档复制、对象存储镜像。可如果这些副本只是字节意义上的复制，而不是执行意义上的可读，备用区依然救不了真正的 run。比如：
- session event 复制过去了，但 policy version 没跟过去
- artifact 有备份，但旧 runner 的 execution context 不可重建
- callback token 还在原区，备用区无法接续外部结果
这类问题最麻烦的地方，是它们不会在演练第一页就暴露。你往往得在真正尝试 resume 某类具体 run 时，才发现“数据明明都在，可系统其实看不懂这份历史现在该怎么接”。
一个典型事故：DNS 切成功了，客户却觉得系统更乱了
某团队给 AI 运维 agent 做了跨区切流。某次主区对象存储异常后，他们在 15 分钟内就把入口切到了备用区。从基础设施指标看，这次容灾很成功。可客户体验却很差，原因在于：
- 新任务确实能创建
- 旧任务里一部分还能继续，一部分被重复执行，一部分则长期停在
running - 支持团队也说不清哪些 run 该重试，哪些该等待
问题不在切流本身，而在 failover 没有显式区分 run recovery class。后来他们修的第一件事不是更快切 DNS，而是给 run 增加容灾分类：resumeable、checkpoint_only、manual_gate。这个分类一旦存在，支持、工程和平台调度终于不再在故障时各自猜测。
真正该先补的，是故障时的决策顺序，而不是更复杂的架构图
如果你现在只能先做一层，优先不是补更花哨的多活架构图，而是写清楚：区域故障发生后，平台先冻结什么、再恢复什么、哪些 run 能自动继续、哪些 run 必须人工确认、哪些外发动作要继续保持冻结。只要这个顺序没有被制度化，灾备切换就永远只是基础设施动作，不是业务连续性动作。
AI agent 的容灾真正考验的，不是你有没有第二个区域，而是第二个区域能不能接住第一 个区域没做完的那件事。能接住，才叫 failover；接不住，只是重新开始。
延伸阅读：
