聚合引擎：从单资源到可调容量池文章目录聚合引擎：从单资源到可调容量池引言：聚合不是加法先对坐标：聚合引擎站在"数据融合三级跳"的中间一、输入单元：档案与评估的合成快照二、分组器：同节点是铁律三、容量池计算器：两层折扣的承诺口径四、反弹效应：200 栋楼不能同时恢复五、快慢接力：储能先上，空调跟上，储能退出六、资源评级与滚动修正七、架构总视角：三层漏斗与信息对等八、指令分解器：先可行性校验，再按有效能力等比分配真实缺陷复盘：负分配是怎么发生的修复后的分解主流程容量预占：同一资源不能在重叠窗口里卖两次九、实测：九个场景全过十、生产扩展条件：教学实现与生产的差距十一、现实对照：接入容量、调节能力与响应实绩十二、学术视角：资源耦合性与多目标聚合十三、现实对照：湖北的"分钟级池 + 秒级池"双池实践结语：容量池建好了，指令该上路了引言：聚合不是加法前 13 篇攒齐了零件：档案（第 11 篇）、四类资源的可调容量评估（第 12/13 篇）。本篇把它们组装成引擎——把一万台设备的零散能力，聚合成一个能对电网说"我能调 10MW"的可信容量池。先破除最大的误区：聚合承诺容量 ≠ 各资源铭牌加总。行业经验里已经给过教训——100 栋楼基准功率加总 120MW，聚类+可靠性+回弹+通信折扣后，能对外承诺的只有约 37-70MW。聚合引擎的核心工作不是加，是打折：每一层折扣都有物理或行为依据，少打一个就是一次响应不合格。openvpp-aggregator模块交付五个组件：分组器（UnitGrouper）、容量池计算器（CapacityPoolCalculator）、指令分解器（InstructionDecomposer）、任务时间窗（TaskWindow）、容量预占台账（CapacityReservationLedger），10 个单测守住口径（含预占台账的并发回归：登记/查询/释放全方法互斥，并发下不丢更新、不抛并发修改异常）。先对坐标：聚合引擎站在"数据融合三级跳"的中间平台里从设备原始数据到市场报价，中间隔着三跳，每一跳的输入输出与负责模块完全不同。先把这张图立起来，避免边界混淆——聚合引擎既不负责清洗原始数据，也不负责决定市场策略：