Z1.07.3Loss of the aggregation point设计
聚合控制点失效会导致整体系统失去可控性
别名: 聚合点失效 · 控制中枢失联 · hub outage
概念解释
分散的入口需要一个聚合控制点（中枢应用、网关、语音平台）来统一状态与规则。这个聚合点失效时——断电、断网、云端故障、应用打不开——损失不是「少一个入口」，而是整体系统失去可控性：所有经由它聚合的功能同时不可达，而它恰恰聚拢了大部分功能。
失效的形态常被低估：不是黑屏报错，而是卡在中间态。聚合点失联时设备仍在执行最后的指令，自动化仍在按旧规则跑，但用户既改不了规则也停不掉动作——系统不是死了，是「不听指挥地活着」，这比死更难受。
机制
聚合点为什么一倒全屋瘫？因为它承担着三样不可替代的东西：
- 规则的宿主。 多数联动逻辑运行在聚合点（或其云端）上，聚合点失效即规则停摆——触发还在发生（传感器照常上报），但没人解释触发、没人分发动作。
- 状态的汇合处。 各设备的状态经聚合点拼成全屋图景；聚合点失效后，每个入口只剩自己直连的那一小片，没有任何一处能看到整体。
- 控制的路由。 跨设备指令（「离家模式」要动十台设备）只有聚合点知道完整的路由表；失效后用户只能逐台手动，而「逐台」这个操作模式用户从未练过——它的存在本身就依赖聚合。
深一层的问题在失效的传染方向：分布式系统本可设计成部分失效（掉一台坏一台的事），但把智能集中到聚合点后，失效结构被改写成集中式——聚合点的可用性成为全屋可用性的上限。物理开关还能用的设备，用户也想不起来用了，因为控制习惯已经全部迁移到聚合入口上。
边界
- 失效时长决定伤害等级。 十秒的闪断只是延迟感；跨夜的中枢失效会把用户逐台手动的生疏全部暴露——可用性问题的严重度与聚合点平均恢复时间挂钩，评估时按恢复时长分布算，不按故障率算。
- 本地聚合与云聚合失效面不同。 本地网关断的是家里一段；云聚合断的是全远程入口加所有云端规则——依赖云的中枢失效时，人在家也控制不了家里。聚合点放在哪一侧，决定哪类故障最伤。
- 聚合点失效不等于设备失效。 设备本身健康而不可达时，修复聚合点即可全量恢复；把两者混为一谈会导致用户在设备端做无用的重启与重置，反而制造新问题。
怎么落地
- 保底控制路径物理化：为每个有后果的设备保留一条不经聚合点的本地控制方式（物理开关、红外遥控、蓝牙直连），并在日常就以「聚合入口为主、物理路径为辅」并存——保底路径平时不用也要偶尔用，否则失效时形同虚设。
- 聚合点失效时降级而非空白：入口界面明确呈现「中枢失联」状态与可用操作清单（哪些设备还能直控），别让用户在无反馈的界面上反复尝试。
- 规则本地兜底：关键联动（安防、温控）在聚合点失联时能退到设备间本地执行的最小集，不因中枢失效而全停。
- 验证办法：演练「拔掉中枢」——断网关或退掉云端服务二十四小时，统计这期间家庭完成基本操作的成功率与绕行路径。完成率过低的操作，就是保底路径没建够的地方。