# 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` 运行包络 | 人工预批准的自治边界(授权,向下) | 人工审批 → 可信执行链 | | `FlexibilityEnvelope` 灵活性包络 | 资源/聚合单元的可调能力(能力,向上;省间交换的核心工件) | 资源调度 → 交易博弈 / 省间联邦 | | `ExecutionPermit` 执行许可 | 现势复核后签发的短时效执行凭证,网关只认许可 | 授权环节 → 网关 | | `DecisionCase` 运营工单 | 运营人员的问责单元,聚合一件事的证据/建议/审批/结果 | 触发源 → 运营工单台 | | `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 基础条件 | | 09-runtime-implementation | Runtime 实现设计(Mastra 落地细节) | 2.3 建设内容 05 | | 10-federation | 省间协同联邦边界 | 3.3 二期推广 |