① 平台级 8 大问题
企业平台不是单 Agent，是几十上百个 Agent 同时跑——故障面完全不同。
P0 冷启动延迟
沙箱/模型加载慢 → 首次响应超时（架构级，必须在架构阶段解决）
P0 状态丢失
长时任务中途崩溃 → 状态存在哪、怎么续跑
P0 级联失败
一个 Agent 挂 → 连累整条链路 → 雪崩
P0 安全隔离
多用户共享平台 → A 的操作不能影响 B
关键：P0 问题是架构级——必须在架构设计阶段解决，不能靠 Prompt 或运维。
② 容错自愈机制全景
六件套组合拳，共同保证平台「挂了也能自己爬起来」。
Supervisor Tree
父管子的层级守护（Erlang 启发）
+
三态熔断器
正常→熔断→半开探测
+
幂等守卫
spawn_if_not_running
+
Watchdog
MAX_ITERATIONS=10
+
上下文压缩
75% 阈值触发
+
5 级优雅降级
能力递进损失
Supervisor Tree 思路（Erlang OTP 启发）：父 Agent 监控子 Agent，子 Agent 崩溃 → 父 Agent 检测 → 按策略重启/隔离/上报——「崩溃隔离 + 层级守护」，不是「一刀切全部失败」。
三态熔断器：正常（放行）→ 熔断（快速失败，不调下游）→ 半开（试探性放行一条，成功则恢复）。熔断是「保护下游不被打垮」，不是「让自己失败」。
③ 为什么层级化优于线性
架构选择比模型选择更重要——这是用数据说话。
关键数据：10 步管道每步 85% 可靠性 → 端到端仅 20%；层级化结构单 Agent 失败性能仅降 5.5%（线性管道 -23%）。
为什么：线性管道一个节点挂 = 整条断；层级化树一个子 Agent 挂 = 父 Agent 重调度，兄弟节点不受影响。
故障分布（1642 trace）：规格 42% / 协调 37% / 验证 21%——超过 4 成故障是「任务规格不清」，不是模型不行。诊断和容错要优先覆盖规格与协调。
④ 编排模式与收束
| 模式 | 适用 |
|---|
| Sequential Pipeline | 步骤严格有序 |
| Parallel Fan-out | 独立子任务并行 |
| Hierarchical | 主管分解调度 |
| Swarm（慎用） | 去中心化协作 |
| Blackboard | 共享黑板协作 |
| Hybrid | 组合，覆盖 95%+ 场景 |
一句话：企业平台容错 = 架构选择（层级化 + 六件套自愈）优先于模型选择——用 Supervisor Tree 隔离崩溃、熔断器保护下游、幂等守卫防重复、Watchdog 防死循环、压缩防溢出、降级保可用。