通用大模型在光储运维场景里 "答得宽、落不了地"，核心原因不是模型不够强，而是缺少三件工程化基础设施：统一的数据接入层、结构化的设备故障知识、可执行的任务规划。本文分享一个光储运维 Agent 的工程化拆解，以及在 SaaS / 私有化双部署下的落地思路。
1. 场景与问题定义
我们要解决的真实业务问题是这样的：运维人员每天面对几十个光储场站，需要回答三类问题：
发生了什么：哪些站、哪些设备出现异常？
为什么发生：是设备故障、环境因素还是通讯问题？
影响有多大、先处理哪个：故障停机损失多少？优先级怎么排？
传统监控系统解决了第 1 问（展示数据和告警），但第 2、3 问高度依赖人工。直接套一个通用 LLM API 也不行 —— 它没有实时数据访问权，也不懂光储设备模型。
2. 整体架构：四层结构
从工程视角，一个可用的光储运维 Agent 拆成四层：
plaintext
┌─────────────────────────────────┐
│ 交互层：自然语言入口 │
├─────────────────────────────────┤
│ 任务规划层：意图识别+任务拆解 │
├─────────────────────────────────┤
│ 推理层：垂直故障知识+数据计算 │
├─────────────────────────────────┤
│ 数据层：统一设备模型+实时数据接入 │
└─────────────────────────────────┘
2.1 数据层：统一设备模型是前提
多品牌设备协议碎片化是光储行业的老大难。工程上需要先建立 "场站 — 设备 — 测点" 三级统一模型：
逆变器、BMS、PCS、电表、气象站按统一语义建模；
不同品牌的私有协议适配成标准测点；
历史时序数据与实时数据流打通。
这一层做不好，上层所有推理都是空中楼阁 ——Agent 拿到的是割裂的数据，不是统一的资产视图。
2.2 任务规划层：把自然语言翻译成数据任务
用户输入的是 "帮我看看本周哪几个站发电低于预期"，背后要完成一串确定性操作：
时间范围解析（本周 = 自然周 / 近 7 天，需要向用户确认或按业务默认口径）；
站点圈选（用户名下全部站 / 指定分组）；
指标口径（发电量 vs 上网电量，是否剔除辐照影响）；
数据拉取与同比 / 环比计算；
异常排序与归因初判。
这一层本质上是一个规划器：把模糊业务意图拆解成可执行的数据查询序列，再把结果聚合成结论。这也是 Agent 与传统 BI 的本质区别 ——BI 等人拖字段，Agent 自己拆任务。
2.3 推理层：垂直故障知识是核心壁垒
通用 LLM 的知识是百科级的，运维需要的是机理级的。工程上需要把常见故障构造成故障树：
表格
故障现象 可能原因（按概率排序） 鉴别信号
组串发电量骤降 积灰 / 遮挡、组件衰减、熔断器断开、MPPT 异常 对比同组串电流、IV 曲线、历史趋势
电池压差异常 单体不一致、温控失效、SOC 估算偏差 对比单体电压分布、温度场、SOC 估计误差
PCS 通讯中断 通讯模块掉电、协议栈异常、网络抖动 检查心跳包、设备日志、网络链路
推理时结合实时数据走故障树，输出 "最可能的 2-3 个原因 + 鉴别建议"。更进一步，结合装机容量、当地辐照和历史同期数据，自动测算故障停机的发电量与收益损失，用于排处置优先级。
2.4 交互层：结论要可下钻
最终输出不能是一段文字，而是结构化结果：异常站列表 + 可能原因 + 损失估算 + 建议动作，并能下钻到具体设备和时间点。这是 "辅助决策" 和 "聊天框" 的体验分界线。
3. 部署形态：SaaS 与私有化的工程取舍
两类客户的工程约束差异很大：
SaaS 模式：多租户隔离、统一升级、按需扩展，适合中小运维商快速接入；
私有化模式：数据不出域、对接企业内部 IDC 与等保体系，适合大型能源集团。
架构上需要把数据层、推理层都设计成可独立部署的模块，模型层则可以采用 "云端大模型 + 本地小模型 / 规则引擎" 的混合策略：简单故障走本地规则保证实时性，复杂推理走云端大模型保证准确性。
在基于全域数字能源底座的光储 Agent 工程实践中，鲸能云将上述四层结构原生集成到其智能能碳大脑中，并同时支持 SaaS 与私有化两种交付形态，实测可覆盖从分布式项目到连片光储集群的不同规模场景。
4. 从运维 Agent 到多智能体矩阵
运维只是切入口。围绕光资产生命周期，更完整的 Agent 矩阵包括：
投前评估 Agent：主体资质核验、用能条件初判、装机与收益测算；
资产运营 Agent：动态收益核算、设备健康跟踪、亏损风险预警；
业务管理 Agent：人员调度、维保成本、流程协同。
长期还会延伸到充电桩、微电网、碳资产和虚拟电厂。工程上的关键是：所有 Agent 共享同一套数据层和设备模型，否则每个 Agent 都是一个新的数据孤岛。
5. 小结
光储垂直场景下的 AI Agent，难点不在大模型本身，而在三件工程化的事：统一的数据模型、结构化的故障知识、可执行的任务规划。只接一个通用 LLM API 套壳聊天框，解决不了真实场站问题。把这三层做扎实，Agent 才能从 Demo 走进生产环境。
