11f19a661a
- 01: add eight testable hard invariants (self-approval ban, duty separation, digest-bound approvals, permit-only effects, LLM-less degraded operation) - 03: approval staleness model — proposal digest, FRESH_CHECK/STALE states, APPROVED→AUTHORIZED split with revocable ExecutionPermit; gateways accept permits, never bare plans - 05: rules packaged as versioned, testable Policy Packs pinned in proposal lineage - 02: approval workbench reshaped into a Case Desk (DecisionCase as the operator's accountability unit) - 10 (new): cross-province federation boundary — signed artifacts only, plus three phase-1 no-rework reservations - 08: add M5 shadow-run milestone as phase-1 acceptance form - 00/04/07: object table, doc map, and walkthrough consistency updates - add brainstorming.md (peer review source document) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019u5SLNweVio6ozJX7yfxQr 🔮 View transcript: https://logs.lojong.info/s/e8u90k3t33w590r7b5y7yzqh
101 lines
7.1 KiB
Markdown
101 lines
7.1 KiB
Markdown
# 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 任务建立评测集，
|
||
换后端 = 跑评测集对比，而非人工感觉；这也是向评审证明「模型可替换、平台不锁定」的硬材料。
|
||
|
||
## 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 评测基线尽早暴露差距；数据质量门禁先行 |
|