vpp-ai-platform/docs/03-safety-chain.md
2026-09-01 19:46:59 -04:00

5.3 KiB
Raw Blame History

03 · 可信执行链:Proposal 状态机与包络自治

可信执行链是认知平面与控制平面之间唯一的通道,也是本平台在等保与调度合规语境下的 「真正产品」——评审与验收看的就是这条链的完整性与留痕。

1. Proposal 对象

一切拟执行动作(市场申报、用户邀约、控制计划、调度方案)统一为 Proposal:

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. 状态机

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)模型

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 与阈值的初值。