技术
用于楼宇控制的多智能体机器学习
大型商业楼宇不是一个控制旋钮。机房启停、空气侧分配和分区设定点会在时间和空间上相互影响。多智能体机器学习把学习边界分配给真正联动运行的子系统，同时用系统层守住舒适度、设备和运维约束。
目标不是许多彼此独立的优化器互相争抢，而是结构化协同：本地智能体学习有用的本地策略；共享约束和实测证据保证整栋系统稳定。
为什么拆分
为什么大型楼宇会变成多智能体问题
问题拆分应跟随设备现实和控制权限，而不是算法流行词。
单体控制很快会让动作空间失控——多分区分楼宇叠加机房、复位和通风变量后，很难在一个策略头里安全探索。
楼宇系统本来就有自然边界：冷站、空气处理机组、楼层分区和热力分组，这些边界与运维认知和设备响应方式一致。
耦合真实存在，因此智能体需要协同层来处理共享资源、冲突需求和系统级舒适或容量限制。
为什么用多智能体
问题拆分带来什么改善
当楼宇过大、耦合过强、又对安全过于敏感时，多智能体学习比单一扁平控制器更合适。
每个子系统上的学习更可处理
每个智能体可以聚焦有边界的状态和动作集——机房启停、送风复位或热力分组——而不是一次学习所有旋钮。
更容易向运维解释
建议可以绑定到可识别的子系统，这让实时运行中的审查、接管和变更管理更现实。
分层关口让上线更安全
系统级限制可以在本地提案进入 BMS 前拒绝或重塑它，并保留清晰的故障回退路径。
协同流程
多智能体学习如何变成可部署控制
流程从架构开始：智能体边界、共享状态、协同规则，然后才是本地学习和实测验证。
01
把智能体边界映射到真实控制权限
智能体围绕运维已经认识的设备组和可写控制点定义，而不是任意模型切分。
- 01在控制权限真实存在的地方，区分机房、空气侧和分区职责。
- 02记录每个智能体可以提议哪些点，哪些仍由操作员持有。
- 03智能体范围要小到可解释，又要大到能覆盖有意义的耦合。
02
定义协同和共享状态
本地智能体需要共享容量、舒适风险、日程和系统级限制的图景，才能把提案安全组合起来。
- 01暴露机房负荷、送风条件、占用上下文和舒适越限等共享变量。
- 02设定协同节拍，避免快速本地决策与较慢的机房级约束互相冲突。
- 03当两个智能体想要互不兼容的结果时，冲突解决必须显式。
03
在系统级约束下训练智能体
学习发生在 ClimaMind 其他训练流程相同的舒适、安全和设备边界内，而不是无约束地追逐本地奖励。
- 01在仿真中覆盖天气、负荷和日程变化，训练本地策略。
- 02用数字孪生拒绝会造成机房不稳或分区舒适失败的本地策略。
- 03在任何建议被推进前，把协同行为与基线序列对比。
04
通过安全和操作员审查关口输出
多智能体输出只有在组合行为稳定、可解释且被现场运维接受时才有意义。
- 01在本地提案变成面向 BMS 的建议前做系统级检查。
- 02在每一层保留人工接管和故障回退路径。
- 03用实测结果决定协同规则或本地策略是否需要修订。
现实问题
架构先于算法。
多智能体机器学习会在团队只增加智能体、却不定义共享资源归属、冲突解决和不良提案停止机制时失败。
协同才是难点
价值不在智能体数量，而在机房、空气侧和分区决策是否能组合成稳定的整栋行为。
单栋强化学习不会自动扩展
一个有边界问题上有效的策略，不会在没有显式边界和通信设计的情况下变成可复制到组合的多智能体控制。
度量仍要看系统级结果
本地奖励改善没有意义，如果总能耗、舒适或操作员负担反而变差。验证必须审查组合结果。
协同标准
多智能体控制被信任前必须满足什么
ClimaMind 把多智能体学习当作协同楼宇控制，而不是一群互相独立的优化器。
01
智能体边界与真实控制权限一致。
02
共享舒适、安全和设备限制位于智能体之上。
03
冲突的智能体提案有显式解决路径。
04
系统级故障回退在任何智能体动作上线前存在。
05
实测行为在本地和机房两个层面都被审查。
参考依据
外部参考资料
这些公开资料用于支撑本页关于多智能体 HVAC 控制和楼宇系统协同的表述。