# 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 关联，禁止互相替代。