同时异常会超出处理能力
别名: 多机同时异常 · intervention bottleneck
概念解释
当多台机器人同时出现异常时，即使已经采用了按异常触发的注意力分配策略，同时涌现的异常数量一旦超过操作者的处理能力，仍然会造成响应延迟或遗漏——这是一个独立于轮询/触发策略选择之外的容量上限问题。
机制
这个问题的本质是排队意义上的过载。事件触发策略解决的是"如何优先响应真正需要关注的信号"这个分配效率问题，但操作者处理每一个异常本身需要时间——诊断原因、做出决策、执行响应——当单位时间内涌入的异常数量超过操作者的处理速率，异常会在队列里堆积，后到的异常必须等前面处理完才能轮到，这段等待期间对应的机器人实际上处于事实上被忽视的状态，即使触发信号本身已经准确送达。这种情况在编队规模大、或环境本身容易引发关联性异常时尤其容易发生——共享的天气条件、地图错误、网络中断、软件版本更新，都会让多台机器人在同一时刻同时触发相关而非独立的异常，这使得日常的平均负荷完全无法预测这种峰值时刻的压力。每一次介入还包含定向和情境重建的固定开销，简单地为操作者多开几路画面，并不会凭空增加人可处理的带宽。
怎么研究
这类过载效应的研究通常人为制造同时异常的场景——用共因故障（多台机器人因同一根源同时出问题）和独立多故障两种场景分别操纵并发数量、响应时间窗口和机器人自身的自动安全行为，测量操作者首次做出正确介入所需的时间、积压队列长度、超时次数，以及是否出现错误的注意力切换。只用均匀随机故障做操纵会低估真实场景里异常聚集出现的概率，这和传统人因工程里对报警泛滥现象的研究方法一致。
边界
过载并不意味着每一次并发异常都必须由人立即介入解决——如果机器人具备安全停车、自我隔离或有限的自主恢复能力，一部分异常可以先由机器人自己兜底，不必等待人工响应，这会显著降低同时异常对人类处理容量造成的实际压力。过载的实际发生阈值也和异常本身的处理复杂度密切相关，简单确认类异常造成的压力远小于需要复杂诊断的异常，不能只用异常数量本身衡量是否过载。对于后果较轻的任务，过载造成的主要代价可能是任务进度延迟，而不是安全风险，这类场景对过载的容忍度也相应更高。队列本身采用的调度策略也会左右过载造成的实际损失——如果只按到达顺序处理（先进先出），一个后果轻微、只是碰巧最先到达的异常可能挤占本该优先处理的高风险异常的时间窗口，过载状态下"按什么顺序处理"往往比"处理速度能不能再快一点"更能决定谁最终真正受损。
怎么落地
多机器人监督系统需要为每一类异常预先定义本地安全动作、最晚可接受的人工介入时间、影响范围和升级路径，而不是假设所有异常都必须立刻由人处理；队列界面要显示每个待处理异常剩余的响应窗口，以及疑似共因的候选异常，帮助操作者判断能否合并处理。验证办法是做压力测试——用通信全断、共享定位漂移、多机碰撞风险等容易引发关联异常的场景，观察当前系统设计下操作者的实际处理延迟和遗漏率，确定在什么规模的同时异常下开始出现不可接受的过载，并据此设定编队规模上限或投入提升机器人自主恢复能力的优先级，必要时触发自动减速、停车或召集第二名操作者支援。召集第二操作者的触发条件应该写成可判定的规则，比如"待处理队列超过某个长度且其中包含高风险项"，而不是留给当值操作者临时判断要不要求援，后者在真正过载、注意力最紧张的时刻反而最不可靠。