一个 50 台 AMR 的仓，RCS 一天能吐多少条告警？我经手过的项目里，多的那家高峰一天 3000 多条，少的那家几百条。你可以理解为：中控台的操作员，相当于手机里装了 20 个 App，每个 App 每小时都给你推 10 条通知——用不了一个星期，他就学会了全部忽略。然后真正的故障来了，淹没在通知海里，没人看见。
这不是危言耸听，这是告警疲劳，医疗行业十年前就玩剩下的词，现在轮到自动化仓了。
先说原理：为什么 RCS 的告警会爆炸
RCS 是车队的"交警＋调度员"，管路线、管任务、管充电。你可以理解为：每台 AMR 身上挂着几十个传感器——激光雷达、安全触边、编码器、电池 BMS、WiFi 模块——每个传感器都有阈值，超了就往上抛事件。50 台车 × 几十个传感器 × 24 小时，这就是告警的原材料。
爆炸一般来自三个地方：
第一，单机层。AMR 本体抛的：电池温度波动、单次避障减速、定位重定位、WiFi 漫游切换。特点是量大、绝大多数自愈。
第二，车队层。RCS 抛的：任务超时、路径死锁、区域拥堵、充电排队。量不大，但每条都和节拍直接相关。
第三，集成商的"免责心态"。这话不好听但是实话：很多项目的告警策略是集成商为了"出事别找我"配的——"WiFi 信号低于 -70dBm 就弹窗"，这种告警除了让操作员麻木，没有任何用处。对伪需求我一向不客气：告警不是越多越负责，报了一堆没人看的告警，等于没报。
还有一个结构性原因：告警链路是层层加码的。传感器抛原始事件，车载控制器先过滤一遍，RCS 再按车队规则加一遍，中控台软件为了"功能丰富"又加一遍弹窗。你可以理解为：村里喊一声，乡里转一遍，县里再发个红头文件——到操作员耳朵里，一件事变成了三件事。所以治理告警的第一步不是调阈值，是先画出这条链路，看清楚到底在哪一层被加了码。很多项目我一看，RCS 里一条"任务超时"，中控台配了弹窗＋短信＋邮件三连发，纯属自己吓自己。
告警分级：AMR 的告警只分三级，多了就是耍流氓
分级就三级，P0、P1、P2。分界线只有一条硬标准：这条告警如果没人看，会不会在 30 分钟内变成停线？ 会，就是 P0；不会但影响节拍，是 P1；都不会，进 P2 日志。简单粗暴，但好用。
| 级别 | 典型告警 | 推送方式 | 响应要求 |
|---|---|---|---|
| P0 生死线 | 急停触发、安全触边、激光雷达遮挡、整车失联、电池异常高温、主干道死锁 | 声光＋短信/电话 | 几分钟内必须有人响应 |
| P1 影响节拍 | 回充失败、单次导航失败（已自动恢复）、充电排队、区域拥堵降速 | 中控台列表＋班次汇总，不弹窗 | 当班处理 |
| P2 纯日志 | WiFi 漫游、速度降档、心跳抖动、单次避障减速、自愈成功的事件 | 只进日志 | 查问题时再翻 |
讲两个真事。
2024 年"双 11"之前，华东某电商仓，60 台 AMR，RCS 告警策略是默认全开，一天 4000 多条。中控员后来跟我说，他学会了"用余光扫一眼弹窗然后点掉"。结果一台车的电池 BMS 报了过温——P0 级别的事，淹没在几千条"WiFi 漫游""减速避障"里，40 多分钟后巡检才发现车趴窝在主干道上，半条拣货线停摆。复盘结论就一句话：不是没告警，是告警太多等于没告警。
另一个反例在华南，某 3C 仓 40 台 AMR，上线第一个月把"定位重定位成功"这种自愈事件也推弹窗，一天 800 条里 700 条是"报喜"的。改完规则：自愈成功的只记日志，自愈失败的才升级推送。弹窗从 800 掉到 60 多条，操作员又开始看屏幕了。你看，问题从来不是"报得不够多"。
分级不是一次性工程。我要求项目上线后每周做一次告警复盘：把这周的 P0 全拉出来，一条条过——误报的降级，漏报的升级，连续两周没人看的 P1 直接进 P2。三个月下来，P0 会收敛到一个很小的值，而且每条都是真家伙。这个习惯比任何调优工具都管用，可惜大部分仓上线时轰轰烈烈，复盘一次都没做过。
屏蔽不是删：调优的三个坑
分级定完了，下一步是动手屏蔽和调阈值。这里有三个坑，我见过每个坑都至少埋过一个项目。
坑一：关掉就忘，不留记录。 屏蔽是一次风险决策，必须走变更：谁批的、为什么屏蔽、有效期到哪天。这就像把烟雾报警器的电池抠了还不告诉物业——真着火了，第一个问题就是"谁抠的电池"。我的做法：所有屏蔽规则进一张表，带审批人和复检日期，过期自动恢复推送，逼着你定期重新评估。
坑二：阈值照抄别家。 每家的地面平整度、WiFi 覆盖、货架密度都不一样，"避障减速超过 10 次/分钟就告警"这个阈值，A 仓合适，B 仓可能天天误报。正确姿势：上线前两周全开只记录不推送，拿自家真实数据定阈值。这叫先观测再定规矩，别反着来。
坑三：合并粒度太粗。 有人为了降数量，把"导航失败"和"任务超时"合并成一条"AMR 异常"，查问题的时候想哭都哭不出来。合并只合并"同一台车、同一原因、几分钟内"的重复事件，原因不同的告警永远别合并——合并的是噪声，不是信息。
顺带说一句，RCS 厂家自带的"智能告警"功能，十个有九个是噱头。我测过两家的所谓 AI 降噪，逻辑就是按时间窗口合并同类事件，跟你自己写条规则没区别，授权费还贵一截。值不值，一样的标准：它能不能把 P0 的平均响应时长打下来，打不下来就是智商税。
再给一个决策框架，屏蔽每条告警之前，先把它放进这个四象限：
| 后果轻微 | 后果严重 | |
|---|---|---|
| 高频 | 屏蔽，只记日志 | 这是设计缺陷，去修系统，别调告警 |
| 低频 | P2 日志 | 保留，P0 推送 |
右上角那个格子最值得说：一条告警又频繁、后果又严重，说明你的系统本身有病，调告警只是在给重症病人喂止痛药。
拿两条最常见的告警过一遍这张表。"充电排队"：高峰期一小时出现几十次，算高频；后果呢？车多等几分钟才充上电，节拍影响有限，算轻微。结论：屏蔽弹窗，只记日志，班次报表里给个总数就行。再拿"主干道死锁"过一遍：低频，但一次就能停半条线，妥妥的 P0，声光＋电话，一个都不能少。这张表打印出来贴中控台墙上，新来的工程师半小时就能上手分级。
最后说个反常识的：很多人觉得"屏蔽得越多，系统越危险"。反了。屏蔽本身不危险，危险的是"屏蔽了但没人知道屏蔽了什么"。一个全是 P0 弹窗的系统，和一个没有告警的系统，死法一模一样——都是没人看。
所以这钱花得值不值，看这一个数：P0 告警从触发到有人开始处理的平均时长。这个数从 40 分钟降到 5 分钟，你的告警治理就值了；降不下来，前面做的分级、屏蔽、合并，全是自嗨。
作者：大刘｜自动化设备工程师
