HVAC强化学习控制：从MDP建模到安全部署的完整实践

简介：面向智能建筑与能源控制领域开发者，这份资源是MATLAB平台下基于强化学习的暖通空调（HVAC）控制器实现工程，采用Q学习与SARSA(λ)两种经典算法对电加热器做动态优化控制，并封装了与EnergyPlus仿真软件的接口，便于模拟建筑热动态和验证控制策略。压缩包共31个文件，包含13个mat数据文件、10个m源码脚本、3个idf建筑模型文件，以及说明文档、许可证、MATLAB工程文件和CSV占用时间表等，整体仅8.7MB，结构紧凑且模块区分清晰。该资源已有406人学习下载，适合有一定控制理论基础、希望将强化学习实际运用于空调系统调优的研究者与工程师。通过源码可复现探索与利用平衡下的学习过程，对比离策略Q学习与在线SARSA(λ)的收敛特性，还可结合EnergyPlus时序结果分析温度响应延迟对奖励反馈的影响，为设计低能耗、高舒适度的智能HVAC控制器提供完整基线方案。

1. HVAC_RL 到底在解决什么问题：一个控制周期省一度电，还是让系统具备自适应能力

HVAC_RL，也就是 HVAC 控制器的强化学习实施，最近几年在楼宇自动化圈子里逐渐从实验室走向试点。简单说，它不是用一个神秘算法替换掉所有控制器，而是让智能体通过与环境的持续交互，学习“在什么状态下把风机、水阀、设定点调整到什么位置最合适”。传统规则控制和 PID 在面对多变量耦合、大惯性、时变负荷时，往往只能靠工程师经验调一堆参数，而强化学习能够自动从数据中挖掘出比规则更好的策略。这个标题适合两类人：一类是有楼宇自控项目经验、想给现有系统增加节能能力的工程师；另一类是刚接触强化学习、想找一个真实工业场景练手的开发者。但先说清楚，这活儿有门槛，不是把算法库装上就能跑出结果。后面我会从建模、仿真、部署到避坑，完整拆一遍。

2. 从状态、动作到奖励：搭建 HVAC 强化学习的马尔可夫决策过程（MDP）建模

强化学习解决任何控制问题，第一步都是把问题转成马尔可夫决策过程。MDP 定义得好不好，直接决定后面是省电还是玄学跑飞。HVAC 控制的 MDP 很简单：智能体读入当前建筑和设备状态，输出一个控制动作，环境（建筑、设备、天气）给出下一时刻状态和一个奖励信号。但“简单”只是形式，真正难的是状态选哪些、动作怎么给、奖励怎么定。

2.1 状态空间怎么选：温度、湿度、人数、电价…不是越多越好

状态空间是 MDP 的输入，也是智能体做决策的依据。HVAC 系统里可用的测量量很多，但把它们一股脑塞进观测向量，只会让训练变慢、策略变脆。我一般把候选状态分成三组：环境状态、设备状态、扰动状态。

表格：HVAC 强化学习常用状态变量

选状态的核心原则是“可观测、可因果、可归一化”。可观测指传感器稳定可用；可因果指状态必须早于动作产生影响；可归一化指每个维度的取值范围要明确，方便做标准化。我第一版只会保留室内温度、室外温度、当前设定点、设备当前功率、占用标识五维，等策略收敛后再把电价、太阳辐射加进去。如果一上来就是十三个维度，探索空间指数膨胀，训练时间可能从几小时变成几周。

状态还需要做预处理。真实传感器读数抖动大，建议在环境返回观测值之前做一次中值滤波或限幅。归一化要用训练时统计的 min/max，不能用实时的动态 min/max，否则状态分布会漂移。另外，把上一个动作也拼进状态里往往有明显收益，因为 HVAC 系统有惯性，智能体需要知道“我刚才把阀门开到多大”才能判断当前温度变化的原因。

2.2 动作空间设计：连续设定点 vs 离散档位，以及约束处理

动作空间决定智能体能做什么，也决定算法选型和训练难度。HVAC 控制器最常见的两种动作输出是温度设定点和设备启停/档位。离散动作空间适合 DQN 这类基于价值的算法，连续动作空间适合 PPO、TD3 这类基于策略的算法。

表格：动作空间设计对比

我的建议是：如果是第一次做 HVAC_RL，先从离散动作开始。比如把设定点量化成 20、22、24、26、28 五档，或者把风机频率分成四档。这样训练快、容易收敛，也能快速验证奖励函数设计是否合理。等离散策略跑出稳定效果，再切换到连续动作，用 PPO 去微调设定点精度。

动作约束必须在环境里强制执行。例如连续动作输出 19℃，但设备最低只能设 20℃，环境不能直接接受。常见做法是在 step() 里对动作做 clip，但注意不能只在奖励里惩罚超限，因为惩罚只能提供梯度信号，无法保证动作一定合法。更可靠的方式是把动作 clip 和“投影”结合：如果动作超出范围，先裁剪到边界，再计算一个小的惩罚项，让智能体逐渐学会不输出越界值。

2.3 奖励函数设计：舒适度与能耗的权衡，以及稀疏奖励问题

奖励函数是 HVAC_RL 项目里最容易“翻车”的地方。终端目标通常是“在满足舒适度的前提下最小化总能耗”，所以奖励一般写成能耗项和舒适度惩罚项的加权和。我常用的形式是：

r = - ( w1 × P_t / P_max + w2 × |T_set - T_target| + w3 × max(CO2 - CO2_limit, 0) / 100 )

其中 P_t 是当前实测功率，P_max 是设备额定功率，T_set 是实际室温，T_target 是舒适目标温度。w1 控制节能权重，w2 控制温度偏差权重，w3 控制空气质量约束。权重初值可以从历史数据里统计：过去一个月平均能耗和平均温度偏差分别记下来，然后按“温度偏差每超 1℃ 相当于多少能耗”来设初始比例。

稀疏奖励是新手最容易踩的坑。如果只在月底看到电费单才给奖励，智能体完全无法将某个动作与未来的电费关联起来。所以每个控制周期（比如 15 分钟）都要给一次奖励，而且最好能拆成分量，分别记录到日志里。我习惯在环境里返回一个 info 字典，包含能耗项、舒适项、CO2 项，训练时每 100 步打印一次这些分量的均值，而不是只看 total_reward。否则可能出现总奖励一直在涨，但 CO2 已经爆表的“奖励黑客”问题。

这里给一个简单的奖励函数实现，可以直接嵌进自定义环境：

def compute_reward(power, max_power, temp, target_temp, co2, co2_limit): w1, w2, w3 = 0.5, 0.5, 0.3 # 能耗分量：归一化到 0~1 energy_penalty = w1 * power / max_power # 舒适度分量：温度偏差每 1℃ 计 0.5 分惩罚 comfort_penalty = w2 * abs(temp - target_temp) / 2.0 # CO2 超限惩罚：超过阈值后线性增长 co2_penalty = w3 * max(co2 - co2_limit, 0) / 100.0 reward = -(energy_penalty + comfort_penalty + co2_penalty) return reward

逻辑说明：这个函数返回一个负数，智能体的目标就是让负数尽量接近 0，即同时压低能耗和舒适度损失。三个分量都做了归一化处理，避免某一项数值过大主导梯度。注意 w3 系数 0.3 只惩罚 CO2 超限部分，没有奖赏低于阈值的部分，这样智能体不会为了“更干净”而无限加大新风。实际项目中，w 参数需要做几轮网格搜索，先固定 w2，然后扫描 w1 / w3，观察训练曲线的 Pareto 前沿。

3. 在仿真环境里训练 HVAC 智能体：最小 Gym 环境与 PPO 收敛要点

MDP 建好后，不能直接拿到真实楼宇上跑。强化学习要大量试错，真实环境里一次试错可能意味着室内温度失控、压缩机损坏、甚至租户投诉。所以正规的 HVAC_RL 流程一定是在仿真环境里先训练，再把策略迁移到真实控制器。这章给出一条从 Gym 环境到策略收敛的最小可行路径。

3.1 为什么先跑仿真：真实楼宇容不下十万次试错

强化学习本质是靠试错攒经验。一个控制策略要想学会“白天预冷、午后保温”，往往需要与环境交互几万步甚至几十万步。假设一个控制周期 15 分钟，十万步相当于连续跑一年多。这在真实楼宇里是不可能的。仿真环境的好处是：可以加速运行、可以随机化天气和人员做泛化、还能安全地测试极端工况。

常见做法是：用建筑能耗仿真引擎模拟室内热过程和设备能耗，外面封装一层符合 Gym 接口的 Python 环境。封装层核心就是两个方法：reset() 让建筑回到某个初始状态；step(action) 执行一个控制周期，返回下一状态、奖励、是否结束。下面这个类骨架是完整的 MDP 封装模板：

import gym class HVACEnv(gym.Env): """HVAC 控制环境：封装仿真引擎，暴露 Gym 接口""" def __init__(self, cfg): super().__init__() # 仿真引擎可以是 EnergyPlus、TRNSYS 或自研的热模型 self.sim = SimulationEngine(cfg['building_model']) # 动作空间：连续设定点，范围 20~28℃ self.action_space = gym.spaces.Box(low=20.0, high=28.0, shape=(1,), dtype=float) # 观测空间：归一化后的状态向量 n_obs = len(cfg['obs_vars']) self.observation_space = gym.spaces.Box(low=0.0, high=1.0, shape=(n_obs,), dtype=float) def reset(self): # 初始化到夏季典型日，返回归一化状态 obs = self.sim.reset_to(season='summer') return self._normalize(obs) def step(self, action): # 动作是温度设定点，直接传给仿真引擎 temp_setpoint = float(action[0]) obs, power, comfort = self.sim.advance(temp_setpoint, dt=15 * 60) # 奖励函数里同时考虑能耗和温度偏差 reward = - (0.5 * power / self.sim.nominal_power + 0.5 * abs(obs['room_t'] - temp_setpoint) / 2.0) done = self.sim.is_finished() return self._normalize(obs), reward, done, {'power': power, 'temp': obs['room_t']} def _normalize(self, obs): # 将原始观测按 min/max 归一化到 0~1 norm = {} for k in self.obs_keys: lo, hi = self.obs_bounds[k] norm[k] = np.clip((obs[k] - lo) / (hi - lo), 0.0, 1.0) return np.array([norm[k] for k in self.obs_keys])

逻辑说明：这个环境把动作定义为“温度设定点”，符合多数暖通工程师的操作习惯。step() 执行 15 分钟仿真，把功率和温度偏差折算成奖励。注意done在真实项目中一般不用单个 episode 结束，而是让仿真引擎跑完整个制冷季，done表示仿真时间走完。_normalize必须与训练时保持完全一致，后面部署到真实控制器时也要用同一组 min/max。

3.2 一个最小训练循环：用 Stable-Baselines3 跑 PPO

环境就绪后，训练本身在开源强化学习库里只需要十几行代码。我用 PPO 比较多，因为它在连续控制任务上比 DQN 更稳定，对 HVAC 这种有滞后、有噪声的环境更鲁棒。

from stable_baselines3 import PPO from hvac_env import HVACEnv # 加载自定义环境 env = HVACEnv(cfg="hvac_config.yaml") # 创建 PPO 智能体，MlpPolicy 表示用全连接网络处理状态 model = PPO( "MlpPolicy", env, learning_rate=3e-4, n_steps=2048, batch_size=256, gae_lambda=0.95, clip_range=0.2, verbose=1, ) # 开始训练，总步数视环境复杂度而定 model.learn(total_timesteps=200_000) model.save("hvac_ppo_final")

参数说明：learning_rate 初始 3e-4，如果训练后期奖励震荡，可以降到 1e-4 或使用学习率衰减。n_steps 是每次更新前收集的经验步数，仿真速度慢时建议降到 1024，避免一次收集时间太长。batch_size 控制每次梯度更新的样本量，一般取 n_steps 的 1/4 到 1/8。gae_lambda 是优势估计的折扣因子，越大表示越看重远期收益。clip_range 是 PPO 裁剪范围，0.2 是默认值；如果策略更新过于激进导致奖励崩掉，可以调小到 0.1。

训练时要注意：不要把total_timesteps设得非常大就认为一定能收敛。HVAC 环境的奖励尺度小，PPO 的标准化技巧（normalize advantage）在这里很重要。Stable-Baselines3 默认开启 advantage normalization，但如果你自己写算法，千万别漏掉这一步。另外，环境内部仿真时间步长要远小于控制周期，比如仿真相 5 分钟、控制动作每 15 分钟发一次，否则热惯性无法体现。

3.3 训练观察指标与早停策略

训练过程中不能只看终端打印的ep_rew_mean。我要求团队必须把每个 episode 的能耗总和、平均温度偏差、CO2 超限时长分别记录到 CSV，然后实时画曲线。真正该关注的收敛标志有三个：总奖励均值进入平台期、温度偏差的方差缩小、验证场景上的能耗不再下降。如果只看总奖励，很可能出现“总奖励不错但能耗没降”的假收敛。

早停策略要拿独立的验证环境来测，验证环境的初始天气和训练环境不同。比如训练时用夏季 7 月数据，验证时用 9 月数据，看策略是否还能稳住温度。下面这段评估代码可以直接复用：

import numpy as np def evaluate(model, eval_env, num_episodes=10): """在验证环境里评估策略，返回平均奖励、平均能耗、平均温度偏差""" rewards, energy, temp_err = [], [], [] for _ in range(num_episodes): obs = eval_env.reset() done = False ep_reward = 0.0 ep_energy = 0.0 ep_temp_err = 0.0 steps = 0 while not done: action, _ = model.predict(obs, deterministic=True) obs, reward, done, info = eval_env.step(action) ep_reward += reward ep_energy += info['power'] ep_temp_err += abs(info['temp'] - info['setpoint']) steps += 1 rewards.append(ep_reward) energy.append(ep_energy) temp_err.append(ep_temp_err / steps) return np.mean(rewards), np.mean(energy), np.mean(temp_err)

逻辑说明：deterministic=True是为了去掉探索噪声，用策略网络的最大概率动作去评估，这样多次评估才有可比性。info 字典里需要环境返回真实的功率和设定点，否则评估代码拿不到分项指标。我一般会跑完一个完整制冷季作为评估 episode，然后对比训练时的 best checkpoint。如果验证集上能耗和温度偏差都优于带初值的规则控制，才考虑进入下一步部署。

4. 把策略部署到真实 HVAC 控制器：安全护栏与工程改造

训练只是开始，部署才是真正考验工程能力的地方。仿真环境再逼真，真实世界总有传感器噪声、执行器延迟、设备老化、通信抖动。直接拿训练好的神经网络输出接进 BAS 系统，不出一个礼拜就会有人来找你推责。所以部署的核心不是“把模型跑起来”，而是“让模型在安全边界内跑”。

4.1 安全层：给神经网络输出加上限幅和缓变

HVAC 控制器有物理限制，制冷设定点不能低于某个值，阀门不能从一个极端瞬间跳到另一个极端。神经网络策略天然没有这些概念，它只负责输出最小化奖励的数值，可能上一秒给 22℃，下一秒给 27℃。如果不加处理，轻则设备磨损，重则触发压缩机高压保护。我强烈建议在策略输出和执行器之间加一个安全层函数，做两件事：限制变化速率、限制绝对边界。

def safe_action(raw_action, current_setpoint, min_sp=21.0, max_sp=28.0, max_step=0.5): """ 安全层：限制设定点的变化幅度和绝对范围 - raw_action: 神经网络输出的原始设定点 - current_setpoint: 当前实际设定点 - max_step: 单个控制周期内允许的最大变化量（℃） """ # 先限制变化速率，防止设定点抖跳 action = np.clip(raw_action, current_setpoint - max_step, current_setpoint + max_step) # 再限制舒适允许区间 action = np.clip(action, min_sp, max_sp) return round(float(action), 1)

参数说明：min_sp / max_sp 是设备允许的设定点范围，由暖通专业给出，不是算法拍脑袋定的。max_step 建议从 0.2℃ 起步，如果一个控制周期是 15 分钟，0.2℃ 的步长已经能平滑逼近目标。如果系统制冷能力偏弱，可以放宽到 0.5℃，但绝不能超过 1℃，否则室温容易出现振荡。round(..., 1)是为了避免设定点出现 22.30000001 这种浮点数，给 BAS 系统制造解析问题。

在线下部署时，我会把这个安全层放在推理进程和 BAS 网关之间。推理进程只负责输出 raw_action，安全层拿到当前实际设定点做限幅。实际运行中，需要把安全层的输入输出都打进日志，尤其是连续 5 个周期都被 max_step 限制的情况，说明策略想走出边界，这时候需要关注是不是状态分布出了问题。

4.2 状态输入的真实化：缺失值填充、滤波与归一化

仿真环境的观测向量总是完整、干净的，真实传感器会出现丢包、坏值、量程异常。如果直接把一个 null 或 9999 塞进神经网络，策略会输出一个随机动作。部署前，状态输入管道必须做三层处理：异常值判断、缺失值填充、归一化。

import math import numpy as np def build_state(raw_values, obs_bounds, fallback_values): """ 将真实传感器原始值转成神经网络的归一化状态 - raw_values: 来自传感器的原始读数列表 - obs_bounds: 每个传感器的 (min, max) 归一化边界 - fallback_values: 传感器异常时的替代值，用训练时的中位数 """ state = [] for val, (lo, hi), fb in zip(raw_values, obs_bounds, fallback_values): # 异常值判断：None、NaN 或超出物理量程 if val is None or math.isnan(val) or val < lo * 0.5 or val > hi * 1.5: val = fb # 二次保护：裁剪到边界内 val = np.clip(val, lo, hi) # 归一化到 0~1 norm = (val - lo) / (hi - lo) state.append(norm) return np.array(state)

逻辑说明：这里用lo * 0.5和hi * 1.5作粗筛，防止个别传感器漂移直接污染归一化。fallback_values 必须来自训练集的统计中位数，不能用 0 或当前值，否则状态分布突然跳变，策略会误判。需要注意的是，归一化的 min/max 要和训练环境完全一致。我见过有人部署时用 numpy 自带 min/max 实时归一化，结果训练时是 [0,1] 分布，部署时变成 [0.3,0.7] 分布，策略立刻失效。

真实项目里还会有传感器融合：比如室内温度有两个测点，一个坏了，可以用另一个加上走廊温度做线性修正。这个逻辑可以放到 build_state 之前，也可以直接用 fallback 扛过故障。我的原则是：宁可让状态退回到“最近一次正常值”，也不要让缺失状态变成 0 或随机数，因为策略看到的是“崖式变化”，很容易输出危险动作。

4.3 控制器切换与回退机制：RL 失灵时谁接手

就算安全层和状态处理都做好了，神经网络依然可能因为没见过的新工况输出不合理动作。所以部署架构里必须有一个“监督器”角色，持续监控 RL 的动作质量，一旦异常就切回原来的规则控制器或 PID。这不是对 RL 的不信任，而是对设备负责。

我常用的切换条件是三选一：动作变化率连续超过阈值、温度偏差连续多个周期超过 ±2℃、或者策略网络输出的动作方差异常。这里要区分“动作方差”和“策略熵”。策略熵是决策概率的分散程度，动作方差是相邻周期输出的差异。后者更能表征执行层面的抖动。

def controller_manager(rl_action, pid_action, monitor_state, thresholds): """ 监督器：决定当前周期用 RL 动作还是 PID 动作 - monitor_state: 包含 action_var, temp_err, co2 - thresholds: {'action_var': 0.2, 'temp_err': 2.0, 'consecutive': 3} """ if monitor_state['action_var'] > thresholds['action_var'] or \ monitor_state['temp_err'] > thresholds['temp_err']: # 计数器累加，连续 3 次触发才切换，避免单次抖跳导致乒乓 manager_state['consecutive_count'] += 1 else: manager_state['consecutive_count'] = 0 if manager_state['consecutive_count'] >= thresholds['consecutive']: log_event("RL fallback to PID", monitor_state) return pid_action return rl_action

逻辑说明：这里特意要求“连续 3 次触发才切换”，是为了防止传感器噪声造成控制器在 RL 和 PID 之间反复横跳。manager_state 是一个全局字典，在函数外初始化。log_event要记录触发原因、当时的观测状态、RL 动作和 PID 动作，方便事后分析。切换之后不要马上切回 RL，至少要稳定运行 1 个小时，否则系统会在两个策略之间震荡。最理想的做法是：切回 PID 后，让 RL 继续在后台收集数据，等到奖励估计值重新回到合理区间，再由人工确认后恢复。

5. HVAC 强化学习落地避坑指南：从仿真到实机的 5 个高频故障

这章写的都是从实际项目里踩出来的坑。每一个都对应着“现象 -> 原因 -> 解决”三步，希望能帮你少走几个月弯路。

5.1 仿真与真实环境差异导致策略失灵

现象：仿真里能耗比规则控制省 15%，实机上线后室温频繁震荡，压缩机启停明显增多，能耗不降反升。

原因：仿真引擎没有完整建模设备延迟、传感器噪声、盘管积灰、阀门非线性。智能体在仿真里学到的是“理想世界”的应对方式，比如在室外温度刚过阈值时立刻把阀门关小，但真实设备响应慢，等到阀门真正动的时候室温已经冲过头了。

解决：训练时在环境里注入随机噪声和一步动作延迟。具体做法是在 step() 中把当前动作缓存起来，实际作用到热模型的动作是上一个周期的。这样可以提前让策略感知滞后。部署初期用 max_step=0.2℃ 的小步长运行，收集真实设备响应曲线去校准仿真参数，不要让 RL 直接接管大权。

5.2 奖励函数被钻空子：模型学会了“关掉风机”

现象：训练到中后期，总奖励一直上涨，但日志里 CO2 浓度逐渐逼近甚至超过 1000ppm。智能体找到了“关风机”这个偷懒捷径，因为风机能耗占了奖励里很大一块，而 CO2 惩罚权重太小。

原因：奖励函数只惩罚了能耗和温度偏差，CO2 要么没进状态、要么惩罚权重过低。强化学习不关心人的感受，它只优化你给出的目标函数。

解决：把 CO2 浓度加进观测空间，同时在奖励里增加一个硬阈值惩罚：当 CO2 超过 800ppm 时，每超 100ppm 给予一个 -0.2 的额外惩罚。还可以加一条安全约束：当 CO2 超过 1000ppm 时，环境强制下一次动作必须为“新风开启”状态，让智能体学会提前守住通风。记录奖励分量时，把 CO2 惩罚单独输出，训练时盯着它看，不能只看总奖励。

5.3 训练不稳定：奖励震荡与灾难性遗忘

现象：训练到 10 万步后，奖励曲线开始像过山车，前段时间表现最好的 checkpoint 在后续训练中又突然变差，甚至完全崩掉。

原因：常见诱因是学习率过高；或者训练数据里只有一个季节的样本，经验回放缓冲里相似样本过多，导致策略过拟合到近期数据；也可能是 PPO 裁剪范围太大，更新步长没有约束住。

解决：先降学习率，从 3e-4 降到 1e-4，同时把 n_steps 从 2048 提到 4096，让每次更新看到更多不同场景。在环境里做“场景多样化”：每次 reset 随机化初始温度、室外气象数据、人员密度周期，而不是固定死一套初始条件。另外在训练脚本里设置定期评估，每 5000 步保存一次 checkpoint，最终挑验证集表现最好的那个，不要用训练轨迹最后一个模型。

5.4 延迟与异步问题：真实控制器时钟不同步

现象：实机部署后，明明设定点已经送到 BAS 系统，室温响应却比仿真里慢一两个周期，导致策略误判“动作没效果”，连续加大输出，最后超调。

原因：强化学习的 MDP 假设“在状态 S_t 执行动作 A_t，下一状态 S_{t+1} 只依赖这两者”。但真实系统里存在多个延迟源：Python 推理耗时、网络传输到 BAS 网关、执行器执行动作、传感器采样周期。这些延迟叠加起来可能超过一个控制周期。

解决：仿真环境的 step() 里加入动作延迟队列：先进先出缓存两个控制周期的动作。如果原控制周期是 15 分钟，那么加入 2 步延迟后就相当于模拟了 30 分钟的内置滞后。部署时在状态输入里增加一个“动作时间戳”字段，当检测到状态时间戳与动作执行时间差超过一个控制周期时，监督器强制切换回规则控制，等待同步恢复。

5.5 数据分布偏移：季节更替让策略失效

现象：夏天训练好的策略在秋初还能跑，入冬后第一个寒潮来临时，智能体开始频繁把设定点顶到上限，室内却依然不暖和，能耗骤增。

原因：强化学习策略只见过训练数据分布内的状态。夏天室外 30~37℃，冬天室外 0~5℃，状态空间完全不同。网络的泛化能力有限，面对极端没见过的新数据，输出可能是随机的。

解决：训练时做“域随机化”，把仿真环境写成一个可以随机选择季节、天气文件、人员密度的超环境，让每个 episode 都从不同分布中采样。部署后建立一个在线监控：统计最近 7 天的状态向量分布（均值、方差），和训练集的状态分布做 KL 散度比较，超过阈值就触发再训练。再训练不是从零开始，而是用已有的 best checkpoint 在新增季节数据上微调，学习率降到 1e-5，小步慢跑。

6. 进阶：多区域 HVAC 控制的分层强化学习与模型预测控制结合

单区域训练跑通只是第一步。我接触过的实际项目里，很少有一台空调只服务一个房间的情况。多区域建筑中，不同区域的朝向、人员密度、设备热负荷差异很大，而且共用水系统时会出现冷热耦合——一个区域大制冷，另一个区域要制热，系统边上一个控制指令可能造成“左冷右热”的尴尬。

一种靠谱的进阶路线是分层强化学习。上层智能体负责分配各区域的冷量优先级，它输出的是“哪个区域多给、哪个区域少给”的离散选择；下层智能体负责执行具体设定点，它只针对自己负责的区域，输入本区域状态和上层给的优先级。上层奖励用“总能耗 + 区域间温度均方差”来平衡公平性和能耗，下层奖励沿用单区域的标准。这样既保留每个区域的局部精细控制，又避免了直接在联合动作空间上爆炸式探索。

另一种路线是把强化学习和模型预测控制结合。模型预测控制的强项是能够在硬约束下求最优控制序列，但它需要相对准确的系统模型；强化学习的强项是从数据中学非线性映射，但缺少约束保证。我的做法是：用 RL 学习室外温度、太阳辐射和室内温度之间的动态响应误差，把它作为 MPC 模型的在线修正量；MPC 仍然负责生成控制序列，但它的预测方程里已经包含了 RL 带来的偏差估计。这种方式比纯 RL 更容易通过安全审查，也比纯 MPC 适应更多非线性工况。

验证这个方法时，我会先在多区域仿真里构建一个“区域间温度均方差”指标，和总能耗一起作为双目标。目标不是让每个区域都精准保持在 24℃，而是让平均偏差和方差都落入可接受区间。下面这张对比表可以帮助团队选型：

我现在的习惯是，从单区域项目一开始就把状态和动作接口设计成“可扩展”的：状态向量里预留区域 ID 字段，动作字典里允许对多区域输出多个设定点。这样后面扩展到分层 RL 时，只需要把上层策略的决策作为下层策略的一个附加状态，不需要推倒重写环境。这个习惯帮我少踩了很多坑，也让 HVAC_RL 不再只是实验室玩具，而是一个能真正融入楼宇自控系统的选项。希望帮到你。

本文还有配套的精品资源，点击获取