接手这类项目多了以后我最大的感触是传统值班岗位的在岗监管根本不是技术问题而是管理问题。过去靠班长巡检、定时打卡、监控中心人工盯屏本质上是抽查式管理抽查就意味着有空档有空档就会有人钻空子。把视频汇聚、视频融合、视频分析这条链路打通之后用视频AI做在岗离岗监测才算真正把监管从抽查变成了全时智能防控。这篇文章不打算讲太多概念就围绕EasyCVR这类视频汇聚与分析平台结合我在实际项目里的落地经验聊聊在岗离岗监测功能怎么拆解、怎么部署、怎么调参、怎么避坑。如果你正打算上一套类似的AI视频监管系统这篇内容应该能让你少走不少弯路。1. 从人到岗到智到岗在岗离岗监测到底要解决什么问题1.1 传统值守抽查模式的三大痛点只要经历过值班管理的人基本都能说出那三个让人头疼的场景一是人不在岗没人知道”要么等上级查岗要么等出了事翻监控才知道二是人在岗但状态不对趴着睡、玩手机、长时间背对监控区域这些行为靠人盯屏很难持续发现三是事后追溯成本高等真出了问题再回头调录像几天的视频逐个看时间成本高到没人愿意做。这三个痛点的本质是同一个监管是离散的不是连续的。抽查只能证明抽查那一刻没问题证明不了其他时间没问题。一旦监管密度上不去岗位纪律就会退化。我见过一个工厂项目门卫脱岗导致外来人员进入车间半小时没人发现事后查监控花了整整一个下午。后来上了视频AI监测这种问题基本杜绝了因为系统是7×24小时盯着每个值守点位的。1.2 EasyCVR在这条链路里扮演什么角色很多人一提到AI视频监控第一反应是买几台带AI算法的摄像头。但实际项目里前端摄像头、后端算法、业务平台往往是分离开的EasyCVR这类平台的价值就在于把视频汇聚、视频融合、视频分析三件事统一起来。先说视频汇聚。一个园区里可能同时存在海康、大华、宇视还有老旧的模拟摄像机协议有GB/T 28181、RTSP、ONVIF如果每路视频都要单独配置接入运维会非常痛苦。EasyCVR做的就是把这些异构设备统一接入让上层应用不用关心前端设备是什么品牌、什么协议。再说视频融合。这里指的其实是视频流层面的统一处理和整合把不同来源的视频流转换成标准化格式再统一输出给AI分析模块和业务端这样算法服务就不用一个品牌一个品牌地去适配。最后是视频分析。平台把AI模型的推理结果转化成结构化事件比如离岗事件超时未归事件再联动录像回放、告警截图和消息推送完成从看到画面到产生业务动作的闭环。可以这么说EasyCVR解决的不是某一个算法问题而是整个视频监管链路怎么串起来的问题。2. 平台怎么把视频汇聚、融合、分析三件事串起来2.1 视频汇聚先把前端设备和流协议收拢起来视频汇聚听起来简单做起来琐碎。实际项目里的摄像机品牌五花八门协议也不一致。正规一点的厂家走GB/T 28181国标这是国内视频监控系统对接最主流的协议几乎所有的政府和园区项目都会要求支持但也有不少项目用的是RTSP直连或者ONVIF协议尤其是一些小品牌的IPC。EasyCVR把协议适配这一层做在了平台内部接入端支持GB/T 28181、RTSP、RTMP、ONVIF、海康SDK、大华SDK等常见方式。我在项目里最常用的是GB/T 28181因为它跟平台无关只要是支持国标的设备只要能配置SIP服务器地址就能把视频流推上来。实际接入的时候要注意几个细节。GB/T 28181接入需要填SIP服务器IP、端口和设备编号每个摄像机都有一个唯一的20位国标编码这个编码最好按规则规划比如行政区划编码行业编码类型编码序号方便后期批量管理。编码乱写的话几百路摄像机接进来以后查起来会非常痛苦。RTSP接入相对直接把视频流地址填进去就行但这种方式的缺点是设备状态和码流稳定性不如国标方式可控建议只在设备不支持国标的时候用。ONVIF接入的优势是自动发现设备适合小规模快速部署但在大型项目里的管理能力和国标比还是弱一些。2.2 视频融合消除平台割裂和流格式差异融合这个词在很多厂商的PPT里都被讲得很大但在实际工程里它解决的核心问题其实是两件事格式统一和流分发。前端设备输出的视频流编码格式、分辨率、帧率都不一样。H.264、H.265、MJPEG混在一起Smart 264、Smart 265这类厂商私有编码也常出现。AI分析模块和客户端播放器不可能无限兼容所有格式所以平台要做的就是把各路视频流拉取下来、转码成统一的格式再对外分发。这就是视频融合层最基础的功能。但更现实的场景是平台割裂。我遇到过不少企业一栋楼里装了三套独立的监控系统每套系统都有自己的客户端和存储保安要看三块屏幕、开三个软件。EasyCVR这类平台把多套系统的视频流统一汇聚到一个平台里之后起码在监看层面做到了一个平台看所有画面。对于在岗离岗监测来说视频融合还有一个直接价值AI算法不用直接对接每一路原始视频流而是从平台拿统一格式的视频流这样算法模型的输入就是稳定的不会因为前端设备换了一个品牌、调整了一种编码就导致算法崩溃。稳定是在岗监测场景里比准确率更重要的指标。2.3 视频AI分析把视觉信号变成业务事件视频汇聚和融合解决的还是看见的问题AI分析解决的是看懂的问题。在岗离岗监测的AI逻辑可以拆成几个层次第一步是人员检测识别画面里有没有人、人在哪里第二步是人员跟踪判断同一个人是不是一直在场景里第三步是岗位状态判断结合预设的检测区域和时间规则得出结论是在岗离岗还是超时离岗。重点说一下人员检测和跟踪的区别。很多人以为只要画面里有人就算在岗这是不够的。实际场景里一个岗位区域可能会有人员走动、外来人员经过、交接班人员重叠如果算法只做有人/没人判断误报率会非常高。好的方案应该做到跟踪到人也就是从视频流里持续锁定某个目标判断这个人是否一直停留在指定区域里。EasyCVR平台的AI能力不是只输出一个是否离岗的布尔值还会输出检测框、目标ID、置信度、时间戳这些结构化数据。这些数据除了用来触发告警还可以做统计分析比如统计某个岗位一天内离岗多少次、每次离岗多长时间这些数据对于管理考核非常有用。3. 在岗离岗AI监测的核心功能拆解3.1 检测逻辑怎么判别在岗或离岗判别逻辑是整个功能的核心。把逻辑说清楚参数怎么调也就明白了。通用的判定流程如下系统会先划定一个检测区域这个区域一定是覆盖岗位核心位置的一个多边形或矩形区域。然后AI持续检测区域内的人员目标。注意这里有一个很关键的参数叫离岗判定时间意思是人的离开持续时间超过多少秒才认定为离岗。我建议这个参数不要设太短因为人会去打水、上洗手间、临时接个电话太敏感会导致告警刷屏反而降低系统的可信度。离开时间超过判定阈值之后系统会生成一条离岗记录通知相关管理人员。如果系统配置了超时未归规则离岗超过某个更长时间告警级别会从提示升级为严重。这个分级机制很重要因为不是所有离岗都值得马上打电话通知需要根据岗位的重要程度和离岗时长来动态决定。另外要注意一个容易忽略的场景人员遮挡。工位旁边有柱子、柜子或者设备人员走到遮挡物后面算法可能短暂丢失目标。如果程序只看目标突然消失就判定为离岗误报率会高到让人崩溃。好的实现方案是允许短时间的目标丢失缓冲在设定时间内目标重新出现就不判定离岗。3.2 阈值参数与场景划分不同岗位的离岗容忍度是完全不同的。消防中控室的值班员离岗一分钟都可能出大事仓库门口的值守员离岗五分钟可能问题不大所以阈值必须按场景区分而不是一套参数打天下。我列一个实际项目里常用的初始参数表供大家参考场景离岗判定时间超时未归时间告警级别备注消防中控室10秒60秒严重需要联动声光报警门卫值守岗30秒180秒普通同时通知保安队长机房值班岗30秒300秒提示可只推送值班记录窗口服务岗20秒120秒普通建议结合人脸识别这组参数是初始值上线后要根据实际误报和漏报情况再调。调参的原则我后面专门说。还有一个概念叫无人值守时段夜间和白天应该用不同的规则。比如白天允许离岗30秒夜晚门卫岗离岗10秒就应该告警。EasyCVR这类平台支持按时间模板配置规则把同一路摄像机的不同时段策略分开设置这是项目里很实用的能力。3.3 告警推送和事件闭环离岗检测出来之后事情还没完。如果告警只是停留在平台界面上管理人员没在看平台那这个告警等于没用。所以告警推送渠道必须覆盖管理人员实际会关注的终端。我建议至少配置三种推送渠道平台界面弹窗、微信公众号或企业微信推送、短信或电话语音通知。告警级别不同通知方式不同。普通告警推送一条图文消息就够包含离岗截图、点位名称、时间严重告警最好能触发电话语音通知确保有人在夜间能接起来。告警消息的内容要包含四个要素谁点位名称、什么时候时间戳、什么情况离岗/超时未归、现场画面抓拍截图。没有截图的离岗告警说服力会大打折扣管理者收到消息还要去调录像确认效率和体验都会差很多。事件闭环是很多人忽略的环节。每条离岗告警产生后应该有一个确认—处理—归档的流程。比如中控室管理人员收到告警查看截图通知值班员返回在系统里记录已处理。这样后期做月度复盘时可以统计离岗次数、平均离岗时长、告警响应时长用数据推动管理改进。4. 从部署到上线的完整实操流程4.1 点位规划与摄像机安装角度点位规划直接决定AI识别效果这个环节做不好后面再怎么调算法都是白费。在岗离岗监测的核心是拍到人的全身或半身并且保持画面中没有大面积遮挡。摄像机安装角度是有讲究的。枪型机一般建议安装在岗位前方或斜上方俯角控制在15到30度之间这样既能捕捉到人员的完整身形又不容易因为俯角太大导致头部占比过高、身体检测不稳定。如果是吸顶半球机安装高度建议在2.8到3.5米之间过低了视野太窄过高了人员目标太小识别置信度会下降。画面里的人员目标大小也有参考值建议目标在画面中的像素高度不低于60像素。以1080P摄像机为例如果摄像机高度3米、俯角20度检测区域平均宽度在3到4米左右能做到比较好的识别效果。分辨率太低或者目标太小算法就很难稳定跟踪。我去过的一个项目里客户为了省成本用原有的模拟摄像机做离岗检测结果摄像机分辨率只有D1人员稍微离远一点整个身体模型的置信度就低于阈值漏报严重。后来换成200万像素的IPC问题立刻解决。在岗检测这个场景200万像素是最低门槛。4.2 平台侧接入配置点位规划完就进到平台侧配置环节。如果使用的是EasyCVR大体的流程是启动平台后在国标设备模块里添加设备填入设备的SIP信息每个设备添加完成后平台会自动拉取目录在通道列表中订阅对应的视频通道视频通道上线后先做实时预览确认画面正常再做流检测。这里有一个我反复遇到的坑国标设备接入后视频流可以预览但AI分析模块拉不到流。原因通常出在码流类型上很多设备默认只推送主码流但AI分析需要的是子码流因为子码流的帧率和分辨率适合算法推理且更节省资源。解决办法是到设备端把子码流编码设置为H.264、分辨率为D1或720P、帧率15fps左右再回到平台重新拉流。AI分析模块接入方式有几种。有些项目是平台自带推理服务在平台界面直接开启AI分析通道就行有些项目是平台把视频流通过RTSP转发给独立的算法容器/算法服务器算法推理完把结果通过消息队列或API回调给平台。我更推荐后面这种方案因为算法和平台解耦后续升级算法版本或者替换算法厂商都不用动平台。4.3 AI模型配置和报警联动验证算法接入完成后进入AI模型配置环节。核心就是框选检测区域。检测区域不要画太大要把岗位核心区域画进去同时排除人员正常通行的走道、窗口、门边区域。区域画得太大通行人员会被误判为在岗画得太小人员稍微移动出区域就误报离岗。一个比较稳妥的画法以工位/岗亭为中心向外扩展0.5到1米的范围作为检测区域。人员可以在这个范围内活动但离开这个范围就开始计时。配置时平台会提供一个实时视频画面叠加编辑框用鼠标画多边形画完之后可以马上预览AI识别效果。联动验证环节要模拟真实场景来测。我一般会让现场人员配合做几轮测试第一轮是正常在岗状态确认不会自动告警第二轮是短时间离开确认在设定的离岗判定时间内不告警第三轮是长时间离开确认告警产生、推送通道收到消息、截图正确。只有三轮测试全部通过才算联动验证完成。联动验证完成后还建议做一次7×24小时的连续观察把一天内的误报、漏报记录一次。没有连续观察就直接上正式运行很容易在晚班时段遇到夜间光照变化导致的误报爆发那时候再紧急处理就比较被动了。5. 现场调试常见问题与排查实录5.1 误报问题明明人在工位却说离岗误报是最常见的问题。我这里说的误报是指人一直在岗位上但系统告警离岗了。这类问题的排查优先级建议从高到低。第一个要查的是检测区域是否包含了人员频繁进出的通道。比如工位后面有个过道同事走来走去算法误把过道上的人当作工位上的目标目标一消失就判定离岗。解决方案是把过道区域从检测区域内抠掉EasyCVR的平台支持设置多个检测区域也可以画不规则的区域把通道排除出去。第二个要查的是画面遮挡。值班桌面上的文件堆高了、座椅靠背挡住了人的下半身等都会导致人体检测置信度下降。这里最麻烦的是目标短暂丢失缓冲不足如果平台支持目标丢失重识别参数建议把缓冲时间从默认的0秒调到3到5秒。第三个要查的是摄像头角度和逆光。正面逆光时人脸和上半身暗部细节丢失AI检测框会忽大忽小不稳定跟踪目标反复出现和消失也会触发误报。解决方案是调整摄像机位置或者开启宽动态WDR让目标主体亮度提升。5.2 漏报问题人真的离开了系统却没反应漏报比误报更致命因为管理者会因此怀疑整个系统的价值。漏报的排查方向主要有三块。一块是目标太小。摄像机看得远、目标占比小AI模型识别不出人体自然就不会触发离岗判断。这不是参数能解决的需要重新调摄像机角度或者缩小检测区域。一块是人员离开路径不在检测区域内。比如检测区域只覆盖了工位正前方人从侧面悄悄溜出画面算法因为没有检测到区域内目标从存在变为消失的完整过程就不触发离岗。这点很关键检测区域必须覆盖所有可能的离岗出口。还有一块是规则配置问题。离岗判定时间设得太长比如设了5分钟人走了4分钟就回来了系统当然不会告警。这里要说一句经验如果管理人员希望更严格宁可把离岗判定时间适当调短宁可产生一些轻微的误报也要保证重要岗位不漏报。5.3 光照和环境变化的影响光照变化是AI监控最大的隐性杀手。白天阳光直射、傍晚逆光、晚上灯光不足同一个监控点位的画面亮度和色温会大幅变化算法稳定识别难度变大。夜间场景里需要检查摄像机是否支持红外夜视。如果摄像机是纯彩色模式晚上画面太暗AI检测不到人等于系统完全失效。建议部署时就确认摄像机支持红外或者带补光灯。还有一类环境问题是周期性变化每周有一天保洁人员会出现在工位区域打扫卫生如果这些人被识别为在岗目标会导致假在岗——系统认为有人但实际上值班员已经脱岗。这种问题的处理办法是开启人脸身份绑定功能使用人脸识别来绑定具体的人只有绑定的目标在才认为在岗。EasyCVR平台如果单独接入了人脸识别算法可以做这样的联动。我不止一次遇到过客户问能不能不做人脸识别只用人体检测答案是能用但只能做到有人就算在岗做不到正确的人在岗。如果岗位的监管要求比较高建议上人脸绑定成本会增加但管理价值完全不一样。6. 上线后的管理与优化心得6.1 阈值迭代没有一套参数能直接用到天荒地老系统上线只是开始真正要花心思的是持续调参。我建议上线后的第一个月每周做一次告警数据复盘把误报和漏报案例逐一过一遍不断调整参数。一个月后告警准确率通常能稳定在95%以上这时候就可以把频率降为每两周一次。调参有个原则一次只改一个参数。很多人一上来同时改动离岗时间、检测区域、缓冲时间导致出问题都不知道是哪个参数引起的。正确的做法是每次只调整一个变量验证一段时间后记录前后数据对比再决定是否继续调整。另外要在旺季和淡季分别观察数据。比如仓库的旺季人员进出频繁临时人员增多转运车辆装卸货可能导致检测区域干扰增多淡季则安静得多。如果没有按业务周期调整过参数旺季的误报率大概率会上升。6.2 与考核制度衔接AI监测量化数据怎么用最后聊一个管理层面的问题。AI监测产生的离岗数据如果不能跟管理制度衔接系统再准也发挥不了价值。我在项目里通常建议客户把平台的数据导成周报/月报内容包括离岗总次数、平均离岗时长、最长单次离岗时长、响应及时率。这些数据直接作为基层班组和外包服务商的绩效考核依据。数据是系统自动产生的有截图有时间戳几乎不可抵赖管理争议大大减少。这里要特别提醒离岗监测不是用来惩罚人的而是用来保护人的。我见过一个客户把离岗数据做得极端严格结果员工对系统产生敌意各种想办法躲避监测比如用假人放在工位上、拿照片对着摄像头。后来管理方调整了策略把离岗告警跟安全提醒挂钩超过告警时限系统先发提示消息给本人连续告警才升级到管理者效果反而更好。说到底视频AI在岗离岗监测是手段不是目的。用系统把看不过来变成看得过来把事后追责变成事前提醒才是这套方案真正的价值。EasyCVR这类平台的厉害之处在于它把汇流、融合、分析、告警、复盘整个链路串得足够顺让使用者能把精力放在管理优化上而不是天天跟技术问题较劲。我最后再分享一个小技巧如果你同时有多个项目的类似需求建议在平台里把点位、规则、告警模板都做成标准化配置包新项目上线时直接复制导入能省下大量重复配置时间。我在连续做完两个园区的在岗监测项目后第三个项目只用了不到半天就完成了全部点位的规则配置这个效率差距就来自前期的标准化沉淀。