vpp-ai-platform/docs/08-implementation.md

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 模板并填参

需自建、框架不提供的部分（工作量估算时别漏）： 政策包引擎（规则校核）、包络模型与检查器、现势复核与执行许可服务（ExecutionPermit）、 持仓账本服务、运营工单台（Case Desk，含多级审批收件箱）、 交易平台/调度/计量适配器、执行引擎与边缘协议、审计血缘组装。 ——这些恰恰是本平台的差异化资产；智能体框架只解决约 1/3 的问题。

2. LLM 提供商抽象层（P6）

Agent 代码 → 能力接口（complete / plan / extract / explain, 统一消息与工具调用格式）
              → 模型路由器（按任务类型 × 环境选择后端）
                  ├── 开发/测试：商用 API（Claude 等）
                  ├── 预生产：本地开源模型（Qwen/DeepSeek，验证本地化部署可行性）
                  └── 生产：光明电力大模型适配器

设计约束：

1. 面向能力最小公倍数：不依赖单一厂商特性（如特定结构化输出模式）； 工具调用格式在抽象层归一，必要时降级为「提示词 + JSON 解析 + 重试」；
2. 光明大模型适配器的未知项（需在一期尽早与国网侧确认）： 接口协议（是否 OpenAI 兼容）、上下文长度、工具调用支持形式、 电力语义特有能力的调用方式、部署位置与网络分区； ——在确认前，抽象层按「OpenAI 兼容 + 8K 上下文 + 无原生工具调用」的保守假设设计降级路径；
3. 评测集先行：为意图解析、规则问答、申报说明生成等每个 LLM 任务建立评测集， 换后端 = 跑评测集对比，而非人工感觉；这也是向评审证明「模型可替换、平台不锁定」的硬材料。 评测体系全貌（四层对象、数据集、变更门禁、KPI 口径）见 12 篇。

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. M5 影子运行（一期验收形态）：全链路接实时数据，外部效果全部仿真 （申报只生成不提交、指令只投递仿真网关），逐日对比影子决策与人工实际决策—— 既是最有说服力的验收演示，也是包络初值设定的数据依据；
6. 交互服务/负荷控制 Agent 与边缘控制链路放二期（依赖现场资源接入与外部联调）； 二期上线路径：影子运行 → 受控实报（人工逐笔批）→ 包络自治逐步放宽。

排序理由：M1–M3 不依赖任何外部单位排期，最快形成端到端演示与真实历史回测能力； 回测结果（用历史行情验证报价优化收益）是二期扩大授权（包络放宽）与评审汇报的最强证据。

5. 风险登记（架构相关）

风险	影响	缓解
光明大模型接口/能力与假设不符	抽象层返工	保守假设 + 降级路径先行；一期尽早拿到接口规格
外部接口联调排期不可控	二期进度	一期全部走可独立闭环的降级通道；接口协议对接提前启动
规则校核与知识库双轨漂移	合规风险	05 篇 §4 的同步评审工作流，上线即启用
包络初值定不下来	自治能力无法演示	03 篇 TODO 清单作为业务侧一期交付物管理
预测精度不达 8%	连锁影响报价与考核	M2 评测基线尽早暴露差距；数据质量门禁先行