一、项目背景

某连锁门店几百个网点，空调照明各自为政，电费按月才出账单，等总部看到哪家店空调用猛了、哪个灯忘关了，钱已经花出去一个月。我们进场摸排时，对方最痛的不是单店贵，是"完全没处下手"，没有准的能耗数据，节能全靠店长自觉，总部连哪家店是耗能大户都说不清。他们之前装过智能电表，但数据只是堆在表里，没人看、没人管，节不节能全凭运气。缺的不是采集，是把数据变成动作的那一环。这个项目让我们看清，节能系统的成败不在电表多准，而在能不能把异常变成店长愿意执行的具体指令。

二、落地场景

我们用多智能体把能耗管起来：能耗采集 Agent 拉电表数据做清洗；异常用电识别 Agent 盯突增、忘关、非营业时段用电；节能策略 Agent 给门店推定时开关和温度建议；店长提醒与总部看板协同，把建议变成可执行的动作。总部能看到每家店的单位面积能耗和跨店基线对比，耗能大户一眼可见，店长收到的是具体哪台设备该关而不是一句"注意节能"。策略执行结果还会回采，形成"建议、执行、复核"的小闭环。

三、关键技术挑战与解决思路

采集数据噪声是第一道坎。电表偶尔跳变、门店自己接了个大功率设备没报备，数据就歪了。我们先做滑动均值加异常点剔除，脏数据不滤，后面节能策略全是拍脑袋。异常用电识别别太敏感，一家店周末备货提前开空调就被报异常，店长直接无视系统。我们改成结合营业时段和天气基线，非营业时段用电才高优告警。节能与体验平衡最麻烦，总部的目标是省钱，店长是怕客人热，策略 Agent 推温度建议时留了人工覆盖口，店长觉得不舒服可以改，但改了留痕，总部能看哪些店长期不听建议。跨店基线对比用同类型门店分群，别拿南方店和北方店硬比。还有个坑是季节切换时基线没跟上，初春还按冬季基线判异常，误报一堆，我们给基线加了滚动窗口自动更新。

异常识别里的"非营业时段"判定我们调过一轮。初版按固定作息表，遇到门店做夜促或盘点，正常用电被报异常，店长烦不胜烦。后来改成按该店历史用电曲线动态判定非营业时段，临时活动自动学进去，误报少了。还有个细节：同类型门店分群不能只看业态，还要看面积和客流，一家大店和小店的基线绝对值差很多，按归一化强度比才公平。这些参数看着小，但直接决定告警准不准，不准的系统再好看也没人用，我们后来把参数调整也纳入了上线评审，不再随手改。

案例片段（已脱敏）： 某门店曾因电表跳变，单日能耗被算成三倍触发误报。治理后异常识别关键配置如下：energy_agent:  smooth: sliding_mean_15min  outlier_drop: 3sigma  baseline: same_type_store  anomaly_rule: off_hours_power > 0.3*peak  suggest_override: store_manager上线后异常用电发现时效从月级缩到小时级，单位面积能耗下降约一成二，店长对节能建议的执行率约七成，总部首次能按周排出耗能 Top10 门店。

四、效果数据

单位面积能耗下降约一成二，主要是非营业时段忘关设备和空调温度过低这两类被精准逮到。异常用电发现时效从月级账单缩到小时级，总部当天就能提醒店长。店长对节能建议的执行率约七成，留痕机制让"长期不听建议"的店浮出来，针对性沟通比通报批评管用。总部首次能按周排出耗能 Top10 门店，节能资源精准投到该投的地方。滚动基线上线后，季节切换的误报基本消失，店长对系统的信任度也上来了。电表数据从堆着没人看到每天被人盯着用，采集本身终于产生了价值。

滚动基线机制上线后，店长对系统的信任明显上来，之前季节切换一堆误报时他们天天关告警，现在愿意盯着看。总部把耗能 Top10 门店的整改当成月度动作，连续几个月垫底的店被约谈后，单位面积能耗肉眼可见地往下走，形成了正向压力。我们后来把"建议执行率"也做成指标，哪些店长期忽略节能建议一目了然，总部据此做针对性沟通而非一刀切罚款，店长配合度高了不少。节能策略回采形成的小闭环还带来个意外发现：部分门店非营业时段用电其实是冰柜等必需设备，不该算异常，我们把这类刚需设备白名单后，告警更准了。能耗治理到最后，拼的是数据准、建议实、执行有反馈，三者缺一个都转不起来。

五、可复用经验总结

能耗治理先有准的表再谈省，这个项目把"装了表不等于管了能耗"讲透了。采集噪声不滤，省电策略最后都成了拍脑袋，我们初版就栽在电表跳变误报上。异常识别别太敏感，结合营业时段和天气基线才不招人烦，店长无视的系统等于没装。节能建议一定要留人工覆盖口，强压温度得罪客人，留痕比强控实在。那个季节切换基线没跟上的坑，让我们此后默认给基线加滚动窗口，别用死阈值。这套多智能体节能框架在连锁门店跑通，往园区、厂房扩的时候，基线分群和异常规则得按建筑类型重设，商超和冷库的能耗逻辑完全两码事。