MATLAB强化学习HVAC控制器：DDPG智能体实现暖通空调节能优化-尧图手机网站定制

简介：HVAC_RL是一套基于MATLAB的强化学习暖通空调控制器实现资源，面向建筑能源、智能控制方向的研究者与开发者，针对电加热器控制场景，给出Q学习与带λ的SARSA算法完整实现，用于解决传统规则控制适应性不足的问题。包内共31个文件，以m脚本、mat模型、idf建筑仿真文件为主，另含csv、prj等辅助配置，可支撑从EnergyPlus虚拟环境搭建、状态数据采集到RL算法调试、控制策略对比的完整流程。压缩包仅8.7MB，结构紧凑。现有406人学习，适合希望将强化学习落地到HVAC系统控制中的入门与进阶人员。资源附有算法代码、仿真接口、控制文件及预训练模型，可复现实验过程，帮助理解探索与利用平衡、时序差分更新等关键概念，并为实际能耗优化提供参考。

1. HVAC_RL 是干嘛的：给暖通空调装一个能自己学着省电的控制器

做楼宇自控的人大多有这样的体会：传统 PID 不是不能用，但一到换季、极端天气或者办公楼不同时段人员密度变化时，那组调好的参数就开始"不听话"，要么温度拉不回来，要么压缩机频繁启停白白耗电。这个项目的思路是干脆把控制器替换成强化学习智能体——让智能体在仿真环境里自己尝试调节暖通设备的供给功率，用奖励函数同时约束"省电"和"舒适度"两个目标，训练完直接当控制器用。HVAC_RL 就是用 MATLAB 实现的这么一套最小可落地的样例：从热动态环境建模、DDPG 智能体搭建，到训练、评估、可视化全流程都给出了可跑的代码。适合两类人看：一类刚接触强化学习、想在暖通场景找个小而完整的工程参考；另一类是手里有能耗仿真数据、想试试用 RL 替代传统规则控制的工程师。

2. 目录结构与工程分层：MATLAB RL Toolbox 下的环境与智能体搭法

2.1 顶层目录设计：训练、评估、环境、工具函数各司其职

拿到工程先别急着跑，把目录捋清楚是第一步。这种 RL 项目最忌讳把所有逻辑塞进一个脚本里，HVAC_RL 的目录结构是按"环境、智能体、训练、评估、工具"五个维度拆的，和常见 MATLAB 强化学习项目的组织方式基本一致。

HVAC_RL/ ├── main_train.m # 训练入口，负责装配环境与智能体，启动 train ├── main_eval.m # 评估入口，加载训练结果做指标计算 ├── config/ │ └── buildingConfig.m # 建筑热参数与仿真步长配置 ├── environment/ │ ├── HVACEnv.m # 基于 rlFunctionEnv 的环境封装 │ ├── thermalModel.m # 一阶 RC 热动态模型 │ └── weatherData.mat # 典型日温度、湿度、光照时序数据 ├── agent/ │ ├── createDDPGAgent.m # 创建 DDPG 智能体 │ └── hyperparameters.m # 学习率、批大小、经验池容量等超参 ├── reward/ │ └── rewardFunction.m # 奖励函数：能耗与舒适度惩罚之和 ├── evaluate/ │ ├── baselineRulePolicy.m # 规则基线策略，用于对比 │ └── computeMetrics.m # 节能率、PMV、温度偏差统计 └── utils/ ├── normalizeState.m # 状态归一化 └── plotTrainingResult.m # 训练过程与评估结果绘图

区分"训练入口"和"评估入口"是个好习惯。训练入口做的是装配环境、创建智能体、调用train；评估入口则负责加载训练好的智能体参数、跑整数周期的仿真、输出节能率等指标。两件事混在一个脚本里的话，跑一次训练等几小时不说，想复现结果还得重新跑一遍，太折磨人了。

运行顺序也简单：先打开config/buildingConfig.m确认建筑参数，然后直接跑main_train.m，训练完在同一个工作区里跑main_eval.m看报告。第一次跑通的时间不会很长，因为这个环境状态维度低，不需要太多算力就能看到收敛趋势。

2.2 热动态模型：用一阶 RC 等效电路描述房间温度变化

RL 环境的核心是"状态怎么转移"，在暖通场景里就是温度随时间的演化。HVAC_RL 没有用 EnergyPlus 这种重型工具，而是采用一阶 RC 等效热模型——把墙体热阻 R、室内热容 C 看作电路元件，室内外温差驱动热量流动，再叠加空调供冷/供热功率和内部热增益。模型简单但物理意义明确，训练迭代速度快，适合做算法验证。

function nextTemp = thermalModel(currentTemp, outsideTemp, hvacPower, dt, params) % 一阶 RC 热动态离散递推 % currentTemp: 当前室内温度 (°C) % outsideTemp: 室外温度 (°C) % hvacPower: 暖通设备的制热/制冷功率 (kW)，正值制热，负值制冷 % dt: 时间步长，本项目取 0.25h，即 15 分钟一个控制周期 % params: 结构体，包含热阻 R、热容 C、内部热增益 Qgain、能效比 COP C = params.C; % 室内空气与围护结构的等效热容 (kJ/°C) R = params.R; % 围护结构等效热阻 (°C/kW) Qgain = params.Qgain; % 人员、设备产生的内部热增益 (kW) COP = params.COP; % 制冷/制热能效比，作用是把电耗映射到冷量 Qh = hvacPower * COP; % 电功率转化为热功率 dT = (outsideTemp - currentTemp) / R; % 墙体传热引起的温度变化速率 dT = dT + (Qh + Qgain) / C; % 叠加空调与内部热增益 nextTemp = currentTemp + dT * dt; % 欧拉法离散递推 end

这里有个细节值得注意：hvacPower是电功率，但进到热平衡方程里得是热功率，所以乘了COP。很多第一次做暖通 RL 的人会在这里算错，导致奖励曲线的量级看起来一切正常、实际温度却对不上物理过程。params里的R和C从哪来？常见来源是 ASHRAE 手册里的典型围护结构参数，或者从实际楼宇的能耗数据反推。HVAC_RL 的默认值设在一个商用办公建筑的量级上：R大概 2.5 °C/kW，C大约 8000 kJ/°C，这样 15 分钟的步长下温度变化平滑但不迟钝。

2.3 智能体选型：为什么连续动作空间选了 DDPG

HVAC 的控制动作是连续的——压缩机频率、冷冻水阀门开度、送风温度设定值都不是离散档位。DQN 这类基于值函数的算法天然不适合，所以这个项目选择了深度确定性策略梯度（DDPG），它属于 Actor-Critic 架构，Actor 直接输出连续动作，Critic 评估状态动作对的价值，搭配目标网络和软更新让训练过程更稳定。

function agent = createDDPGAgent(obsInfo, actInfo) % 从固定配置创建 DDPG 智能体 hyper = hyperparameters(); % Actor 网络：状态 4 维 -> 隐藏层 128/64 -> 动作 1 维，用 tanh 限制范围 actorNet = [ featureInputLayer(obsInfo.Dimension(1), 'Normalization', 'none', 'Name', 'obs') fullyConnectedLayer(128, 'Name', 'fc1') reluLayer('Name', 'relu1') fullyConnectedLayer(64, 'Name', 'fc2') reluLayer('Name', 'relu2') fullyConnectedLayer(actInfo.Dimension(1), 'Name', 'action') tanhLayer('Name', 'actionTanh') ]; actorOptions = rlRepresentationOptions('LearnRate', hyper.actorLearnRate, 'Optimizer', 'adam'); actor = rlContinuousDeterministicActor(actorNet, obsInfo, actInfo, actorOptions); % Critic 网络：状态与动作拼接 -> 隐藏层 128/64 -> Q 值 criticNet = [ featureInputLayer(obsInfo.Dimension(1) + actInfo.Dimension(1), 'Normalization', 'none', 'Name', 'stateAction') fullyConnectedLayer(128, 'Name', 'fc1') reluLayer('Name', 'relu1') fullyConnectedLayer(64, 'Name', 'fc2') reluLayer('Name', 'relu2') fullyConnectedLayer(1, 'Name', 'qValue') ]; criticOptions = rlRepresentationOptions('LearnRate', hyper.criticLearnRate, 'Optimizer', 'adam'); critic = rlQValueFunction(criticNet, obsInfo, actInfo, criticOptions); % 组装智能体 agentOpts = rlDDPGAgentOptions('SampleTime', hyper.sampleTime, 'MiniBatchSize', hyper.miniBatchSize); agentOpts.ExperienceBufferLength = hyper.bufferLength; agentOpts.TargetUpdateFrequency = hyper.targetUpdateFrequency; agentOpts.NoiseOptions.Variance = hyper.explorationNoise; agent = rlDDPGAgent(actor, critic, agentOpts); end

网络结构走的是"宽到窄再到单输出"的典型压缩路径：观测 4 维最先映射到 128 维，保证信息充分表达；Critic 这边把状态和动作拼接后喂进去，原因是一个动作的好坏必须是"在这个状态下做这个动作"才有意义，拆开评估会丢关联信息。rlContinuousDeterministicActor最后一个tanhLayer把动作限制在 [-1,1]，但实际的控制量是 0 到 1 的归一化值，所以环境那边在接收到动作后还要做一次线性的反归一化。

3. 核心代码拆解：观测、动作、奖励到训练闭环

3.1 环境封装：观测空间与动作空间的规格定义

在 MATLAB RL Toolbox 里自定义环境有两条路：用rlFunctionEnv包两个函数句柄，或者用 Simulink 搭模型。HVAC_RL 用的是前者，因为纯脚本仿真调试速度快，方便打断点观察中间量。观测空间包含四个量：室内温度、室外温度、设定温度、人员状态。动作空间只有一个：归一化的暖通设备功率。为了让智能体更快收敛，所有输入量都按合理范围做了缩放到大致相同的数值区间。

function [env, obsInfo, actInfo] = HVACEnv(params) % 定义观测空间：前 3 个是连续温度，最后一个是 0/1 occupancy 状态 obsInfo = rlNumericSpec([4 1], ... 'LowerLimit', [16; -15; 18; 0], ... 'UpperLimit', [35; 45; 28; 1]); obsInfo.Name = 'HVAC State'; obsInfo.Description = 'T_in; T_out; T_set; occupancy'; % 定义动作空间：归一化的设备功率，范围 0-1，1 代表满负荷制冷 actInfo = rlNumericSpec([1 1], 'LowerLimit', 0, 'UpperLimit', 1); actInfo.Name = 'HVAC Power'; % 用函数句柄包成 rlFunctionEnv env = rlFunctionEnv(obsInfo, actInfo, ... @(action, loggedSignals) stepFunction(action, loggedSignals, params), ... @() resetFunction(params)); end

rlNumericSpec的LowerLimit和UpperLimit不只是格式声明，它会被智能体用来初始化网络输出层的范围估计。这里把室外温度下限放到 -15°C，覆盖了大部分寒冷地区冬季场景。动作空间的 0-1 归一化很关键：如果直接把功率范围设成 0 到 200kW，Actor 的tanh输出会被放大 200 倍，梯度在边界附近的敏感度完全不同，收敛难度会大很多。

resetFunction负责每次回合开始时的状态初始化，常见做法是让室内温度从一个随机值出发，模拟不同工况：

function [initialState, loggedSignals] = resetFunction(params) % 回合开始时随机初始化室内温度与人员状态 initialT = 20 + 3 * randn(); % 取均值 20°C 的正态分布，模拟不同起始工况 occupancy = double(rand() > params.occupancyProb); % 按概率生成 0/1 状态 loggedSignals.accumulatedEnergy = 0; % 记录本回合累计能耗 loggedSignals.currentTemp = initialT; initialState = [initialT; params.outsideTemp; params.setPoint; occupancy]; end

loggedSignals是个可选的传递结构体，用来在 step 之间携带累计量。这里放accumulatedEnergy是为了在回合结束时统计总能耗，也可以在奖励函数里做实时能耗惩罚。注意归一化只发生在观测送到网络之前，环境内部始终用物理量纲计算，避免在建模阶段就引入归一化带来的数值混乱。

3.2 奖励函数：把"省电"和"舒适"翻译成一个数

奖励函数设计是 RL 项目里最需要反复试验的部分，直接决定智能体学会什么。HVAC_RL 的奖励拆成两端：能耗成本和舒适度惩罚。舒适度用室内温度与设定温度的绝对偏差来度量，但允许一个死区——在这个范围内认为用户无感知，不扣分，避免智能体为了省电刻意把温度压到设定值边缘。

function [reward, nextState, loggedSignals] = stepFunction(action, loggedSignals, params) % step 函数：执行动作 -> 递推温度 -> 计算奖励 state = loggedSignals.currentTemp; outsideTemp = params.outsideTemp; setPoint = params.setPoint; occupancy = loggedSignals.occupancy; % 反归一化：把 [0,1] 的动作映射到实际电功率范围 power = action(1) * params.maxPower; if params.mode == 0 power = -power; % 制冷模式下功率为负，代表从室内抽走热量 end % 调用热动态模型更新温度 nextTemp = thermalModel(state, outsideTemp, power, params.dt, params); % 能耗成本：电功率乘以电价再乘步长，折算为元 energyCost = power * params.electricityPrice * params.dt; if power < 0 energyCost = abs(power) * params.electricityPrice * params.dt; % 制冷耗电按绝对值算 end % 舒适度惩罚：死区 1°C，超出部分线性惩罚 comfortPenalty = 0; if abs(nextTemp - setPoint) > params.deadband comfortPenalty = params.comfortWeight * (abs(nextTemp - setPoint) - params.deadband); end reward = -energyCost - comfortPenalty; % 奖励为负成本之和，目标是最小化 % 组装下一状态 occupancyNext = loggedSignals.occupancy; % 本场景假设一个回合内 occupancy 不变 nextState = [nextTemp; outsideTemp; setPoint; occupancyNext]; loggedSignals.currentTemp = nextTemp; loggedSignals.accumulatedEnergy = loggedSignals.accumulatedEnergy + energyCost; % 回合结束条件：超出安全温度范围 isDone = (nextTemp < params.minSafeTemp) || (nextTemp > params.maxSafeTemp); if isDone reward = reward - params.safetyPenalty; % 重大惩罚，防止智能体探索过热/过冷状态 end end

这段代码里有三个参数直接影响训练行为：comfortWeight控制舒适度惩罚的相对权重、deadband控制容忍范围、safetyPenalty则是安全兜底。常见的调参误区是comfortWeight设太大，智能体学到了"精准控温"，但能耗高得离谱；设太小又会在舒适度边缘疯狂试探。HVAC_RL 默认值里，comfortWeight约在 0.5 而电价系数在 0.1 量级，意味着偏离设定温度 1°C 的代价大约是同时段能耗代价的 5 倍左右，这个比例在多数楼宇场景下是比较合理的起点。

奖励统一为负值还有一个好处：训练曲线的最低点就是"成本"最低点，看着AverageReward从 -300 慢慢爬到 -50，心里有底。

3.3 训练主循环与监控手段

训练入口做的事情就是把前两节的部件拼起来，然后调用train。MATLAB 的train函数是封装好的，但训练选项里的参数很值得逐一看。

trainOpts = rlTrainingOptions('MaxEpisodes', 600, 'MaxStepsPerEpisode', 96, ... 'StopTrainingCriteria', 'AverageReward', 'StopTrainingValue', -80, ... 'SaveAgentCriteria', 'EpisodeReward', 'SaveAgentValue', -100); trainOpts.Plots = 'training-progress'; trainOpts.Verbose = true; trainOpts.ParallelizationOptions.UseParallel = false; trainingStats = train(agent, env, trainOpts);

MaxStepsPerEpisode取了 96，对应一天 24 小时除以 15 分钟步长——一个回合就是完整的一天。这是刻意设计的，让智能体在一个回合内看到昼夜温差变化和不同 occupancy 状态的切换。StopTrainingCriteria设为AverageReward后，只要最近若干回合的平均奖励超过 -80，训练会提前终止，不需要傻等 600 个回合。SaveAgentCriteria则保证哪怕最终训练不够理想，中途也有一个中间版本的智能体被保存下来——这是很多项目会忽略的后悔药。

MATLAB 的training-progress画板能实时看每回合奖励和平均奖励曲线，我一般还会额外用plotTrainingResult把奖励和能耗拆开画，因为奖励是两者的加权和，有时看奖励曲线觉得不错，实际能耗却异常高。

4. 训练与评估：判断智能体是否真的学会了省电

4.1 超参数初值设定与收敛性判断

训练能不能收敛，一半看奖励函数设计，另一半看超参数。HVAC_RL 把超参集中在hyperparameters.m里，改起来很方便。几个关键值的初始设定和理由如下：

参数	默认值	说明
`actorLearnRate`	1e-4	Actor 网络学习率，偏低防止策略更新过猛
`criticLearnRate`	1e-3	Critic 学习率，通常比 Actor 高一个量级
`MiniBatchSize`	64	经验回放批大小
`ExperienceBufferLength`	1e5	经验池容量，存约 1000 个回合的数据
`TargetUpdateFrequency`	100	目标网络同步间隔，每 100 步更新一次
`explorationNoise`	0.15	探索噪声方差，训练后期可人工调低
`SampleTime`	0.25	控制周期，单位小时，与热模型 dt 一致

判断收敛不能只看奖励曲线。一个可靠的辅助信号是 Actor 输出的动作分布——在训练初期动作噪声覆盖整个 [0,1] 区间，接近收敛时动作应该集中到某个稳定区域。如果训练到后半段动作仍在大幅波动，基本可以断定是 Critic 对 Q 值的估计还不稳定，常见应对是降低criticLearnRate或增大TargetUpdateFrequency。

4.2 离线评估与基线对比

训练是"在环境中边试边学"，评估则是"把策略固定下来，在不同工况下统计表现"。HVAC_RL 的评估脚本会跑三个对比对象：训练好的 RL 智能体、传统规则策略（如"温度高于设定值就全功率制冷到设定温度再停机"的滞环控制）、以及一个固定功率策略作为下界参考。

function metrics = computeMetrics(agent, env, weatherProfile, numDays) % 在给定天气序列上评估策略，返回多项统计指标 R = reset(env); dayCount = 0; totalEnergy = 0; totalDeviation = 0; totalComfortViolationTime = 0; for step = 1:numDays * 96 % 每天 96 个 15 分钟步长 action = evaluatePolicy(agent, R); % 注意用 evaluate，不加探索噪声 [nextR, reward] = env.step(action); totalEnergy = totalEnergy + env.EnergyCost; tempDeviation = abs(nextR(1) - nextR(3)); totalDeviation = totalDeviation + tempDeviation; if tempDeviation > 1.5 totalComfortViolationTime = totalComfortViolationTime + 1; end R = nextR; end metrics.avgEnergy = totalEnergy / numDays; metrics.avgTempDeviation = totalDeviation / (numDays * 96); metrics.comfortViolationRatio = totalComfortViolationTime / (numDays * 96); metrics.pmvEstimate = estimatePMV(metrics.avgTempDeviation); % 用温度偏差近似 PMV 趋势 end

评估时必须关闭探索噪声。DDPG 的 Actor 在训练时输出会叠加高斯噪声，这是为了探索；但评估时若还带着噪声，跑出来的指标方差会很大，同一个策略跑两次结果差别明显，让人摸不着头脑。evaluatePolicy内部第一个动作应该直接取 Actor 的确定性输出。

4.3 结果可视化与节能率计算

评估完要把结果画出来，图比数字更直观。HVAC_RL 的plotTrainingResult会生成两张图：第一张是室内温度轨迹与设定温度曲线对比，第二张是逐时能耗柱状图，RL 策略与规则策略各画一组。节能率的计算公式很简单：

energySavingRatio = (baselineEnergy - rlEnergy) / baselineEnergy * 100; fprintf('节能率: %.2f%% \n', energySavingRatio); fprintf('平均温度偏差: %.2f °C \n', avgDeviationRL);

由于项目的热模型和奖励函数用的是同一套参数，RL 策略天然知道"怎么做能耗低"，节能率会比实际工程中偏高——这是仿真评估的局限，读数据时心里要有一杆秤。在默认参数训练到收敛后，RL 策略通常在"非占用时段"（夜间）会把温度带控制得比规则策略更松，白天提前预冷，整体节能率大致落在 10% 到 20% 的区间，具体数值会随天气数据文件不同而变化。

5. 避坑记录：MATLAB RL 实战里几个容易翻车的地方

5.1 状态没做归一化，训练直接发散

现象是：训练前几十个回合奖励还能看，突然某个回合开始NaN，后面所有回合并全部变成NaN，曲线直接断掉。查了很久发现是状态向量里的室外温度在冬季可达 -10°C，夏季可达 35°C，与室内温度的尺度差了一个数量级，神经网络中间层的加权求和很容易让数值进入梯度爆炸区。

原因本质是 ReLU 网络的输入分布不一致，加上 MATLAB 默认不对rlNumericSpec的数据做标准化，需要自己在环境层把状态变换到接近 0 均值、单位方差的区间。解决方式是写一个normalizeState.m，用运行时统计到的 min/max 做线性缩放，同时在网络首层不要轻易开Normalization，因为 MATLAB 的featureInputLayer标准化参数需要额外配置，直接用环境侧手工归一化更可控。

function normState = normalizeState(rawState, stateMin, stateMax) % 线性归一化到 [0,1]，避免量纲差异干扰网络更新 normState = (rawState - stateMin) ./ (stateMax - stateMin); end

从那以后，我每次搭新环境都会先把观测空间的上下限明确写出来，如果某个维度变化范围超过 20 倍，一律先归一化再进网络。

5.2 奖励函数尺度失当，智能体学会"摆烂"

现象是训练后期奖励曲线稳定在一个"还不错"的水平，但温度轨迹明显偏离设定温度，能耗也居高不下。把奖励拆开看才发现：由于comfortWeight设得太小（0.1），温度偏差 2°C 的舒适度惩罚只有 0.2，而能耗项每步就有 0.3 到 0.5 的成本，智能体发现"干脆不制冷，让温度飘着"是更省事的策略。

这类问题在奖励设计里叫reward hacking，智能体找到的"最优解"不是我们想要的语义。解决方式是先单独跑一次固定功率策略，统计它的单步能耗与温度偏差量级，再把comfortWeight设定为让温度越限的惩罚显著大于能耗节约的量级。我把deadband从 0.5 调大到 1.0、comfortWeight调到 0.5 之后，温度轨迹重新贴回设定带，奖励曲线虽然绝对值变大了，但策略行为符合预期。

5.3 仿真步长与 RL 采样时间不一致

现象是训练过程很慢，而且温度曲线出现明显的高频抖动。原因是热模型dt取了 5 分钟，而rlDDPGAgentOptions的SampleTime误设成 1 小时。智能体以为一次控制的效果管一小时，实际环境 5 分钟就响应一次，中间大量状态转移智能体根本"没看见"，学习到的策略自然是短视的——只盯着眼前的温度变化猛调功率。

解决方式有两种：要么把dt与SampleTime对齐，HVAC_RL 默认两者都是 0.25 小时；要么在stepFunction内部做多步内循环，智能体每产生一次动作，环境内部跑若干小步。我个人倾向后者，因为热模型的小步仿真更逼真，能让 RL 看到温度在控制间隔内的演化过程，代价是仿真速度变慢。

5.4 并行训练跑出来的结果不可复现

现象是打开ParallelizationOptions.UseParallel = true后训练速度确实快了，但同一套配置连续跑两次，得到的最终策略差异巨大，有时候甚至一个收敛一个发散。原因是经验回放的随机批次顺序在并行工作器之间不同步，且工作器之间的网络参数同步有延迟，导致训练轨迹出现较大分歧。

做工程调参时要保证可复现，我的习惯是先关闭并行训练跑通逻辑和确定奖励函数，最后再用并行训练拉速度。MATLAB 里顺带可以设置rng(0)固定随机种子，虽然并行下不能完全保证一致性，但至少单线程训练时可以做到精确复现。

6. 二次开发：把 HVAC_RL 移植到自己的场景

6.1 替换建筑参数与天气数据

接到实际项目时，你大概不会用 ASHRAE 典型参数，而是要代入本地的围护结构信息和气象文件。改buildingConfig.m里的C、R、maxPower三个值即可，具体数值可以来自能耗模拟软件校准结果。天气数据从.mat替换成本地 TMY（典型气象年）文件，注意观测空间里室外温度的上下限要对应实际气候范围，否则归一化会失真。

6.2 增加控制变量与算法迁移

如果你的系统有多台冷水机组或需要同时控制温湿度，把动作维度从 1 维扩到 2-3 维，Actor 输出层节点数对应调整。算法层面，从 DDPG 迁移到 TD3 或 SAC 时，网络结构不必大改，TD3 主要是加了 Clipped Double-Q 与延迟更新，MATLAB 里换rlTD3Agent或rlSACAgent即可，观测与动作规格不变。