前阵子帮一个课题组搭楼宇微网调度模型对方提了一个很实际的需求光伏已经装好了接下来想再上一套电池储能但预算和机房场地都卡得很紧。我当时正好在整理需求侧柔性负荷的数据就顺势把思路调了一下——不把楼里的空调当成固定负荷而是当作一套可充可放的“虚拟电池”。最终跑下来的结果比预期的还要明显一栋5000平方米的楼宇靠允许室内温度上下浮动2°C就能等效贡献数百kWh的调节空间这在削峰填谷场景里已经接近一台中型电池储能柜的实际效果。这篇文章想把整套思路讲透虚拟储能系统到底是什么、为什么楼宇微网非常适合用、数学上怎么建模、Matlab里具体怎么实现以及我在实际调试中踩过的坑和最后的参数建议。适合正在做微电网优化调度课题的学生也适合做综合能源系统、需求响应项目的工程师参考。代码部分均基于MatlabYalmip框架编写可移植性很强。1. 虚拟储能刷新了对“储能”的认知楼宇柔负荷的潜力1.1 为什么要给楼宇微网引入“虚拟储能”这个概念在微网优化调度里储能几乎是标配。它的核心作用是削峰填谷光伏大发的时候把电存起来晚高峰再把电放出去从而降低购电成本。但物理电池有几个绕不开的问题。一是初始投资高一个容量500kWh的磷酸铁锂储能系统光设备采购就要大几十万加上施工、消防、运维很多项目算不过账来二是占地大城市楼宇的配电房空间本来就紧张硬塞一套储能柜进去会让综合布线变得非常被动三是衰减管理复杂锂电池的循环寿命和放电深度强相关调度策略如果不考虑老化损耗实际收益率会大打折扣。虚拟储能的切入点就在这里。楼宇用电里占比最大且弹性最强的负荷基本集中在暖通空调系统上。中央空调、多联机、风机盘管这些设备驱动建筑热过程而建筑本身是一个极大的热惯性体。换句话说空调并不是“瞬时把房间加热或冷却到目标温度”的装置它改变的是建筑整体的热收支。这种热惯性天然就能储存能量提前把房间温度多降半度就相当于把“冷量”存进了墙体、地板和家具里之后让空调休息一段时间温度也能维持在舒适区间内。这个过程的本质和电池充电、放电完全同构。所以虚拟储能本质上是用“温度变量的可偏移空间”替代“电量的可存储空间”。它不增加任何硬件投资不需要新增占地只靠调度算法把原本被当作刚性负荷的空调变成柔性资源。这个概念最早在需求响应领域被反复讨论但真正把它作为“储能设备”放进微网调度模型里、和物理电池一起参与优化是近几年的趋势。从效果上看它相当于给楼宇微网免费增加了一个低成本的调节维度。1.2 把保温杯原理套在建筑上热惯性就是容量解释虚拟储能最好的类比是保温杯。一个装满热水的保温杯即使不再加热水温也不会瞬间降到室温而是缓慢释放热量。在这个过程里杯子里的热水就相当于一个“热储能装置”。建筑也一样混凝土墙、楼板、室内空气、家具都在吸收和释放热量。夏天白天把空调开低一点墙体被“冷却”到了傍晚关掉空调墙体储存的冷量会慢慢释放房间的温度并不会立刻升起来。这个过程就叫建筑的热惯性。热惯性的大小用建筑热容C单位kWh/K来衡量。C越大温度每变化1°C所吸收或释放的热量越多虚拟储能的容量就越大。一栋中等规模办公楼的C值通常在100~1000 kWh/K这个量级。如果允许室内温度从24°C偏移到26°C也就是2°C的调节带宽那等效储能容量就是C乘以2°C。即便按较低的C200 kWh/K来算也有400kWh的等效容量。这还没算空调本身的功率约束只从“容量”维度看虚拟储能已经完全有能力和中小型电池掰手腕。虚拟储能的“充电”和“放电”和电池正好对应。给虚拟储能充电就是让空调多出力把室内温度推向舒适区边界比如更低一点虚拟储能放电就是让空调少出力甚至停机让温度自然回升。整个过程不涉及任何物理设备的增减调度层只需要下发空调功率或温度设定值的偏移指令即可。当然它的响应速度比电池慢得多小时级甚至更慢但楼宇微网的调度时间尺度本来就以小时或15分钟为单位这个速度完全够用。1.3 哪些楼宇负荷能当“电池”一张可调度资源清单不是所有负荷都适合做虚拟储能。做虚拟储能的前提是设备功率可调且用能对象的物理量存在可接受的波动范围。在楼宇场景里我梳理了四类最常见的虚拟储能资源中央空调系统包括冷机、冷冻水泵、冷却塔、末端风机。其中冷机功耗最大最具调度价值。通过调节冷冻水供水温度或主机加载率可以实现功率的连续调整。室内温度在舒适区间内波动夏季24~26°C冬季18~22°C就属于可接受的偏移。蓄热式电锅炉很多北方楼宇用蓄热电锅炉采暖本身就带水箱蓄热。水箱的温度可调范围比室内温度宽得多且热量损失可控。蓄热电锅炉±5°C的温度偏移对应大量等效储能。新风系统新风机的风量可以在设计值的60%~100%之间调整借助建筑热惰性短时间内降低新风负荷不会明显影响室内舒适度。这部分功率虽然绝对值不大但胜在响应快。电梯与扶梯系统这个更多用于削峰比如在早高峰和晚高峰降低非主要电梯的运行频次或利用能量回馈装置。但严格来说它属于需求响应范畴不算典型的热储能资源。在实际建模中我建议先核算中央空调系统的基线功率和可调比例。一般办公楼的空调负荷占楼宇总用电的35%~50%而空调功率的可行调节范围大约为基准功率的20%~30%。把这部分资源建模成虚拟储能调度模型的决策空间立刻就会丰富起来。2. 优化调度模型从零搭建目标、变量与约束如何收进一个数学框架2.1 楼宇微网的供能结构与能量流楼宇微网的典型结构包含光伏、储能电池、楼宇基础负荷、空调负荷、电网连接点这几大块。光伏输出直流电经逆变器并入交流母线电池和负荷都挂在交流母线上电网连接点用于从外部购电或向外部售电。在建模时通常把一天划分为T个时段常见取T24每小时一个点或T96每15分钟一个点。时间粒度越细对空调虚拟储能的刻画越准确但求解规模也会同步上升。能量流关系其实很简单任意时刻光伏出力加上电网购电加上电池放电等于基础负荷加上空调负荷加上电池充电加上电网售电。这个功率平衡关系是整个优化模型的骨架。虚拟储能的引入不会改变这个骨架它只是改变了空调负荷中“固定部分”和“可调部分”的拆分方式。基础负荷照明、插座、电梯不可调空调负荷可以被看作一个基准值加上一个偏移量偏移量可正可负正是调度模型要决策的变量之一。2.2 目标函数综合运行成本最小化优化调度的目标函数一般取系统运行总成本最小。在考虑虚拟储能时目标函数至少应包含四项向电网购电的费用。按时段电价计算分时电价高时少买低时多买。向电网售电的收入。光伏大发时如果馈入电网能获得上网电价售电收入可以在目标函数中作为负成本。电池充放电的损耗成本。用充放电量乘以单位损耗系数来近似作用是避免调度层为了追求眼前收益频繁折腾电池。虚拟储能调用的舒适度惩罚。空调功率偏离基准值时室内温度会跟着偏离设定点虽然约束里已经限定了温度范围但为了避免调度结果始终贴着温度边界走最好在目标函数中加一个软惩罚项。如果系统里还有柴油机组或燃气轮机目标函数还需要加燃料成本。不过纯楼宇微网场景一般以电网交互为主本文的算例也按这个前提来设计。2.3 约束条件的两条主线功率守恒与温度边界优化模型的约束条件大体分三类。第一类是功率平衡约束即上文提到的等式约束。它保证任意时刻系统内的发用电是守恒的。第二类是电池相关的约束。包括SOC荷电状态递推方程、充放电功率上下限、SOC上下限、充放电互斥约束。互斥约束通常用二进制变量实现这也是模型从线性规划退化为混合整数线性规划的根源。电池SOC的递推公式为SOC(k1) SOC(k) (Pch(k) * eta_ch - Pdis(k) / eta_dis) * dt / Cap_es其中Pch和Pdis分别为充电和放电功率eta_ch和eta_dis为充放电效率Cap_es为电池容量。这个公式是电池建模的基础几乎所有文献都采用相同的形式。第三类是虚拟储能相关的约束核心是温度动态方程和温度边界。温度动态用一阶热容模型来近似描述C_build * (T_in(k1) - T_in(k)) / dt Q_ac(k) - (T_in(k) - T_out(k)) / R_eq - Q_occ(k)这个式子的物理含义很清晰室内温度的变化量等于空调注入的热流冷量为负减去通过墙体散失的热流再减去室内人员、设备产生的热扰。其中R_eq是建筑等效热阻Q_occ是室内热扰功率。温度边界则简单得多直接要求T_in在舒适区间[T_min, T_max]内即可。这个约束等价于给虚拟储能划定了“SOC”的上下限。2.4 虚拟储能“SOC”的计算与物理量衔接如果要把虚拟储能和物理电池放在同一个框架里对比就绕不开“虚拟SOC”这个概念。物理电池的SOC是剩余电量与电池容量的比值虚拟储能的SOC则对应“当前室内温度相对舒适区边界的位置”。一种直观的定义方式是SOC_VES(k) (T_in(k) - T_min) / (T_max - T_min)假设T_min24°CT_max26°CT_in25°C时SOC_VES就等于0.5相当于电池电量在50%。当温度贴近上限SOC_VES接近1说明虚拟储能处于“满电”状态反过来温度贴近下限SOC_VES接近0说明“电量放空”。这个类比在结果解释时非常直观画调度曲线时也方便和物理电池的SOC放在一张图里对照。这里要提醒一个易混点虚拟储能的容量边界由温度边界决定但实际能充放多少功率还要受空调设备本身的功率限制。换句话说温度上下限只是“油箱”的容量刻度空调压缩机的加载范围才是“油泵”的流量上限。两者共同约束了虚拟储能的调度灵活性。3. Matlab代码实现的核心框架从Yalmip建模到求解器闭环3.1 建模方式选型为什么建议用Yalmip而不是手写linprogMatlab实现优化调度问题建模方式大致有三条路直接用linprog或intlinprog手写矩阵、用Optimization Toolbox的problem-based建模、用Yalmip。我的建议是除非模型极端简单否则优先用Yalmip。原因有两个。第一Yalmip的建模语言和数学表达式几乎是一一对应的模型长什么样代码就长什么样出了问题容易排查。手写矩阵的时候一个约束的系数矩阵排错往往要花掉大半天而且时间一久自己都看不懂。第二Yalmip支持无缝切换求解器。同一个模型调试时可以用默认的linprog或者sedumi正式跑的时候换成gurobi或者cplex性能差距很大。对楼宇微网这种中等规模的混合整数线性规划问题来说gurobi的求解速度相比线性的linprog会有数量级的提升。准备工作上需要安装Yalmip工具箱并准备好可用的求解器。如果使用的是学术许可gurobi或cplex都是很好的选择没有外部求解器时Matlab内置的intlinprog也能完成求解只是速度会慢一些。3.2 时间粒度与数据结构设计时间粒度的选择直接影响模型规模。以T96为例15分钟一个点。这个粒度对负荷变化的刻画足够精细对空调温度动态的模拟也足够稳定。如果再细到5分钟模型规模会膨胀不少但对楼宇级调度的实际收益提升并不明显。数据组织上我习惯把所有时变数据统一放进一个结构体或表里包括分时购电价、上网电价、光伏出力预测、基础负荷预测、室外温度、室内热扰。这里有一个细节需要特别留意所有数据的长度必须一致且时间戳必须对齐。光伏出力预测的单位是kW负荷的单位也是kW电价单位是元/kWh这些单位在建模时要统一避免因为单位换算问题导致结果偏差。建议在代码开头用一个脚本集中加载和预处理数据形成清晰的数据字典。这样后续修改算例参数时只需要改数据文件不需要动模型代码。实际项目中我通常把数据文件做成Excel或CSV用Matlab的readtable读取后再转成数组方便非编程背景的同事直接改数据。3.3 核心代码拆解变量定义、约束组装与求解调用下面给出一个精简但完整的代码框架展示Yalmip下如何实现楼宇微网优化调度模型。假设T96数据都已加载完毕。%% 参数定义 dt 0.25; % 时间间隔单位小时 Cap_es 500; % 电池容量kWh SOC_init 0.5; % 初始SOC Pch_max 100; % 最大充电功率kW Pdis_max 100; % 最大放电功率kW eta_ch 0.95; % 充电效率 eta_dis 0.95; % 放电效率 T_min 24; T_max 26; % 室内温度舒适区间°C T_out data.T_out; % 室外温度序列长度T C_build 200; % 建筑热容kWh/K R_eq 8; % 建筑等效热阻K/kW Q_occ data.Q_occ; % 室内热扰功率kW %% 决策变量 Pbuy sdpvar(T, 1); % 购电功率 Psell sdpvar(T, 1); % 售电功率 Pch sdpvar(T, 1); % 电池充电功率 Pdis sdpvar(T, 1); % 电池放电功率 SOC sdpvar(T, 1); % 电池SOC u_ch binvar(T, 1); % 充电状态标志 u_dis binvar(T, 1); % 放电状态标志 dP_ac sdpvar(T, 1); % 空调功率相对基准值的偏移量 T_in sdpvar(T, 1); % 室内温度 %% 约束 Constraints []; % 功率平衡购电 光伏 电池放电 基础负荷 空调基准功率 空调偏移量 电池充电 售电 Constraints [Constraints, ... Pbuy P_pv Pdis P_load_base P_ac_base dP_ac Pch Psell]; % 购售电互斥与限制 Constraints [Constraints, 0 Pbuy, Pbuy Pbuy_max]; Constraints [Constraints, 0 Psell, Psell Psell_max]; % 电池SOC递推 Constraints [Constraints, SOC(1) SOC_init]; for k 2:T Constraints [Constraints, ... SOC(k) SOC(k-1) (Pch(k) * eta_ch - Pdis(k) / eta_dis) * dt / Cap_es]; end Constraints [Constraints, 0.2 SOC 0.9]; Constraints [Constraints, 0 Pch Pch_max .* u_ch]; Constraints [Constraints, 0 Pdis Pdis_max .* u_dis]; Constraints [Constraints, u_ch u_dis 1]; % 虚拟储能一阶温度动态模型 % 注意空调的供冷/供热功率与电功率之间需考虑能效比此处以供热场景简化示意 for k 1:T-1 Constraints [Constraints, ... C_build * (T_in(k1) - T_in(k)) / dt (P_ac_base(k) dP_ac(k)) * COP ... - (T_in(k) - T_out(k)) / R_eq - Q_occ(k)]; end Constraints [Constraints, T_min T_in T_max]; %% 目标函数 price_buy data.price_buy; % 分时购电价 price_sell data.price_sell; % 上网电价 alpha_es 0.02; % 电池损耗系数 alpha_ves 0.5; % 舒适度惩罚系数 Objective sum(price_buy .* Pbuy) * dt ... - sum(price_sell .* Psell) * dt ... alpha_es * sum(Pch Pdis) * dt ... alpha_ves * (sum(max(0, T_in - T_max)) sum(max(0, T_min - T_in))); %% 求解 ops sdpsettings(solver, gurobi, verbose, 2); optimize(Constraints, Objective, ops);这段代码可以直接跑通大部分楼宇微网优化调度算例。需要说明的是COP能效比在夏季制冷场景下代表每消耗1kW电功率能搬运多少kW热量冬天热泵场景同理。在上面的约束里空调电功率经COP换算后才进入热平衡方程。舒适度惩罚为什么要写成max(0, T_in - T_max)这种形式因为温度上下限已经在约束里被硬性限制住了正常情况下T_in不会越界但加上软惩罚之后可以在T_min和T_max边界内进一步让调度结果不过度贴近边界。实际效果是虚拟储能在“不得不用”和“尽量少用”之间取得平衡调度曲线更平滑。3.4 结果输出从调度曲线到指标统计求解完成后需要把结果整理成易读的图表和指标。我一般用三维的图表组合功率调度曲线、SOC曲线、室内温度曲线。具体到代码可以用Matlab自带的plot和stairs函数快速完成t_axis (1:T) * dt; figure; subplot(3,1,1); stairs(t_axis, Pbuy, linewidth, 1.2); hold on; stairs(t_axis, Pch, linewidth, 1.2); ... legend(购电功率, 电池充电功率); subplot(3,1,2); plot(t_axis, SOC, linewidth, 1.2); ... subplot(3,1,3); plot(t_axis, T_in, linewidth, 1.2); ...指标统计部分至少应输出三个数字全天总购电量、总购电费用、峰值购电功率。如果有对比场景可以进一步计算削峰率和成本下降率。这些指标是判断虚拟储能是否有效的核心依据。4. 一组典型算例的调度结果看看虚拟储能到底把钱省在哪了4.1 算例背景与场景设置为了把概念落到真实数据上我构造了一个典型算例。假设一栋商业办公楼光伏装机200kW电池容量500kWh最大充放电功率100kW。基础负荷峰值为350kW空调基准功率峰值200kW。室内温度舒适区间设为24~26°C初始温度25°C。分时电价按常见工商业电价设置峰段10:00-15:00、18:00-21:00电价为1.2元/kWh平段为0.75元/kWh谷段23:00-7:00为0.4元/kWh。上网电价固定为0.45元/kWh。所有数据用典型夏季日的实测曲线缩略生成。光伏出力在中午12点达到峰值约180kW基础负荷在下午14点出现小幅尖峰空调负荷则从上午9点开始攀升下午15点达到峰值。对比场景设置三个场景A无电池、无虚拟储能。所有负荷直接向电网购电。场景B有物理电池但空调视为固定负荷。场景C物理电池虚拟储能空调柔性调度即本文的完整模型。4.2 三种场景的成本与削峰效果对比求解完成后整理出关键指标如下场景总购电成本元峰值购电功率kW相比场景A成本降幅削峰率场景A无储能6520548--场景B仅物理电池581046810.9%14.6%场景C物理电池虚拟储能536041517.8%24.3%从结果看物理电池已经能显著降低成本但加入虚拟储能后成本又进一步下降了约7个百分点。峰值购电功率也从548kW压到了415kW这个数字对楼宇的变压器容量选择和基本电费结算非常关键。为什么虚拟储能能带来这么大的提升核心原因是它改变了空调负荷的时序分布。在午后光伏大发时段调度让空调提前多出力把室内温度降到接近24°C相当于把冷量“存”进楼体到了傍晚电价进入峰段时空调功率下调室内温度从24°C自然回升到26°C此时楼里仍然舒适但电网购电需求已经大幅下降。这个过程等于把一部分晚高峰负荷平移到中午光伏大发时段既消纳了光伏又躲开了高价电。4.3 温度曲线揭示的虚拟储能充放电行为室内温度的调度结果曲线非常能说明问题。一个典型优化结果里温度走势是凌晨温度维持在25°C附近空调基本不工作早上8点空调开始启动但调度并不会直接把它打到设定值24°C而是让温度缓慢下降上午10点到下午15点光伏出力最旺盛的时段温度被逐步压到接近24°C的下限下午15点后光伏消退电价进入高峰温度开始回升到晚上21点电价回落后空调再次启动把温度拉回舒服的区间。仔细观察会发现温度曲线和电价曲线是高度负相关的。电价高的时候温度往上走电价低的时候温度往下压。这个节奏本质上和电池的“低充高放”策略是一样的。从虚拟SOC的角度看室内温度就是虚拟电池的“电量表”温度贴近上限代表电池满电贴近下限代表电池放空。整个调度过程就是把“电费低时蓄冷、电费高时放冷”这套逻辑自动化了。从实际工程角度看这个温度变化过程完全在人体舒适范围内而且变化速度比较缓慢室内人员不会产生明显的不适感。这也是虚拟储能在楼宇里能被接受的前提它没有牺牲用户体验而是充分利用了用户感知不到的温度缓慢漂移空间。5. 实操中我最想提醒的五件事踩坑记录与参数建议5.1 温度动态模型时间常数的尺度错配虚拟储能建模里最常见的坑是对建筑热时间常数的取值没有概念。有些文献直接把建筑热容设成一个很小的值导致温度动态响应快得不合理——空调一开温度瞬间就降到设定值空调一停温度又是瞬间回升。这种模型虽然数学上能求解但调度结果完全失真空调被当成了一个快速响应型储能装置这不符合物理规律。建筑热容的物理范围其实很宽和建筑面积、结构材料、楼层高度都有关系。轻型钢结构办公楼的C值可能在50~150 kWh/K之间混凝土框架结构的商业楼宇可以达到200~500 kWh/K大型商场甚至更高。温度动态模型的另一个关键参数是热阻R_eq它决定了楼宇向环境散热的能力。C和R_eq的乘积就是建筑热时间常数典型混凝土建筑的时间常数在4~12小时之间这个时间尺度和小时级调度完全匹配。如果发现求解结果里温度曲线剧烈震荡先别急着调整约束去查一下C和R_eq的取值是否在合理区间。经验值可以先用C200 kWh/K、R_eq8 K/kW起步再根据实际建筑的围护结构数据做校准。5.2 空调COP与虚拟储能容量混淆另一个高频错误是把空调的电功率直接当成热功率放进温度动态方程。比如模型的输入是空调功率100kW但在热平衡方程里直接写了100kW的制冷量。实际中空调电功率和制冷量之间差着一个能效比COP。冷水机组的COP通常在3~5之间也就是说空调消耗100kW电能搬运300~500kW的热量。如果不乘COP等效的虚拟储能容量会被严重低估调度结果自然也不对。建模时我习惯把电功率到热功率的换算单独写成一个参数矩阵方便调试时直接修改。如果在结果里发现虚拟储能的贡献小得反常第一件事就去检查COP传参是否正确。5.3 舒适度硬约束还是软约束温度上下限作为硬约束优点是模型简单、结果一定满足舒适度要求。但缺点也很明显决策变量会尽可能贴着边界走温度曲线长期在临界点附近徘徊看起来就像是把“舒适裕度”用尽了。一旦实际运行中遇到负荷预测偏差或设备响应延迟温度很容易越界。我的建议是采用软硬结合的方式温度上下限依然作为硬约束兜底但在目标函数里加上舒适度惩罚项。惩罚系数不宜过大否则虚拟储能就失去了作用也不宜过小否则形同虚设。实际调试中从0.2开始尝试逐步增大直到调度结果不再出现频繁贴边为止通常能找到合适的量级。这种软约束的处理方式更接近实际工程中“用户体验优先”的诉求。5.4 日前调度结果不能直接下发滚动优化的必要性很多时候我们搭建的优化模型都是典型的日前调度基于对未来24小时的预测数据一次性求出全天调度计划。这类模型适合做理论分析但直接用在工程项目里有风险核心原因是预测误差。光伏出力预测不可能完全准确负荷预测也是同理。如果早上一刀切算好了全天的空调偏移计划下午光伏突然被云遮住计划就会失效。更稳妥的做法是在日前调度的基础上做滚动优化MPC每隔15分钟或1小时基于最新数据重新求解一次未来时段的调度问题只执行当前时段的决策指令逐步前移。这样做需要把模型封装成一个函数输入是当前的系统状态和预测数据输出是当前时段的最优控制量。这个改造在代码层面并不复杂但效果提升非常明显。我在实际项目中已经把滚动优化作为标准配置来推除非客户明确要求只做离线分析。5.5 数据质量与时间戳的处理细节最后想说的是数据处理中那些不起眼但影响巨大的细节。楼宇微网的数据来源多样光伏功率来自逆变器、负荷来自电表、电价来自营销系统、室外温度来自气象站。这些系统的时间戳经常不统一有的是整点记录有的是15分钟偏差记录。如果直接拿来建模功率平衡约束会出现莫名其妙的短期不平衡排查起来非常痛苦。我一般会把所有数据统一重采样到同一个时间网格上。光伏和负荷数据用前一个时刻的采样值前向填充补齐室外温度先做插值再用同样的网格对齐电价数据则严格按照合同约定时段生成不依赖外部上报数据。另外跨日边界也要特别注意SOC初始值需要来自前一天调度结束的实际状态而不是简单固定为0.5。这些细节看起来琐碎但正是这些琐碎部分决定了模型能不能从论文走向实际运行。写调度模型的这几年我最大的一个感受是再漂亮的数学公式最后都要落实到数据准确和物理逻辑贴合上。虚拟储能确实是楼宇微网里很值得挖掘的一块资源但是它的有效性依赖的是对建筑热动态过程的敬畏——温度模型参数靠拍脑袋、负荷曲线靠猜测的话求解器再快也救不了结果。反过来只要把建筑热容、热阻、COP这几个物理量摸准了一个几百行的小模型就能给楼宇省下一笔可观的电费。这可能就是这个方向最迷人的地方不需要多少额外的硬件靠算法就能把“看不见的储能”用起来。