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
138 lines
8.0 KiB
Markdown
138 lines
8.0 KiB
Markdown
# 02 · 认知平面：智能体与 Runtime
|
||
|
||
## 1. Agent Runtime
|
||
|
||
Runtime 是认知平面的操作系统，五类智能体是运行其上的「业务进程」。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph TRIG["任务触发（三源）"]
|
||
T1[人工触发<br/>自然语言 / 专题分析 / 任务下达]
|
||
T2[事件触发<br/>负荷偏差超阈 / 光伏异常 / 响应不足 / 设备离线]
|
||
T3[周期触发<br/>日前预测 / 申报前策略 / 响应前筛选 / 事后复盘]
|
||
end
|
||
TRIG --> IR[意图解析<br/>LLM]
|
||
IR --> WF[流程编排<br/>确定性工作流引擎]
|
||
WF --> AG[Agent 调度]
|
||
AG --> TL[工具调用<br/>注册表 + 版本化契约]
|
||
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. 人机交互面：运营工单台（Case Desk）
|
||
|
||
运营人员的工作单元不是「某个 Agent 的输出」，而是**运营工单（DecisionCase）**——
|
||
一件有明确目标、责任人、期限和完结条件的业务事项：
|
||
|
||
```yaml
|
||
DecisionCase:
|
||
kind: DAY_AHEAD_BID | DR_EVENT | DEVIATION_RESOLUTION | REVIEW | ...
|
||
objective: "完成 D 日现货申报" # 一单一目标，禁止杂物箱化
|
||
owner: string # 责任人（问责单元）
|
||
deadline: ts # 期限（如申报截止）
|
||
contents: # 工单聚合的全部工作产物（引用，非复制）
|
||
evidence: [...] # 态势报告、预测、画像快照
|
||
proposals: [...] # 关联 Proposal 及其状态
|
||
approvals / permits: [...]
|
||
scenarios: [...] # 情景分支（高价情景、低光伏情景的对比测算）
|
||
outcome: ... # 执行回执与复盘结论（完结条件）
|
||
```
|
||
|
||
- 工单由三类触发源随流程模板**自动开单**（周期申报单、事件偏差单），人工也可开专题单；
|
||
- 审批收件箱、看板、报告都是工单与账本/事件日志之上的**投影**，不是独立功能烟囱；
|
||
- 运营人员可在工单内叉分情景（「如果明日出现高价时段？」）——由 Agent 重跑测算工具
|
||
生成对比分支，但不产生新 Proposal，纯分析用途；
|
||
- 自由文本只存在于「人 ↔ 平台」界面：智能问答、专题分析、报告生成，均挂在工单上下文内；
|
||
- 业务页面嵌入 AI 结论卡片，卡片与页面双向联动；每张卡片可展开血缘：
|
||
结论 → 引用的工具输出 → 数据来源（P5 在 UI 层的体现）。
|
||
|
||
**工单 vs 工作流**：工作流（Runtime 内部）是机器的执行单元，工单是人的问责单元；
|
||
一张工单通常聚合多条工作流的产物（申报单 = 态势流程 + 画像流程 + 申报流程 + 生命周期流程）。
|
||
两者通过 case_id 关联，禁止互相替代。
|