需要按异常而非按轮询分配注意
别名: 事件驱动监督 · exception-based management
概念解释
多机器人监督下的注意力分配应该按异常事件触发（event-driven / management-by-exception），而不是按固定周期轮询（round-robin polling）逐一检查每台机器人。
机制
轮询策略的问题在于，它把有限的注意力资源平均分配给所有机器人，不管每台机器人当下是否真的需要关注。多数时候多数机器人都处于正常运行状态，轮询检查这些正常机器人所花的时间，和按异常触发相比是纯粹的浪费——这部分被浪费的时间原本可以用来更快响应真正出现异常的机器人。按异常触发的策略要求系统主动把需要关注的信号（性能偏离、故障预警、需要确认的任务节点）推送给操作者，而不是要求操作者主动巡视去发现问题，这把"发现异常"这件事从操作者身上转移到了系统的监测逻辑上。这个转移是有代价的：系统的检测器现在决定了人能看见什么，一旦检测阈值设置不当，异常可能永远进不了操作者的视野。检测阈值通常是在部署时一次性标定的，但机器人的传感器会随使用时间漂移、任务环境也会发生变化，如果阈值不随之重新校准，检出率会逐渐偏离标定时的水平——这意味着事件驱动策略不是设计完成后就能长期成立的一次性方案，而是需要持续维护的活动部件。
怎么研究
常见做法是对比轮询式界面和异常触发式界面在同等编队规模下的整体任务表现、异常响应时间和操作者工作负荷；也有工作专门考察阈值设置不当带来的后果——阈值过松会漏报真正的异常，阈值过紧则退化成变相的高频轮询，因为频繁误报同样会消耗注意力，这个现象和传统人因工程里的报警泛滥（alarm flood）问题是同一类机制。做这类比较时通常会刻意向检测器注入漏报和误报，而不是只在检测器完美工作的理想条件下测量触发策略的优势，后者会系统性高估异常触发的收益。
边界
按异常触发的前提是系统能够可靠地检测和分类异常，如果异常检测本身不准确——漏报或大量误报——这个策略的优势会被抵消甚至变成负担。对于需要预防性、非异常性检查的任务，比如例行巡检本身就是任务目标的场景，轮询式检查仍然有其必要性，不能一概替换为异常触发；长期完全不查看正常机器人，也会让操作者逐渐丢失对每台机器人个体状态的上下文，一旦真正需要接管会缺乏背景信息。另外，如果检测器对相关性异常缺乏聚合能力，同一根源引发的多条报警会被当成独立事件逐条推送，表面上仍是"按异常触发"，实际效果却退化成了一场未经过滤的小规模报警泛滥——这种退化和轮询造成的注意力浪费性质不同，但结果同样是把操作者的注意力耗在了不该耗的地方。
怎么落地
设计多机器人监控界面时，应该把系统的自动异常检测和分级报警当作核心功能来投入，而不是简单罗列所有机器人的状态面板让操作者自行巡视；每条推送都要说明是哪台机器人、依据什么证据判定异常、后果有多严重、留给操作者多少响应时间，以及检测器本身的置信度，按风险排序并保留未处理项目，同时安排低频率的主动抽查兜底。验证办法是对比异常触发界面上线前后，操作者从异常发生到实际响应之间的时间间隔是否缩短，同时监测误报率是否处于操作者能够接受、不至于产生报警疲劳的范围，并专门用多个异常同时到达的场景检验队列设计是否顶得住。