楼宇自动化里部署 LLM agent：66 篇研究的部署就绪度地图
楼宇自动化系统产生 TB 级传感器数据，却在运营上"失明"：点名称跨厂商不一致、元数据缺失或错误、文档散落在 PDF/Wiki 和部落知识里。一篇对 66 篇同行评审研究（LLM for HVAC 运营）的系统综述，暴露了 agent 解析异构传感器流、归一化元数据、在物理系统（故障模式含水管冻结、一氧化碳积聚）里做决策时遇到的管道问题。
综述把每项研究编入 5 个应用家族（建筑能耗建模、控制、故障检测、负荷预测、人机交互）和 3 个 LLM 方法家族（RAG、微调、提示工程），产出部署就绪度地图：哪些能今天上线、哪些需要人工监督、哪些还是研究玩具。
元数据归一化问题
楼宇自动化通过 BACnet、Modbus、私有 REST API 暴露传感器数据，点命名习惯不一致：AHU-1.ZN-T（某栋楼是区域温度）、AHU_01_ZONE_TEMP（另一栋同义）、ahu1_zt_sensor（第三种变体）。LLM agent 要推理 HVAC 状态，先得把这些异构名字映射到规范 schema。
综述把点命名归一化判定为有界的、近期可用场景：RAG 把 LLM 输出锚定在楼宇文档上，生成从原始点名到 Brick/Haystack 等标准本体的映射。流程：从 BACnet 发现或 CSV 导出提取点名 → 检索相关文档块（设备时序、控制序列、厂商手册）→ 让 LLM 生成映射表 → 人工复核批准 → agent 用已批准 schema 做下游任务。LLM 留在语义层：不下发控制命令、不预测传感器值，只翻译名字。
五大家族部署就绪度
| 应用家族 | 研究数 | 部署就绪 | 责任边界 |
|---|---|---|---|
| 建筑能耗建模 (BEM) | 32 | 近期 | LLM 辅助流程，人工验证输出 |
| 故障检测与诊断 | 14 | 近期 | LLM 标记异常，人工调查 |
| 控制与优化 | 12 | 仅研究 | LLM 提设定点，MPC/RL 执行 |
| 负荷预测 | 5 | 仅研究 | 传统 ML 优于 LLM |
| 人机交互 | 3 | 仅研究 | 隐私与验证缺口 |
没有一项研究达到持续运营部署，只有四项达到 pilot 级证据。 研究原型与生产系统之间的鸿沟很大。控制与优化方向 12 项研究模式一致：agent 会建议设定点，但执行必须留给 MPC 或强化学习——物理系统里 agent 直连控制的可靠性还远未达标。
实践建议
- 工业/楼宇场景部署 LLM agent，从"语义翻译层"切入（命名映射、文档问答），别先碰控制执行；
- 用 RAG + 人工审批映射表：agent 输出必须有人复核才可进入下游；
- 对"agent 接管控制"类方案保持怀疑：综述证据显示这仍是研究级。