把自动化搬到容器、微服务这套架构上，很多团队的直觉反应是"把进程塞进容器"。跑起来之后问题才出来：任务重启后状态丢了、某台机器上的实例异常影响了一批任务、容灾演练时才发现切过去根本跑不动。架构问题不会自己消失，只会换一个地方出现。
一、先给结论
结论是：云原生化之后，自动化系统要重新分成接入层、编排层、执行层、治理层四层，每层各司其职；同时有三项必须在上线前真实验证——状态恢复、容量弹性、容灾切换。自动化属于企业级智能体自动化里对状态一致性要求较高的一类，架构红利要拿到，得先把这三项验掉。
二、四层结构各管什么
- 接入层：接收任务、校验入参、生成幂等键，负责把外部世界的随机性挡在门外。
- 编排层：决定任务顺序、依赖关系、重试策略与超时口径，不看具体实现。
- 执行层：真正干活的部分，负责与业务系统交互，做到可中断可续跑。
- 治理层：留痕、监控、告警、回放，负责出问题之后能不能说清楚。
分层的判断标准很简单：某一层的改动，是否需要对其他层做连带修改。如果需要，说明分层没做干净。我们一般用 3 到 5 个工作日做一次分层评审，评审通过后边界不再轻易变动。三、状态恢复要排在前面
任务在容器里被调度走，状态就留在了上一个实例上。执行层必须把"中间状态"写进外部存储，而不是留在内存里。常见做法是每完成一个可确认的步骤就落一次快照，重启后按快照续跑，而不是从头再来。快照粒度按外部系统的写入能力定，太粗会重复执行，太细则拖慢正常流程。我们的经验是控制在 10 个以内的写入动作落一次快照，这样既不会重复作业，也不会因为快照过密把正常流程拖慢。四、容灾切换不能只演练"切得过去"
很多团队的容灾演练只验证控制平面切换，不验证任务本身能在备用环境跑完。我们要求演练必须执行一次完整的业务任务：从接入到终态，包括依赖的外部系统是否可达、凭证是否可用、日志是否能回捞。演练频率建议每季度 1 次、每次覆盖 3 种失败注入，并且要覆盖"备用环境资源不足"这种降级情形，而不只是正常切换。五、我们踩过的三个具体坑
- 把会话状态放在实例本地。实例被调度走，任务随即失败。改为外部存储快照后，恢复成功率从不稳定走向稳定。
- 并发上限按实例数估算。扩容之后总并发超过外部系统承受范围，触发限流。改为按外部系统能力反推并发上限。
- 告警只看任务失败数。积压涨到几千条时任务仍在"运行中"，没有告警。补了积压与时效两类指标才及时。
六、行业里已经跑到什么规模
公开资料里可以看到这类系统的实际运行形态：某保险集团的运行机器人规模达到 2000 多个，另有保险场景在同一时间点的资源占用可以压到 CPU 1% 的量级，并发会话能力在 10000 以上。这些数字的前提都是状态外置与弹性调度做到了位，否则规模上去之后恢复与切换会更难。七、怎么验证这套机制真的生效
- 状态恢复成功率：中途终止实例后按快照续跑，成功完成的比例，按 100 个实例抽样统计。
- 弹性响应时长：负载上升到 2 倍后，新实例投入服务所需分钟数。
- 容灾演练通过率：完整业务任务在备用环境跑通的比例。
- 积压告警命中次数：因积压或时效触发告警的天数占比。
这四项建议每月看一次，容灾演练通过率的下降往往早于故障出现。检查清单
- 中间状态是否写入外部存储，而不是留在实例内存。
- 快照粒度是否与实际写入能力匹配。
- 并发上限是否由外部系统能力反推，而非按实例数估算。
- 容灾演练是否执行完整业务任务，而不只是控制平面切换。
- 是否同时监控任务失败、积压、时效三类指标。
