背景与问题
光伏电站越建越多，站内往往同时存在多个品牌的光伏逆变器、储能变流器（PCS）、电表和能量管理系统（EMS）。多数运维平台已完成数据上屏，但使用体验仍是"查询靠翻、汇总靠表、异常靠经验"：
- 多品牌设备数据分散，查询需反复切换系统；
- 报表汇总、趋势分析、多站对比依赖人工；
- 告警信息孤立，缺乏根因判断；
- 数据、告警与处置脱节，问题闭环效率低。
本质问题是缺少从"数据"到"决策"的自动化链路。运维智能体的工程实现，通常分为四层：接入感知 → 语义解析 → 知识推理 → 测算输出。
一、接入与感知层：先归一化，再谈智能
多品牌设备协议各异，第一步是接入与指标归一化。光伏行业现场以 Modbus TCP/RTU 为主，也常遇到厂商私有协议与规约转换器。建议先建立统一的"电站-设备-指标"模型，再谈上层分析。
指标字典示例（JSON 结构，示意）：
{
"station_id": "ST-2026-001",
"device": {
"type": "inverter",
"vendor": "vendor_a",
"modbus_addr": 1,
"register_map": {
"active_power": "30001",
"daily_yield": "30003"
}
},
"metrics": [
{
"metric": "active_power", "unit": "kW", "granularity": "5min" },
{
"metric": "daily_yield", "unit": "kWh", "granularity": "1d" }
]
}
要点：字段命名、单位、时间粒度必须统一；采集层建议 5 分钟级高频数据入时序库，日/周级统计由定时任务生成。先完成指标归一化，后续 AI 能力才有可靠的数据底座。
二、语义解析层：把业务问题变成查询任务
传统监控要求用户熟悉菜单层级与查询逻辑。智能体通过 NL2Query 思路，将自然语言问题解析为结构化查询与计算任务：
| 自然语言输入 | 解析结果 |
|---|---|
| "对比A站和B站上周发电量" | 查询 A/B 站过去 7 天 daily_yield，按日聚合 |
| "本周有哪些站发电异常" | 计算各站日发电量同比/环比偏差，阈值过滤 |
| "昨天B站的告警有哪些" | 查询 B 站告警表，按时间倒序 |
实现上采用意图识别 + 槽位填充（Slot Filling），再翻译为 SQL 或内部 DSL。对高频业务问题建议固化查询模板，避免每次都走大模型推理，降低延迟与调用成本。
三、知识推理层：垂直知识库 + 检索增强
通用大模型回答宽泛，无法支撑"这个故障损失了多少收益"这类问题。工程上建议自建光储故障知识库，并通过检索增强生成（RAG）让模型基于知识库回答，而不是自由发挥。知识条目建议包含：
- 故障现象（告警代码、表象特征）
- 可能根因（如发电量骤降 → 组串衰减 / PCS 通讯中断 / 限电）
- 排查步骤
- 处置建议与优先级
高频故障场景优先覆盖：发电量骤降、电池压差异常、组串衰减、PCS 通讯中断、并网异常等。RAG 流程：告警触发 → 向量化检索知识条目 → 拼接上下文 → 生成根因分析与处置建议。注意对检索结果做置信度与来源标注，避免模型臆测。
四、测算与输出层：把告警换算成钱
没有损失量化的告警，无法支撑处置优先级排序。损失测算示意公式：
损失发电量 ≈ 故障时长 × 受影响装机容量 × 实时出力系数
收益损失 ≈ 损失发电量 × 分时电价 × 消纳系数
说明：实际工程需结合场站 PR 值、弃光率、市场化电价曲线等参数标定；输出建议给出"损失区间"而非单一数值，避免误导决策。最终按"损失金额 × 恢复成本 × 处置时效"生成优先级排序，形成"感知-推理-测算-闭环"链路。
五、部署形态：云端 SaaS 与本地私有化
考虑不同经营主体，推荐双部署方案：
- 云端 SaaS：边缘网关采集上报 → 云端服务容器化部署（如 ACK），时序数据使用云上时序数据库，离线分析用对象存储；按电站/账号维度做多租户隔离，适合中小型运维服务商快速上线；
- 本地私有化：适合数据合规要求高的大型投资集团，Kubernetes 集群容器化部署，支持离线推理与断网可用。
典型链路：边缘网关（Modbus 采集）→ MQTT/HTTP 上报 → 数据接入服务 → 时序库 + 指标服务 → 智能体编排（查询解析、RAG、测算）→ 运维大屏与告警工单。
六、实践建议与踩坑
- 指标归一化先行：设备厂商多、协议杂，先统一指标字典，再谈 AI；
- 知识库质量决定上限：建议由运维专家参与知识条目建设与评审，定期更新，模型能力只是下限；
- 注意数据质量：坏数据、断点、时钟不同步会造成误告警，采集层需做完整性校验与补采；
- 告警收敛：多站海量告警需做去重、聚合与根因聚类，否则智能体输出会被噪声淹没；
- 从高频场景切入：优先落地"多站运营分析"与"异常风险研判"两个场景，验证后再扩展。
总结
运维智能体的本质，是把"人找数据"变为"数据找人"，把"经验判断"升级为"知识库+模型判断"。落地顺序建议：先归一化、再知识库、后测算。技术选型上，云端优先利用托管容器与时序数据库降低运维成本；数据敏感场景保留私有化选项。
