109 lines
5.3 KiB
Markdown
109 lines
5.3 KiB
Markdown
# 03 · 可信执行链：Proposal 状态机与包络自治
|
||
|
||
可信执行链是认知平面与控制平面之间唯一的通道，也是本平台在等保与调度合规语境下的
|
||
「真正产品」——评审与验收看的就是这条链的完整性与留痕。
|
||
|
||
## 1. Proposal 对象
|
||
|
||
一切拟执行动作（市场申报、用户邀约、控制计划、调度方案）统一为 Proposal：
|
||
|
||
```yaml
|
||
Proposal:
|
||
id: string # 全局唯一
|
||
type: BID | INVITATION | CONTROL_PLAN | DISPATCH_PLAN
|
||
timescale: ANNUAL | MONTHLY | DAY_AHEAD | INTRADAY | REALTIME
|
||
originator:
|
||
agent: string # 发起 Agent
|
||
trigger: MANUAL | EVENT | SCHEDULED
|
||
task_id: string
|
||
payload: object # 类型化载荷（申报曲线 / 邀约清单 / 控制设定值序列）
|
||
lineage: # 血缘（P5）
|
||
tool_calls: # 每个数字的来源
|
||
- {tool: string, version: string, inputs_ref: string, outputs_ref: string}
|
||
data_refs: [string] # 引用的数据快照
|
||
ledger_version: string # 读取的持仓账本版本
|
||
envelope_ref: string | null # 命中的包络（null = 必走人工）
|
||
status: <状态机，见 §2>
|
||
audit: [...] # 状态迁移全记录：时间、执行者(系统/人)、依据
|
||
```
|
||
|
||
**硬约束**：`payload` 中任何数值字段必须能在 `lineage.tool_calls` 中找到来源（P2 的机器可校验形式，规则校核阶段强制检查）。
|
||
|
||
## 2. 状态机
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> DRAFT: Agent 生成
|
||
DRAFT --> RULE_CHECK: 提交
|
||
RULE_CHECK --> REJECTED: 规则不通过
|
||
RULE_CHECK --> SIMULATION: 通过
|
||
SIMULATION --> PENDING_HUMAN: 仿真告警（一票升级）
|
||
SIMULATION --> ENVELOPE_CHECK: 仿真通过
|
||
ENVELOPE_CHECK --> AUTO_APPROVED: 包络内
|
||
ENVELOPE_CHECK --> PENDING_HUMAN: 包络外 / 无包络
|
||
PENDING_HUMAN --> APPROVED: 人工批准（可多级）
|
||
PENDING_HUMAN --> REJECTED: 人工驳回
|
||
AUTO_APPROVED --> RELEASED: 下发
|
||
APPROVED --> RELEASED: 下发
|
||
RELEASED --> EXECUTING: 控制平面 / 外部接口受理
|
||
EXECUTING --> COMPLETED: 执行完成，反馈回传
|
||
EXECUTING --> ROLLED_BACK: 异常触发回退
|
||
REJECTED --> [*]
|
||
COMPLETED --> [*]: ExecutionReport → 复盘
|
||
ROLLED_BACK --> [*]: 异常报告 → 复盘 + 告警
|
||
```
|
||
|
||
要点：
|
||
|
||
- **规则校核**（确定性规则引擎）：合规性（交易规则、申报格式）、约束校验（资源约束、合同边界、账本一致性）、权限校验（发起 Agent 是否有权发起该类型）、血缘完整性；
|
||
- **仿真验证**：按类型选择——申报类走收益/风险情景回测，控制类走功率平衡/潮流仿真；仿真告警**一票升级**人工，没有例外；
|
||
- **实现形态**：持久化工作流（durable workflow）。审批可能悬挂数小时，状态机必须可恢复、超时可配（如申报截止前 30 分钟未批自动升级告警）。
|
||
|
||
## 3. 包络（Envelope）模型
|
||
|
||
```yaml
|
||
Envelope:
|
||
id: string
|
||
scope:
|
||
proposal_type: BID | INVITATION | CONTROL_PLAN | DISPATCH_PLAN
|
||
timescale: [...]
|
||
resource_set: string # 适用资源/用户集（引用资源池分组）
|
||
bounds: # 按类型定义，示例：
|
||
# BID: 价格 ∈ [p_min, p_max]，电量 ∈ [q_min, q_max]，持仓偏离 ≤ x%
|
||
# CONTROL: 单用户削减 ≤ 合同可中断容量，总削减 ≤ y MW，时段 ∈ 允许窗口
|
||
# INVITATION: 仅限已签自动邀约协议用户群，激励单价 ≤ z
|
||
validity: {from, to} # 有效期，到期必须重新审批
|
||
approval:
|
||
level: L1 | L2 | L3 # 包络本身的审批级别（多级审批）
|
||
approved_by: [...]
|
||
escalation: # 收缩条件
|
||
- 连续 N 次包络内执行偏差超阈 → 包络自动挂起，回归人工
|
||
- 复盘 ReviewFinding 建议收缩 → 触发重审
|
||
```
|
||
|
||
### 3.1 自治拨盘（运营节奏）
|
||
|
||
| 阶段 | 包络状态 | 效果 |
|
||
|---|---|---|
|
||
| 上线初期 | 空集 | 一切 Proposal 走人工，等价传统模式 |
|
||
| 试运行 | 窄包络（如申报价格 ±5% 于预测基准） | 常规日自动，波动日人工 |
|
||
| 成熟运行 | 按复盘数据逐步放宽 | 人工只处理异常与包络续批 |
|
||
|
||
包络的扩与缩都由复盘数据驱动并留痕——「自主决策」能力的增长是可审计的。
|
||
|
||
## 4. 异常回退
|
||
|
||
- 执行中任何环节异常（校核失败、执行偏差超阈、通道故障）→ 回退至 Runtime 安全控制：
|
||
控制类回退到上一批准计划或安全停机曲线（边缘终端本地持有，见 04 篇）；
|
||
申报类在截止前可撤单重报，截止后转入偏差管理流程。
|
||
- 回退动作本身也是留痕事件，并强制生成复盘任务。
|
||
|
||
## 5. 【待补充：包络边界初值 —— 需要业务侧输入】
|
||
|
||
> **TODO(业务)**：以下参数需由运营团队按湖北现货规则与合同实际确定，是包络模型落地的第一批配置：
|
||
>
|
||
> 1. 申报类包络：价格边界相对什么基准（电价预测值？历史分位数？），初始偏离容差取多少；
|
||
> 2. 控制类包络：分资源类型（空调/储能/工业可中断）的单点削减上限与恢复速率约束；
|
||
> 3. 包络审批层级 L1/L2/L3 分别对应公司内哪些岗位/会签流程；
|
||
> 4. 「连续 N 次偏差超阈挂起包络」中 N 与阈值的初值。
|