commit ef39d4375732578c6b4c7f4513490dad593eb621 Author: stewart hu Date: Tue Sep 1 19:46:59 2026 -0400 init check in diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000..0a5d4fb Binary files /dev/null and b/.DS_Store differ diff --git a/docs/00-overview.md b/docs/00-overview.md new file mode 100644 index 0000000..e553ab7 --- /dev/null +++ b/docs/00-overview.md @@ -0,0 +1,117 @@ +# 00 · 总体架构概览 + +> 本文档集是《基于光明电力大模型的虚拟电厂多时空协同智能运营平台》(proposal.md) 的技术架构设计。 +> 阅读顺序：本篇 → 01 原则 → 02–06 分平面设计 → 07 端到端场景验证 → 08 实现映射。 + +## 1. 系统定位 + +平台是一个**面向虚拟电厂运营的 AI 协同决策与受控执行系统**： + +- 向上对接省级电力交易平台、调度/负荷管理系统、计量结算系统； +- 向下聚合光伏、储能、充电桩、空调、工业负荷、微网/园区等可调资源（现状 31 MW → 目标 ≥ 80 MW）； +- 对内以五类智能体支撑「运行监测 → 资源组织 → 交易决策 → 用户响应 → 控制执行 → 偏差复盘」六环节业务闭环。 + +## 2. 核心架构决策：两平面分离 + +整个系统最重要的一条结构性决策：**认知平面与控制平面严格分离**。 + +| | 认知平面 Cognitive Plane | 控制平面 Control Plane | +|---|---|---| +| 时间尺度 | 分钟 ~ 天（协同决策响应 ≤ 3 分钟） | 秒级 | +| 核心构件 | 五类 LLM 智能体 + Agent Runtime | 执行引擎 + 边缘控制终端 | +| 决策方式 | 大模型编排 + 专业模型计算 | 确定性规则，预批准包络内执行 | +| 输出 | 建议（Proposal 对象）、计划、运行包络 | 控制指令、执行反馈 | +| LLM 参与 | 是（意图理解、任务规划、工具编排、结果解释） | **否，永不** | + +两平面之间唯一的通道是**可信执行链**（03 篇）：认知平面产出的任何计划，必须经过 +规则校核 → 仿真验证 → 审批（包络内自动 / 包络外人工）才能进入控制平面。 +这在结构上落实了 proposal 中「AI 不直接下发控制指令」的强制要求。 + +## 3. 总体架构图 + +```mermaid +flowchart TB + subgraph EXT["外部系统"] + TP[交易平台] + DP[调度 / 负荷管理系统] + MS[计量结算系统] + WX[气象等外部数据] + end + + subgraph COG["认知平面（02 篇）"] + direction TB + RT["Agent Runtime
任务触发 · 意图解析 · 流程编排
工具注册 · 记忆读写 · 审计留痕"] + A1[智能分析 Agent] + A2[资源调度 Agent] + A3[交易博弈 Agent] + A4[交互服务 Agent] + A5["负荷控制 Agent
（仅生成建议）"] + RT --- A1 & A2 & A3 & A4 & A5 + end + + subgraph SKILL["专业模型工具层（05 篇）"] + F[负荷 / 光伏 / 电价预测] + O[优化求解（申报、调度编排）] + SIM[潮流 / 功率平衡仿真] + end + + subgraph SAFE["可信执行链（03 篇）"] + P[Proposal] --> RC[规则校核] --> SV[仿真验证] --> AP{包络内?} + AP -->|是| AUTO[自动放行] + AP -->|否| HUM[人工审批] + end + + subgraph CTRL["控制平面（04 篇）"] + EX[执行引擎] --> EDGE[边缘控制终端] + EDGE --> RES[终端资源：光伏 / 储能 / 充电桩 / 空调 / 工业负荷 / 微网园区] + end + + subgraph DATA["数据与知识底座（05 篇）"] + TS[(时序库)] + RDB[(业务库)] + VDB[(知识库 / RAG)] + FS[(特征库)] + EL[(事件日志)] + end + + subgraph LLM["光明电力大模型（经提供商抽象层接入，08 篇）"] + GM[语义理解 · 规则推理 · 任务规划 · 工具选择 · 策略生成 · 结果解释] + end + + EXT <--> COG + COG <--> SKILL + COG -->|建议| SAFE + AUTO & HUM -->|批准的计划 / 包络| CTRL + CTRL -->|执行反馈| COG + COG <--> DATA + CTRL --> DATA + COG <--> LLM + SV <--> SIM +``` + +## 4. 关键业务对象（系统内的「通用语言」） + +智能体之间不直接对话，只通过类型化业务对象协作（原则 P4，见 01 篇）： + +| 对象 | 说明 | 主要生产者 → 消费者 | +|---|---|---| +| `SituationReport` 态势报告 | 运行状态、异常、风险研判 | 智能分析 → 全体 | +| `ResourceProfile` 资源画像 | 容量、约束、可调潜力、可靠性评分 | 资源调度 → 交易博弈 / 负荷控制 | +| `PositionLedger` 持仓账本 | 各时间尺度的持仓与约束级联 | 交易博弈 ↔ Runtime（共享账本） | +| `Proposal` 建议 | 一切拟执行动作的载体（申报、邀约、控制计划） | 各 Agent → 可信执行链 | +| `Envelope` 运行包络 | 人工预批准的自治边界 | 人工审批 → 可信执行链 | +| `ExecutionReport` 执行报告 | 指令执行结果与偏差 | 控制平面 → 偏差复盘 | +| `ReviewFinding` 复盘结论 | 结构化经验教训，回写记忆与策略库 | 复盘流程 → Runtime 记忆 | + +## 5. 文档地图 + +| 文档 | 内容 | 对应 proposal 章节 | +|---|---|---| +| 01-principles | 九条架构原则 | 2.1 总体架构 | +| 02-cognitive-plane | 五智能体、Runtime、记忆与复盘闭环 | 2.2 / 2.4 | +| 03-safety-chain | Proposal 状态机、包络自治模型 | 2.1 控制安全链 | +| 04-control-plane | 执行引擎、边缘终端、多时空级联 | 2.1 / 2.5 | +| 05-skills-and-data | 专业模型工具契约、数据分层存储 | 2.3 建设内容 02/03 | +| 06-integration | 外部系统接口边界 | 2.1 业务系统 | +| 07-scenario-walkthrough | 日前现货申报端到端场景 | 全部（验证用） | +| 08-implementation | Mastra 映射、LLM 抽象层、部署形态 | 2.5 基础条件 | diff --git a/docs/01-principles.md b/docs/01-principles.md new file mode 100644 index 0000000..8b62702 --- /dev/null +++ b/docs/01-principles.md @@ -0,0 +1,79 @@ +# 01 · 架构原则 + +以下九条原则是全部设计决策的裁判标准。评审任何模块设计、任何 PR 时，先对照本篇。 + +## P1 两平面分离 + +认知平面（LLM 智能体，分钟~天）与控制平面（确定性执行，秒级）严格分离， +唯一通道是可信执行链。**LLM 永远不出现在秒级控制路径上。** + +*推论：* 边缘终端断连时依然能在最近一次批准的包络内自治运行（见 P9）。 + +## P2 LLM 不算数 + +大模型负责意图理解、约束组装、工具选择、流程编排与结果解释； +**申报价格、调度量、控制设定值等一切数字，必须来自专业模型工具层** +（预测模型、优化求解器、仿真引擎），且工具输出原样进入 Proposal，不经 LLM 转写。 + +*反例判据：* 若某个申报数字的来源无法追溯到某次工具调用的输出，即为架构违规。 + +## P3 包络自治（分级授权） + +化解「事事人工审批」与「协同决策响应 ≤ 3 分钟」的矛盾： + +- 人工审批的对象是**包络（Envelope）**——策略级授权（价格/电量边界、可控用户集、有效期），走多级审批高规格流程； +- 包络**内**的单笔动作经规则校核 + 仿真验证后自动放行，全程留痕； +- 包络**外**或校核/仿真告警的动作，升级人工审批。 + +*先例：* 与电网调度对 AGC 机组的「调节死区内自治」授权模型同构——不是新信任模型，是既有模型向 VPP 资源的延伸。 + +*自治拨盘：* 新业务上线初期包络可设为空集（等价于全人工），随复盘数据积累逐步放宽。 + +## P4 对象化通信 + +智能体之间**不进行自由文本对话**。协作只通过事件总线上的类型化、带版本号的业务对象 +（`Proposal`、`ResourceProfile`、`PositionLedger` 等，见 00 篇 §4），由 Runtime 统一路由。 + +*收益：* 协作即数据，数据即审计；事件日志直接成为复盘的原始材料。 + +## P5 一切皆可审计 + +事件溯源（event sourcing）为默认持久化模式。每个 Proposal 携带完整血缘： +发起 Agent、触发源、引用的工具调用及其版本、命中的规则、仿真结果、审批人/包络、执行反馈。 +满足等保合规「操作留痕、合规可审计」要求。 + +## P6 提供商抽象 + +所有 LLM 调用经统一抽象层（模型路由器），面向能力（语义理解/规划/生成）而非厂商 API 编程。 +开发期用商用 API，交付期切换光明电力大模型适配器（预期本地化部署），业务代码零改动。 +提示词、工具定义、评测集均按可迁移标准维护（见 08 篇）。 + +## P7 约束级联（多时间尺度协同） + +年度 → 月度 → 日前 → 日内 → 实时不是五套系统，而是一条**约束级联**： +上层的决策成为下层的约束。级联状态集中于共享的 `PositionLedger`（持仓账本）， +所有 Agent 经 Runtime 读写，禁止在各 Agent 内部私存持仓状态。 + +*推论：* 偏差复盘 = 逐时间尺度对比账本计划值与计量实际值，账本天然是结算对账主干。 + +## P8 数据分层存储 + +不用一个库解决所有问题：时序库（遥测曲线）、关系库（合同/用户/市场结果）、 +向量库（规则/政策/设备约束文档，RAG）、特征库（喂预测模型）、事件日志（审计与复盘）。 +各库有明确的写入方和消费方（见 05 篇）。 + +## P9 边缘自治 + +边缘控制终端在包络内就地闭环（秒级响应、断连续行）， +仅接受经可信执行链下发的计划/包络更新，并持续回传执行反馈。 +省级平台失联 ≠ 资源失控。 + +--- + +## 原则间的张力与取舍备忘 + +| 张力 | 取舍 | +|---|---| +| P3 自治效率 vs 安全底线 | 包络审批规格从严，包络内动作从宽；仿真告警一票升级人工 | +| P4 对象化 vs 大模型灵活性 | 自由文本仅存在于「人 ↔ Agent」交互面；「Agent ↔ Agent」一律对象化 | +| P6 抽象层 vs 光明大模型特有能力 | 抽象层按能力最小公倍数设计；光明特有能力（电力语义）以可选扩展点接入，降级可运行 | diff --git a/docs/02-cognitive-plane.md b/docs/02-cognitive-plane.md new file mode 100644 index 0000000..0a38986 --- /dev/null +++ b/docs/02-cognitive-plane.md @@ -0,0 +1,112 @@ +# 02 · 认知平面：智能体与 Runtime + +## 1. Agent Runtime + +Runtime 是认知平面的操作系统，五类智能体是运行其上的「业务进程」。 + +```mermaid +flowchart LR + subgraph TRIG["任务触发（三源）"] + T1[人工触发
自然语言 / 专题分析 / 任务下达] + T2[事件触发
负荷偏差超阈 / 光伏异常 / 响应不足 / 设备离线] + T3[周期触发
日前预测 / 申报前策略 / 响应前筛选 / 事后复盘] + end + TRIG --> IR[意图解析
LLM] + IR --> WF[流程编排
确定性工作流引擎] + WF --> AG[Agent 调度] + AG --> TL[工具调用
注册表 + 版本化契约] + AG <--> MEM[记忆读写] + WF --> OUT[结果校核 → 业务交付 / Proposal] + WF -.全程.-> LOG[(事件日志 / 审计)] +``` + +### 1.1 组件职责 + +| 组件 | 职责 | 确定性? | +|---|---|---| +| 任务触发器 | 三类触发源统一转为标准 `Task` 对象入队 | 是 | +| 意图解析 | 人工自然语言 → 结构化任务（任务类型、参数、涉及 Agent） | 否（LLM） | +| 工作流引擎 | 按预定义流程模板编排 Agent 与 Skill 步骤；持久化、可恢复 | 是 | +| Agent 调度 | 按业务对象路由（P4），管理 Agent 生命周期与并发 | 是 | +| 工具注册表 | Skill 的类型化契约、版本、权限；LLM 只能调用注册表内工具 | 是 | +| 记忆服务 | 三层记忆的统一读写口（见 §3） | 是 | +| 审计服务 | 事件溯源写入，Proposal 血缘组装 | 是 | + +**关键设计**：意图解析（LLM，非确定）与流程编排（工作流引擎，确定）分离。 +LLM 决定「做什么」（选择流程模板 + 填参数），工作流引擎决定「怎么按步骤做」。 +业务周期触发（如每日申报）甚至不经过 LLM 意图解析，直接实例化流程模板—— +把不确定性压缩到最小必要范围。 + +## 2. 五类智能体 + +每个智能体 = 角色/目标 + 上下文构建 + 流程模板集 + 工具集 + 记忆视图 + 输出对象类型。 + +### 2.1 智能分析 Agent + +- **职责**：态势感知、时序预测组织、异常识别、波动归因、风险预警 +- **触发**：周期（日前 6:00 态势报告）、事件（偏差超阈）、人工提问 +- **工具**：负荷/光伏/电价预测、异常检测、归因分析、报告生成 +- **产出**：`SituationReport`（含风险等级与量化建议） +- **消费**：全体 Agent 及运营人员（数字化运营中心看板） + +### 2.2 资源调度 Agent + +- **职责**：资源接入建档、资源画像、可调潜力评估、资源编组编排、调度方案生成 +- **触发**：周期（画像日更）、事件（新资源接入/资源离线）、申报前（可调容量核定） +- **工具**：潜力辨识模型、聚合优化求解、约束校验 +- **产出**：`ResourceProfile`（含可靠性评分——来自复盘回写）、调度方案类 `Proposal` +- **关键约束**：可调容量核定必须引用最新执行反馈数据（画像时效性直接决定申报风险） + +### 2.3 交易博弈 Agent + +- **职责**：市场规则适配（RAG 检索规则库）、价格研判、报价优化、收益/风险测算、申报生成 +- **触发**：周期（日前申报窗口开启）、事件（价格异常）、人工（策略专题） +- **工具**：电价预测、报价优化求解（MILP）、收益测算、申报格式校验 +- **产出**：申报类 `Proposal`、`PositionUpdate`（写持仓账本） +- **关键约束**：报价数字只能来自优化求解器输出（P2）；申报前必须读取 `PositionLedger` 获取上层时间尺度约束（P7） + +### 2.4 交互服务 Agent + +- **职责**：用户画像、响应意愿识别、用户分群、邀约策略、激励匹配、履约跟踪 +- **触发**：事件（响应容量缺口）、周期（响应前用户筛选）、人工 +- **工具**：用户画像模型、响应率预测、激励优化 +- **产出**：邀约类 `Proposal`（邀约清单 + 激励方案）、`CommitmentRecord`（用户承诺） +- **人机边界**：批量邀约触达属于对外动作，默认包络外（人工审批）；对已建立自动邀约协议的用户群可纳入包络 + +### 2.5 负荷控制 Agent（仅生成建议） + +- **职责**：控制目标分解、控制计划生成、执行偏差监测、纠偏建议、异常处置建议 +- **触发**：批准的响应/调度计划、事件（执行偏差超阈） +- **工具**：指令分解优化、设备约束校验、偏差分析 +- **产出**：控制计划类 `Proposal`（分解到聚合单元/用户/设备的时序设定值） +- **强调**：本 Agent 的输出永远止步于 Proposal，执行由控制平面在可信执行链批准后进行（P1/P3） + +## 3. 记忆体系（三层） + +| 层 | 内容 | 存储 | 写入方 | 生命周期 | +|---|---|---|---|---| +| 工作记忆 | 当前任务上下文、中间结果 | Runtime 内存/缓存 | 各 Agent | 任务级 | +| 情景记忆 | 运行状态、交易结果、控制结果、用户响应等历史事件 | 事件日志 + 时序库 | Runtime 自动 | 永久（审计） | +| 语义记忆 | 复盘沉淀的结构化经验：预测偏差模式（按天气类型）、用户响应可靠性、策略效果评级 | 知识库 + 策略库 | 复盘流程 | 长期，版本化 | + +## 4. 复盘闭环（「自主迭代」的落点） + +``` +D+1 结算数据到达 + → 偏差复盘流程（周期触发） + → 逐尺度对比 PositionLedger 计划值 vs 计量实际值 + → 归因分析工具：预测偏差 / 响应偏差 / 交易偏差 / 控制偏差 + → 产出 ReviewFinding（结构化） + → 回写：语义记忆（经验）、ResourceProfile（可靠性评分）、 + 策略库（策略效果评级）、包络建议（扩/缩自治边界） +``` + +**注意**：复盘不设独立第六 Agent，而是由智能分析 Agent 主导的跨 Agent 工作流模板—— +复盘本质是分析任务，其结论的权威数据源是持仓账本与事件日志（P5/P7）， +单独设 Agent 会造成与分析 Agent 的职责重叠。 + +## 5. 人机交互面 + +- 自由文本只存在于「人 ↔ 平台」界面：智能问答、专题分析、报告生成（AI 交互与分析引擎） +- 业务页面嵌入 AI 结论卡片，卡片与页面双向联动（点卡片定位数据，选数据追问 AI） +- 每张 AI 卡片必须可展开血缘：结论 → 引用的工具输出 → 数据来源（P5 在 UI 层的体现） diff --git a/docs/03-safety-chain.md b/docs/03-safety-chain.md new file mode 100644 index 0000000..b02fbd3 --- /dev/null +++ b/docs/03-safety-chain.md @@ -0,0 +1,108 @@ +# 03 · 可信执行链：Proposal 状态机与包络自治 + +可信执行链是认知平面与控制平面之间唯一的通道，也是本平台在等保与调度合规语境下的 +「真正产品」——评审与验收看的就是这条链的完整性与留痕。 + +## 1. Proposal 对象 + +一切拟执行动作（市场申报、用户邀约、控制计划、调度方案）统一为 Proposal： + +```yaml +Proposal: + id: string # 全局唯一 + type: BID | INVITATION | CONTROL_PLAN | DISPATCH_PLAN + timescale: ANNUAL | MONTHLY | DAY_AHEAD | INTRADAY | REALTIME + originator: + agent: string # 发起 Agent + trigger: MANUAL | EVENT | SCHEDULED + task_id: string + payload: object # 类型化载荷（申报曲线 / 邀约清单 / 控制设定值序列） + lineage: # 血缘（P5） + tool_calls: # 每个数字的来源 + - {tool: string, version: string, inputs_ref: string, outputs_ref: string} + data_refs: [string] # 引用的数据快照 + ledger_version: string # 读取的持仓账本版本 + envelope_ref: string | null # 命中的包络（null = 必走人工） + status: <状态机，见 §2> + audit: [...] # 状态迁移全记录：时间、执行者(系统/人)、依据 +``` + +**硬约束**：`payload` 中任何数值字段必须能在 `lineage.tool_calls` 中找到来源（P2 的机器可校验形式，规则校核阶段强制检查）。 + +## 2. 状态机 + +```mermaid +stateDiagram-v2 + [*] --> DRAFT: Agent 生成 + DRAFT --> RULE_CHECK: 提交 + RULE_CHECK --> REJECTED: 规则不通过 + RULE_CHECK --> SIMULATION: 通过 + SIMULATION --> PENDING_HUMAN: 仿真告警（一票升级） + SIMULATION --> ENVELOPE_CHECK: 仿真通过 + ENVELOPE_CHECK --> AUTO_APPROVED: 包络内 + ENVELOPE_CHECK --> PENDING_HUMAN: 包络外 / 无包络 + PENDING_HUMAN --> APPROVED: 人工批准（可多级） + PENDING_HUMAN --> REJECTED: 人工驳回 + AUTO_APPROVED --> RELEASED: 下发 + APPROVED --> RELEASED: 下发 + RELEASED --> EXECUTING: 控制平面 / 外部接口受理 + EXECUTING --> COMPLETED: 执行完成，反馈回传 + EXECUTING --> ROLLED_BACK: 异常触发回退 + REJECTED --> [*] + COMPLETED --> [*]: ExecutionReport → 复盘 + ROLLED_BACK --> [*]: 异常报告 → 复盘 + 告警 +``` + +要点： + +- **规则校核**（确定性规则引擎）：合规性（交易规则、申报格式）、约束校验（资源约束、合同边界、账本一致性）、权限校验（发起 Agent 是否有权发起该类型）、血缘完整性； +- **仿真验证**：按类型选择——申报类走收益/风险情景回测，控制类走功率平衡/潮流仿真；仿真告警**一票升级**人工，没有例外； +- **实现形态**：持久化工作流（durable workflow）。审批可能悬挂数小时，状态机必须可恢复、超时可配（如申报截止前 30 分钟未批自动升级告警）。 + +## 3. 包络（Envelope）模型 + +```yaml +Envelope: + id: string + scope: + proposal_type: BID | INVITATION | CONTROL_PLAN | DISPATCH_PLAN + timescale: [...] + resource_set: string # 适用资源/用户集（引用资源池分组） + bounds: # 按类型定义，示例： + # BID: 价格 ∈ [p_min, p_max]，电量 ∈ [q_min, q_max]，持仓偏离 ≤ x% + # CONTROL: 单用户削减 ≤ 合同可中断容量，总削减 ≤ y MW，时段 ∈ 允许窗口 + # INVITATION: 仅限已签自动邀约协议用户群，激励单价 ≤ z + validity: {from, to} # 有效期，到期必须重新审批 + approval: + level: L1 | L2 | L3 # 包络本身的审批级别（多级审批） + approved_by: [...] + escalation: # 收缩条件 + - 连续 N 次包络内执行偏差超阈 → 包络自动挂起，回归人工 + - 复盘 ReviewFinding 建议收缩 → 触发重审 +``` + +### 3.1 自治拨盘（运营节奏） + +| 阶段 | 包络状态 | 效果 | +|---|---|---| +| 上线初期 | 空集 | 一切 Proposal 走人工，等价传统模式 | +| 试运行 | 窄包络（如申报价格 ±5% 于预测基准） | 常规日自动，波动日人工 | +| 成熟运行 | 按复盘数据逐步放宽 | 人工只处理异常与包络续批 | + +包络的扩与缩都由复盘数据驱动并留痕——「自主决策」能力的增长是可审计的。 + +## 4. 异常回退 + +- 执行中任何环节异常（校核失败、执行偏差超阈、通道故障）→ 回退至 Runtime 安全控制： + 控制类回退到上一批准计划或安全停机曲线（边缘终端本地持有，见 04 篇）； + 申报类在截止前可撤单重报，截止后转入偏差管理流程。 +- 回退动作本身也是留痕事件，并强制生成复盘任务。 + +## 5. 【待补充：包络边界初值 —— 需要业务侧输入】 + +> **TODO(业务)**：以下参数需由运营团队按湖北现货规则与合同实际确定，是包络模型落地的第一批配置： +> +> 1. 申报类包络：价格边界相对什么基准（电价预测值？历史分位数？），初始偏离容差取多少； +> 2. 控制类包络：分资源类型（空调/储能/工业可中断）的单点削减上限与恢复速率约束； +> 3. 包络审批层级 L1/L2/L3 分别对应公司内哪些岗位/会签流程； +> 4. 「连续 N 次偏差超阈挂起包络」中 N 与阈值的初值。 diff --git a/docs/04-control-plane.md b/docs/04-control-plane.md new file mode 100644 index 0000000..7768a16 --- /dev/null +++ b/docs/04-control-plane.md @@ -0,0 +1,72 @@ +# 04 · 控制平面：执行引擎、边缘终端与多时空级联 + +控制平面是确定性系统：没有 LLM，没有「智能」，只有在批准计划与包络内的可靠执行（P1/P9）。 + +## 1. 空间层级（四级） + +``` +省级平台（认知平面 + 执行引擎 + 可信执行链） + └── 区域 / 聚合单元（VPP 聚合层：计划分解、单元内再平衡） + └── 用户 / 站点（本地 CPS + 数据网关） + └── 终端设备（光伏 / 储能 / 充电桩 / 空调 / 工业负荷 / 微网） +``` + +| 层级 | 决策内容 | 时间尺度 | 自治能力 | +|---|---|---|---| +| 省级 | 总量计划、包络、跨聚合单元分配 | 15 分钟 ~ 天 | — | +| 聚合单元 | 单元内资源再分配、失效资源替补 | 分钟级 | 单元包络内再平衡 | +| 用户/站点 | 设备组协调、就地闭环 | 秒 ~ 分钟 | 断连续行（见 §3） | +| 设备 | 设定值执行 | 秒级 | 设备保护自主 | + +**分解原则**：省级只下发到聚合单元粒度的**目标 + 包络**，单元内的设备级分配由聚合层 +本地完成。省级不做设备级微观管理——既降低通信与时延要求，也符合「分区隔离」安全要求。 + +## 2. 执行引擎（省级） + +- **输入**：可信执行链 RELEASED 状态的 Proposal（控制计划 / 调度方案） +- **职责**： + 1. 计划分解：按聚合单元拆解目标曲线与包络参数； + 2. 受控通道下发：加密、鉴权、幂等（重发不重执行）； + 3. 执行跟踪：汇聚各单元回传，实时对比计划 vs 实际； + 4. 偏差处置：偏差超阈 → 发事件给认知平面（负荷控制 Agent 生成纠偏 Proposal）， + 同时在当前批准包络内触发聚合层再平衡——**纠偏的快速路径是确定性的， + LLM 参与的是下一轮计划修正，不在快速路径上**； + 5. 回退执行：异常时切换到上一批准计划或安全曲线。 +- **输出**：`ExecutionReport`（→ 事件日志 → 复盘） + +## 3. 边缘控制终端 + +- 持有本地副本：当前批准计划 + 包络 + 安全停机曲线（每次下发时原子更新）； +- 秒级就地闭环：按设定值序列控制设备，本地校验设备保护约束； +- **断连策略**：与省级失联时，继续执行最近批准计划至计划期末；计划期满仍未恢复， + 切换安全曲线（逐步退出调节、恢复用户默认运行）。失联期间动作全部本地留痕，恢复后补传； +- 就地量测直采、边缘预处理（清洗、聚合）后上送，降低上行带宽与时延要求。 + +## 4. 时间尺度级联（与持仓账本的配合） + +```mermaid +flowchart TB + Y[年度 / 月度
中长期合约持仓] -->|持仓约束| DA[日前
96 点申报 + 日前调节计划] + DA -->|计划约束| ID[日内
偏差修正 / 滚动调整] + ID -->|设定值序列 + 包络| RT[实时
边缘秒级执行] + RT -->|计量 / 执行反馈| L[(PositionLedger
+ 事件日志)] + L -.复盘.-> Y & DA & ID +``` + +| 尺度 | 决策者 | 产物 | 进入下层的形式 | +|---|---|---|---| +| 年/月 | 交易博弈 Agent + 人工 | 中长期持仓 | 账本约束（日前申报的电量边界） | +| 日前 | 交易博弈 / 资源调度 Agent | 申报曲线 + 调节计划 | 批准计划（96 点） | +| 日内 | 负荷控制 Agent + 执行引擎 | 修正计划 | 更新的设定值序列 | +| 实时 | 执行引擎 + 边缘终端 | 控制动作 | —（终点） | + +**级联的完整性检查**由规则校核承担：任何下层 Proposal 必须引用当前账本版本， +且不得突破上层约束（如日前申报电量不得超出月度持仓允许的偏差带）。 + +## 5. 与安全合规底座的关系 + +- 受控通道全链路加密、双向鉴权；控制指令签名，边缘验签后执行； +- 生产控制区与管理信息区分区隔离，认知平面部署于管理区， + 只能经可信执行链的单向受控接口向控制区投递批准计划； +- 入侵/误操作监测：通道上的异常指令模式（频率、幅度、越界）独立于业务逻辑做旁路监测， + 告警直达人工并可熔断通道（熔断 = 边缘进入断连策略，系统仍安全）。 diff --git a/docs/05-skills-and-data.md b/docs/05-skills-and-data.md new file mode 100644 index 0000000..72da07a --- /dev/null +++ b/docs/05-skills-and-data.md @@ -0,0 +1,80 @@ +# 05 · 专业模型工具层与数据底座 + +## 1. 工具层（Skills）总则 + +- 每个 Skill 是**类型化、版本化、无状态**的服务，注册于 Runtime 工具注册表； +- LLM 只能调用注册表内工具，调用记录（输入/输出快照引用 + 版本）自动写入 Proposal 血缘（P2/P5）; +- Skill 内部可以是任何技术（统计模型、深度学习、MILP、仿真引擎），对外契约统一。 + +## 2. 核心 Skill 契约（一期清单） + +### 2.1 预测类 + +| Skill | 输入 | 输出 | 备注 | +|---|---|---|---| +| 短期负荷预测 | 用户/聚合级历史负荷、气象、日历特征、horizon | 96 点曲线 + 分位数区间（P10/P50/P90） | 目标：平均误差 ≤ 8% | +| 光伏出力预测 | 场站档案、辐照预报、历史出力 | 96 点曲线 + 区间 | | +| 现货电价预测 | 市场历史出清、供需信息、气象 | 96 点分时价格 + 区间 | 已有基础能力，迭代 | + +**契约要点**：预测输出必须带不确定性区间——报价优化的风险测算依赖区间而非点值。 + +### 2.2 评估与优化类 + +| Skill | 输入 | 输出 | +|---|---|---| +| 可调潜力辨识 | 用户负荷曲线、设备档案、历史响应记录 | 分时段可调容量 + 置信度（目标准确率 ≥ 90%） | +| 报价优化（MILP） | 电价预测区间、可调容量、持仓约束（账本）、风险偏好参数 | 96 点申报曲线（价格/电量对）+ 预期收益分布 | +| 聚合/调度优化（MILP） | 资源池、目标曲线、网络与设备约束 | 分聚合单元的分配方案 | +| 指令分解优化 | 单元目标、设备约束、用户承诺 | 设备级设定值序列 | +| 激励优化 | 候选用户集、响应率预测、预算约束 | 邀约清单 + 激励方案 | + +### 2.3 仿真与校核类 + +| Skill | 输入 | 输出 | +|---|---|---| +| 收益情景回测 | 申报 Proposal、价格情景集 | 收益/风险分布、极端情景亏损 | +| 功率平衡/潮流仿真 | 控制计划 Proposal、网架数据 | 可行 / 告警（越限点清单） | +| 申报格式校验 | 申报文件 | 通过 / 错误清单 | + +### 2.4 分析与生成类 + +归因分析（预测/响应/交易/控制偏差分解）、异常检测（遥测流）、报告生成（复盘/专题，LLM 参与文字，数字全部引用工具输出）。 + +## 3. 数据底座（五类存储，各司其职） + +| 存储 | 内容 | 主要写入方 | 主要消费方 | 选型示意 | +|---|---|---|---|---| +| 时序库 | 负荷/出力/电价/气象遥测曲线 | 数据接入管道、边缘上送 | 预测 Skill、监测看板 | TimescaleDB / IoTDB | +| 关系库 | 用户档案、合同、资源台账、市场结果、持仓账本 | 业务应用、结算接入 | 全体 | PostgreSQL | +| 向量库 + 知识库 | 交易规则、政策法规、设备约束文档、案例（RAG） | 知识运营流程 | 交易博弈 Agent、规则校核辅助、智能问答 | pgvector / 专用向量库 | +| 特征库 | 预测模型特征（在线/离线一致） | 特征管道 | 预测 Skill 训练与推理 | Feast 或自建 | +| 事件日志 | 全部业务事件、Proposal 状态迁移、审计 | Runtime（事件溯源） | 复盘、审计、监管取证 | Kafka + 对象存储归档 | + +### 3.1 数据流主干 + +```mermaid +flowchart LR + SRC[电网 / 市场 / 气象 / 用户 / 设备] --> ING[接入管道
清洗 · 对齐 · 质量校验 · 主数据] + ING --> TS[(时序库)] & RDB[(关系库)] & FS[(特征库)] + DOCS[规则 / 政策 / 设备文档] --> KB[(知识库/RAG)] + RT[Runtime / 可信执行链] --> EL[(事件日志)] + EL -->|复盘 ETL| RDB + TS & FS --> SKILL[预测 / 优化 Skill] + KB --> AG[智能体 RAG] +``` + +### 3.2 治理要点 + +- **主数据管理**：用户、资源、站点、设备的唯一标识与映射（现有共性能力层的档案/设备/站点中心是承接点）； +- **数据质量门禁**：进入特征库的数据必须通过质量校验（缺失率、跳变、时标对齐），不合格数据打标隔离——预测误差 ≤ 8% 的 KPI 一半靠数据质量； +- **快照与引用**：Proposal 血缘引用的数据是不可变快照（按版本/时间戳），保证任何历史决策可复现； +- **脱敏分级**：用户行为数据按敏感级分级，跨区流动（如上送省级）经脱敏策略。 + +## 4. 知识库运营（容易被低估的持续成本） + +规则库不是一次性建设：交易规则年年修订、政策频繁更新。设计上： + +- 知识条目带**生效期与版本**，RAG 检索默认过滤失效条目； +- 规则校核引擎中的硬规则与知识库中的文本规则**双轨维护**， + 文本规则变更触发硬规则同步评审的工作流（避免「文档更新了、校核引擎还是旧规则」）； +- 每次申报被交易平台驳回的原因，强制回流为知识条目候选（复盘流程的一部分）。 diff --git a/docs/06-integration.md b/docs/06-integration.md new file mode 100644 index 0000000..33234e0 --- /dev/null +++ b/docs/06-integration.md @@ -0,0 +1,63 @@ +# 06 · 外部系统集成边界 + +## 1. 集成总则 + +- 所有外部系统经**防腐层（Anti-Corruption Layer）适配器**接入：外部报文格式在适配器内 + 转换为平台内部业务对象，外部系统的字段语义、编码习惯不渗入核心域模型； +- 每个适配器双向留痕（原始报文 + 转换后对象），满足对账与审计； +- 外部接口的可用性假设**从悲观设计**：超时、重试（幂等）、降级路径全部显式定义。 + +## 2. 三大业务接口 + +### 2.1 交易平台接口 + +| 交互 | 方向 | 内容 | 备注 | +|---|---|---|---| +| 申报提交 | 出 | 日前/日内申报文件（Proposal RELEASED 后由适配器投递） | 截止时间硬约束，见降级策略 | +| 撤单/改单 | 出 | 截止前修正 | | +| 出清结果 | 入 | 中标计划、出清价格 → 写持仓账本、触发计划分解 | | +| 市场信息 | 入 | 披露的供需/价格信息 → 时序库，喂电价预测 | | + +**降级策略**：申报窗口临近截止（可配，如 T-30min）而 Proposal 仍未批准 → 强制告警升级； +接口故障 → 回退人工申报通道（平台导出标准申报文件，人工上传），该路径纳入演练。 + +### 2.2 调度 / 负荷管理系统接口 + +| 交互 | 方向 | 内容 | +|---|---|---| +| 调节指令/需求 | 入 | 调度下达的调节需求 → 转为事件触发（负荷控制 Agent 生成响应计划） | +| 调节能力申报 | 出 | 可调容量申报（来自资源画像核定值） | +| 基线与考核数据 | 入 | 响应基线、考核结果 → 复盘与用户履约评价 | + +### 2.3 计量结算系统接口 + +| 交互 | 方向 | 内容 | +|---|---|---| +| 计量数据 | 入 | 用户/资源电量数据 → 时序库 + 持仓账本「实际值」列 | +| 结算结果 | 入 | 结算单 → 收益复盘、内部收益分摊 | + +计量数据到达是**复盘流程的触发事件**（D+1 周期触发的数据前提）。 + +## 3. 数据类接入 + +气象服务（预报 + 实况）、外部行情等只读数据源：统一经数据接入管道（05 篇 §3.1）， +带来源标记与质量门禁，不设专用适配器逻辑。 + +## 4. 内部既有系统的关系 + +平台不是推倒重建，与既有 3060 平台/业务模块的关系： + +| 既有能力 | 关系 | +|---|---| +| 共性能力层（客户/档案/设备/站点中心） | **复用**，作为主数据源；平台经服务接口读写 | +| 平台底座（用户权限、消息、工作流） | 用户权限体系**对接复用**（审批人身份来自既有权限系统）；Agent Runtime 的工作流引擎为新建（需求不同：持久化 AI 任务编排 vs 传统 OA 流程） | +| 既有交易/虚拟电厂业务模块 | 保留为业务操作界面，逐步嵌入 AI 卡片；申报等关键动作的**通道收敛**到可信执行链（避免绕过安全链的旁路） | +| 客户侧资源聚合（数据网关、本地 CPS） | **复用并升级**为控制平面的边缘层（04 篇），新增包络/断连策略能力 | + +**通道收敛**是集成阶段的关键治理动作：上线后人工申报也应走平台（人工直接创建 Proposal， +跳过 Agent 生成环节但不跳过校核与留痕），否则账本与审计出现盲区。 + +## 5. 接口清单的落实节奏（对应实施计划） + +- 一期（省内能力落地）：气象/市场信息只读接入 + 计量数据接入 + 申报文件导出（人工上传通道）——不依赖外部单位排期即可闭环演示； +- 二期（资源接入与推广）：交易平台程序化申报、调度接口、边缘控制链路——需与外部单位联调，是二期进度的主要风险项，尽早启动接口协议对接。 diff --git a/docs/07-scenario-walkthrough.md b/docs/07-scenario-walkthrough.md new file mode 100644 index 0000000..403c515 --- /dev/null +++ b/docs/07-scenario-walkthrough.md @@ -0,0 +1,93 @@ +# 07 · 端到端参考场景：日前现货申报 + +本篇用一个完整业务日验证 00–06 的全部构件。时间线中的市场时点为**占位假设**， +需按湖北现货实际规则修正（见文末待补充清单）。 + +**场景设定**：D-1 日，平台为 D 日的现货市场生成并提交申报（代理购电 + 虚拟电厂可调资源）， +D 日执行与监测，D+1 复盘。 + +## 时间线 + +### D-1 06:00 · 周期触发：日前态势报告 + +1. Runtime 周期触发器实例化「日前态势」流程模板（不经 LLM 意图解析——周期任务直达模板）； +2. **智能分析 Agent** 调用工具：负荷预测（96 点 + 区间）、光伏预测、电价预测； +3. 异常检测扫描昨日遥测；归因工具解释显著波动（如「明日高温，空调负荷预计 +12%」）； +4. 产出 `SituationReport`（含风险等级）→ 事件总线 → 运营看板 + 下游 Agent。 + +*验证构件：周期触发、P2（预测数字来自工具）、对象化通信。* + +### D-1 07:00 · 资源画像核定 + +1. **资源调度 Agent** 被 `SituationReport` 事件唤醒（流程模板：申报前容量核定）； +2. 调用可调潜力辨识：结合最近执行反馈（画像时效性约束），核定 D 日分时可调容量与置信度； +3. 更新 `ResourceProfile`；发现某储能站 SOC 异常 → 容量核减并标记，产生告警事件。 + +### D-1 08:00 · 申报策略与报价优化 + +1. **交易博弈 Agent** 启动申报流程模板： + - RAG 检索规则库（当前生效版本的申报规则、价格上下限）； + - 读取 `PositionLedger`：月度合约持仓 → 日前申报电量边界（P7 约束级联）； + - 组装优化输入：电价预测区间、核定可调容量、持仓约束、风险偏好参数（配置项，人工维护）； +2. 调用**报价优化 MILP**：输出 96 点申报曲线 + 预期收益分布； +3. LLM 生成申报说明（策略解释，供审批人阅读），**数字原样引用求解器输出**； +4. 组装 `Proposal{type: BID, timescale: DAY_AHEAD}`，血缘含全部工具调用与账本版本。 + +### D-1 08:30 · 可信执行链 + +1. **规则校核**：申报格式 ✓、价格限值 ✓、账本一致性 ✓、血缘完整性 ✓； +2. **仿真验证**：收益情景回测——千组价格情景，极端亏损在容忍带内 ✓； +3. **包络检查**：本日申报曲线落在已批准的申报包络内（价格偏离预测基准 < 容差、电量在持仓偏差带内）→ `AUTO_APPROVED`； + - *对照分支*：若明日有极端天气、优化结果越出包络 → `PENDING_HUMAN`，交易员在审批界面看到申报说明 + 血缘展开 + 仿真结果，批准/修改/驳回； +4. `RELEASED` → 交易平台适配器提交申报；回执写入事件日志。 + +*验证构件：状态机全路径、包络自治、降级路径（若接口故障 → 导出文件人工上传）。* + +### D-1 16:00 · 出清结果处理 + +1. 交易平台适配器收到出清：中标计划 + 出清价格 → 写 `PositionLedger`（日前层）； +2. 事件触发**资源调度 Agent**：中标计划分解 → 聚合/调度优化 → 调度方案 `Proposal`； +3. 走可信执行链（控制类：功率平衡仿真）→ 批准后执行引擎分解到聚合单元， + 连同包络参数下发边缘终端（本地副本原子更新）。 + +### D 日 · 执行与日内修正 + +1. 边缘终端按 96 点计划就地闭环执行，秒级；遥测经边缘预处理上送； +2. 10:42 某工业用户实际负荷偏离计划超阈 → 执行引擎**确定性快速路径**： + 聚合单元包络内再平衡（储能补偿），同时发事件给认知平面； +3. **负荷控制 Agent**（慢路径）生成日内修正计划 `Proposal` → 校核 → 仿真 → 包络内自动批准 → 更新设定值序列下发； +4. 若修正需突破包络（如需调用未承诺用户资源）→ 升级人工，同时**交互服务 Agent** 生成临时邀约 Proposal（默认人工审批的对外动作）。 + +*验证构件：P1 快慢路径分离、边缘自治、跨 Agent 协作全部经对象与事件。* + +### D+1 · 计量到达，偏差复盘 + +1. 计量数据接入 → 触发复盘流程（智能分析 Agent 主导的跨 Agent 模板）； +2. 逐尺度对比账本：计划 vs 实际（申报 vs 出清 vs 执行 vs 计量）； +3. 归因工具分解偏差：预测偏差（高温敏感度低估）/ 响应偏差（用户 X 履约率 82%）/ 控制偏差； +4. 产出 `ReviewFinding` 回写： + - 语义记忆：「高温日空调负荷预测系统性偏低 → 特征工程候选」； + - `ResourceProfile`：用户 X 可靠性评分下调； + - 包络建议：本月包络内执行 26/26 达标 → 建议价格容差放宽（触发包络重审工作流，人工批准生效）； +5. 报告生成 Skill 产出复盘报告，推送运营看板。 + +## 覆盖矩阵 + +| 构件 | 覆盖时点 | +|---|---| +| 三类任务触发 | 周期(06:00/复盘)、事件(出清/偏差)、人工(审批分支、专题追问) | +| 五类智能体 | 分析(06:00)、资源(07:00/16:00)、交易(08:00)、交互(D 日邀约分支)、负荷控制(D 日修正) | +| Proposal 状态机 | AUTO_APPROVED、PENDING_HUMAN、RELEASED→EXECUTING→COMPLETED | +| 持仓账本级联 | 月度→日前(08:00)、日前→日内(D 日)、对账(D+1) | +| 快慢路径分离 | 10:42 偏差处置 | +| 复盘回写三处 | 记忆/画像/包络 | + +## 【待补充：湖北现货市场关键参数 —— 需要业务侧输入】 + +> **TODO(业务)**：本场景的时间线与规则细节按以下清单修正后，才能作为评审/开发的权威版本： +> +> 1. 日前申报窗口的实际开启/截止时间；出清结果发布时间； +> 2. 申报品种与格式：代理购电申报与虚拟电厂（可调资源）申报是否同一通道、是否分开建模； +> 3. 日内市场/滚动调整的实际机制（湖北是否开日内、频次、截止规则）； +> 4. 偏差考核规则：偏差带宽度、考核价格机制（直接决定报价优化的目标函数与风险测算口径）； +> 5. 中长期持仓对日前申报的实际约束形式（分解曲线偏差带的具体规定）。 diff --git a/docs/08-implementation.md b/docs/08-implementation.md new file mode 100644 index 0000000..be35365 --- /dev/null +++ b/docs/08-implementation.md @@ -0,0 +1,95 @@ +# 08 · 实现映射：技术栈、LLM 抽象层与部署形态 + +> 00–07 为框架中立的架构设计；本篇是当前技术选型下的实现映射，选型变更只影响本篇。 + +## 1. 技术栈基线 + +| 层 | 选型 | 理由 | +|---|---|---| +| Agent Runtime / 智能体 / 工作流 | TypeScript + Mastra（或同类 TS 智能体框架） | 类型化工具契约与业务对象（P4 的天然载体）、工作流原语、良好 DX | +| 专业模型 Skill | Python 微服务（预测：PyTorch/statsforecast；优化：Pyomo/PuLP + 商用/开源求解器；仿真：电科院既有引擎封装） | ML/优化生态在 Python；对电科院/武大协作方友好 | +| Skill 接口 | HTTP/JSON + JSON Schema 契约（注册表校验） | 跨语言、可版本化 | +| 事件总线 | Kafka（或一期先用 PostgreSQL 事务性发件箱，二期升级） | 事件溯源主干 | +| 存储 | PostgreSQL（关系 + pgvector）+ TimescaleDB/IoTDB + 对象存储归档 | 见 05 篇 | +| 前端 | 既有业务前端渐进嵌入 AI 卡片 + 新建审批/看板界面 | 见 06 篇 §4 | + +**Mastra 概念映射**（具体 API 以实现时框架版本为准）： + +| 架构构件 | Mastra 原语 | +|---|---| +| 五类智能体 | Agent（各配独立 instructions、工具集、记忆视图） | +| 流程模板（申报流程、复盘流程） | Workflow（步骤化、可挂起恢复——承载 Proposal 状态机的悬挂审批） | +| Skill 调用 | Tool（封装对 Python Skill 服务的类型化调用，自动写血缘） | +| 记忆三层 | Memory + 自建情景/语义存储（Mastra memory 承担工作记忆，情景/语义按 05 篇落库） | +| 意图解析 | 路由 Agent → 选择 Workflow 模板并填参 | + +**需自建、框架不提供的部分**（工作量估算时别漏）： +规则校核引擎、包络模型与检查器、持仓账本服务、审批工作台（多级审批 UI）、 +交易平台/调度/计量适配器、执行引擎与边缘协议、审计血缘组装。 +——这些恰恰是本平台的差异化资产；智能体框架只解决约 1/3 的问题。 + +## 2. LLM 提供商抽象层（P6） + +``` +Agent 代码 → 能力接口（complete / plan / extract / explain, 统一消息与工具调用格式） + → 模型路由器（按任务类型 × 环境选择后端） + ├── 开发/测试：商用 API（Claude 等） + ├── 预生产：本地开源模型（Qwen/DeepSeek，验证本地化部署可行性） + └── 生产：光明电力大模型适配器 +``` + +设计约束： + +1. **面向能力最小公倍数**：不依赖单一厂商特性（如特定结构化输出模式）； + 工具调用格式在抽象层归一，必要时降级为「提示词 + JSON 解析 + 重试」； +2. **光明大模型适配器的未知项**（需在一期尽早与国网侧确认）： + 接口协议（是否 OpenAI 兼容）、上下文长度、工具调用支持形式、 + 电力语义特有能力的调用方式、部署位置与网络分区； + ——在确认前，抽象层按「OpenAI 兼容 + 8K 上下文 + 无原生工具调用」的保守假设设计降级路径； +3. **评测集先行**：为意图解析、规则问答、申报说明生成等每个 LLM 任务建立评测集， + 换后端 = 跑评测集对比，而非人工感觉；这也是向评审证明「模型可替换、平台不锁定」的硬材料。 + +## 3. 部署形态 + +``` +┌─ 省级云（管理信息大区）──────────────────────────┐ +│ 认知平面（Runtime + Agents） LLM 推理（光明/本地） │ +│ Skill 服务群 数据底座 可信执行链 审批工作台 │ +└──────────────┬───────────────────────────────┘ + │ 单向受控接口（批准计划/包络） +┌─ 生产控制相关区 ─────────────────────────────────┐ +│ 执行引擎 受控通道网关 旁路监测/熔断 │ +└──────────────┬───────────────────────────────┘ + │ 加密通道 +┌─ 边缘 ─────────────────────────────────────────┐ +│ 聚合单元边缘节点 → 本地 CPS/数据网关 → 终端设备 │ +└────────────────────────────────────────────────┘ +``` + +- 训练（预测模型迭代）用云端 GPU 集群（租赁规划）；推理分两类： + LLM 推理在省级本地推理引擎，秒级控制不依赖任何推理服务（P1）； +- 分区与等保：认知平面全部位于管理区；跨区仅有可信执行链单向投递与遥测回传两条通道。 + +## 4. 一期落地切片（建议的构建顺序） + +一期（2025.12–2026.5）以 07 篇场景的**可演示闭环**为验收锚点： + +1. **M1**：数据接入管道 + 时序/关系库 + 持仓账本服务（数据先行）； +2. **M2**：Skill 服务群 v1（负荷/光伏/电价预测 + 报价优化 MILP）+ 评测基线； +3. **M3**:Runtime + 智能分析/交易博弈两个 Agent + 规则校核 + 审批工作台 + （此时即可跑通 07 篇 06:00→08:30 的申报链路，申报走文件导出人工上传）； +4. **M4**：资源调度 Agent + 包络模型 + 复盘流程 + AI 卡片嵌入既有页面； +5. 交互服务/负荷控制 Agent 与边缘控制链路放二期（依赖现场资源接入与外部联调）。 + +**排序理由**：M1–M3 不依赖任何外部单位排期，最快形成端到端演示与真实历史回测能力； +回测结果（用历史行情验证报价优化收益）是二期扩大授权（包络放宽）与评审汇报的最强证据。 + +## 5. 风险登记（架构相关） + +| 风险 | 影响 | 缓解 | +|---|---|---| +| 光明大模型接口/能力与假设不符 | 抽象层返工 | 保守假设 + 降级路径先行；一期尽早拿到接口规格 | +| 外部接口联调排期不可控 | 二期进度 | 一期全部走可独立闭环的降级通道；接口协议对接提前启动 | +| 规则校核与知识库双轨漂移 | 合规风险 | 05 篇 §4 的同步评审工作流，上线即启用 | +| 包络初值定不下来 | 自治能力无法演示 | 03 篇 TODO 清单作为业务侧一期交付物管理 | +| 预测精度不达 8% | 连锁影响报价与考核 | M2 评测基线尽早暴露差距；数据质量门禁先行 | diff --git a/proposal-assets/slide-03.png b/proposal-assets/slide-03.png new file mode 100644 index 0000000..95750e4 Binary files /dev/null and b/proposal-assets/slide-03.png differ diff --git a/proposal-assets/slide-04.png b/proposal-assets/slide-04.png new file mode 100644 index 0000000..3cb06d9 Binary files /dev/null and b/proposal-assets/slide-04.png differ diff --git a/proposal-assets/slide-05.png b/proposal-assets/slide-05.png new file mode 100644 index 0000000..c836969 Binary files /dev/null and b/proposal-assets/slide-05.png differ diff --git a/proposal-assets/slide-06.png b/proposal-assets/slide-06.png new file mode 100644 index 0000000..bedee40 Binary files /dev/null and b/proposal-assets/slide-06.png differ diff --git a/proposal-assets/slide-08.png b/proposal-assets/slide-08.png new file mode 100644 index 0000000..e5d99b7 Binary files /dev/null and b/proposal-assets/slide-08.png differ diff --git a/proposal-assets/slide-09.png b/proposal-assets/slide-09.png new file mode 100644 index 0000000..a4fee57 Binary files /dev/null and b/proposal-assets/slide-09.png differ diff --git a/proposal-assets/slide-10.png b/proposal-assets/slide-10.png new file mode 100644 index 0000000..c0b8b40 Binary files /dev/null and b/proposal-assets/slide-10.png differ diff --git a/proposal-assets/slide-11.png b/proposal-assets/slide-11.png new file mode 100644 index 0000000..77b797d Binary files /dev/null and b/proposal-assets/slide-11.png differ diff --git a/proposal-assets/slide-12.png b/proposal-assets/slide-12.png new file mode 100644 index 0000000..94d9ce3 Binary files /dev/null and b/proposal-assets/slide-12.png differ diff --git a/proposal-assets/slide-14.png b/proposal-assets/slide-14.png new file mode 100644 index 0000000..21c0283 Binary files /dev/null and b/proposal-assets/slide-14.png differ diff --git a/proposal-assets/slide-15.png b/proposal-assets/slide-15.png new file mode 100644 index 0000000..a13dab1 Binary files /dev/null and b/proposal-assets/slide-15.png differ diff --git a/proposal-assets/slide-16.png b/proposal-assets/slide-16.png new file mode 100644 index 0000000..8786681 Binary files /dev/null and b/proposal-assets/slide-16.png differ diff --git a/proposal.md b/proposal.md new file mode 100644 index 0000000..2cf8211 --- /dev/null +++ b/proposal.md @@ -0,0 +1,713 @@ +# 基于光明电力大模型的虚拟电厂多时空协同智能运营平台应用及共享场景 + +**申报单位：** 国网湖北综合能源服务有限公司 +**时间：** 2026年7月 + +--- + +## 目录 + +1. [项目概况及业务现状](#一项目概况及业务现状) + - [项目概况](#11-项目概况) + - [政策背景](#12-政策背景) + - [业务现状](#13-业务现状) + - [重点难点](#14-重点难点) +2. [实施路径及基础条件](#二实施路径及基础条件) + - [总体架构](#21-总体架构) + - [技术路径](#22-技术路径) + - [建设内容](#23-建设内容) + - [核心技术](#24-核心技术) + - [基础条件](#25-基础条件) +3. [预期成果及组织架构](#三预期成果及组织架构) + - [目标成果](#31-目标成果) + - [组织架构](#32-组织架构) + - [实施计划](#33-实施计划) + +--- + +## 一、项目概况及业务现状 + +### 1.1 项目概况 + +![项目概况](proposal-assets/slide-03.png) + +| 项目 | 内容 | +|---|---| +| 申报场景 | 虚拟电厂多时空尺度智能协同运营 | +| 牵头单位 | 国网湖北综合能源服务有限公司 | +| 联合单位 | 国网湖北省电力有限公司电力科学研究院、武汉大学数据智能研究院、武汉智网兴电科技开发有限公司 | +| 投资预算 | **2998.71 万元** | +| 建设定位 | 湖北示范、华中推广、全国可复制 | + +#### 牵头申报单位信息 + +- **单位名称：** 国网湖北综合能源服务有限公司 +- **单位性质：** 国有企业 +- **注册资本：** 10 亿元 +- **通讯地址：** 湖北省武汉市武昌区徐东大街 197 号 +- 成立于 2018 年，由国网综合能源服务集团有限公司与国网湖北省电力有限公司共同出资设立 +- 国家电网体系内专注于综合能源服务的国有控股企业、高新技术企业、湖北省专精特新中小企业 +- 围绕综合能源服务全产业链，提供规划设计、系统集成、投资建设、运营维护一体化解决方案 +- 在电力交易、能效提升、分布式光伏、储能应用、能源托管等领域形成系统能力 +- 具备售电牌照及相关资质认证，拥有发明专利 8 项、软件著作权 18 项，业务覆盖湖北全省 + +#### 建设方案简述 + +| 维度 | 内容 | +|---|---| +| **背景** | 面向“双碳”战略与新型电力系统建设需求 | +| **目标** | 构建“人工智能 + 虚拟电厂多时空尺度智能协同运营”平台 | +| **路径** | 依托光明电力大模型，建设智能分析、智能资源调度、智能交易博弈、智能负荷控制、智能交互服务五类 AI 智能体 | +| **能力** | 实现年度、月度、日前、日内、实时跨时间尺度协同，以及用户终端、聚合单元、区域电网、省级平台跨空间尺度协同 | +| **成效** | 形成具备自主感知、自主决策、自主调控、自主迭代能力的虚拟电厂智能协同运营平台，打造可复制、可推广的省级样板 | + +#### 联合申报单位 + +- 国网湖北省电力有限公司电力科学研究院 +- 武汉大学数据智能研究院 +- 武汉智网兴电科技开发有限公司 + +> **讲解要点：** 项目名称为“基于光明电力大模型的虚拟电厂多时空协同智能运营平台应用及共享场景”，由国网湖北综合能源服务有限公司牵头，联合国网湖北电科院、武汉大学数据智能研究院和武汉智网兴电科技开发有限公司共同申报，投资预算约 2998.71 万元。项目面向“双碳”战略和新型电力系统建设需求，依托光明电力大模型，构建覆盖年度、月度、日前、日内、实时等多时间尺度，以及用户终端、聚合单元、区域电网、省级平台等多空间层级的虚拟电厂智能运营平台。通过建设智能分析、资源调度、交易博弈、负荷控制和交互服务等智能体能力，形成具备自主感知、自主决策、自主调控和自主迭代能力的虚拟电厂协同运营平台，打造湖北示范、华中推广、全国可复制的共享应用场景。 + +--- + +### 1.2 政策背景 + +![政策背景](proposal-assets/slide-04.png) + +**国家政策牵引、湖北先行实践，为虚拟电厂多时空尺度智能协同运营提供政策与场景基础。** + +#### 国家政策演进 + +| 年份 | 政策 | 要点 | +|---|---|---| +| 2022 | 《关于加快建设全国统一电力市场体系的指导意见》 | 提出加快构建适应新型电力系统的全国统一电力市场体系 | +| 2023 | 《电力需求侧管理办法（2023 年版）》 | 支持可调节负荷、分布式电源、新型储能等以聚合方式参与需求响应 | +| 2023 | 《电力现货市场基本规则（试行）》 | 明确新型经营主体可参与日前、日内、实时电能量交易 | +| 2024 | 《电力市场运行基本规则》 | 进一步明确虚拟电厂等新型主体参与电能量市场与辅助服务市场 | +| 2025 | 国家能源局推动“人工智能 + 能源”高价值场景建设 | 为虚拟电厂智能协同运营提供政策机遇 | + +#### 湖北政策进展与实践 + +**湖北场景优势** + +- 华中负荷中心，保供与能源安全要求高 +- 水、火、风、光、储等资源类型丰富，能源多样性好 +- 本地电源支撑与外来电协同并存，具备较强能源保障基础 +- 工业、商业、公共机构等负荷场景丰富，柔性调节潜力大 +- 具备开展源网荷储协同优化的优质应用场景 + +**湖北虚拟电厂业务发展路径** + +| 阶段 | 时间 | 重点 | 内容 | +|---|---|---|---| +| 阶段一 | 2022.09—2024 | 需求响应、调峰辅助服务 | 启动虚拟电厂探索，围绕负荷聚合与需求响应开展实践 | +| 阶段二 | 2025.02—至今 | 调频辅助服务 | 推动虚拟电厂参与调频，提升灵活调节与快速响应能力 | +| 阶段三 | 2025.02—至今 | 虚拟电厂参与现货 | 开展现货侧虚拟电厂运营实践，探索市场化收益机制 | +| 阶段四 | 未来 | 电碳双 VPP、多市场协同 | 向现货、辅助服务、需求响应、绿电绿证等多市场协同演进 | + +**湖北先行实践** + +- 较早开展虚拟电厂与需求响应试点探索 +- 持续推进虚拟电厂参与调频辅助服务实践 +- 积极探索虚拟电厂参与现货交易运营模式 +- 形成从资源聚合、调节响应到市场化运营的先行路径 +- 湖北在虚拟电厂参与调频、现货等方面走在前列 + +#### 对本项目的启示 + +| 市场协同升级 | 资源范围扩展 | 能力要求提升 | 建设方向明确 | +|---|---|---|---| +| 虚拟电厂正由辅助服务工具向多市场协同运营主体演进 | 由负荷聚合逐步扩展至分布式电源、储能等全类型资源 | 需要具备跨时间尺度、跨空间层级、跨市场协同的智能运营能力 | 亟需建设具备自主感知、自主决策、自主协同、自主执行能力的 AI 智能运营平台 | + +> **讲解要点：** 从国家层面看，近几年国家持续推动全国统一电力市场建设，明确可调节负荷、分布式电源、新型储能等资源参与电力市场和需求响应，并逐步拓展虚拟电厂参与现货、辅助服务等市场空间。同时，“人工智能 + 能源”高价值场景建设，也为虚拟电厂智能化运营提供了政策机遇。从湖北自身来看，湖北处于华中负荷中心，保供和能源安全要求较高，同时水、火、风、光、储等资源类型较为丰富，本地电源支撑和外来电协同并存，工业、商业、公共机构等负荷场景多样，具备开展源网荷储协同优化的良好基础。更重要的是，湖北在虚拟电厂政策实践上走在前列，已较早开展需求响应试点，并持续推进虚拟电厂参与调频辅助服务和现货交易探索，逐步形成从资源聚合、调节响应到市场化运营的实践路径。因此，本项目不是单纯做技术试点，而是在国家政策牵引、湖北能源场景优势和虚拟电厂先行实践基础上，进一步建设具备多时间尺度、多空间层级、多市场协同能力的 AI 智能运营平台。 + +--- + +### 1.3 业务现状 + +![业务现状](proposal-assets/slide-05.png) + +| 建设起点 | 业务覆盖 | 业务成果基础 | +|---|---|---| +| 2023 年起，在 3060 平台基础上开展市场化交易与虚拟电厂业务功能建设 | 已建设覆盖电力交易、市场化交易业务全业务流程的功能模块 | 虚拟电厂侧接入集中式空调、铁塔基站、分布式光伏、大工业用户等资源，完成 **31MW** 可调资源接入；交易业务侧稳定签约 **657** 户，年签约量 **110 亿 kWh**，现货交易首批签约代理年用电量 **30 亿 kWh** | + +#### A. 建设内容 + +**顶层运营入口 / 门户：** 数字化运营中心、互联网门户、智慧总 APP + +**业务应用层（核心业务）** + +| 电力交易 | 虚拟电厂 | 负荷聚合 | +|---|---|---| +| 交易业务看板、售电客户画像、电量签约信息、交易数据准备、分时电量预测、电量计划管理、交易持仓分析、交易清分管理 | 用户序列节点、调节能力验证、电量曲线分解、分段申报、中标计划分解、日前调节计划、资源调度管理、内部收益分摊 | 聚合全景、响应资源管理、需求响应、调峰服务 | + +**支撑运营类：** 项目建设（工程项目 / 资源接入 / 方案设计 / 合规管理）、运维管理（设备监控 / 故障处置 / 运维工单 / 运检管理）、光伏运营（发电监控 / 预测分析 / 收益管理 / 运维管理）、储能运营（充放电管理 / 能量优化 / 状态评估）、能效运营（能耗监测 / 能效分析 / 节能技改 / 指令执行） + +**共性能力层：** 客户中心、合作伙伴中心、解决方案中心、档案中心、设备中心、站点中心 + +**平台底座层：** 用户与权限管理、消息管理、任务管理、工作流、算法管理、数据管理 + +**客户侧资源聚合** + +- 全景概览：资源总览、运行态势、资产画像、容量监测、健康画像 +- 碳管理：碳排放监测、碳核算、碳分析 +- 能碳监控：能流监测、碳流监测、电碳预测、能碳分析、告警处理 +- 调控响应：调度控制、资源调度、负荷调节、策略管理、指令执行 +- 数据接入：资源注册、协议接入、数据质量、数据解析、指令下发 + +**终端设备 / 资源：** 光伏、风机、传感器、表计、空调、缝绣、储能、冷热泵、给排水、照明、交通流、充电桩 + +数据链路：客户侧资源聚合 → 数据网关 → 本地 CPS → 终端设备 / 资源 + +#### B. 当前业务成果 + +| 指标 | 数值 | +|---|---| +| 可调资源接入规模 | **31 MW** | +| 稳定签约用户（截至 2026 年 6 月） | **657 户** | +| 年签约量 | **110 亿 kWh** | +| 现货交易首批签约代理年用电量 | **30 亿 kWh** | +| 能力状态 | 虚拟电厂与市场交易全流程贯通；资源接入、交易运营、调节响应驱动齐备 | + +#### C. 当前差距 + +现有可调资源 **31 MW** → 试点目标 **≥ 80 MW** + +需通过 AI 多智能体提升：资源挖掘能力、用户响应组织能力、市场交易能力。需进一步由“平台支撑业务”向“AI 智能体驱动业务”升级。 + +已形成“平台底座 + 市场交易 + 虚拟电厂 + 资源聚合 + 运营支撑”一体化业务体系，但在资源规模扩展与智能化运营能力上仍需进一步升级。 + +> **讲解要点：** 湖北综合能源服务有限公司 2023 年起，在 3060 平台建设的基础上开展电力市场化交易与虚拟电厂业务功能建设；建设覆盖虚拟电厂业务、市场化交易业务全业务流程功能模块。虚拟电厂业务中，接入集中式空调、铁塔基站、分布式光伏、大工业用户等设备，完成 31 MW 可调资源接入。参与现货交易后第一批签约代理，年用电量达 30 亿 kWh。市场化交易业务中，用户逐年增长，截止 2026 年 6 月，稳定签约 657 户，年签约量达 110 亿 kWh。但对照试点目标，当前可调资源 31 MW 距离 80 MW 以上目标仍有差距，后续需要通过 AI 多智能体提升资源挖掘、用户响应组织和市场交易能力，推动平台从“支撑业务”向“AI 智能体驱动业务”升级。 + +--- + +### 1.4 重点难点 + +![重点难点](proposal-assets/slide-06.png) + +面向多资源、多市场、多主体、多目标、多时间尺度的虚拟电厂运营场景，业务重心正由“单一问题优化”转向“复杂运营协同”。 + +#### 以往 vs 当前 + +**以往：单一问题优化** + +一个问题 → 单个模型 → 一个结果 + +**当前：复杂运营协同** + +| 多资源 | 多市场 | 多主体 | 多目标 | 多时间尺度 | +|---|---|---|---|---| +| 光伏、储能、可调负荷、充电桩 | 现货、需求响应、辅助服务、绿证 | 运营商、电网、市场、用户 | 收益、低碳、安全、服务、用户体验 | 秒级、分钟级、小时级、日 / 年级 | + +#### 当前虚拟电厂业务应用五大痛点 + +1. **大电网与微电网协同不足** + - 协议接口不统一 + - 数据标准不一 + - 协同机制缺失 +2. **跨区域市场联动不深** + - 缺少跨省市场联动机制 + - 收益评估不统一 + - 协同交易壁垒高 +3. **存量资源潜力挖掘不足** + - 资源利用率不高 + - 潜力分类型低 + - 缺乏精细化评估 +4. **电碳一体化闭环不完整** + - 碳核算口径不统一 + - 电碳协同机制不完善 + - 价值联动不足 +5. **AI 全链条协同赋能不足** + - 点状应用割裂 + - 多源数据未融合 + - 决策执行闭环未打通 + +#### 不是简单升级算法，而是升级运营方式 + +| 协同感知 | 协同研判 | 协同调度 | 协同运营 | 协同优化 | +|---|---|---|---|---| +| 统一感知负荷、光伏、储能、设备与用户状态 | 统筹多源识别、风险分析与策略判断 | 联动资源组织、市场响应与控制执行 | 贯通交易、调控、复盘等业务协作 | 沉淀经验、持续迭代、优化运营效果 | + +**升级方向：** 趋势分析、资源调度、市场运营、负荷控制、复盘优化 +路径：沉淀经验 → 优化策略 → 提升价值 + +**五个升级抓手：** 协同调度增强｜市场运营升级｜资源潜力释放｜电碳价值拓展｜全链智能闭环 + +> **讲解要点：** 过去虚拟电厂更多是围绕单一问题开展优化，通常是一个问题、一个模型、一个结果。但随着业务复杂度提升，当前虚拟电厂已经进入复杂运营协同阶段，需要同时统筹多资源、多市场、多主体、多目标和多时间尺度。在实际运营中，主要存在五大痛点：一是大电网与微电网协同不足，资源难以统一接入和调度；二是跨区域市场联动不深，省内与跨省交易衔接不足；三是存量资源潜力挖掘不足，优质可调资源尚未充分盘活；四是电碳一体化闭环不完整，电力收益与碳价值联动不强；五是 AI 全链条协同赋能不足，智能化应用仍偏单点、碎片化。因此，本项目核心不是简单升级算法，而是推动虚拟电厂运营方式升级，形成协同感知、协同研判、协同调度、协同运营和持续优化能力。 + +--- + +## 二、实施路径及基础条件 + +### 2.1 总体架构 + +![总体架构](proposal-assets/slide-08.png) + +光明电力大模型作为底座，统一支撑智能体运行、知识检索、工具调用、记忆更新与安全控制。 + +#### 业务系统 + +运行监控 → 策略生成 → 申报生成 → 市场申报 → 用户邀约 → 收益复盘 + +**外部系统接口（标准化对接）：** 交易平台接口、调度 / 负荷管理系统接口、计量结算系统接口 + +#### 多源数据接入 + +电网、市场、气象、用户、设备 + +#### 虚拟电厂业务智能体应用层 + +五类智能体按运营链路协同决策： + +| 智能体 | 职责 | +|---|---| +| 智能分析 Agent | 态势感知、预测研判、风险预警 | +| 资源调度 Agent | 资源画像、潜力评估、动态编排 | +| 交易博弈 Agent | 规则适配、报价优化、收益测算 | +| 交易服务 Agent | 用户邀约识别、交易协同协商 | +| 负荷控制 Agent | 指令分解、执行建议、编排校核（仅生成建议） | + +单个智能体构成：角色 / 目标、上下文、规划、工具、记忆、安全、输出 + +#### 智能体运行框架（Agent Runtime） + +Runtime 统一编排 / 状态同步：流程编排 → 上下文构建 → 记忆读写 → 工具调用 → 安全控制 + +**安全控制与合规保障（全流程强制执行）：** 规则校核、仿真验证、人工审批、异常回退、日志留痕 + +**能力服务调用** + +| 编排策略库 | 知识库 / RAG | 运行记忆 | 专业模型工具 | 安全控制闭环 | +|---|---|---|---|---| +| 沉淀典型运行策略、智能体协作模板和分级处理范式 | 汇合行业规则、政策法规、设备参数、案例实例和典型事件 | 记录运行状态、用户响应、交易结果、控制结果和复盘效果 | 调用负荷 / 出力 / 价格预测、优化求解、仿真验证、评价与校核模型 | 执行闭环校核、仿真校核、权限管控、入侵 / 误操作监测与告警联动 | + +#### 控制安全链（强制流程） + +AI 不直接下发控制指令，全过程受控： + +1. **AI 建议生成** — 智能体输出策略与操作建议 +2. **规则校核** — 合规性、约束校验与权限校验 +3. **仿真验证** — 潮流 / 出力 / 功率平衡等仿真验证 +4. **人工确认 / 审批** — 人工审核、确认或多级审批 +5. **指令执行** — 通过受控通道下发执行 +6. **反馈复盘** — 执行结果回传、复盘分析迭代 + +异常触发处理：回退至 Runtime 安全控制；执行反馈回传复盘。 + +**终端资源（通过受控通道执行）：** 光伏、储能、充电桩、空调、工业负荷、微网 / 园区、可调负荷（可中断 / 可转移）、其他资源 + +#### 光明电力大模型基础支撑层 + +电力语义理解、规则推理、任务规划、工具选择、策略生成、结果解释 + +**安全合规底座：** 合规可审计、最小权限原则、数据安全与隐私保护、全链路加密传输、操作留痕、分区隔离、等保合规 + +> **讲解要点：** 平台以光明电力大模型作为基础支撑层，向上提供语义理解、规则推理、任务规划、工具选择、策略生成和结果解释等能力；中间通过智能体运行框架 Runtime，实现流程编排、上下文构建、记忆读写、工具调用和安全控制；上层面向虚拟电厂业务，构建智能分析、资源调度、交易博弈、交易服务和负荷控制五类智能体，支撑运行监测、策略生成、市场申报、用户邀约、收益复盘等业务流程。在数据和接口方面，平台一侧接入电网、市场、气象、用户、设备等多源数据，另一侧面向光伏、储能、充电桩、空调、工业负荷、微网园区等终端资源。同时，在业务系统对外交互上，设置交易平台接口、调度 / 负荷管理系统接口和计量结算系统接口，支撑交易申报、调度协同和结算复盘。需要重点强调的是，AI 不直接下发控制指令。平台设置了完整的控制安全链：先由 AI 生成操作建议，再经过规则校核、仿真验证、人工确认或审批，最后才通过受控通道执行指令，并将执行结果反馈复盘。全过程配套异常回退、日志留痕和权限管控，确保虚拟电厂智能运营既高效协同，又安全可控。 + +--- + +### 2.2 技术路径 + +![技术路径](proposal-assets/slide-09.png) + +**虚拟电厂 AI 多智能体实施路径图** +P2 虚拟电厂业务流程与人工智能融合路径 +业务人员需求触发与智能体主动触发并行，推动虚拟电厂从人工驱动向智能协同驱动转变。 + +#### ① 任务触发源 + +| 业务人员触发 | 运行事件触发 | 业务周期触发 | +|---|---|---| +| 自然语言提问 / 专题分析 / 任务下达 / 策略制定 | 负荷偏差超阈值 / 光伏出力异常 / 用户响应不足 / 设备离线 | 日前预测 / 申报前策略生成 / 响应前用户筛选 / 事后复盘 | + +#### ② 虚拟电厂核心业务流程 + +运行监测 → 资源组织 → 交易决策 → 用户响应 → 控制执行 → 偏差复盘 + +#### ③ 人工智能融合机制 + +任务触发 → 意图识别 → Agent 接管 → Skill 执行 → 结果校核 → 业务交付 → 反馈记忆 + +大模型理解任务意图，Runtime 拆解任务并调度 Agent 与 Skill 协同执行。 + +#### ④ 各业务环节的 AI 主动工作流 + +| 环节 | AI 工作内容 | +|---|---| +| 运行监测 | 智能感知运行状态，自动识别负荷波动、光伏偏差、电价异常与运行风险 | +| 资源组织 | 动态更新资源画像，自动测算可调容量、识别调度边界并维护资源池 | +| 交易决策 | 自动检索规则、研判价格、测算收益并形成报价与申报建议 | +| 用户响应 | 自动筛选目标用户，识别响应意愿，生成邀约与激励方案 | +| 控制执行 | 自动分解控制目标，监测执行偏差，触发纠偏与异常处置 | +| 偏差复盘 | 自动沉淀预测偏差、响应偏差、交易偏差与控制偏差，驱动持续优化 | + +#### ⑤ 融合方式总结 + +业务需求与事件共同触发 → 智能体按职责主动工作 → 专业 Skill 承接具体业务任务 → 形成可校核、可执行、可记忆的业务闭环 + +> **讲解要点：** 业务流程拆解与智能体定位，从业务流程出发，识别智能体介入点，明确每个智能体在流程中的角色、触发条件和协同关系。整体思路是以业务任务为牵引，以核心流程为主线，以人工智能融合机制为支撑，推动虚拟电厂从“人工驱动”向“智能协同驱动”转变。首先，在任务触发层面，系统支持三类触发方式：一是业务人员通过自然语言提问、专题分析、任务下达等方式主动触发；二是系统根据负荷偏差、光伏出力异常、用户响应不足、设备离线等运行事件自动触发；三是按照日前预测、申报前策略生成、响应前用户筛选、事后复盘等业务周期定时触发。第二，在业务流程层面，围绕虚拟电厂运行管理的完整链条，贯通“运行监测、资源组织、交易决策、用户响应、控制执行、偏差复盘”六个核心环节，确保每一项智能任务都能嵌入实际业务流程。第三，在人工智能融合机制层面，系统通过大模型理解任务意图，由 Runtime 拆解任务，并调度对应 Agent 和专业 Skill 协同执行，经过结果校核后形成业务交付成果，同时将执行结果、人工修正和业务反馈沉淀为记忆，支撑后续持续优化。第四，在各业务环节中，AI 不只是被动问答，而是主动参与业务工作。例如在运行监测中识别异常和风险，在资源组织中更新资源画像，在交易决策中生成报价建议，在用户响应中筛选目标用户，在控制执行中分解控制目标，在偏差复盘中归因分析并提出优化建议。总体来看，这一路径实现了“业务需求与事件共同触发、智能体按职责主动工作、专业 Skill 承接具体任务、结果可校核可执行可记忆”的闭环体系，为虚拟电厂智能化运营提供完整支撑。 + +--- + +### 2.3 建设内容 + +![建设内容](proposal-assets/slide-10.png) + +#### 01 业务体系设计 + +- 核心业务场景梳理：运行监测、资源组织、交易申报、需求响应、控制执行、复盘分析 +- 端到端业务流程设计：输入、处理、输出、确认节点 +- 任务触发机制设计：人工触发、事件触发、周期触发 +- 人机协同边界设计：AI 建议、人工审核、关键动作确认 +- 业务指标口径设计：响应率、执行率、偏差率、收益率 + +#### 02 数据与知识底座建设 + +- 多源数据接入：负荷、光伏、储能、气象、电价、调度、用户档案 +- 数据治理与标准化：清洗、对齐、质量校验、主数据管理 +- 资源 / 用户画像建模：容量特性、运行约束、响应能力 +- 业务知识库与规则库：交易规则、调控规则、设备约束 +- 智能体工具库建设：查询、预测、测算、优化、报告生成 + +#### 03 专业算法与 Skill 建设 + +- 负荷预测与光伏出力预测模型 +- 可调资源评估与响应能力测算模型 +- 交易报价、收益测算与最优优化模型 +- 控制目标分解与执行偏差分析 Skill +- 复盘归因、效果评估与报告生成 Skill + +#### 04 五类智能体开发建设 + +- **智能分析 Agent：** 状态感知、异常识别、趋势研判、风险预警 +- **智能资源调度 Agent：** 资源建模、资源画像、能力聚合、调度方案生成 +- **智能交易 Agent：** 价格研判、报价生成、交易辅助、收益风险测算 +- **智能交互 Agent：** 目标筛选、邀约策略、激励推荐、用户履约跟踪 +- **智能负荷管理 Agent：** 指令编排、执行跟踪、偏差纠正、异常处置 + +#### 05 智能体协同调度平台建设 + +- 任务识别与意图解析 +- 任务拆解、编排与 Agent 路由 +- Skill 调用、工具编排与状态跟踪 +- 结果校核、多智能体协同人工接管 +- 执行日志、反馈记忆与过程留痕 + +#### 06 业务应用集成与验证 + +- 业务页面功能开发：监测、组织、交易、响应、执行、复盘 +- AI 嵌入卡片与业务页面双向联动 +- 智能问答、分析询问、报告生成等交互能力 +- 联调测试、历史回测与仿真验证 +- 试运行评估与持续迭代优化 + +> **讲解要点：** 以业务流程 AI 融合为主线，以三类任务触发为入口，以 Agent Runtime 为调度中枢，以 Skill 和工具库为执行能力，以数据、知识、规则、记忆和安全为底座，以五大 Agent 为业务执行单元，最终形成可触发、可编排、可校核、可执行、可记忆的虚拟电厂 AI 协同运营体系。第一，开展业务体系设计，明确核心业务场景、端到端流程、任务触发方式，以及 AI 建议、人工审核、关键确认等人机协同边界。第二，建设数据与知识底座，接入负荷、光伏、储能、气象、电价、调度、用户档案等数据，形成资源画像、用户画像、设备画像，并沉淀交易规则、调控规则和设备约束。第三，建设专业算法与 Skill 能力，包括负荷预测、光伏预测、可调容量测算、响应能力评估、交易报价优化、偏差分析和报告生成等能力。第四，开发多类业务智能体，包括运行监测、资源组织、交易决策、用户响应、控制执行和偏差复盘 Agent，分别支撑不同业务环节的智能处理。第五，建设智能体协同调度平台，实现任务识别、任务拆解、Agent 调度、Skill 调用、结果校核、异常回退和过程留痕。第六，开展业务应用集成与验证，将智能体能力嵌入业务页面，实现 AI 结论卡片、智能问答、报告生成和页面联动，并通过联调测试、仿真验证和试运行持续优化。 + +--- + +### 2.4 核心技术 + +![核心技术](proposal-assets/slide-11.png) + +围绕五类智能体的业务特性，分别构建差异化能力链条与业务交付能力。同样是智能体建设，五类 Agent 因业务对象、决策逻辑和交付成果不同，需要差异化构建路径。 + +#### 01 智能分析 Agent + +- **构建重点：** 从数据采集清洗到趋势研判与风险识别 +- **业务构建链条：** 多源数据融合 → 时序预测 → 异常识别 → 波动归因 → 风险预警 → 策略建议 +- **要点：** 融合金融、宏观、事件、气象、设备状况等数据；识别天气、生产、节假日、设备、市场等关键因素；提供趋势研判到策略推荐的一体闭环 +- **最终业务交付：** 趋势研判 / 风险预警 / 分析结论 / 量化建议 + +#### 02 资源调度 Agent + +- **构建重点：** 从资源动态整合到调度优化与执行 +- **业务构建链条：** 资源接入建档 → 资源画像 → 资源潜力评估 → 资源编组编排 → 调度决策识别 → 调度方案生成 +- **要点：** 覆盖电源、电网通道、储能群组、生产线与设备；动态计算不同约束下最优 / 可行解；联动交易与负荷执行落地 +- **最终业务交付：** 资源池清单 / 可调度量 / 调度方案 / 执行指令 + +#### 03 智能交易决策 Agent + +- **构建重点：** 从规则策略融合到策略决策支撑、风险平衡 +- **业务构建链条：** 市场数据解析 → 价格趋势研判 → 策略能力匹配 → 策略模拟生成 → 收益风险测算 → 申报校核 +- **要点：** 识别现货、辅助服务等各类交易品种；融合多维约束因素，收益最优、综合风险最优；形成收益与风险平衡的市场参与策略 +- **最终业务交付：** 报价方案 / 申报计划 / 收益测算 / 风险提示 + +#### 04 交互服务 Agent + +- **构建重点：** 从用户洞察运营到用户响应组织 +- **业务构建链条：** 用户画像 → 响应意愿识别 → 用户分群 → 邀约策略生成 → 激励方案匹配 → 履约跟踪 +- **要点：** 识别电价敏感度、负荷特性、环保评级等用户画像；精准触达用户，提升邀约率、签约率；促进签约转化与用户质量闭环评价 +- **最终业务交付：** 邀约清单 / 激励方案 / 用户承诺 / 履约状态 + +#### 05 负荷控制 Agent + +- **构建重点：** 从控制指令生成到负荷控制执行闭环 +- **业务构建链条：** 控制目标设定 → 控制计划生成 → 指令分解下发 → 设备联动控制 → 效果监测 → 策略复盘改进 +- **要点：** 综合资源能力、用户承诺、设备状态与工艺约束；满足不同策略、时段和控制协议；实现负荷安全经济的可控管理能力 +- **最终业务交付：** 控制指令 / 执行结果 / 偏差控制 / 闭环记录 + +#### 可信执行闭环运行机制（人机协同 · 可信执行 · 持续优化） + +AI 生成建议 → 专业模型计算 → 规则校核 → 人工确认 → 执行验证 → 反馈优化 + +以可信执行为核心，AI 辅助生成建议，专业模型计算支撑，规则校核与人工确认把关，执行验证后持续反馈优化。 + +**统一建设方法：** 角色定义 → 能力拆解 → 数据建模 → 规则校核 → 执行验证 → 反馈优化 + +> **讲解要点：** 围绕虚拟电厂运营链条，构建五类差异化智能体能力。第一类是智能分析 Agent，重点支撑多源数据融合、时序预测、异常识别、波动归因和风险预警；第二类是资源调度 Agent，面向电源、储能、负荷等资源，开展资源画像、潜力评估、调度编排和方案生成；第三类是智能交易决策 Agent，通过市场数据解析、价格趋势研判、策略能力匹配、收益风险测算和申报校核，辅助形成交易决策建议；第四类是交互服务 Agent，面向用户画像、响应意愿识别、邀约策略生成和激励方案匹配，提升用户响应组织效率；第五类是负荷控制 Agent，重点支撑控制目标设定、控制计划生成、指令分解、执行监测和策略复盘改进。需要强调的是，平台不是由 AI 直接替代人工决策或自动执行控制，而是建立可信执行闭环机制。整体流程按照 AI 生成建议、专业模型计算、规则校核、人工确认、执行验证、反馈优化推进，确保每一步都有业务规则约束、专业模型支撑和人工把关。 + +--- + +### 2.5 基础条件 + +![基础条件](proposal-assets/slide-12.png) + +#### 一、已有业务与数据基础 + +**01 业务基础 — 全业务链路已贯通** + +综合能源服务、分布式光伏运营、用户侧储能运营、负荷聚合、电力市场化交易、电力交易辅助、交易中心数据接入、日滚动交易策略、交易复盘辅助、自动挂撤单 + +**02 技术基础 — 核心算法能力已形成** + +客户精准画像、短期负荷预测、新能源出力预测、现货电价预测、资源聚合优化、交易策略生成 + +**03 数据基础 — 七类数据资源已汇聚** + +设备运行数据、用户行为数据、气象环境数据、电网拓扑数据、市场行情数据、交易结算数据、碳排放数据 + +#### 二、已有存量资源与拟新增部署计划 + +**04 算力基础 — 存量资源 + 租赁规划 + 新增部署** + +| 已有存量资源 | 拟新增部署计划 | +|---|---| +| 基础算力资源、GPU 资源、数据库资源、部分边缘终端 | 云端训练集群（模型训练、参数调优）；本地推理引擎（实时决策、策略生成）；边缘控制终端（秒级响应、就地控制） | + +**05 安全基础 — 五重安全保障已建立** + +权限分级管控｜日志全链留痕｜数据脱敏加密｜仿真校核验证｜异常自动回退 + +#### 三、仍需落实条件 + +1. **云端 GPU 资源落实** — 租赁规划落地；训练推理资源保障 +2. **边缘控制终端部署** — 终端新增部署；现场控制链路配置 +3. **现场资源接入** — 光伏、储能、充电桩、空调、工业负荷等资源接入 + +分步实施、逐项完善。 + +**总结：** 已有基础可承接｜项目建设补能力｜关键条件需落实 + +> **讲解要点：** 前期已经具备较好的业务、技术和数据基础。在业务方面，综合能源服务、分布式光伏运营、用户侧储能运营、负荷聚合、电力市场化交易、交易中心数据接入等全业务链路已基本贯通；在技术方面，已形成客户精准画像、短期负荷预测、新能源出力预测、现货电价预测、资源聚合优化和交易策略生成等核心算法能力；在数据方面，已汇聚设备运行、用户行为、气象环境、电网拓扑、市场行情、交易结算和碳排放等七类数据资源。同时，项目将结合现有算力、GPU、数据库和部分边缘终端资源，制定租赁扩容和新增部署计划，重点补强云端 GPU 资源、边缘控制终端和现场资源接入条件。总体上，现有基础可承接，项目建设补能力，关键条件分步落实。 + +--- + +## 三、预期成果及组织架构 + +### 3.1 目标成果 + +![目标成果](proposal-assets/slide-14.png) + +形成可落地、可推广、可复制的虚拟电厂多智能体协同应用体系，全面提升虚拟电厂运营智能化水平与市场竞争力。 + +#### 业务应用成果 + +提升运营管理能力，实现精益化、智能化、可视化管理。 + +| 运行监测 | 资源组织 | 交易决策 | 用户响应 | 控制执行 | 偏差复盘 | +|---|---|---|---|---|---| +| 运行状态在线感知；异常事件自动预警；风险预警与处置建议 | 可调资源自动发现；可调潜力精准识别；资源聚合与优化组合 | 市场行情动态研判；交易策略智能推荐；收益预测与风险评估 | 目标用户精准触达；响应激励与效果预测；响应监测与执行反制 | 策略指令自动编排；执行跟踪与状态反馈；异常处理与闭环控制 | 偏差智能分析；关键事件溯源定位；优化建议与策略迭代 | + +#### 管理运营成果 + +| 运营监控中心 | 智能决策中心 | 任务调度中心 | 绩效评估中心 | 知识沉淀中心 | +|---|---|---|---|---| +| 全景监控、一屏统览、态势可视化 | 策略推荐、收益试算、智能预案 | 任务统一调度、进度跟踪、协同闭环 | 运营绩效评估、服务分析、价值洞察 | 经验沉淀、知识图谱、持续优化 | + +#### 平台与系统成果 + +形成一体化平台产品，支撑业务全流程智能运行。 + +| 多智能体协同调度平台 | 业务应用系统 | AI 交互与分析引擎 | 运维与安全管理系统 | 开放接口与集成能力 | +|---|---|---|---|---| +| 任务 / 权限 / 激励闭环，Agent 调度、协同执行 | 六大业务模块集成、业务流程与 AI 能力深度融合 | 自然语言交互、智能问答、图表分析、报告生成 | 用户权限、运行监控、日志审计、安全防护 | 标准 API、数据接口、系统集成与能力开放 | + +#### 数据与知识成果 + +沉淀高质量数据资产与知识资产，赋能智能决策。 + +| 资源数据资产 | 用户数据资产 | 运行数据资产 | 知识库与规则库 | 指标体系与标准 | +|---|---|---|---|---| +| 多源 / 权限信息、通道、双边协商、可调负荷等资源全量数据 | 用户画像、响应行为、历史行为、负荷、激励评价等数据 | 电量、功率、调度、气象、电价、设备、扰动等数据 | 政策、规则、调度策略、设备约束、业务知识、经验库 | 统一指标口径、数据标准、分析模型与指标体系 | + +#### 模型算法与智能体成果 + +构建专业算法与多智能体核心能力体系，形成核心技术资产。 + +**专业算法与五大能力：** 负荷预测、光伏预测、可调潜力辨识、交易策略优化、收益测算、故障检测、执行调度分析、复盘归因分析、组合优化分析、报告生成 + +**多智能体能力：** 运行监测 Agent、资源组织 Agent、交易决策 Agent、用户响应 Agent、控制执行 Agent、偏差复盘 Agent + +#### 核心指标 + +| 指标 | 目标 | +|---|---| +| 试点聚合省内可调负荷 | **≥ 80 MW** | +| 预测平均误差 | **≤ 8%** | +| 用户可调潜力辨识准确率 | **≥ 90%** | +| 跨区域资源匹配准确率 | **≥ 85%** | +| 协同决策响应 | **≤ 3 分钟** | +| 调度指令执行成功率 | **≥ 98%** | +| 综合市场收益提升 | **15%** | +| 新能源就地消纳能力提升 | **10%** | + +> **讲解要点：** 总体上，项目将形成可落地、可推广、可复制的虚拟电厂多智能体协同应用体系，覆盖运行监测、资源组织、交易决策、用户响应、控制执行和偏差复盘等核心业务环节。在业务应用层面，将提升虚拟电厂对可调资源的发现、组织、交易和控制能力；在平台系统层面，将形成多智能体协同调度平台、业务应用系统、AI 交互分析引擎以及运维安全管理能力；在数据和知识层面，将沉淀资源、用户、运行、规则和指标等核心数据资产。最终目标是实现省内可调负荷聚合不低于 80 MW，预测平均误差不高于 8%，用户可调潜力辨识准确率达到 90% 以上，协同决策响应不超过 3 分钟，调度指令执行成功率达到 98% 以上，综合市场收益提升 15%，新能源就地消纳能力提升 10%，全面支撑虚拟电厂规模化、智能化运营。 + +--- + +### 3.2 组织架构 + +![组织架构](proposal-assets/slide-15.png) + +牵头单位统筹、产学研用协同，支撑虚拟电厂多智能体协同项目高效实施。 + +#### 申报单位 + +**牵头申报单位：** 国网湖北综合能源服务有限公司 + +- 单位性质：国有企业 +- 注册资本：10 亿元 +- 简述：国网电网体系内综合能源服务企业，聚焦新型电力系统建设与用户侧能源价值升级 + +**联合申报单位** + +- 国网湖北省电力有限公司电力科学研究院 +- 武汉大学数据智能研究院 +- 武汉智网兴电科技开发有限公司 + +#### 组织设置 + +``` +项目领导小组（统筹项目决策、资源协调、重大事项推进） + │ +项目管理办公室 PMO（负责计划管理、进度跟踪、协同组织、成果管理） + │ + ├── 算法研发组：大模型、智能体、预测优化算法、数据建模 + ├── 省间协同业务组：交易机制研究、业务规则梳理、省内外资源对接 + ├── 平台开发组：系统架构设计、应用开发、接口集成、产品交付 + ├── 现场实施组：资源接入、系统部署、联调上线、业务落地 + └── 运维保障组：运行监控、问题响应、系统优化、安全与持续运营 +``` + +形成 **研发 — 建设 — 实施 — 运维** 闭环。 + +#### 创新联合体分工 + +| 单位 | 分工 | +|---|---| +| 国网湖北综合能源服务有限公司 | 总体牵头、业务统筹、场景建设、试点落地、项目管理 | +| 国网湖北省电力有限公司电力科学研究院 | 技术总体、AI 应用支撑、设备研究、测试验证 | +| 武汉大学数据智能研究院 | 算法研究、模型设计、数据工程、智能技术攻关 | +| 武汉智网兴电科技开发有限公司 | 产品设计、平台研发、系统集成、测试交付 | + +#### 项目负责人及核心团队 + +**国网湖北综合能源服务有限公司** + +| 姓名 | 角色 | 投入 | +|---|---|---| +| 罗恒 | 总体负责人 | 12 人月 | +| 巴云磊 | 虚拟电厂业务专家 | 8 人月 | +| 丁宁 | 交易技术专家 | 12 人月 | + +**国网湖北省电力有限公司电力科学研究院** + +| 姓名 | 角色 | 投入 | +|---|---|---| +| 崔一峰 | 技术负责人 | 12 人月 | +| 金晨 | 智能体研发 | 12 人月 | +| 阮佳楠 | 智能体研发 | 12 人月 | + +**武汉大学数据智能研究院** + +| 姓名 | 角色 | 投入 | +|---|---|---| +| 李柯 | 科研组负责人 | 8 人月 | +| 毛进 | 科研技术负责人 | 8 人月 | +| 观昊 | 智能技术负责人 | 8 人月 | +| 梁凯迪 | 数据挖掘专家 | 10 人月 | +| 王海磊 | 建模工程师 | 10 人月 | +| 姜欢 | 平台研发 | 10 人月 | + +**武汉智网兴电科技开发有限公司** + +| 姓名 | 角色 | 投入 | +|---|---|---| +| 杨富宇 | 产品经理 | 12 人月 | +| 欧阳栋健 | 平台研发 | 12 人月 | +| 杨晨晖 | 数据算法 | 12 人月 | +| 江彩云 | 测试验证 | 12 人月 | + +> **讲解要点：** 本项目由国网湖北综合能源服务有限公司牵头，联合国网湖北电科院、武汉大学数据智能研究院、武汉智网兴电科技开发有限公司共同申报，形成“产学研用”协同创新联合体。组织上设立项目领导小组和项目管理办公室，负责重大事项决策、资源协调、计划管控、进度跟踪和成果管理。下设算法研发组、省间协同业务组、平台开发组、现场实施组和运维保障组，分别承担智能体算法研发、业务规则研究、系统平台开发、现场接入实施和运行维护保障等工作。分工上，牵头单位负责总体统筹、业务场景建设和试点落地；电科院负责技术总体、AI 应用支撑和测试验证；武汉大学负责算法模型与智能技术攻关；智网兴电负责产品设计、平台研发、系统集成和交付实施，保障项目高效推进。 + +--- + +### 3.3 实施计划 + +![实施计划](proposal-assets/slide-16.png) + +总体实施路径与两期建设规划。八步推进：省内落地 → 跨省复制。 + +| 一期建设 | 二期建设 | +|---|---| +| **2025.12 — 2026.5**｜650 万元 | **2026.6 — 2027.6**｜2348.71 万元 | +| 系统研发与省内能力落地 | 资源接入与推广应用 | + +#### 八步实施路径 + +**一期（01—04）：系统研发与省内能力落地** + +| 步骤 | 工作 | 内容 | +|---|---|---| +| 01 需求调研 | 省内负荷、交易、用户响应、柔性资源与痛点梳理 | +| 02 架构设计 | 业务边界、技术路线、数据规划、网络安全方案 | +| 03 算法研发 | 画像、负荷 / 功率 / 价格预测、资源优化模型迭代 | +| 04 平台集成 | 五大业务模块开发，数据流与业务逻辑内部联调 | + +**二期（05—08）：资源接入与推广应用** + +| 步骤 | 工作 | 内容 | +|---|---|---| +| 05 资源接入 | 工业园区、商业综合体、储能、充电桩等接入建档 | +| 06 试运行 | 交易接口对接、现场运行、算法参数与流程优化 | +| 07 验收 | 正式上线、指标核验、材料归档、成果固化 | +| 08 推广 | 省间规则适配、协同试点、华中复制推广 | + +#### 分阶段重点 + +**A. 项目总体目标** + +搭建虚拟电厂多时空尺度智能协同运营管理系统，构建省内—省间两级空间协同、中长期—现货多时间尺度协同、运营商—用户—市场多主体协同的 AI 一体化运营体系。 + +**B. 一期重点：系统研发与省内能力落地** + +- Q1：调研梳理、方案设计、基础环境搭建 +- Q2：核心算法迭代、系统功能开发、内部联调 +- 形成省内虚拟电厂智能运营系统版本，支撑省内精细负荷管控与多市场运营 + +**C. 二期重点：资源接入与推广应用** + +- Q3：省内试点资源接入、现场部署、试运行优化 +- Q4：系统上线、指标达标、成果资料归档 +- 开展省间需求调研、协同试点、成熟模式推广，实现跨省复制与规模化应用 + +**建设成果：** 省内精细管控｜省间余缺互补｜多市场联合交易｜智能调度决策｜可复制推广样板 + +> **讲解要点：** 整体按照“两期建设、八步推进”的路径实施。第一期为 2025 年 12 月至 2026 年 5 月，预算 650 万元，重点完成省内系统研发与能力落地，主要包括需求调研、架构设计、算法研发和平台集成四项工作，形成面向湖北省内虚拟电厂运营的系统版本，支撑负荷精细化管控和多市场运营。第二期为 2026 年 6 月至 2027 年 6 月，预算 2348.71 万元，重点开展资源接入、试运行、验收和推广应用。通过接入工业园区、商业综合体、储能、充电桩等典型资源，开展现场部署和试运行优化，完成系统上线、指标核验和成果固化。最终形成省内精细管控、省间余缺互补、多市场联合交易、智能调度决策和可复制推广的建设成果。 + +--- + +## 汇报完毕 + +国网湖北综合能源服务有限公司