147 KiB

Raw Blame History

智能排产智能体（APS Planning Agent）架构设计与实施 Plan

版本：V1.0　｜　定位：面向 MOM 体系的「计划排产」单域智能体关联材料：aps-frontend/（现有高保真原型）、《工业智核 — AI 驱动的智能制造与工业软件平台》商务汇报 PPT 角色视角：资深架构师 × 算法工程师 × APS 计划排产专家

0. 阅读指南

本文是一份"可执行的架构蓝图"，不是营销文案。每一章都遵循同一结构： 定位 → 设计 → 数据结构/接口 → 约束 → 与现有 aps-frontend 的衔接。

全文的两条主线：

业务主线：订单 → 排产 → 交期承诺 → 插单/缺料重排 → 下发 MES/WMS（对应 PPT P10 的 ①→⑧ 闭环）。
智能体主线：自然语言意图 → Plan 治理 → LLM 受限决策 → 工具/插件执行 → 证据链 → 人工确认 → 世界状态提交。

产品边界（务必牢记）：本产品只做"计划排产"一个域。它不是 MES，不是 WMS，而是站在既有 MOM 系统之上、通过 MCP 对接它们的"排产大脑"。

1. 产品定位与愿景

1.1 一句话定位

一个"左手自然语言对话、右手可视化排产盘"的计划排产智能体：计划员用大白话提出目标（"把比亚迪这张插单在不违约其他 VIP 交期的前提下排进去"），智能体基于知识库与算法引擎生成带证据链的排产方案，计划员在可视化甘特上确认后下发到 MOM。

1.2 与 PPT 的对应关系

PPT 主张	本产品承接方式
P7 痛点：排产靠经验、响应慢、交期承诺不准	自然语言 + 算法引擎，秒级出方案 + 交期承诺看板
P10：APS 自动生成方案、插单/缺料触发重排、计划员确认后下发	Runtime 通道 + Checkpoint + 人工确认门禁
P11/P14：写操作必须人工确认、审计留痕、可回滚	门禁 harness + 证据链 + 状态成对分叉
P12：智能排产 Agent、库存预警触发排产重算	MCP 事件订阅 → Explore 通道自动重排
P13：规则与策略引擎可按车间/产线/产品调整	分层 Plan 治理体系（可重生）
P22：排产规则模板、交期承诺看板、4-8 周试点	轻量场景模板 + 知识资产复用

1.3 核心能力清单

意图识别 + NL2Plan：两级管线（规则快路 + LLM 语义解析）把自然语言变成结构化排产计划（§9.6）。
约束体系：13 类硬/软约束目录化管理——主数据即约束、配置中心调参、SOP 转译入库（§9.2a）。
主控参数识别：紧约束/影子价 + 敏感性排序 + 冲突归因三通道，动态定位"这版计划卡在哪"（§9.2b）。
算法库 + 算法引擎：五类算法资产（调度规则/精确优化/ML 预测/优化辅助/敏感性）带注册表与选型决策表（§9.5）；规则 / CP-SAT / GA / 混合引擎可插拔。
方案生成与优选：一次试排产出多样化"方案卡组"，硬过滤→帕累托筛→偏好加权→人拍板（§9.7/§9.7a）。
插单动态重排：秒级负荷/齐套快评 → 影响半径判定 → LNS 局部修复优先，全量重排走 P2（§9.11）。
参数优化：算法超参 / 业务参数 / 模型参数三层调优闭环，黄金算例回放评测（§9.8）。
敏感性分析：What-if / Tornado / 蒙特卡洛，为方案输出鲁棒性评分（§9.9）。
报告生成：日报 / 版本对比 / 交期承诺函 / 复盘，快照冻结口径 + 证据脚注（§9.10）。
小样本学习：偏好学习 + 低数据场景保障（迁移先验/层次借力/案例推理/保形区间，§8.3/§8.3a）。
RAG 知识库：排产算法知识、企业排产 SOP、历史案例，带出处回答。
多模态交互：文本 / 语音 / 图片 / 文件输入，低置信抽取必经人工确认（§6.7）。
项目制会话：项目 → 会话 → 分支三级组织，会话引用与四层上下文管理（§4.6-4.8）。
插件与技能管理：MCP 插件面板 + 声明式技能包，像 Codex 一样可启停、授权、重生（§6.8）。
MCP 插件承载：以 MCP 工具形态对接 MES/QMS/EMS/TMS/WMS。
双形态交付：Web 端（浏览器）+ 桌面端（Electron 壳 + Python Sidecar，已实现于 apps/desktop；可私有化内网离线部署，§14）。Tauri（Rust 壳）列为未来迁移备选，当前不阻塞。
可重生（Regenerable）：每个代码模块、每层 Plan 都能被"重新生成"，支持自愈与灰度替换。

2. 总体分层架构

2.1 分层总图

flowchart TB
  subgraph UI["表现层 · UI Shell（Web / Desktop 同构）"]
    NL["左：自然语言对话流"]
    VIZ["右：可视化排产盘（甘特/负荷/交期看板/3D 车间）"]
    BLK["UI 块协议渲染器"]
    TL["时间线导轨 + 会话分支树"]
  end

  subgraph GW["接入层 · Gateway (BFF)"]
    HTTP["HTTP API"]
    SSE["SSE 会话流"]
    PIA["Pi Agent 接入"]
    SESS["Session / 资源 / 预处理 Provider"]
  end

  subgraph CORE["智能体核心 · Agent Core"]
    ORCH["Orchestrator 编排器"]
    PLAN["分层 Plan 治理体系（可重生）"]
    HARNESS["门禁 Harness（权力边界 / 验收）"]
    CH_EXP["Explore 通道"]
    CH_RUN["Runtime 通道"]
    EVID["证据链 Evidence Chain"]
    MODEL["模型调用（KIMI / DeepSeek）"]
    TOOL["工具机制底座（Tool Runtime）"]
  end

  subgraph DOMAIN["领域层 · APS Domain"]
    NL2PLAN["NL2Plan 解析"]
    ENGINE["排产算法引擎（Rule/CP/GA/Hybrid）"]
    CONSTR["约束求解 + 冲突检测"]
    FEWSHOT["小样本学习 / 偏好学习"]
    KPI["KPI 与交期承诺计算"]
  end

  subgraph KNOW["知识层 · Knowledge"]
    RAG["RAG 检索"]
    VEC["向量库"]
    KASSET["知识资产（算法/SOP/案例）"]
  end

  subgraph INTEG["集成层 · MCP Plugin Bus"]
    MCP["MCP 工具网关"]
    MES["MES"]; QMS["QMS"]; EMS["EMS"]; TMS["TMS"]; WMS["WMS"]; ERP["ERP"]
  end

  subgraph DATA["数据层"]
    WORLD["世界状态 World State"]
    CONV["对话状态 Conversation State"]
    TS["时序库 / 事件流"]
    SNAP["Checkpoint 快照仓"]
  end

  UI <--> GW
  GW <--> CORE
  CORE <--> DOMAIN
  CORE <--> KNOW
  CORE <--> INTEG
  DOMAIN <--> DATA
  INTEG <--> MES & QMS & EMS & TMS & WMS & ERP
  CORE <--> DATA

2.2 各层职责边界（"谁负责什么"）

层	职责	明确不负责
UI Shell	聊天、Workspace、Workflow、文件管理、3D 渲染、插件 UI 承载	不做业务决策、不直接写世界状态
Gateway (BFF)	HTTP API、SSE 会话流、Pi Agent 接入、Session、资源、插件与预处理 Provider	不含排产算法、不含 LLM 决策逻辑
Agent Core	Agent session、模型调用、工具机制底座、Plan 治理、门禁、双通道、证据链	不含具体行业算法实现细节
APS Domain	Workflow、排产工具、领域算法能力、UI 扩展定义	不直接触达外部系统（经 MCP）
Knowledge	RAG、向量检索、知识资产管理	不做写操作
MCP Plugin Bus	承载插件、标准化对接 MOM 各系统	不含业务语义判断
Data	世界状态 / 对话状态 / 时序 / 快照的持久化	不含计算逻辑

这条"平台层与模块的边界"是全系统的宪法：跨层只能通过声明式接口通信，禁止跨层直接引用实现。

3. 核心治理理念

本章是本智能体区别于"套壳 ChatBot"的关键，务必逐条落地。

3.1 分层 Plan 治理体系（可重生）

排产是"目标—策略—约束—动作"的层层分解。我们把 LLM 的输出强制约束为四层 Plan，每层都可独立"重生"（重新生成而不影响其它层）。

flowchart LR
  L0["L0 意图层 Intent<br/>用户目标 + 验收标准"] --> L1["L1 策略层 Strategy<br/>选引擎/权重/约束开关"]
  L1 --> L2["L2 任务层 Tasks<br/>有序步骤 DAG"]
  L2 --> L3["L3 动作层 Actions<br/>工具/算法/MCP 调用"]

分层定义：

层	内容	由谁产生	重生粒度
L0 意图	用户目标 + 验收标准（见 §6.6）	LLM 解析 + 用户确认	改目标 → 全链重生
L1 策略	引擎类型、优化权重、约束开关、排产范围	LLM 结合 RAG 推荐	改策略 → 重生 L2/L3
L2 任务	步骤 DAG（拉取订单→齐套检查→排程→冲突检测→评估）	编排器模板 + LLM 微调	单节点可局部重生
L3 动作	具体工具/算法/MCP 调用及参数	工具底座	单动作可重放/重生

"可重生"的技术含义：每层 Plan 都是一个带 planId / parentId / version / regenCount / inputsHash 的不可变对象；重生 = 基于同一 inputsHash 生成新 version，旧 version 保留于时间线可回看/对比。

// Plan 节点通用结构：四层共用同一骨架，layer 区分层级
interface PlanNode {
  planId: string;              // 全局唯一 ID
  layer: 'L0' | 'L1' | 'L2' | 'L3'; // 所属治理层
  parentId: string | null;     // 上层 Plan ID（L0 为 null）
  version: number;             // 版本号，重生时自增
  regenCount: number;          // 已重生次数（用于熔断：超阈值需人工介入）
  inputsHash: string;          // 输入指纹，用于判定是否需要重生
  status: 'DRAFT' | 'APPROVED' | 'RUNNING' | 'DONE' | 'FAILED' | 'SUPERSEDED';
  payload: unknown;            // 该层的结构化内容（Intent/Strategy/Tasks/Actions）
  evidenceRefs: string[];      // 关联的证据链条目 ID
  createdAt: string;           // 创建时间
  createdBy: 'LLM' | 'USER' | 'SYSTEM'; // 产生者
}

3.2 LLM 权力边界（Power Boundary）

核心原则：LLM 只有"提议权"，没有"执行权"。 LLM 能生成 Plan、能读、能算、能建议，但任何"写世界状态"的动作必须穿过门禁 Harness。

权力分级（与 PPT P14 的动作分级一致）：

等级	动作类型	示例	是否需人工确认
P0 只读	查询、检索、KPI 计算、仿真排产（sandbox）	"看一下本周负荷"	否，自动执行
P1 内部提议	生成排产方案草稿（写入 Explore 沙盒，不落世界状态）	"试排一版"	否，但仅落沙盒
P2 世界写入	发布排产版本、下发工单、调整冻结窗口	"确认下发"	是，强制人工确认
P3 外部副作用	通过 MCP 调 MES/WMS 真正写外部系统	"锁定隔离库位"	是 + 二次确认 + 审计

LLM 在系统 prompt 层被硬约束：输出必须是结构化 Plan / UI 块 / 工具调用，禁止直接输出"已执行"类断言。真正的执行由工具底座在门禁放行后完成。

3.3 门禁 Harness（Gate Harness）

Harness 是一切写操作的唯一入口，扮演"验收 + 授权 + 留痕 + 回滚点"的角色。

flowchart LR
  REQ["动作请求<br/>(来自 L3)"] --> G1{"权限校验<br/>用户 RBAC"}
  G1 -->|通过| G2{"边界校验<br/>硬约束不可违反"}
  G2 -->|通过| G3{"风险分级<br/>P0/P1/P2/P3"}
  G3 -->|P0/P1| EXEC["直接执行"]
  G3 -->|P2/P3| CONFIRM["生成确认卡<br/>推给 UI"]
  CONFIRM -->|人工批准| SNAP["建 Checkpoint 快照"]
  SNAP --> EXEC
  CONFIRM -->|驳回| REJECT["记录驳回 + 反馈 LLM"]
  EXEC --> AUDIT["写审计 + 证据链"]
  G1 -->|拒绝| DENY["拒绝 + 提示"]
  G2 -->|违反| DENY

Harness 的四道防线（对应 PPT P14）：

权限防线：Agent 继承发起用户的 RBAC，越权直接拒。
审计防线：记录"谁、何时、用什么依据、做了什么"。
回滚防线：写操作前建 Checkpoint 快照，异常一键回滚。
数据防线：敏感字段脱敏，私有化部署，数据不出厂。

3.4 证据链（Evidence Chain）

每一个方案、每一个结论都必须"可追溯到源"。证据链把 LLM 的黑箱变成"可审计的推理"。

// 证据条目：把"结论"绑定到"依据"
interface EvidenceItem {
  evidenceId: string;                 // 唯一 ID
  kind: 'DATA' | 'RULE' | 'KNOWLEDGE' | 'CALC' | 'USER'; // 证据类型
  claim: string;                      // 该证据支撑的结论，如"L001 周三超载 120min"
  source: {                           // 来源定位
    system?: string;                  // 来源系统（MES/WMS/内部引擎…）
    ref: string;                      // 引用（记录ID/文档chunk/算法run-id）
    version?: string;                 // 版本号（RAG 强制携带，见 PPT P11）
  };
  snapshot: unknown;                  // 依据当时的数据快照（保证可复现）
  createdAt: string;
}

硬规则：RAG 回答必须携带文档出处 + 版本号；算法结论必须携带 run-id + 输入快照；缺证据的结论不允许进入 P2/P3 动作。

3.5 边界约束（Boundary Constraints）

区分硬约束（不可违反）与软约束（可权衡），这是排产专业性的体现：

类别	硬约束（Hard）	软约束（Soft，进目标函数）
时间	冻结窗口内工单不可动、班次日历外不可排	交期尽量不超期
资源	工位同一时刻不可双占、设备维保期不可排	产线负荷尽量均衡
物料	缺料（stock+inTransit<need）不可开工	库存占用尽量低
工艺	工序先后序不可颠倒、换线换模时间必须预留	换线次数尽量少
质量	不合格批次不可流转（QMS 锁定）	成本尽量低

Harness 的 G2 边界校验只拦硬约束；软约束交给算法引擎的目标函数权衡。

3.6 审计体系（Audit System）

审计不是"顺手记条日志"，而是与门禁、证据链并列的第一等治理设施。设计围绕四个问题：记什么、怎么防篡改、谁能看、怎么用。

3.6.1 审计事件模型（5W1H + 链式防篡改）

# 审计事件：系统内一切"值得追责"的动作的原子记录（append-only，不可改不可删）
class AuditEvent(BaseModel):
    event_id: str                 # 事件 ID（单调递增 + 随机后缀，防猜测）
    ts: str                       # Who-When：UTC 时间戳（毫秒）
    actor: dict                   # Who：{user_id, role, on_behalf: 'HUMAN'|'AGENT'|'AUTOMATION'}
                                  #   —— Agent 代办必须同时记"哪个自动化档位/哪条房间规则授权了它"
    category: str                 # What：事件大类（见 3.6.2 分类）
    action: str                   # What：具体动作，如 "schedule.publish"
    target: dict                  # Where：作用对象 {type, id, project_id, session_id, branch_id}
    power: str                    # 权力等级 P0-P3（与门禁分级一致）
    rationale: dict               # Why：依据 —— {plan_id, evidence_refs[], confirm_card_id, approver}
    payload_digest: str           # How：输入/输出摘要哈希（大对象存对象仓，此处只留指纹）
    before_snapshot: str | None   # 写操作的前置快照引用（回滚防线的锚）
    result: str                   # 结果：SUCCESS / DENIED / FAILED / ROLLED_BACK
    prev_hash: str                # 链式哈希：H(前一事件哈希 ‖ 本事件规范化序列化)
    hash: str                     # 本事件哈希（SHA-256）

防篡改机制（三层）：

哈希链：每事件携带 prev_hash，任何中间篡改导致后续全链校验失败；
定期锚定：每 N 分钟把当前链头做成 Merkle 根，写入独立介质（WORM 存储 / 异机只读库 / 可选企业链），单点管理员也无法整链重写；
职责分离：审计写入通道与业务库物理分离；审计员角色只读，任何人（含超管）无删除/修改权限，保留期满由策略自动归档而非人工删除。

3.6.2 审计事件分类（十类，全覆盖）

类别	覆盖动作	特殊要求
会话与身份	登录/登出/切换项目/权限变更	权限变更双人复核
Plan 治理	L0-L3 生成/重生/驳回	记录 regenCount 与触发原因
模型调用	每次 LLM 请求	记 prompt 指纹、模型名+版本、温度/种子、token 用量、响应指纹——保证可复现与成本可归集；prompt 原文脱敏后入对象仓
工具调用	每次 MCP/内部工具调用	幂等键 + 入出参摘要（PPT P11"谁、何时、用什么依据、做了什么"）
门禁决策	确认卡的批准/驳回/超时	记审批人、停留时长、修改意见
世界写入	版本发布/工单变更/冻结解冻	强制关联 before_snapshot
外部下发	对 MES/WMS 等的写操作	记外部系统回执；补偿动作单独成事件
配置与参数	权重/规则/档位/策略变更	记参数前后 diff（§9.8 调优闭环）
知识与模型资产	知识入库/审批/模型上线/回滚	记版本号与审批链
算法运行	每次求解 run	记算法 ID+版本、随机种子、时限、objective bound——排产结果可复算

3.6.3 审计的消费面（不只是留证，还要好用）

回放：沿哈希链按时间/按订单/按版本回放"这张单是怎么被排成这样的"——与时间线导轨（§4.4）共用同一数据，微观层直接渲染审计事件。
审计视图：按 5W1H 任意维度检索（"上周谁改过 L002 的冻结窗口？"），本身是 P0 查询意图，可用自然语言问（意图识别路由到审计检索工具）。
报表与合规：一键导出监管口径报表；控制项对标 等保 2.0 三级（安全审计：留存≥6 个月、防篡改、定期备份）与 ISO/IEC 27001 A.12.4（日志与监控）；LLM 相关留痕对齐生成式 AI 服务管理相关要求（记录可追溯）。
异常检测：审计流上跑规则告警（高频驳回、越权尝试、非工作时段的 P3 调用、同一 Agent 短时大量写请求），可触发自动降档（G3→G1）。

3.6.4 保留与脱敏策略

数据	热存	归档	说明
审计事件主链	12 个月（在线可查）	≥5 年（WORM）	满足等保与集团内控
LLM prompt/响应原文	90 天（脱敏后）	1 年	敏感字段（客户名/价格）先脱敏再存证，指纹永久保留
前置快照	与 Checkpoint 同生命周期	增量压缩归档	支撑一键回滚
算法运行输入包	90 天	抽样归档	支撑结果复算与争议仲裁

4. 会话分支与探索模型

这是"计划员敢用"的关键：任何试探都不污染现实，任何后悔都能回到过去。

4.1 数据模型：分支即会话树

会话不是线性列表，而是一棵分支树。每次"探索另一种排法"就长出一条新枝。

flowchart TD
  R["根：初始世界状态 W0 + 对话 C0"] --> N1["节点1：拉取订单"]
  N1 --> N2["节点2：交期优先试排 (W1)"]
  N1 --> N3["节点3：产能均衡试排 (W1')"]
  N2 --> N4["节点4：插入比亚迪插单 (W2)"]
  N3 --> N5["节点5：调整权重重排 (W2')"]
  N4 --> N6["节点6：人工确认发布 ✅"]

// 会话树节点：对话与世界状态成对存在
interface BranchNode {
  nodeId: string;                 // 节点 ID
  parentNodeId: string | null;    // 父节点（根为 null）
  childrenIds: string[];          // 子分支
  convStateRef: string;           // 对话状态快照引用
  worldStateRef: string;          // 世界状态快照引用（与对话成对！）
  label: string;                  // 人类可读标签，如"产能均衡试排"
  isCheckpoint: boolean;          // 是否为正式 Checkpoint
  createdAt: string;
}

4.2 硬约束：对话状态与世界状态成对分叉

这是本系统最重要的一条硬约束。 对话状态（聊了什么、Plan 到哪一步）与世界状态（订单/工单/排程数据）必须同生同灭、成对快照、成对回滚。

不允许"对话回退了但数据还停在未来"。
不允许"数据回滚了但对话还以为方案已发布"。
每个 BranchNode 同时持有 convStateRef 与 worldStateRef，切换分支 = 同时切换两者。

// 成对状态：任何分叉/回滚都以 StatePair 为原子单位
interface StatePair {
  pairId: string;                 // 成对状态 ID
  conversation: ConversationSnapshot; // 对话状态快照
  world: WorldSnapshot;               // 世界状态快照（排产数据）
  parentPairId: string | null;    // 派生自哪个 pair
  reason: string;                 // 分叉/提交原因
}

4.3 Checkpoint 触发策略

Checkpoint = 一次成对状态的正式快照，是回滚的锚点。触发时机：

触发点	类型	说明
P2/P3 写操作前	自动·强制	门禁在放行写操作前必建快照（回滚防线）
用户"另存为分支"	手动	计划员想保留当前方案再探索
一轮排产完成	自动	每次 `runScheduling` 完成建一个可命名版本
外部事件触发重排前	自动	插单/缺料事件重排前先锚定现状
会话空闲 N 分钟	自动·节流	防止长会话丢失，去重（inputsHash 相同则跳过）

熔断：单节点 regenCount 超阈值（默认 3）→ 停止自动重生，转人工。

4.4 时间线导轨与导航分层

UI 顶部提供"时间线导轨"，把会话树投影成可导航的时间线，分三层缩放：

flowchart LR
  subgraph 导航分层
    A["宏观层<br/>里程碑/发布版本"] --> B["中观层<br/>Checkpoint/分支"] --> C["微观层<br/>每一步 Plan/动作"]
  end

宏观层：只显示已发布版本与关键决策点（给管理者看）。
中观层：显示所有 Checkpoint 与分支枝干（给计划员导航）。
微观层：显示每一步 L2/L3 动作与证据（给排产工程师复盘）。

导轨支持：点击跳转（回到某成对状态）、分支对比（并排 diff 两个 world）、时间旅行（沿导轨回放）。

4.5 探索 UX

沙盒优先：默认所有排产先落 Explore 沙盒（P1），右侧可视化用"草稿态"配色（半透明/虚线）区分未提交方案。
可对比：任意两个分支一键并排（甘特 diff + KPI 对照表）。
可命名：分支/Checkpoint 支持中文命名，便于计划员记忆。
可丢弃：探索分支随时丢弃，不影响主干世界状态。

4.6 项目 → 会话 → 分支：三级组织模型（借鉴 Codex 的项目制会话）

会话不能是一盆散沙。参照 Codex 桌面端"项目下挂多条会话、每条会话有任务状态"的信息架构，本产品采用三级组织：

flowchart TD
  P["项目 Project<br/>（如：青岛工厂 Q3 排产）"] --> S1["会话 Session：本周主排产"]
  P --> S2["会话 Session：比亚迪插单评估 ⚡运行中"]
  P --> S3["会话 Session：产线B技改产能预案 ✅已完成"]
  S1 --> B1["分支：交期优先"]
  S1 --> B2["分支：产能均衡"]

# 项目：会话的容器 + 共享上下文的作用域（对齐 Codex 的项目概念）
class Project(BaseModel):
    project_id: str               # 项目 ID
    name: str                     # 项目名，如"青岛工厂 Q3 排产"
    scope: dict                   # 业务作用域：工厂/车间/产线/时间窗（决定数据可见范围）
    shared_context: list[str]     # 项目级共享上下文：置顶的知识资产/参数版本/基准排产版本
    default_gear: str             # 项目默认自动化档位（G0-G4）
    members: list[str]            # 成员与角色（RBAC 作用域）
    pinned_sessions: list[str]    # 置顶会话
    archived: bool                # 归档标记（对应 Codex"已归档任务"）

# 会话：一次有目的的对话任务，挂在项目下，持有自己的会话树（§4.1）
class Session(BaseModel):
    session_id: str               # 会话 ID
    project_id: str               # 归属项目
    title: str                    # 标题（首轮意图自动生成，可改）
    status: str                   # running / waiting_confirm / done / archived（列表徽章）
    purpose: dict | None          # 目的声明与验收（§6.6，L0）
    tree_root: str                # 会话树根节点（BranchNode）
    active_node: str              # 当前所在分支节点
    context_policy: dict          # 上下文策略（见 4.8）

规则：

项目 scope 是数据边界：会话内一切查询/排产默认限定在项目作用域内（防止跨厂误操作）。
项目级 shared_context 自动注入该项目所有新会话（如"本项目用 V3 参数版本、以 V20260701-005 为基准版本"）。
会话列表按项目分组展示于左侧面板，带状态徽章与后台任务进度（对应 Codex 任务列表体验）。

4.7 会话引用（Session References）

对话中可以显式引用其他会话/分支/方案/报告，引用是结构化链接而非复制文本：

引用语法（输入框 @ 触发）	解析为	用途
`@会话:比亚迪插单评估`	session_id	"按 @会话:比亚迪插单评估的结论重排本周计划"
`@方案:交期优先-v2`	scenario_id（=分支 ID）	跨会话对比/复用方案
`@版本:V20260716-003`	排产版本 ID	以某版本为基准
`@报告:上周复盘`	报告资产 ID	引用报告结论
`@知识:换线标准SOP`	知识资产 ID	强制 RAG 命中指定文档

# 会话引用：跨会话的结构化链接（进入证据链，可追溯）
class SessionRef(BaseModel):
    ref_id: str                   # 引用 ID
    kind: str                     # session / scenario / version / report / knowledge
    target_id: str                # 目标对象 ID
    snapshot_at: str | None       # 引用时点快照（被引会话后续变化不影响本会话已得结论）

硬规则：引用默认按时点快照取值——被引用的会话之后又变了，不会悄悄改变本会话的推理依据（除非用户显式"刷新引用"）；每次引用解析进证据链。

4.8 会话上下文管理（Context Management）

长会话不能靠"把全部历史塞进 prompt"。上下文分四层组装，每层有明确的注入与淘汰策略：

层	内容	注入策略
L-固定	系统人格/权力边界/输出协议	恒定
L-项目	项目 scope、共享上下文、参数版本、基准版本	会话创建时注入，项目变更时刷新
L-会话	目的声明、当前分支的 Plan 状态、最近 N 轮对话原文	滑动窗口
L-检索	更早对话的摘要（滚动压缩）、RAG 命中、会话引用解析结果	按需检索注入

滚动摘要：超出窗口的对话由后台压缩为结构化摘要（决策点/未决项/关键数字），摘要本身可被检索——保证"聊了三小时依然记得开头的验收标准"。
分支隔离：切换分支时，上下文中的"对话近史"随分支切换（成对分叉 §4.2 的对话侧含义）。
实体钉住（Pin）：用户可把关键对象（某订单/某方案/某参数）钉进会话上下文，钉住项永不被摘要淘汰。
上下文可视：UI 提供"上下文面板"，展示当前注入了什么（项目共享/钉住项/引用/摘要），用户可手动移除——上下文对用户透明可控。

5. Explore 通道与 Runtime 通道

Agent Core 内部有两条并行通道，泾渭分明。

5.1 Explore 通道（探索/只读/沙盒）

用途：试排、仿真、what-if、方案对比、自动重排建议生成。
世界写入：只写 沙盒世界状态（W'），永不触碰主干世界状态。
触发：用户主动试探；或外部事件（库存预警、缺料）自动触发"重排建议"。
产出：候选方案 + 证据链 + KPI 预测，推给 UI 供人工选择。
权力等级：P0/P1，无需确认。

5.2 Runtime 通道（执行/写入/受控）

用途：把被确认的方案落到主干世界状态，并经 MCP 下发外部系统。
世界写入：写主干 World State（P2）、写外部 MOM 系统（P3）。
强制经过：门禁 Harness → Checkpoint → 执行 → 审计 → 证据链。
权力等级：P2/P3，强制人工确认。

sequenceDiagram
  participant U as 计划员
  participant EX as Explore 通道
  participant H as 门禁 Harness
  participant RT as Runtime 通道
  participant MOM as MES/WMS
  U->>EX: "试排三种策略对比"
  EX-->>U: 3 个沙盒方案 + KPI + 证据
  U->>H: 选定方案 B，请求发布
  H->>H: 权限/边界/风险校验 + 建 Checkpoint
  H-->>U: 弹出确认卡（差异 + 影响面）
  U->>H: 批准
  H->>RT: 放行执行
  RT->>MOM: 下发工单（MCP）
  RT-->>U: 执行结果 + 审计留痕

5.3 自动化档位（Automation Gears）

计划员可为不同场景设定"自动化档位"，控制智能体的放手程度：

档位	名称	行为
G0	手动	智能体只出建议，全部人工操作
G1	建议	自动 Explore 生成方案，人工选择 + 确认下发
G2	半自动	常规排产自动执行到 P1，仅 P2/P3 人工确认（默认）
G3	监督自治	低风险重排（如小插单）自动走完，仅事后通知；高风险仍需确认
G4	全自治	仅用于灰度/夜间滚动排产，全审计，异常自动回滚并告警

档位是每场景/每产线可配的策略（见 §10 跨部署点策略共享）。

6. UI 架构（左 NL / 右可视化）

6.0 设计系统（Design System，借鉴 Kimi / ChatGPT / Codex 桌面应用）

POC 验证的是"链路成立"；正式产品的视觉必须达到现代 AI 桌面应用水准。基调：安静、留白、单一强调色、数据卡片化——像 Codex/Kimi 一样"工具感强但不吵"。

维度	规范	说明
色彩	中性底：浅色 `#FAFAF8` / 暗色 `#1B1B1F`；单一强调色工业橙 `#F97316`（仅用于主操作与激活态）；语义色（红/黄/绿）只表达状态，不做装饰	拒绝大面积色块与深色重顶栏
侧栏	浅色毛玻璃/微透明（参考 Kimi 设置页），激活项用浅色填充胶囊而非高对比反色	视觉层级靠明度差，不靠边框
字体	系统栈 + `Noto Sans SC`；正文 14px/1.65；数字一律 `tabular-nums`（KPI/表格对齐）	中文排版优先
圆角	卡片 12px、对话气泡 16px、按钮/输入框 10px、胶囊 999px	统一大圆角、柔和
阴影/边框	低海拔柔和阴影（`0 1px 3px rgba(0,0,0,.06)`），边框仅 `1px` 极浅色；禁止双重描边	"浮起来"而不是"框起来"
间距	8pt 网格（8/12/16/24/32）	大量留白
暗色模式	跟随系统 + 手动切换，所有语义色配对暗色变体	桌面应用必备
动效	150–250ms ease-out；LLM 输出流式打字机；"左说右动"联动时右侧目标元素高亮脉冲一次（让用户看见"动"在哪）	动效服务于因果感知
数据呈现	KPI 用大数字卡片，表格弱化网格线、斑马纹极浅；甘特条用低饱和色板 + 悬浮细节卡	拒绝"Excel 感"
空态/加载	空态给引导话术与快捷指令；长任务给骨架屏 + 可取消进度	不留白屏

6.1 整体布局（三栏桌面应用式，借鉴 Codex）

┌──┬───────────────┬──────────────────────┬───────────────────────────┐
│  │ 项目/会话面板    │  中：会话区            │  右：可视化排产盘（视口）     │
│导│ ─────────────  │  ┌────────────────┐  │  ┌─────────────────────┐  │
│航│ ▸ 新建会话      │  │ 面包屑:项目/会话  │  │ 时间线导轨(宏/中/微)   │  │
│轨│ ▸ 项目列表      │  │ 对话流(UI块内嵌) │  │ 甘特/负荷/交期/冲突     │  │
│  │   青岛Q3排产    │  │ Plan分层面板     │  │ 方案卡对比/敏感性图     │  │
│56│     · 会话1     │  │ 证据链抽屉       │  │ 3D车间(可选)           │  │
│px│     · 会话2⚡   │  │ 确认卡(门禁)     │  │                       │  │
│  │ ▸ 后台任务队列   │  │ ──────────────  │  │                       │  │
│  │   蒙特卡洛 73%  │  │ 输入框(多模态:   │  │                       │  │
│  │ ▸ 插件 ▸ 技能   │  │  文本/语音/图片/ │  │                       │  │
│  │ ▸ 设置          │  │  文件拖拽)      │  │                       │  │
└──┴───────────────┴──└────────────────┘──┴──└─────────────────────┘──┘

导航轨（56px）：新建会话、项目、任务队列、插件、技能、知识库、设置——图标+悬浮提示，参考 Codex 左栏信息架构。
项目/会话面板（可折叠）：会话按项目分组（§4.6）；每条会话显示状态徽章（运行中/待确认/已完成，同 Codex 任务列表）；支持搜索、归档、置顶。
中栏会话区：对话流内嵌 UI 块；顶部面包屑（项目 / 会话 / 分支）；底部多模态输入框（§6.7）。
右栏视口：可整栏收起（纯对话模式）或最大化（纯看板模式）；顶部为时间线导轨与分支切换。
迷你悬浮窗 + 系统托盘（桌面端）：全局快捷键唤起快速口令窗，详见 §11.4。

6.2 UI 块协议（UI Block Protocol）

LLM 不直接吐 HTML，而是吐结构化 UI 块，由前端渲染器映射为组件。这样才能做到"对话里内嵌可交互甘特/表格/确认卡"。

// UI 块：LLM 与前端之间的渲染契约（版本化、可扩展）
interface UIBlock {
  blockId: string;                  // 块 ID
  type:                             // 块类型（前端注册表按 type 渲染）
    | 'text' | 'markdown'
    | 'plan-tree'                   // Plan 分层树
    | 'gantt'                       // 甘特图
    | 'load-heatmap'                // 负荷热力图
    | 'due-board'                   // 交期承诺看板
    | 'conflict-list'               // 冲突列表
    | 'confirm-card'                // 门禁确认卡
    | 'evidence'                    // 证据链
    | 'diff'                        // 分支/方案对比
    | 'scenario-cards'              // 方案卡组（§9.7 方案生成）
    | 'sensitivity'                 // 敏感性分析（tornado/分布图，§9.9）
    | 'report'                      // 报告预览与导出（§9.10）
    | 'media'                       // 多模态内容（图片/音频转写/视频帧，§6.7）
    | 'plugin';                     // 插件自定义 UI
  props: Record<string, unknown>;   // 该块的数据 props
  actions?: UIAction[];             // 块内可触发的动作（回传给 Agent Core）
  bindTo?: { viewport?: string };   // 绑定右侧哪个视口
  evidenceRefs?: string[];          // 关联证据
}

// UI 动作：用户在块上的交互回传
interface UIAction {
  actionId: string;                 // 动作 ID
  label: string;                    // 按钮文案
  power: 'P0' | 'P1' | 'P2' | 'P3'; // 权力等级（决定是否走门禁）
  payload: unknown;                 // 携带参数
}

6.3 视口命令集（Viewport Command Set）

自然语言可以直接"驱动右侧视口"，这是"左说右动"的核心。定义一套稳定的视口命令，LLM 输出命令、前端执行：

命令	语义	自然语言示例
`viewport.focus`	聚焦到某产线/某订单/某时段	"放大看 L001 周三"
`viewport.filter`	过滤显示	"只看 VIP 订单"
`viewport.compare`	并排对比两个分支	"对比方案 A 和 B"
`viewport.highlight`	高亮冲突/超期	"标出所有超期的"
`viewport.timescale`	切换时间粒度	"按小时看"
`viewport.replay`	时间旅行回放	"回放这次重排过程"
`viewport.mode`	切换视图（甘特/热力/看板/3D）	"切到负荷热力图"

// 视口命令：结构化、可校验、可回放
interface ViewportCommand {
  cmd: string;                      // 命令名（上表之一）
  target?: string;                  // 目标对象（lineId/orderId/nodeId…）
  params?: Record<string, unknown>; // 命令参数
  issuedBy: 'LLM' | 'USER';         // 由谁发起
}

6.4 工作台操作（Workbench Operations）

Workbench = 计划员的操作台，聚合三类操作：

对话操作：提问、追问、纠偏、命名分支、切换档位。
画布操作：甘特拖拽调整工单、框选批量操作、右键菜单（冻结/解冻/锁定）。
文件/知识操作：上传排产数据与 SOP、查看知识资产、导出方案报告。

6.4a 拖拽交互协议（Drag Interaction Protocol）

右侧视口不是只读画板，拖拽是与自然语言平权的第二输入通道——"说"和"拖"最终产出同一种结构化命令，走同一条门禁/审计/证据链。

拖拽动作集：

动作	手势	产出命令	权力
平移工单	拖动甘特条水平移动	`workorder.move {woId, newStart}`	P1 草稿
改变工时	拖动条右缘伸缩	`workorder.resize {woId, newDuration}`	P1 草稿
跨资源改派	拖动条到另一工位/产线行	`workorder.reassign {woId, newWorkstation}`	P1 草稿
批量框选	框选多条 + 整体拖动	`workorder.batchMove {woIds[], offset}`	P1 草稿
冻结/锁定	右键菜单	`workorder.freeze / lock`	P2
交换顺序	同工位两条互换	`workorder.swap {woA, woB}`	P1 草稿

拖拽全程的实时反馈（"边拖边校验"）：

flowchart LR
  D["开始拖拽<br/>显示幽灵条+对齐线"] --> V["逐帧调用 checkMoveConflict<br/>(硬约束即时校验)"]
  V -->|可行| G["幽灵条绿色<br/>+ 影响预览(后继工序连带位移)"]
  V -->|违反硬约束| R["幽灵条红色 + 冲突原因提示<br/>(维保期/无班次/重叠/冻结)"]
  G --> P["松手 → 生成变更草稿<br/>(P1, 入暂存区 Staged)"]
  R --> S["松手 → 弹回原位<br/>(禁止落子)"]
  P --> C["暂存区聚合多笔草稿<br/>→ 一次性确认提交(P2 门禁)"]

硬规则：

吸附：拖拽自动吸附班次日历网格（15 分钟粒度）与班次边界，禁止落在非工作时段。
冻结不可拖：冻结窗口内工单显示锁形图标，拖拽直接拒绝（硬约束 §3.5）。
连带预览：拖动某工序时，其工艺后继的连带位移以半透明虚影同步预览——让计划员看见"牵一发动全身"。
草稿暂存：拖拽产生的是变更草稿（Staged，§10.1），可累积多笔后一次确认；确认卡列出全部 diff 与新冲突数；也可一键"让智能体优化这批调整"（把草稿交给引擎做局部重排）。
双向可撤销：Ctrl+Z/Ctrl+Y 撤销重做栈；已提交的走 Checkpoint 回滚。
拖拽即证据：每笔拖拽命令与其校验结果进审计（§3.6），与口令指令同等对待。

6.5 房间内自动化（In-Room Automation）

"房间"= 一个排产工作场景（如"青岛工厂 · 一车间 · 本周排产"）。房间内可挂载自动化规则，让智能体在该房间内持续值守：

// 房间内自动化规则
interface RoomAutomation {
  roomId: string;                   // 房间 ID（工厂/车间/产线 scope）
  trigger:                          // 触发条件
    | { on: 'event'; source: 'WMS'|'QMS'|'ERP'; type: string } // 外部事件
    | { on: 'schedule'; cron: string }                          // 定时
    | { on: 'threshold'; metric: string; op: '>'|'<'; value: number }; // 阈值
  gear: 'G0'|'G1'|'G2'|'G3'|'G4';   // 该自动化允许的最高档位
  action: 're-plan' | 'notify' | 'suggest' | 'commit'; // 触发动作
  guardrails: string[];             // 附加护栏（不可违反的硬约束 ID）
}

典型：WMS 缺料事件 → 触发 Explore 重排建议 → G2 下推确认卡（对应 PPT P12"库存预警触发排产重算"）。

6.6 目的声明与验收（Purpose & Acceptance）

每个任务开始前，智能体必须与用户对齐"目的声明"（要达成什么）和"验收标准"（怎么算成功），并在结束时逐条核验。

// 目的声明 + 验收标准：贯穿 L0 意图层
interface PurposeSpec {
  purpose: string;                  // 目的，一句话，如"消化本周插单且不违约 VIP 交期"
  acceptance: AcceptanceCriterion[];// 可量化验收项
}
interface AcceptanceCriterion {
  metric: 'tardiness' | 'vip_on_time' | 'utilization' | 'conflicts' | 'changeover_count';
  op: '<=' | '>=' | '==';           // 比较符
  target: number;                   // 目标值
  actual?: number;                  // 执行后实际值（回填）
  passed?: boolean;                 // 是否通过
}

验收结果进入证据链，未通过的项会阻止 G3/G4 自动提交，转人工。

6.7 多模态交互（Multimodal I/O）

本智能体是多模态的：口令不只有打字，产出不只有文本。

输入侧：

模态	场景	处理管线	落点
文本	主通道	意图识别（§9.6）	L0 Plan
语音	车间/移动场景（"把三号线明天的单子往后挪半天"）	本地/私有化 ASR（Whisper/FunASR，方言与工业术语热词表）→ 转写文本进意图识别；按住说话 + 全局快捷键	转写文本 + 原音频存证
图片	拍白板排产表、Excel 截图、现场看板照片	VLM（KIMI 多模态/DeepSeek-VL）结构化抽取 → 表格数据 → 用户确认后进世界状态	`media` UI 块 + 抽取结果确认卡
文件	拖入 Excel 订单表 / PDF 工艺文件 / SOP 文档	解析器（openpyxl/pdfplumber）→ 订单导入向导或知识资产入库	数据导入（P2 确认）/ RAG 语料
视频	产线巡检视频、会议录屏	抽帧 + VLM 摘要 / ASR 转写（后置能力，非 MVP）	摘要 + 存证

输出侧：文本/UI 块为主；语音播报（TTS）用于告警与免手场景；报告可导出图文文档（§9.10）。

硬规则：多模态抽取结果（如图片里认出的订单行）属于低置信输入，一律走"抽取 → 结构化预览 → 用户确认"三步，确认前不进世界状态；原始媒体文件与抽取结果成对存入证据链。

6.8 插件管理与技能管理（借鉴 Codex 的"插件 / 技能"双面板）

设置中心提供两个一级面板（对应 Codex 左栏的"插件"与"技能"）：

插件管理（Plugins）——管理"能连什么"：

插件市场/列表：MCP 插件（MES/WMS/…）、模型 Provider、ASR/TTS、导出器；显示状态徽章（已连接/需授权/错误/未启用）。
每个插件详情页：工具清单（含权力等级 P0-P3）、健康检查、调用统计、审计日志入口、启用/停用/重装（重生）。
安装方式：内置目录一键启用 + 导入自定义 MCP 端点（URL + 鉴权）。

技能管理（Skills）——管理"会做什么"：

技能 = 领域能力包（试排、插单评估、敏感性分析、报告生成、参数调优…），声明式定义（见下），可启停、可授权、可重生。
技能面板显示：触发口令示例、依赖的插件/算法、所需权力等级、使用统计、黄金测试通过状态。
支持"自定义技能"：把常用操作序列（如"每周一早上出上周复盘报告并发飞书群"）录制/编排为新技能（对应 §6.5 房间内自动化的用户侧封装）。

# 技能清单：声明式定义一个领域能力包（可重生模块）
class SkillManifest(BaseModel):
    skill_id: str                 # 技能 ID，如 "skill.rush_order_eval"
    name: str                     # 显示名，如"插单影响评估"
    trigger_intents: list[str]    # 绑定的意图（§9.6 意图分类）
    trigger_examples: list[str]   # 口令示例（用于意图识别 few-shot 与用户提示）
    required_plugins: list[str]   # 依赖插件（缺失时技能自动置灰）
    required_algos: list[str]     # 依赖算法（§9.5 算法注册表）
    max_power: str                # 该技能最高权力等级（超出必走门禁）
    workflow: dict                # 步骤编排（L2 任务模板）
    golden_tests: list[str]       # 黄金测试（重生验收）

6.9 布局密度与折叠体系（Progressive Disclosure）

复杂工具的克制之道：默认只露必需，其余渐进披露。所有折叠状态按"项目 × 用户"持久化，重开应用即恢复。

可收缩/折叠的单元清单：

单元	折叠行为	快捷键/手势
项目/会话面板	整栏收起（导航轨图标点击）	`Ctrl+B`
对话栏 ↔ 视口	拖动分隔条调宽；双击分隔条极化（纯对话/纯看板两种极端模式）	分隔条拖拽
甘特产线分组	每条产线可独立收起为一行摘要（显示工单数+冲突数微型徽标）	点击分组标题
时间线导轨	宏/中/微三层缩放（§4.4），默认中观	`Ctrl+滚轮`
消息内 UI 块	长表格/JSON 默认折叠为摘要行 +"展开"链接	点击展开
证据链/上下文面板	抽屉式，从右缘滑出	`Ctrl+E` / `Ctrl+I`
KPI 卡组	窄屏自动降级为单行紧凑数字	响应式
验收清单/状态徽标	溢出折叠为"+N"	自动
视口密度	舒适/紧凑/极简三档（行高与字号联动）	工具栏切换

规则：折叠不丢信息——任何被折叠单元若产生新状态（新冲突/新确认卡），在其折叠态上打红点徽标；全局 Ctrl+K 命令面板可直达任何被折叠的功能（像 Codex/IDE 一样"藏得住、找得到"）。

6.10 产品功能全景：把治理做成看得见的界面（对标 Codex 桌面应用）

原则：治理设施不能只活在后端。门禁、审计、重生、算法库这些"暗能力"必须各有一个一级界面，否则用户感知不到产品的护城河。本节以 Codex 桌面应用的信息架构为对标，给出完整的功能面清单与实施状态。

6.10.1 设置中心（Settings，对标 Codex 设置页三段式：个人 / 集成 / 治理）

分组	页面	内容	实施
个人	常规	语言/时区/默认项目/启动页	M3
个人	外观	浅色/暗色/跟随系统；密度三档（§6.9）；强调色锁定工业橙	M3
个人	语音	ASR 引擎选择/热词表管理/按住说话快捷键（§6.7）	M6
个人	个性化	智能建议三档开关（§9.6a）/偏好权重查看与重置（§8.3）	M3
个人	键盘快捷键	全量可改键位表（Ctrl+B 折叠、Ctrl+K 命令面板、Ctrl+E 证据抽屉…）	M3
个人	账户	身份/角色/所属项目/我的审批权限（RBAC 只读视图）	M3
集成	插件	MCP 插件市场与状态管理（§6.8：健康/授权/调用统计/审计入口）	M4
集成	连接	MOM 系统连接（MES/WMS/…端点与凭据）/模型端点（KIMI/DeepSeek/本地）/数据库；逐项健康检查	M4
集成	数据源	数据集资产管理入口（§8.4：版本/血缘/质量报告）	M3
治理	门禁	门禁管理台（见 6.10.2）	M2 起
治理	钩子	事件钩子（见 6.10.4）	M4
治理	重生	重生中心（见 6.10.3）	M2 起
治理	环境	部署环境信息/环境探针结果（§14.4）/版本兼容矩阵	M6
治理	工作树	会话分支树全景管理（§4 的管理视图：跨会话看所有分支/Checkpoint）	M2
归档	已归档任务	归档会话与任务的检索/恢复（对标 Codex"已归档任务"）	M3

6.10.2 门禁管理台（Harness Console）——把 §3.3 从暗逻辑变成明界面

四个页签：

待审批：当前所有待确认的 P2/P3 动作队列（不只在聊天里弹卡）——谁发起、什么动作、影响面摘要、等了多久；支持批量审批与转派。聊天内确认卡与此队列是同一数据的两个视图。
审批历史：每条批准/驳回记录（审批人、停留时长、修改意见），可回放到时间线对应位置。
策略配置：权力等级映射表的管理界面——哪个动作是 P 几（_POWER_MAP 的产品化）、哪些角色可批哪类动作、自动化档位 G0-G4 的场景默认值；策略变更本身是 P2 动作（改门禁要过门禁）。
防线状态：四道防线（权限/审计/回滚/数据）的运行指标——审计链完整性校验按钮（重算哈希链）、最近回滚记录、脱敏命中统计。

6.10.3 重生中心（Regen Center）——把 §9.4 可重生能力做成操作台

三个页签：

模块注册表：全部可重生模块的清单视图（来自 ModuleManifest）——moduleId、类别、接口版本、黄金测试最近状态（绿/红）、上次重生时间、重生次数。M2 起后端每个模块头部的 moduleId 注释即注册表数据源。
重生流水线：选中模块 → 一键触发重生（LLM 生成新实现 → 自动跑黄金测试 → 通过则出灰度开关，失败自动回滚并展示 diff 与失败用例）；每次重生生成一条可回看的流水线记录。人在环：重生结果上线是 P2 动作，走门禁管理台审批。
黄金测试看板：tests/golden 全量用例的最近运行结果矩阵（模块 × 用例），红灯模块禁止重生上线（§14.3 发版门禁的可视化）。

6.10.4 钩子（Hooks，对标 Codex"钩子"）

在关键生命周期事件上挂用户自定义动作（脚本/通知/技能调用）：

钩子点	典型用法
`session.created`	自动注入项目上下文/播报当日冲突
`schedule.completed`	排产完成后自动跑敏感性分析（§9.9）/发飞书通知
`gate.staged`	有待审批项时通知审批人（飞书/邮件，经 MCP）
`version.published`	发布后自动生成版本对比报告（§9.10）并归档
`conflict.detected`	致命冲突自动建任务/@相关计划员
`checkpoint.created`	快照后触发异地备份

钩子=声明式配置（事件 + 条件 + 动作 + 档位上限），本质是 §6.5 房间内自动化的系统级形态；钩子的每次触发进审计。

6.10.5 任务中心（Tasks，对标 Codex 左栏任务列表）

所有后台长任务的统一队列：排产求解（大规模时）、蒙特卡洛压测、模型重训、报告生成、数据导入、模块重生。每条任务显示进度/耗时/可取消/结果入口；完成后在导航轨打红点徽标。左栏会话面板的"后台任务"分组即其缩略视图。

6.10.6 命令面板（Ctrl+K）

全局模糊搜索并直达：任意口令（直接执行）、任意设置页、任意会话/方案/版本/报告（@引用体系 §4.7 同源）、任意被折叠面板。这是"藏得住、找得到"的兜底入口。

实施状态总览（与 §16 路线图对齐）：M1 已交付门禁确认卡与审计链的机制；M2 交付门禁管理台雏形（待审批/历史）+ 重生中心雏形（注册表+黄金测试看板）+ 工作树；M3 交付设置中心个人组 + 归档；M4 交付插件/连接/钩子；M6 交付语音/环境。

7. MCP 插件承载与 MOM 集成

7.1 设计原则

一切外部能力皆插件：MES/QMS/EMS/TMS/WMS/ERP 都以 MCP 工具 形态接入，Agent Core 不感知具体系统，只感知"工具"。
能力四分类（对应 PPT P11）：查询 / 计算 / 执行 / 回写。查询计算为 P0；执行回写为 P2/P3。
契约优先：每个插件声明 tools + resources + events + schema，Gateway 侧做 Provider 预处理与鉴权。

7.2 MCP 插件描述

// MCP 插件清单：声明该插件对接的系统与暴露的工具
interface McpPluginManifest {
  pluginId: string;                 // 插件 ID，如 "mcp-mes"
  system: 'MES'|'QMS'|'EMS'|'TMS'|'WMS'|'ERP'; // 对接系统
  version: string;                  // 插件版本
  tools: McpTool[];                 // 暴露的工具
  events?: McpEvent[];              // 可订阅的事件（用于房间内自动化）
  auth: 'oauth'|'apikey'|'mtls';    // 鉴权方式
  regenerable: true;                // 插件模块支持重生（见 §9.4）
}
interface McpTool {
  name: string;                     // 工具名，如 "wms.check_kitting"
  power: 'P0'|'P1'|'P2'|'P3';       // 权力等级
  inputSchema: object;              // JSON Schema 入参
  outputSchema: object;             // JSON Schema 出参
  idempotent: boolean;              // 是否幂等（决定可否安全重放）
}

7.3 各系统对接职责

系统	智能排产从它取什么（查询/事件）	智能排产向它写什么（执行/回写）
ERP	销售订单、优先级、客户等级	交期承诺回写、排产状态回写
MES	工单执行进度、报工、在制品	下发/调整工单、冻结/解冻
WMS	库存、在途、齐套状态、缺料事件	生成备料/配送任务
QMS	质检结果、不合格批次锁定	读取锁定状态用于约束
EMS	能耗、能碳、超限事件	排产避峰建议（软约束）
TMS	运输时效、发运计划	交期倒排的运输前置期约束

7.4 集成时序（缺料触发重排，端到端）

sequenceDiagram
  participant WMS
  participant BUS as MCP 事件总线
  participant ROOM as 房间自动化
  participant EX as Explore 通道
  participant U as 计划员
  participant RT as Runtime 通道
  participant MES
  WMS->>BUS: 缺料事件(material=PCB-002, shortage=50)
  BUS->>ROOM: 匹配"缺料→重排"规则(G2)
  ROOM->>EX: 触发受影响订单重排
  EX-->>U: 重排建议 + 证据(缺料快照/交期影响)
  U->>RT: 确认调整
  RT->>MES: 下发调整后工单
  RT-->>U: 完成 + 审计

8. 知识库 RAG 与小样本学习

8.1 知识资产（Knowledge Assets）分类

资产类型	内容	用途
算法知识	排产算法原理（规则/CP-SAT/GA/禁忌/模拟退火）、适用边界、参数含义	LLM 选引擎/调参的依据
企业 SOP	排产规则制度、插单审批流程、换线标准	约束与流程依据
历史案例	过往排产版本 + 计划员的人工微调记录	小样本学习语料
物理/工艺知识	工艺路线、换线矩阵、设备能力	约束构建

所有知识入库需版本化、审批（对应 PPT P11"工艺知识变更需审批入库"），检索回答强制携带出处。

8.2 RAG 检索管线

flowchart LR
  Q["用户 query / Plan 上下文"] --> EMB["向量化"]
  EMB --> RET["混合检索<br/>(向量 + BM25 + 元数据过滤)"]
  RET --> RERANK["重排 Rerank"]
  RERANK --> CTX["拼装上下文<br/>(带出处+版本)"]
  CTX --> LLM["KIMI / DeepSeek"]
  LLM --> ANS["回答 + 证据链条目"]

8.3 小样本学习（Few-Shot / 偏好学习）

目标：让智能体学会"这家工厂的计划员喜欢怎么排"，而不是只会通用算法。

数据来源：每次计划员对自动方案的人工微调 diff（挪了哪个工单、改了什么权重、为什么），沉淀为样本。

三层递进（避免一上来就训模型）：

Few-shot 提示：把最相似的 K 条历史"调整案例"作为 few-shot 示例喂给 LLM，指导它生成更贴合偏好的 L1 策略。
权重偏好学习：从历史 diff 反推目标函数权重（tardiness/cost/utilization/balance），做轻量回归/贝叶斯更新，个性化默认权重。
规则归纳：高频重复的人工调整 → 归纳为可复用的显式排产规则，进规则引擎（人工审批后生效）。

// 偏好样本：一次"自动方案 → 人工调整"的学习单元
interface PreferenceSample {
  sampleId: string;
  scope: { factoryId: number; lineId?: number; productId?: number }; // 适用范围
  before: unknown;                  // 自动方案摘要
  after: unknown;                   // 人工调整后摘要
  deltaFeatures: Record<string, number>; // 差异特征（如 +换线次数 -延迟）
  inferredWeights?: Record<string, number>; // 反推的权重
  note?: string;                    // 计划员备注（宝贵的"为什么"）
  createdAt: string;
}

8.3a 数据量不足场景的决策质量保障（小样本 / 迁移学习）

新品产线没有历史工时、插单这类低频事件没有足够样本——ML 预测器（§9.5 C 类）在这些场景不能硬训。分场景的保障策略：

低数据场景	策略	具体做法
新品无工时数据	迁移 + 相似度冷启动	按工艺特征（工序类型/物料族/复杂度）找最相似的既有产品，迁移其工时分布作先验；投产后每笔报工做贝叶斯更新，先验被真实数据逐步替代（收敛前预测区间显著加宽）
新产线无产能画像	分层借力（partial pooling）	用"同类设备全厂/集团层的分布"作产线先验（§10.2 跨部署策略共享的数据侧价值）；层次贝叶斯天然处理"厂内数据少借集团、线内数据少借厂内"
插单等低频事件	案例推理 + 全精度校核	历史插单案例入知识库（§8.1 历史案例类），新插单先检索最相似案例做 few-shot 参考；最终方案永远走 OR 求解器全精度重算（§9.1a 铁律），ML 缺数据只影响"估得准不准"，不影响"排得对不对"
预测置信不足	不确定性显式化	所有 ML 预测输出保形预测区间（§9.5.6 文献锚点）；样本量低于阈值时区间自动加宽并在 UI 标注"数据不足，预测参考性低"；交期承诺函写区间不写点估计

三道防线（为什么缺数据也不会排错）：

结构兜底：ML 只估参数，可行性由 OR 约束模型保证（§9.1a）——工时估偏 20% 会让计划不优，但不会让它违反工艺/日历/齐套约束。
保守回退：任一预测器样本量/置信度低于阈值，自动回退到静态标准工时 × 安全系数（回退事件进审计，UI 可见"本次用了保守值"）。
快速闭环：新品首周排产以"小批量试产 + 密集报工回流"为默认策略，每天用真实报工重估参数——数据不足是暂态，闭环把暂态压到最短。

落地节奏：M3 案例检索（知识库已就位）→ M5 相似度迁移与层次先验随 ML 预测器一起落地（§16）。

8.4 用户数据上传与数据资产管理（Data Onboarding & Management）

没接 MCP 或补充临时数据时，用户会直接上传排产数据（Excel 订单表、产能表、日历、BOM、工艺路线…）。上传的数据不是"一次性喂给对话"，而是进入受管理的数据资产层。

8.4.1 导入管线（五步，每步可回退）

flowchart LR
  U["① 上传<br/>xlsx/csv/图片/粘贴表格"] --> P["② 解析与识别<br/>表头语义映射(LLM辅助)<br/>→ 识别为哪类主数据/业务数据"]
  P --> V["③ 校验与清洗<br/>Schema校验/单位换算/去重<br/>引用完整性(物料是否存在?)"]
  V --> R["④ 预览确认<br/>逐列映射可改·异常行标红<br/>增量/覆盖/合并策略选择"]
  R --> C["⑤ 落库(P2 门禁)<br/>进世界状态或暂存数据集<br/>+ 血缘登记 + 审计"]

②的表头映射由 LLM 提议（"交货日期→deliveryDate"），但映射结果是可编辑的映射模板，同一客户第二次上传同构表格直接复用模板（模板本身是知识资产）。
③的校验规则来自 Schema 注册表 + 业务规则（交期早于下单日期→标错；数量为负→标错；未知物料→给出"新建物料/映射到现有/丢弃"三选一）。
⑤区分两种落点：正式世界状态（参与真实排产，P2 确认）或暂存数据集（仅供沙盒 what-if 使用，P1，如"用这份下月预测单试排看看"）。

8.4.2 数据资产模型

# 数据集资产：一次上传形成一个可管理、可追溯、可引用的数据集
class DatasetAsset(BaseModel):
    dataset_id: str               # 数据集 ID（可被 @数据集 引用，§4.7）
    name: str                     # 名称，如"7月订单表(销售部王工)"
    kind: str                     # 类别：orders/capacity/calendar/bom/routing/forecast/custom
    origin: dict                  # 来源：{file_hash, uploader, upload_ts, source_file_ref}
    schema_version: str           # 对应 Schema 注册表版本
    mapping_template: str | None  # 使用的表头映射模板 ID
    quality: dict                 # 质量报告：{rows, valid, warnings, errors, completeness}
    status: str                   # staged(仅沙盒) / committed(已入世界状态) / archived
    lineage: list[str]            # 血缘：派生自哪些数据集/影响了哪些排产版本
    scope: dict                   # 归属项目/工厂（数据边界，§4.6）
    retention: str                # 保留策略（临时数据集 90 天自动归档提醒）

8.4.3 管理规则

血缘可追：每个排产版本记录它消费了哪些数据集版本——"这版计划为什么这么排"可以追到"因为用了王工上传的 7 月订单表 v2"。
版本化：同名数据集重复上传形成版本序列，diff 可视（新增/删除/变更行数）；排产引用的是具体版本而非"最新"。
冲突仲裁：上传数据与 MCP 同步数据冲突时（同一订单两个交期），默认 MCP 为准 + 冲突清单人工裁决，裁决结果留审计。
数据面板：Workspace 内的"数据"页签统一管理所有数据集（搜索/预览/质量报告/血缘图/引用计数/删除保护——被版本引用的数据集不可物理删除，只可归档）。
安全：上传文件即刻脱敏扫描（身份证/手机号模式），数据集继承项目 RBAC，导出需 P2 权限。

9. 排产算法引擎与领域能力

9.1 引擎抽象（多引擎可插拔）

复用并升级 aps-frontend 现有 runScheduling，抽象为统一接口，多引擎实现：

// 排产引擎统一接口：Rule/CP/GA/Hybrid 均实现之
interface ISchedulingEngine {
  name: 'RULE' | 'CP' | 'GA' | 'HYBRID'; // 引擎标识
  // 输入：订单/主数据/约束/权重；输出：排产版本 + 冲突 + KPI + 证据
  solve(input: ScheduleInput): Promise<ScheduleResult>;
  // 是否支持在给定时间预算内产出可行解（用于 SSE 分阶段汇报）
  supportsAnytime: boolean;
}

引擎	定位	何时用
RULE	规则/贪心，毫秒级	快速试排、插单快响应（现原型已实现）
CP-SAT	约束规划，求可行/最优	中等规模、硬约束密集
GA	遗传算法，多目标寻优	大规模、软约束权衡、帕累托解集
HYBRID	规则初始解 → CP 局部优化 → GA 全局	综合场景（默认）

现原型 scheduling.html 里 CP/GA 只是进度条标签；本 Plan 要求逐步落地真实求解器（CP 可用 OR-Tools，GA 自研或用现成库），作为独立"算法插件"接入，同样具备重生能力。

9.1a 运筹学 + 机器学习双轮驱动（已决策 ✅）

排产的智能不是"OR 或 ML 二选一"，而是分工协作：

能力	用运筹学（OR）	用机器学习（ML）
求可行/最优解	✅ CP-SAT / MILP / GA（确定性、可解释、约束严格）	—
工时/换线时间预测	—	✅ 回归模型（历史报工数据训练，替代静态标准工时）
交期达成概率	—	✅ 分类/生存分析（给交期承诺看板输出"达成概率"）
插单影响预估	—	✅ 代理模型秒级预估（免于每次全量重排）
目标函数权重个性化	—	✅ 偏好学习（§8.3 小样本）
需求/负荷预测	—	✅ 时序预测（滚动排产的输入）
最终排程决策	✅ OR 求解器输出，ML 预测值只作为 OR 的输入参数	—

铁律：ML 负责"把参数估得更准"，OR 负责"在准确参数下求可行最优解"。ML 预测永不直接生成排程（不可解释、不保证可行），这与 PPT P16"AI 负责探索加速、传统求解负责校核背书"的协作原则一致。

技术落点（Python 栈，已决策）：OR-Tools CP-SAT（约束规划）、DEAP/自研 GA、LightGBM/XGBoost（工时与交期预测）、scikit-learn（偏好回归）。

9.1b 三级联动排程（已决策 ✅）

排程不是一层，而是三级纵向联动，逐级细化、双向反馈：

flowchart TD
  S1["S1 集团主计划层（S&OP / 月·周粒度）<br/>订单→工厂分配 · 产能平衡 · 大宗物料计划"]
  S2["S2 工厂主排产层（MPS / 周·日粒度）<br/>订单→产线 · 交期承诺 · 齐套/产能校验"]
  S3["S3 车间工序排程层（详细排程 / 班次·分钟粒度）<br/>工单→工位/设备/班组 · 换线优化 · 冻结窗口"]
  S1 -- "分配结果=下层边界约束" --> S2
  S2 -- "产线计划=下层边界约束" --> S3
  S3 -- "不可行/超载反馈" --> S2
  S2 -- "产能缺口反馈" --> S1

级	决策对象	时间粒度	主引擎	对应现原型
S1 集团主计划	订单分配到工厂	月/周	MILP 产能平衡 + 需求预测（ML）	无（新增）
S2 工厂主排产	订单分配到产线、交期承诺	周/日	CP-SAT / HYBRID	`runScheduling` 的选线逻辑
S3 车间工序排程	工单落到工位/班次/时刻	班次/15分钟	CP-SAT 详排 + 规则快排	`placeWorkOrder`/`findSlot`

联动机制（硬规则）：

下行：上层输出冻结为下层的边界约束（S1 分配的工厂不可在 S3 更改）。
上行：下层求解不可行（如 S3 发现工位超载）时，生成结构化"反馈单"回流上层，触发上层局部重排——而不是下层自行突破约束。
锚定：每级有独立冻结窗口（S1 按周冻结、S2 按天、S3 按班次），越靠近执行越冻结。
三级与 §10.2 跨部署策略共享的"集团→工厂→车间"组织三级一一对应，策略与排程同构下沉。

本土化服务承诺（已决策 ✅）：中文自然语言语料与术语库（工业口语如"插单/压单/让产/赶工"）、信创环境适配（麒麟/统信/国产算力）、驻场实施与计划员陪跑、按客户现场沉淀专属规则库与偏好模型（数据不出厂）。

9.2 求解流程（管线抽象）

flowchart LR
  A["① 取数<br/>订单+主数据"] --> B["② 齐套/资源预检"]
  B --> C["③ 构建约束模型"]
  C --> D["④ 求解<br/>(引擎可插拔)"]
  D --> E["⑤ 冲突检测"]
  E --> F["⑥ KPI + 交期承诺"]
  F --> G["⑦ 证据链归档"]

9.2a 约束体系（Constraint System）：排产约束的定义与配置

回答"系统里排产时已知的约束条件有哪些、怎么定义、怎么配置"。约束不散落在算法代码里，而是收敛为约束注册表：每条约束有类型、来源、参数化定义与启停配置，构建约束模型（§9.2 ③）时按注册表装配。

9.2a.1 约束目录（两级分类：硬约束不可违反，软约束进目标函数）

#	约束	硬/软	数据来源	定义要点	现状
C1	工艺先后序	硬	工艺路线表（routing.sequenceNo）	工序 i 完成才能开工序 i+1（prec）	✅ M1
C2	工位/设备独占	硬	工位表 + 占用登记	同一工位同一时刻只能一个工单（NoOverlap）	✅ M1
C3	班次日历	硬	班次表 + 工厂日历（含节假日）	工单只能落在可用班次时段内	✅ M1
C4	设备维保窗口	硬	设备维保计划表	维保时段不可排产（与 C3 合成可用窗口）	✅ M1（冲突检测）
C5	机器资格	硬	产品-产线适配表（M_j）	工序只能在具备资格的候选产线/工位上	✅ M1
C6	物料齐套（释放时间）	硬/软可配	BOM + 库存 + 在途（WMS）	齐套时刻 = 工单最早开工时刻 r_j；缺料可配"阻塞"或"带风险排入+冲突标记"	✅ M1（PASSED/PARTIAL/FAILED 三态）
C7	产线日产能上限	硬	产线表（日可用分钟 × 效率系数）	单日占用分钟 ≤ 上限	✅ M1（超载冲突检测）
C8	订单交期	软	销售订单表（deliveryDate）	违反产生延期 T_j，进目标函数加权惩罚	✅ M1
C9	客户优先级/VIP	软	客户表（level）+ 订单优先级（priority）	排序权重与延期权重 w_j 的来源	✅ M1
C10	换线时间（顺序依赖）	软	换线矩阵（产品族 × 产品族，s_ijk）	相邻工单换型耗时进工时与成本	🔜 M5（换线矩阵入库）
C11	冻结窗口	硬	排程配置（按 S1 周/S2 天/S3 班次）	窗口内已发布工单不可移动（§9.1b 锚定）	🔜 M4
C12	班组/工装等累积资源	硬	班组表/工装台账	同时占用量 ≤ 资源容量（Cumulative）	🔜 M5
C13	企业 SOP 规则	硬/软可配	知识资产（§8.1，如"16:00 后不换线"）	由 SOP 条文转译为结构化约束，审批入库生效	🔜 M4（知识→约束编译）

9.2a.2 约束的定义形态（ConstraintDef）

# 约束注册表条目：每条约束自描述，构建约束模型时按此装配
class ConstraintDef(BaseModel):
    constraint_id: str            # 约束 ID（如 "calendar_shift"）
    kind: Literal["hard", "soft", "configurable"]  # 硬/软/可配置
    scope: dict                   # 作用域：工厂/产线/产品族/订单类型（支持逐产线差异化）
    params: dict                  # 参数（如缓冲小时数、缺料策略、权重）
    source: str                   # 数据来源表/知识资产 ID（血缘可追）
    enabled: bool                 # 启停开关（试排时可临时关某条软约束做 what-if）
    power: str                    # 修改此约束的权力等级（硬约束改动=P2）

9.2a.3 配置的三个入口（谁在什么地方改约束）

主数据即约束（C1-C7）：工艺路线/班次/BOM 这类约束跟着主数据走，改主数据即改约束——入口是数据导入管线（§8.4）与 MCP 同步（§7），带血缘与审计。
配置中心（C8-C11 的参数与开关）：目标权重、交期缓冲比、缺料策略、冻结窗口时长在设置中心"排产策略"页配置；任何影响排产结果的参数变更是 P2 写操作（§9.8 业务参数行），需确认并可回滚。
知识资产转译（C13）：企业 SOP 以自然语言入知识库 → LLM 提议结构化 ConstraintDef → 人工审批 → 生效进约束注册表。LLM 只有提议权，约束生效必须过门禁（§3.2 铁律在约束域的投影）。

对话即配置：计划员说"这次先不管物料，强排一版看看"→ 意图解析为临时禁用 C6（沙盒内，P1）；说"以后周六不排产"→ 生成 C3 日历变更提案（P2 确认卡）。

9.2b 主控参数识别（Dominant Constraint Identification）

回答"这么多约束里，系统如何筛选出主控参数"。主控参数 = 当前实例中真正卡住目标的少数紧约束。识别不靠拍脑袋，而是三个互补的计算通道：

通道	方法	输出	开销
① 紧约束/瓶颈分析（求解器视角）	CP-SAT 解的关键路径回溯（哪些工单首尾相接无松弛）；MILP 松弛问题的对偶值/影子价格（哪条产能约束的对偶价最高）；资源利用率排序（利用率 >90% 的产线即候选瓶颈，Shifting Bottleneck 思想 §9.5.5）	瓶颈资源清单 + 每条约束的"绑定程度"	随求解免费产出
② 敏感性排序（扰动视角，§9.9）	Tornado 单因子扰动：逐个放松/收紧约束参数（产能 +10%、交期 +1 天、缺料提前 1 天…）各跑一次沙盒重排，按 KPI 改善幅度排序	因子影响力排行（龙卷风图）	每因子 2 次仿真
③ 冲突归因（不可行视角）	排产冲突按约束类型聚类统计（本版本 60% 冲突来自 C7 产线超载）；CP 不可行时提取最小不可行子集（IIS）直接点名"是这几条约束互相打架"	冲突→约束的归因表	冲突检测免费；IIS 需额外求解

产出与用法：三通道结果合成"主控参数卡"（UI 块），用计划员语言回答——"这版计划卡在 L001 产能（利用率 97%，影子价最高）和华为订单交期（关键路径全程无松弛）上；放松其一可减延迟 32h"。主控参数随每版排产动态更新（换一批订单，瓶颈可能从产能漂到齐套），并作为 §9.9 敏感性分析的优先扰动对象与 §9.8 参数调优的优先调整对象——形成"识别 → 验证 → 调整"的闭环。

9.3 KPI 与交期承诺

沿用原型指标（totalTardiness / avgUtilization / totalCost / conflictCount）并补齐 PPT 强调的交期承诺看板：按订单输出"承诺完成时间 / 达成概率 / 风险等级"，作为独立 due-board UI 块。

9.4 每个代码模块的"重生能力"（Regenerable Modules）

要求：每个功能模块都能被重新生成/替换，而不破坏系统。 落地机制：

契约先行：每个模块（引擎、插件、UI 块渲染器、RAG 组件）只暴露稳定接口 + JSON Schema，实现可整体替换。
元数据自描述：每个模块带 moduleManifest（下），记录接口版本、输入指纹、测试用例。
重生流水线：重生 = 读 manifest → LLM/工程师生成新实现 → 跑门禁 harness 的模块级验收（golden test）→ 通过则灰度替换 → 失败则回滚。
黄金测试集：每个模块自带一组"输入→期望输出"用例，重生后必须全绿才允许上线。

// 模块清单：让模块可被安全"重生"
interface ModuleManifest {
  moduleId: string;                 // 模块 ID
  kind: 'engine'|'plugin'|'ui-block'|'rag'|'domain'; // 模块类别
  interfaceVersion: string;         // 接口版本（语义化）
  contractSchema: object;           // 输入/输出契约（JSON Schema）
  goldenTests: string[];            // 黄金测试用例路径
  regen: {                          // 重生策略
    strategy: 'llm' | 'manual' | 'hybrid'; // 谁来重生
    maxAttempts: number;            // 最大尝试次数（超则转人工）
    canaryPercent: number;          // 灰度比例
  };
}

9.5 算法库（Algorithm Library）

算法不散落在代码里，而是收敛为一个带注册表的算法库：每个算法是一个可重生模块（§9.4），带契约、黄金测试与适用边界声明。LLM/编排器按"选型决策表"取用，而不是自由发挥。

9.5.1 算法目录（五大类）

类别	算法	用途	适用边界
A. 调度规则/构造启发式	EDD（最早交期）、SPT/LPT（最短/最长加工）、CR（临界比）、ATC（表观延迟成本）、Slack（松弛量）、贪心插入	快速构造初始解、插单快评、派工	毫秒级；解质量一般，作初始解/兜底
B. 精确/近似优化	CP-SAT（约束规划）、MILP（混合整数规划）、LNS/ALNS（大邻域搜索）、禁忌搜索、模拟退火、GA / NSGA-II（多目标遗传）	详细排程求优、S1 产能平衡、多目标权衡	秒~分钟级；规模与时限需匹配（见选型表）
C. ML 预测器	LightGBM/XGBoost（实际工时/换线时间回归）、生存分析（交期达成概率）、时序预测（需求/负荷）、孤立森林（报工异常检测）	把 OR 的输入参数估准（§9.1a 铁律）	需历史数据；输出必带置信区间
D. 优化辅助	代理模型（GP/随机森林响应面）、贝叶斯优化（超参调优）、帕累托前沿提取	插单影响秒级预估、算法参数自动调优、方案集多样性	代理模型结论需全精度复核（PPT P16 原则）
E. 敏感性/鲁棒性	OAT 单因素扰动、Tornado 龙卷风分析、蒙特卡洛情景模拟、Sobol 全局敏感性	方案鲁棒性评估、瓶颈识别（§9.9）	批量仿真开销大，跑在 Explore 沙盒

9.5.2 算法注册表（AlgorithmManifest）

# 算法注册表条目：每个算法自描述，编排器据此选型与调用（Python，已决策）
class AlgorithmManifest(BaseModel):
    algo_id: str                  # 算法唯一 ID，如 "cp_sat_detail_v2"
    category: str                 # 类别 A/B/C/D/E（对应上表）
    scale_limit: str              # 适用规模声明，如 "<=50k 工单"
    time_budget: str              # 典型时限，如 "5s~5min"
    input_schema: dict            # 输入契约（JSON Schema）
    output_schema: dict           # 输出契约（含证据字段）
    golden_tests: list[str]       # 黄金测试用例路径（重生验收）
    deterministic: bool           # 是否确定性（GA/SA 需固定随机种子才可复现）
    regen_strategy: str           # 重生策略：llm / manual / hybrid

9.5.3 选型决策表（编排器/LLM 的取用依据）

场景	规模	时限要求	推荐算法链
插单影响快评	任意	< 1s	代理模型预估 →（用户要精确时）规则试排
对话中试排	≤ 5k 工单	< 30s	规则构造初始解 → CP-SAT 局部优化（HYBRID）
日/周滚动排产	≤ 50k 工单	< 5min	CP-SAT + LNS，超时输出当前最优可行解（anytime）
多目标权衡探索	中等	分钟级	NSGA-II 输出帕累托解集 → 方案卡（§9.7）
S1 集团产能平衡	工厂级聚合	分钟级	MILP（月/周桶粒度）
鲁棒性压测	按需	后台批量	蒙特卡洛 × 规则快排（沙盒并行）

9.5.4 排产问题的数学形式化（Formal Problem Definition）

我们面对的问题在调度理论中的标准刻画（Graham 三元组记号 α|β|γ，Graham, Lawler, Lenstra & Rinnooy Kan, 1979）：

FJc | s_{ijk}, prec, calendars, M_j, rj | ΣwjTj（主）+ 多目标 柔性作业车间（FJSP：工序可在多台候选机器/产线上加工）+ 顺序依赖换线时间 s_{ijk} + 工艺先后序 prec + 班次日历 calendars + 机器资格 M_j + 释放时间 rj（物料齐套时刻），主目标为总加权延期 ΣwjTj。

复杂度定位（为什么必须"分层+启发式+时限"）：

J2||Cmax（两机作业车间）已是 NP-hard（Garey, Johnson & Sethi, 1976）；单机 1||ΣwjTj 同为 NP-hard（Lawler, 1977；Lenstra, Rinnooy Kan & Brucker, 1977）。我们的 FJSP 是其严格超集——不存在多项式精确算法，工程上必须接受 anytime 近优解 + 时限预算，这正是 §9.5.3 选型决策表的理论依据。

MILP 析取式建模（disjunctive formulation，Manne, 1960）——用于 S1/S2 与基准校核：

决策变量：
  S_i ≥ 0              工序 i 的开始时间（连续变量）
  x_{im} ∈ {0,1}       工序 i 是否分派到机器 m（机器资格 M_i 内）
  y_{ijm} ∈ {0,1}      同机器 m 上工序 i 是否先于 j（析取排序变量）
  T_j ≥ 0              订单 j 的延期（tardiness）
约束（节选）：
  (1) Σ_{m∈M_i} x_{im} = 1                       每道工序恰选一台机器
  (2) S_i + p_{im} ≤ S_k                          工艺先后序（i→k ∈ prec，p 为工时）
  (3) S_i + p_{im} + s_{ijm} ≤ S_j + M(3 - x_{im} - x_{jm} - y_{ijm})
                                                  同机不重叠 + 顺序依赖换线（big-M 析取对）
  (4) S_i ≥ r_i；S_i ∈ 班次日历可行时段            释放时间与日历（分段建模或 CP 处理）
  (5) T_j ≥ S_{last(j)} + p_{last(j)} - d_j       延期定义（d_j 为交期）
目标：
  min  w1·Σ w_j T_j + w2·Σ换线成本 + w3·负荷不均衡度 − w4·利用率

CP 区间变量建模（首选，用于 S3 详排）：现代约束规划用 IntervalVar（可选区间）+ 全局约束表达同一问题远比 big-M 高效——NoOverlap（带换线转移矩阵）处理析取，Cumulative 处理班组/工装等累积资源，可选区间天然表达机器柔性（Laborie et al., 2018《IBM CP Optimizer for scheduling》；Google OR-Tools CP-SAT 的 lazy clause generation 机制源自 Ohrimenko, Stuckey & Codish, 2009）。工程铁律：日历/换线/柔性机器一律走 CP 区间模型，MILP 只用于 S1 聚合层与小规模基准校核。

多目标的三种处理方式（按场景选用）：

加权和（默认，权重来自偏好学习 §8.3）——快，但只能触及帕累托前沿凸部；
字典序（如"先保 VIP 零延期，再最小化换线"）——符合计划员决策习惯，CP-SAT 原生支持分阶段求解；
真多目标（NSGA-II 产帕累托解集）——用于 §9.7 方案生成的多样化候选。

9.5.5 经典调度规则与最优性保证（文献依据）

调度规则不是"土办法"，多数有严格的最优性定理——这是算法库 A 类资产的理论出身，也是 LLM 解释"为什么这么排"的证据来源：

规则/算法	最优性保证	文献	在本系统的用途
Johnson 法则	`F2		Cmax` 两机流水线精确最优
EDD 最早交期	单机 `1		Lmax` 最优（Jackson 定理）
Moore-Hodgson	单机最小化延期订单数精确算法 O(n log n)	Moore, 1968	"尽量少违约几张单"场景
WSPT 加权最短加工	单机 `1		ΣwjCj` 最优（Smith 法则）
ATC 表观延迟成本	ΣwjTj 的高质量启发（k 参数可调）	Vepsäläinen & Morton, 1987	综合策略默认派工规则
MDD / COVERT	延期类目标经验最优规则族	Baker & Bertrand, 1982	规则引擎备选
NEH	置换流水线 `Fm		Cmax` 最强构造启发
Shifting Bottleneck	作业车间经典分解：逐台机器解 `1	rj	Lmax` 子问题
CR 临界比 / Slack	无最优保证的经验规则	工业实践	快评与解释性展示

9.5.6 元启发式与现代求解（文献依据）

方法	关键文献	本系统落点
禁忌搜索 TS	Nowicki & Smutnicki, 1996/2005（i-TSAB，JSP 长期标杆）；关键在 N7 邻域（关键路径块移动）	LNS 内层改进算子
模拟退火 SA	Kirkpatrick et al., 1983；van Laarhoven et al., 1992（JSP 应用）	轻量改进备选
遗传算法 GA	Cheng, Gen & Tsujimura, 1996（JSP 编码综述：工序序列 + 机器分派双染色体）	GA 引擎主体
NSGA-II	Deb et al., 2002（快速非支配排序 + 拥挤距离）	多目标方案生成（§9.7）
LNS / ALNS	Shaw, 1998；Ropke & Pisinger, 2006（自适应算子权重）	CP-SAT + LNS 是主力组合：破坏算子=释放某产线/某时窗/某订单簇，修复=CP-SAT 子问题重排（天然利用增量性）
CP-SAT	Ohrimenko et al., 2009（lazy clause generation）；OR-Tools 团队工程实现	S3 详排主引擎
分层生产计划 HPP	Bitran & Hax, 1977（聚合→分解的层级规划理论）	三级联动排程（§9.1b）的理论基础：S1 聚合规划的可行性由"产能预留 + 下层反馈"保证
滚动时域	MPC 式 rolling horizon + 冻结窗口	滚动排产 + 冻结窗口（§9.1b 锚定规则）
DRL 派工（研究线）	Zhang et al., NeurIPS 2020（L2D：GNN + PPO 学派工规则，析取图表征）	仅列为研究储备，不进生产——不可解释且无可行性保证，违反 §9.1a 铁律；可用于离线生成派工规则候选，经黄金测试后以"规则"形态入库

ML 侧文献锚点：LightGBM（Ke et al., 2017）做工时/换线回归；生存分析（Cox, 1972 比例风险）+ 保形预测（Vovk et al.；Angelopoulos & Bates, 2023 综述）给交期达成概率一个有覆盖率保证的区间（写进交期承诺函的是区间而非拍脑袋点估计）；贝叶斯优化（Snoek, Larochelle & Adams, 2012）调算法超参；Sobol 全局敏感性（Sobol, 1993；Saltelli, 2002 高效估计）；偏好权重反推属逆优化（Ahuja & Orlin, 2001）。

9.5.7 HYBRID 主管线（组合策略的落地形态）

flowchart LR
  A["ATC/EDD/NEH<br/>构造初始解<br/>(毫秒级, 9.5.5)"] --> B["CP-SAT 全模型<br/>warm start 热启动<br/>(时限 T1)"]
  B --> C["LNS 循环改进<br/>破坏: 产线/时窗/订单簇<br/>修复: CP-SAT 子问题<br/>(时限 T2, anytime)"]
  C --> D{"需要多目标?"}
  D -->|是| E["NSGA-II 围绕现解<br/>产帕累托解集 → 方案卡"]
  D -->|否| F["输出 + 全精度校核<br/>+ 证据链归档"]
  E --> F

每一步的输出都带下界/间隙报告（CP-SAT 可报告 objective bound）：向计划员解释"当前解距理论最优至多差 X%"——这是把数学上的 optimality gap 变成业务上的信任。

9.6 意图识别（Intent Recognition）

意图识别是"左说右动"链路的第一环，产出 L0 意图层 Plan。两级管线：

flowchart LR
  T["用户输入<br/>(文本/语音转写)"] --> R["一级：规则快路<br/>词表+正则，<10ms<br/>（POC 已验证）"]
  R -->|命中| CMD["直接产出命令"]
  R -->|未命中/低置信| L["二级：LLM 语义解析<br/>意图分类+槽位填充<br/>JSON Schema 强校验"]
  L --> CONF{"置信度"}
  CONF -->|">0.85"| CMD2["产出 L0 Plan"]
  CONF -->|"0.5~0.85"| ASK["澄清确认<br/>（复述理解请用户确认）"]
  CONF -->|"<0.5"| REJ["拒识<br/>（列出可选意图）"]

意图分类体系（一级分类 × 权力等级）：

意图大类	子意图示例	权力	产出
查询 query	KPI / 订单状态 / 负荷 / 知识问答	P0	回答 + UI 块
视图 view	切换 / 过滤 / 聚焦 / 高亮 / 缩放	P0	ViewportCommand
试排 explore	试排 / what-if / 方案对比	P1	沙盒方案
调整 adjust	挪工单 / 改优先级 / 冻结锁定	P1 草稿 → P2 提交	变更草稿
发布 commit	发布版本 / 下发工单	P2/P3	门禁确认卡
分析 analyze	敏感性 / 瓶颈 / 插单影响评估	P0/P1	分析 UI 块
报告 report	日报 / 版本对比 / 交期承诺函	P0	报告文档
配置 config	改权重 / 规则 / 自动化档位	P2	配置变更确认
拒识 fallback	闲聊 / 越权 / 语义不明	—	澄清或礼貌拒绝

槽位（Slot）设计：每个意图声明必填/可选槽位（策略、范围、时间窗、约束开关、订单引用…），缺槽走多轮追问而非猜测。

上下文继承与指代消解：意图解析必须携带会话上下文——"把它再提前一天"中的"它"解析为上一轮方案中被讨论的工单；"和刚才那版比一下"解析为会话树中最近的方案分支（§12.3 会话引用）。

本土化词表：内置工业口语词典（插单/压单/让产/赶工/甩单/爆产能…）作为一级快路与 LLM few-shot 语料，按客户现场持续扩充（知识资产）。

9.6a 意图预测与主动引导（Proactive Guidance）

好的助手不只听懂指令，还能揣测下一步、在关键处主动引导——但主动性必须有边界，否则变成打扰。

9.6.1a 三种主动形态（由轻到重）

形态	载体	示例	打扰度
续写建议	输入框幽灵文本 + 对话尾部建议椽（chips）	刚看完冲突列表 → 椽显示"生成解决方案""只看致命冲突""导出冲突报告"	零打扰（可无视）
时机性提示	视口内联气泡 / 状态条黄点	拖拽某工单三次未落成 → "这条工单受维保约束，要我帮你找可行时段吗？"	低（单次，可关闭）
主动预警	对话内智能体主动发言（带原因）	房间自动化发现缺料将影响 VIP 订单 → 主动播报 + 附重排建议	中（仅限订阅的事件类型）

9.6.2a 预测的依据（不靠猜，靠信号）

下一步建议由轻量意图转移模型产生，输入信号包括：

会话状态机：意图分类（§9.6）天然构成状态转移图——"试排完成"后的高频后继是"看冲突/对比方案/发布"，直接由历史转移频率给出 Top-3；
视口上下文：用户正盯着什么（当前视图/过滤/选中的工单）决定建议的宾语——看着超期高亮时建议"生成赶工方案"而非泛泛的"执行排产"；
个体习惯：按用户累积的操作序列做个性化重排（计划员 A 习惯先看热力图，B 习惯先看交期看板）；
业务日历：周一早上建议"生成上周复盘报告"，月末建议"下月主排产"（房间自动化的软提醒形态）。

9.6.3a 引导式补全（把新手带成熟手）

槽位引导：口令缺参数时不是报错，而是给出可点选的补全卡（"试排一版——用哪个策略？[交期优先] [产能均衡] [综合]"），点选即补全，同时教会用户完整口令。
空态引导：新会话/空视口给"你可能想做"的三件事（基于项目状态：有未处理冲突→引导处理；无版本→引导首排）。
教学时刻：用户用鼠标点了三次菜单完成的事，提示一次"下次可以直接说『只看VIP订单』"（同类提示每场景最多一次，可全局关闭）。

9.6.4a 主动性的边界（硬规则）

主动建议永远是建议：形态上只产生 P0/P1 动作入口，绝不代用户执行 P2/P3（与自动化档位 §5.3 正交——G3/G4 的自动执行走房间自动化的显式授权，不走"揣测"）。
预测信号只用本产品内行为数据，按用户可关（设置内"智能建议"开关分三档：全开/仅续写/全关）。
每条主动发言必须自带解释（"我提醒你是因为：缺料事件 E1023 影响了 VIP 订单 SO...002"），且计入审计（§3.6 会话类）。
建议被采纳/忽略本身是偏好信号，回流意图转移模型（§8.3 同一学习闭环）。

9.7 方案生成（Solution Generation）

一次"试排"不应只给一个答案，而是产出一组可对比的候选方案组合：

flowchart LR
  IN["L1 策略层输入<br/>(目标+约束+范围)"] --> GEN["并行生成<br/>多策略 × 多引擎"]
  GEN --> S1["方案A：交期优先"]
  GEN --> S2["方案B：产能均衡"]
  GEN --> S3["方案C：成本最优"]
  GEN --> S4["方案D：NSGA-II 帕累托点"]
  S1 & S2 & S3 & S4 --> RANK["排序与去重<br/>(用户偏好权重 §8.3)"]
  RANK --> CARDS["方案卡组 ScenarioCards<br/>推送 UI + 各自沙盒分支"]

方案卡（ScenarioCard）——方案的标准交付物，对应 UI 块 scenario-cards：

# 方案卡：一个候选排产方案的完整摘要（推给 UI 供计划员对比选择）
class ScenarioCard(BaseModel):
    scenario_id: str              # 方案 ID（同时是沙盒分支 ID —— 方案即分支）
    label: str                    # 人类可读名，如"交期优先·不加班"
    strategy: dict                # 生成该方案的 L1 策略（引擎/权重/约束开关）
    kpi: dict                     # KPI 组：延迟/利用率/成本/冲突数/换线次数
    acceptance: list[dict]        # 对照 L0 验收标准的逐项达成情况（§6.6）
    diff_vs_baseline: dict        # 相对基准（当前已发布版本）的差异摘要
    risks: list[str]              # 风险提示（如"依赖周六加班班次"）
    robustness: float | None      # 鲁棒性评分（若已跑敏感性分析 §9.9）
    evidence_refs: list[str]      # 证据链引用

硬规则：

每个方案 = 一个 Explore 沙盒分支（§4.1），选中即切换分支，丢弃即删枝——方案生成天然接入会话树。
方案组必须多样化（策略维度或帕累托前沿上彼此支配不了），禁止输出四个大同小异的方案凑数。
每张方案卡必须逐项回答 L0 验收标准（达成/未达成/超额），让计划员"看验收选方案"而非凭感觉。

9.7a 最优方案优选（Solution Ranking & Selection）

回答"最终怎么从多个可行方案里优选出最优解、用什么求解算法思路"。分两层：单方案内求优（求解器的事）与多方案间优选（评分与人的事）。

第一层：单方案内，求解器怎么逼近最优

求解算法思路即 §9.5.7 HYBRID 主管线：调度规则构造初始解（ATC/EDD/NEH，毫秒级）→ CP-SAT 全模型热启动求优（时限 T1）→ LNS 大邻域循环改进（破坏某产线/时窗/订单簇 → CP-SAT 子问题修复，anytime）→ 需要多目标时 NSGA-II 产帕累托解集。因为 FJSP 是 NP-hard（§9.5.4），追求的不是数学全局最优，而是时限内的近优解 + 可证明的间隙——CP-SAT 输出 objective bound，能向计划员报告"当前解距理论最优至多差 X%"。

第二层：多方案间，怎么优选出"该采纳的那个"

flowchart LR
  A["候选方案组<br/>(§9.7 多策略×多引擎)"] --> F1["① 硬过滤<br/>违反硬约束/L0验收红线者出局"]
  F1 --> F2["② 帕累托筛<br/>被其他方案全面支配者出局"]
  F2 --> F3["③ 加权评分排序<br/>score = Σ wk·KPIk^norm<br/>权重来自偏好学习 §8.3"]
  F3 --> F4["④ 鲁棒性并列<br/>蒙特卡洛评分 §9.9<br/>'稳'与'快/省'并列展示"]
  F4 --> H["⑤ 人最终拍板<br/>方案卡对比 → 采用(P1)<br/>推荐≠代替决策"]

评分函数与三种多目标处理方式（加权和/字典序/真多目标，§9.5.4）对应：默认加权和给排序，客户有"VIP 绝不迟交"这类硬偏好时切字典序（先保零延期再比换线），探索型对比用 NSGA-II 帕累托解集让计划员看清权衡面。硬规则：系统只做"推荐 + 理由"（推荐徽章 + 逐项 KPI 与验收对照），采纳永远是人的 P1/P2 动作——这是 §3.2 权力边界在方案域的投影。评分权重的每次变更走 §9.8 业务参数通道（P2、版本化、可回滚）。

9.8 参数优化（Parameter Optimization）

三层参数、三种调法，全部版本化、全部过门禁：

层	参数示例	调优方式	频率	权力
算法超参	CP-SAT 时限/线程、LNS 邻域大小、GA 种群/代数	贝叶斯优化离线调（以黄金算例集为基准）	版本级	P1（离线）+ P2（生效）
业务参数	目标权重（延迟/成本/利用率/均衡）、交期缓冲比、冻结窗口时长、插单策略	偏好学习在线微调（§8.3 从人工调整 diff 反推）+ 用户显式设置	周级/事件级	P2（影响排产结果，需确认）
模型参数	ML 预测器（工时/交期概率）再训练	定期重训 + 漂移检测触发（预测误差超阈值自动告警）	月级/漂移触发	P1 训练 + P2 上线

调优闭环：候选参数 → 黄金算例集回放评测（KPI 对比）→ 门禁审批（参数变更=配置写操作 P2）→ 灰度生效（先单产线）→ 全量。任何参数变更留存前后对照证据，可一键回滚到上一参数版本。

9.9 敏感性分析（Sensitivity Analysis）

回答计划员最关心的问题："这个方案抗不抗折腾？哪里是瓶颈？"

扰动因子库（可配置、可扩充）：

因子	扰动方式	现实来源
订单量波动	±10%/±20% 数量	客户改单
工时偏差	实际工时 = 标准 × N(1, σ)（σ 取自 ML 预测残差）	报工数据
设备故障	随机停机 2~8h	TPM 历史故障率
缺料延误	在途到货推迟 1~3 天	WMS 历史准时率
插单冲击	注入 1~3 张紧急单	历史插单频率
人员缺勤	班组产能 × 90%	考勤数据

方法矩阵（由浅入深、按需取用）：

方法	回答的问题	开销	输出 UI 块
What-if 单因素（OAT）	"如果 L001 周三坏 4 小时会怎样？"	单次沙盒重排，秒级	对比甘特 + KPI diff
Tornado 分析	"哪个因子对交期影响最大？"	每因子 2 次仿真	龙卷风图
蒙特卡洛情景	"这版计划的交期达成概率分布？"	数百次沙盒仿真（后台并行）	概率分布 + 鲁棒性评分
Sobol 全局敏感性	"因子交互效应？"（高级）	大批量仿真	敏感性指数表

鲁棒性评分：robustness = 蒙特卡洛情景下验收标准仍全部达成的比例，回填到方案卡（§9.7），让"稳"成为和"快/省"并列的选型维度。

执行位置：全部跑在 Explore 沙盒（P1，批量并行、不触主干）；分析结论 + 输入快照进证据链。

9.10 报告生成（Report Generation）

把排产结果变成面向不同受众的可交付文档，全程带证据引用：

报告类型	受众	触发	内容要点
排产日报	车间/计划	定时（房间自动化）	今日计划、变更、冲突、齐套风险
版本对比报告	计划主管	发布新版本时	新旧版本 KPI diff、受影响订单清单
交期承诺函	销售/客户	按订单请求	承诺完成时间、达成概率、依据摘要
插单影响评估	计划/销售	插单请求时	可行方案组、对存量订单的影响、代价
周复盘报告	管理层	定时	计划达成率、偏差归因、改善建议（PPT P10 ⑧Agent 复盘）
敏感性分析报告	计划工程师	分析完成时	因子排序、鲁棒性、瓶颈与建议

生成管线：数据快照（冻结口径）→ 结构化章节模板 → LLM 叙事润色（只许引用快照数据，禁止编造数字）→ 证据链脚注 → 人工审阅（对外文档强制）→ 导出。

硬规则：

报告中每个数字必须可溯源到快照字段（LLM 只做"叙事"，不做"算数"）。
导出格式：Markdown（默认）/ docx / PDF / 飞书云文档（经 MCP 插件）。
报告本身入知识资产库，成为后续 RAG 与复盘的语料。
对外报告（交期承诺函）必须人工审批后才可发出（P2）。

9.11 插单响应与动态重排（Rush Order & Dynamic Rescheduling）

回答"紧急订单进来时，系统怎么重新评估负荷与齐套、快速调整排程；做全量重排还是局部优化"。核心答案：先秒级评估，再按影响半径选修复策略——默认局部修复，触发条件才全量重排。

9.11.1 插单响应管线（三阶段，时间预算递增）

flowchart LR
  RO["紧急订单进入<br/>(对话/MCP事件)"] --> A["阶段① 秒级快评 <1s<br/>负荷重估+齐套核查+代理模型预估"]
  A --> B{"影响半径判定"}
  B -->|"局部(默认)"| C["阶段② 局部修复 <30s<br/>LNS: 只解冻受影响时窗/产线<br/>其余排程冻结不动"]
  B -->|"越界"| D["阶段③ 全量重排 分钟级<br/>HYBRID 主管线(9.5.7)<br/>需计划员确认后才跑"]
  C & D --> E["插单影响评估卡<br/>方案组+代价+存量订单影响"]
  E --> F["人工选择方案<br/>发布走 P2 门禁"]

阶段①（秒级快评，P0 只读）：

负荷重估：目标时窗内逐产线算 占用分钟/可用分钟（可用分钟 = 班次日历 − 维保 − 冻结工单占用，即 C3/C4/C11 合成），得出"哪条线还有多少真实余量"。
齐套核查：按 BOM 展开物料需求，对照 库存 + 在途（含到货时间） 三态判定（PASSED/PARTIAL/FAILED，C6 现成逻辑）；缺料直接给出"最早齐套时刻"= 插单最早可开工时间。
影响预估：代理模型（§9.5 D 类）用瓶颈余量/交期裕量分布等特征秒级预估"挤掉谁、延多久"，不跑真排产——给计划员一个"值不值得继续"的即时体感。

9.11.2 局部修复 vs 全量重排的决策规则（可配置的判定表）

判定维度	局部修复（默认）	升级为全量重排
受影响订单数	≤ N 张（默认 5）	> N 张
瓶颈状态	插单产线利用率 < 95%	插单落在瓶颈线且已 ≥95%（挤压连锁传导）
交期红线	无 VIP 订单被挤破交期	任一 VIP/合同红线订单将违约
齐套	物料齐套或短期可齐	需改采购/调拨计划（跨域影响）
冻结窗口	不触碰冻结工单	必须动冻结工单（本身即 P2 审批事项）

局部修复的算法形态：即 §9.5.6 的 LNS——把"受影响时窗 × 受影响产线"内的工单解冻为子问题，其余全部固定为硬约束，CP-SAT 重排子问题（规模小所以快）。这天然保证"改动最小化"：计划员看到的 diff 只有十几个工单挪动，而不是整张甘特图重画。全量重排是 P2 级动作：影响面大，必须出确认卡（"将重排 N 单/涉及 M 条产线"），且重排前自动建 Checkpoint（§4.3）。

9.11.3 交付物：插单影响评估卡（§9.10 报告类型第 4 行的 UI 化）

方案组通常三张卡：A 顺排（不动存量，插单交期 X 日）/ B 局部让产（挤 2 张普通单各延 1 天，插单按期）/ C 加班扩容（周六加班 4h，全部按期，成本 +¥Y）——每卡带对存量订单的影响清单与代价，计划员选卡即选策略，发布走 P2。M1 已落地的沙盒对比（§9.7）是这个能力的底座；MCP 事件触发的自动插单快评在 M4 房间自动化（§6.5）接入。

10. 状态、提交语义与跨部署策略共享

10.1 状态与提交语义（Commit Semantics）

借鉴 Git，但强制"对话+世界"成对：

概念	含义
Working（工作区）	当前分支的沙盒态，Explore 通道在此涂改
Staged（暂存）	通过门禁确认卡、等待写入的方案
Commit（提交）	经 Runtime 通道落主干世界状态 + 外部下发，生成 Checkpoint
Branch（分支）	一次探索，成对状态派生
Revert（回滚）	回到某 Checkpoint，成对恢复对话与世界
Merge（合并）	把探索分支的方案合入主干（需门禁 + 冲突消解）

提交是事务性的：世界状态写入与外部 MCP 下发要么全成功，要么整体回滚（Saga/补偿模式，因外部系统未必支持分布式事务）。

同一集团多工厂/多车间部署时，"排产策略、规则、偏好权重、知识资产"应可跨部署点共享与继承：

flowchart TD
  G["集团策略库（中央）<br/>通用规则/算法知识/模板"] --> F1["青岛工厂<br/>覆盖+本地规则"]
  G --> F2["合肥工厂<br/>覆盖+本地规则"]
  F1 --> L1["一车间<br/>产线级微调"]
  F1 --> L2["二车间"]

继承 + 覆盖：集团级默认 → 工厂级覆盖 → 车间/产线级微调（三级）。
策略即数据：策略/规则/权重/自动化档位都是版本化数据对象，可导出/导入/同步。
隔离性：某部署点的世界状态严格隔离；仅"策略与知识"可共享，业务数据不出厂（私有化）。

11. 技术选型与形态

11.1 技术栈

层	选型	理由
前端框架	React + TypeScript + Vite	组件化、UI 块协议易实现、生态成熟
可视化	甘特（自研 Canvas / 或 DHTMLX-Gantt）、ECharts（负荷/看板）、three.js（3D 车间可选）	现原型已用原生 Canvas，可平滑升级
桌面端	Electron（`apps/desktop`，electron-builder + NSIS，Sidecar 随包分发）✅已实现	可离线私有化、一套前端双形态；Tauri（Rust 壳）列为备选（体积更小），迁移需另行立项
Web 端	同一前端代码，浏览器直出	一套代码双形态（对应 PPT P20 容器化交付）
Gateway/BFF	Python (FastAPI) ✅已决策（与 Agent Core 同栈）	SSE 会话流、HTTP API、Session 管理，全栈 Python 降低维护成本
Agent Core	Python ✅已决策	算法生态（OR-Tools/ML）与 LLM 编排在 Python 最顺
求解器	OR-Tools(CP-SAT)、DEAP/自研 GA、规则引擎 + LightGBM/sklearn（ML 预测，见 §9.1a）	OR+ML 双轮，多引擎可插拔
向量库	pgvector / Milvus	RAG 检索
关系库	PostgreSQL	世界状态/对话状态/审计
时序库	TimescaleDB / InfluxDB	设备/能耗时序
基座模型	KIMI / DeepSeek（可切换，支持私有化推理）	中文强、成本可控、可内网部署

11.2 模型抽象（可切换 KIMI/DeepSeek）

// 模型 Provider 抽象：屏蔽 KIMI/DeepSeek 差异，支持私有化端点
interface ModelProvider {
  id: 'kimi' | 'deepseek' | 'local';   // 提供方
  endpoint: string;                     // 端点（可私有化）
  supportsToolCall: boolean;            // 是否支持工具调用
  supportsStream: boolean;              // 是否支持流式（SSE）
  contextWindow: number;                // 上下文窗口
  // 统一调用入口：入参与工具/流式解耦
  chat(req: ChatRequest): AsyncIterable<ChatChunk>;
}

11.3 一套代码双形态

前端与 Agent 逻辑不区分形态；差异只在"外壳"与"数据后端地址"。
Web：连远程 Gateway。
Desktop（Electron 壳，Tauri 备选）：可内嵌本地 Gateway + 本地模型端点，实现离线私有化（数据不出厂，对应 PPT P14/P20）。

12. 代码规范（强制）

用户明确要求："每写一行代码都要有注释"。以下为团队铁律。

逐行注释：每一行代码上方或行尾必须有解释其"意图"（不是复述语法）的中文注释。
- 反例：i++ // i 加一（禁止）。
- 正例：i++ // 移到下一个待排工序。
函数头注释：说明目的、入参、出参、副作用、权力等级（P0-P3）。
模块头注释：声明 moduleId / 契约版本 / 是否可重生。
证据可溯：任何产生"结论"的函数必须返回/记录证据引用。
权力标注：涉及写操作的函数必须标注权力等级，并强制走门禁。
类型优先：TS strict 模式；所有跨层数据结构必须有接口定义与 JSON Schema。
可测试：每个可重生模块必须附黄金测试用例。
无魔法数：排产参数（缓冲比、粒度、阈值）集中于配置，禁止硬编码散落。
文档同步（活文档铁律）：以 docs/README.md 大管家为入口；分类文档与代码同轮更新，缺一不得交付——
- 任意功能增删改 / 修缺陷 → 必在 docs/CHANGELOG.md 追加一节（强制模板见大管家 §2.2）；
- 改 _POWER_MAP 或新增需备案 API → 必改 docs/architecture/harness.md；
- 新增/删除/改名带 moduleId 的模块 → 必改 docs/architecture/modules.md；
- 产品能力/业务旅程变更 → 必改 docs/product/features.md 与/或 docs/product/journeys.md；
- 排产规则/冲突/策略语义变更 → 必改 docs/algorithm/scheduling-v1.md。

示例（体现逐行注释 + 权力标注 + 证据）：

/**
 * 发布排产版本到主干世界状态（权力等级 P2：写世界状态，必须经门禁）
 * @param versionId 待发布的排产版本 ID
 * @param ctx       执行上下文（含用户身份、门禁令牌、证据收集器）
 * @returns         发布结果（含 Checkpoint ID 与审计条目）
 * @sideEffect      修改主干世界状态；生成 Checkpoint；写审计
 */
async function publishScheduleVersion(versionId: string, ctx: AgentContext) {
  // 校验门禁令牌，未经 Harness 放行的调用直接抛错（LLM 无执行权）
  ctx.harness.assertApproved(versionId, 'P2');
  // 读取目标版本，确保其存在且处于可发布状态
  const version = await ctx.world.getVersion(versionId);
  // 发布前建立成对 Checkpoint（对话+世界），作为回滚锚点
  const checkpoint = await ctx.snapshot.createPair('publish:' + versionId);
  // 将版本状态置为已发布，并回填发布时间
  version.status = 'PUBLISHED';
  version.publishedAt = ctx.clock.now();
  // 把该版本下的生产订单状态推进为已确认（进入执行准备）
  await ctx.world.confirmProductionOrders(versionId);
  // 记录审计：谁、何时、依据哪条证据、发布了哪个版本
  await ctx.audit.write({ action: 'PUBLISH', target: versionId, evidence: ctx.evidence.refs() });
  // 返回发布结果，供 UI 展示与后续 MCP 下发使用
  return { versionId, checkpointId: checkpoint.pairId };
}

13. 目录结构（Monorepo 建议）

aps-agent/
├─ plan.md                      # 本文档
├─ poc/
│  └─ workbench.html            # "左说右动"验证原型（M-POC，纯静态可直接打开）
├─ apps/
│  ├─ web/                      # Web 前端（React+TS，UI Shell）
│  └─ desktop/                  # Electron 桌面端外壳（复用 web，已实现；Tauri 备选）
├─ packages/                    # 前端 TS 包
│  ├─ ui-shell/                 # 聊天/Workspace/Workflow/文件/3D/插件UI（表现层）
│  └─ ui-blocks/                # UI 块协议渲染器（gantt/due-board/…，每块可重生）
├─ server/                      # Python 后端（✅已决策，全栈 Python）
│  ├─ gateway/                  # FastAPI：HTTP API / SSE / Session / Provider 预处理 / Pi Agent 接入
│  ├─ agent_core/               # Agent session / 模型调用 / 工具底座 / Plan治理 / 门禁 / 双通道 / 证据链
│  │  ├─ intent/                # 意图识别：规则快路 + LLM 语义 + 澄清（§9.6）
│  │  ├─ guidance/              # 意图预测与主动引导：转移模型 / 建议椽 / 引导补全（§9.6a）
│  │  └─ context/               # 会话上下文：四层组装 / 滚动摘要 / 钉住 / 会话引用（§4.7/4.8）
│  ├─ aps_domain/               # 领域：Workflow / 排产工具 / 三级联动排程(S1/S2/S3) / UI 扩展定义
│  │  ├─ scenario/              # 方案生成：多策略并行 / 方案卡组 / 排序去重（§9.7）
│  │  ├─ sensitivity/           # 敏感性分析：What-if / Tornado / 蒙特卡洛（§9.9）
│  │  ├─ tuning/                # 参数优化：三层参数 / 贝叶斯调优 / 灰度生效（§9.8）
│  │  ├─ onboarding/            # 数据上传导入：解析映射 / 校验清洗 / 数据集资产与血缘（§8.4）
│  │  └─ reporting/             # 报告生成：模板 / 快照冻结 / LLM 叙事 / 导出（§9.10）
│  ├─ algolib/                  # 算法库：注册表 + A-E 五类算法实现（§9.5，逐算法可重生）
│  ├─ engines/                  # 排产引擎装配层（rule/cp_sat/ga/hybrid，从 algolib 组装）
│  ├─ knowledge/                # RAG / 向量检索 / 知识资产 / 小样本学习
│  ├─ skills/                   # 技能包：SkillManifest + 编排模板（§6.8，可启停/重生）
│  ├─ multimodal/               # 多模态：ASR / VLM 抽取 / 文件解析 / TTS（§6.7）
│  ├─ mcp_plugins/              # MCP 插件承载（mes/qms/ems/tms/wms/erp）
│  └─ state/                    # 世界状态/对话状态/项目与会话/成对快照/Checkpoint/提交语义
├─ shared/                      # 跨语言契约：JSON Schema（UI块/视口命令/Plan/MCP工具/技能/算法）
├─ config/                      # 分层策略：集团→工厂→车间（跨部署共享）
├─ deploy/                      # 打包部署（§14）：docker/ helm/ sidecar/ offline-installer/ ci/
├─ tests/golden/                # 各模块黄金测试集（支撑重生验收 + 发版门禁）
└─ legacy/aps-frontend/         # 现有原型（作为 UI/算法迁移的参考与素材）

14. 打包与部署规范（Packaging & Deployment）

14.1 构建产物矩阵

形态	产物	构建链	目标环境
Web 端	前端静态包 + 后端容器镜像	Vite build → Nginx 镜像；FastAPI → 多阶段 Dockerfile（含 OR-Tools/ML 依赖）	Docker Compose（单机）/ K8s Helm Chart（集群，对应 PPT P20）
桌面端 Windows	NSIS 安装包（electron-builder）	Electron 壳 + Python Sidecar（PyInstaller 冻结 Agent Core 为单可执行文件，随包分发、随应用启停）	Win10/11，含离线运行
桌面端 macOS/Linux	dmg / AppImage、deb	同上（按平台交叉构建）	含麒麟/统信（ARM64 + x86-64 双架构，信创）
离线一体包	All-in-one 安装介质	桌面包 + 本地模型（可选 DeepSeek 蒸馏版/量化版）+ 向量库 + 种子知识库	无外网车间（数据不出厂）

桌面端进程拓扑：Electron 壳（主进程）→ 启动/守护 Python Sidecar（Gateway+Agent Core 合体，监听 localhost 随机端口）→ 前端连本地端口。Sidecar 崩溃由 Electron 主进程自动重启（进程级"重生"）。

14.2 版本与兼容性规范

语义化版本：主.次.补；四个可独立发版的部件（前端 / 后端 / 算法库 / 知识库 Schema）各自有版本号，安装包声明兼容矩阵。
契约版本：UI 块协议、视口命令集、MCP 工具契约均带 interfaceVersion；前后端握手时校验，不兼容则明确报错而非静默降级。
数据迁移：世界状态/会话树的 Schema 变更必须附迁移脚本（升级前自动全量备份，失败自动回滚）。

14.3 发布流水线（CI/CD）

flowchart LR
  C["提交"] --> L["Lint + 类型检查<br/>(ruff/mypy/eslint/tsc)"]
  L --> T["单元测试 + 黄金测试集<br/>(算法回放评测 §9.8)"]
  T --> B["构建矩阵<br/>(Web镜像 + 各平台桌面包)"]
  B --> S["签名 + SBOM + 漏洞扫描"]
  S --> R["发布通道<br/>dev → beta → stable"]

黄金测试是发版门禁：算法库任一算法黄金测试不过，整条流水线红灯（与 §9.4 重生验收同一套用例）。
代码签名：Windows 包 Authenticode 签名、macOS 公证；私有化客户可用企业自签根证书。
三通道发布：dev（内部）→ beta（试点客户）→ stable；桌面端经 electron-updater 增量更新，私有化环境支持离线升级包（U 盘介质 + 校验和）。

14.4 配置与环境规范

分层配置：默认值 → 集团 → 工厂 → 车间（与 §10.2 策略共享同构），落地为版本化配置文件 + 环境变量覆盖；密钥一律走 OS 凭据库（桌面）/ Secret 管理（K8s），禁止明文入库。
模型端点配置：KIMI/DeepSeek 云端 API、私有化推理端点、本地量化模型三种模式可在设置中切换（对应 §11.2 ModelProvider）。
环境探针：应用启动自检清单（数据库可达/模型端点可用/MCP 插件健康/许可证有效），任一异常在 UI 顶部亮黄条并给出修复指引。

14.5 私有化交付与国产化

交付形态：① 纯桌面单机（演示/小厂）；② 桌面 + 内网服务器（标准）；③ K8s 集群（集团多厂）。
信创适配矩阵：麒麟 OS / 统信 UOS × x86-64（海光）/ ARM64（鲲鹏/飞腾）；OR-Tools 与 ML 库的 ARM 轮子预编译入私仓。
许可证：按"部署点 × 启用技能/插件数"授权（对应 PPT P12"每个智能体独立授权计费"）；离线许可证文件 + 硬件指纹绑定。
审计与合规：按 §3.6 审计体系落地（哈希链 + Merkle 锚定 + WORM 归档 + 职责分离）；支持导出等保 2.0 / ISO 27001 口径的操作留痕报表。

15. 已知实施缺口（非实施计划，仅记录风险/待决）

本节只列"已知还没解决的问题"，不排期，供决策与后续拆解。

真实求解器：CP-SAT / GA 目前在原型是标签；OR-Tools 引入后的性能、私有化许可、国产化算力适配（对应 PPT P20）待验证。
外部系统契约不确定：MES/QMS/EMS/TMS/WMS 各家接口差异大，MCP 插件需按现场逐一适配，事件推送能力不一定具备（可能要轮询）。
分布式事务：跨"内部世界状态 + 多外部系统写入"的一致性只能靠 Saga/补偿，存在中间态窗口，需定义补偿边界。
小样本学习冷启动：初期缺历史 diff 语料，偏好学习收益有限，需人工先注入若干典型规则。
成对状态存储成本：会话树 + 双状态快照在大规模数据下的存储与性能（快照增量化 / 写时复制）待设计。
LLM 可靠性：NL2Plan 的结构化输出稳定性依赖模型能力；KIMI/DeepSeek 工具调用一致性需评测，需强 Schema 校验兜底。
3D 车间渲染：数据来源（车间布局/设备坐标）与实时性尚无确定数据源，列为可选后置能力。
权限模型对齐：Agent 继承用户 RBAC，但各 MOM 系统权限模型不统一，跨系统权限映射待治理。
重生的安全性：LLM 自动重生模块存在引入回归风险，黄金测试覆盖度与灰度回滚策略需持续加固。
多语言/多时区：集团跨地域部署的时区、日历、语言本地化尚未系统化。
多模态抽取精度：白板/截图里的排产表 VLM 结构化抽取错误率未知，"确认前不进世界状态"能兜底但体验依赖精度；车间噪音下 ASR 准确率待实测。
Sidecar 打包体积：PyInstaller 冻结 OR-Tools + ML 栈后桌面包可能达数百 MB，需裁剪依赖与按需下载模型。
敏感性分析算力：蒙特卡洛数百次仿真在桌面单机上的耗时与并行策略（进程池/远程算力卸载）待验证。

16. 实施路线图（里程碑，可按 PPT P22"4-8 周试点"节奏）

阶段	目标	主要交付	参考周期
M-POC 左说右动验证	先验证"左说右动"是否成立，再建"说"和"动"的系统	`poc/workbench.html`：左中文指令→确定性意图解析→视口命令→右侧甘特/热力/交期看板联动；验证 UI 块协议与视口命令集的可行性（不接 LLM）	先行
M0 地基	Monorepo + 类型契约 + UI 块协议 + 模型抽象	骨架工程、KIMI/DeepSeek 可切换、SSE 打通	1-2 周
M1 核心闭环	意图识别（两级管线 §9.6）→ Rule 引擎试排 → 右侧甘特可视化 → 门禁确认 → 发布	从原型迁移算法；左说右动（接 LLM）；证据链 v1；设计系统 v1（§6.0）	2-3 周
M2 探索与治理	项目/会话/分支三级组织（§4.6）+ 成对状态 + Checkpoint + 时间线导轨 + 双通道 + 方案生成（方案卡组 §9.7）	试排不污染现实、可回滚、多方案对比选择	2-3 周
M3 知识与偏好	RAG 知识库 + 会话引用与上下文管理（§4.7/4.8）+ 交期承诺看板 + 小样本 few-shot + 报告生成 v1（日报/版本对比 §9.10）	带出处回答、偏好权重个性化、报告可导出	2-3 周
M4 集成	MCP 插件（先 WMS 缺料 + MES 下发）+ 插件/技能管理面板（§6.8）+ 房间内自动化	缺料触发重排端到端闭环（PPT P12）	3-4 周
M5 引擎升级	CP-SAT / GA 真实求解器 + 算法库注册表（§9.5）+ 参数优化闭环（§9.8）+ 敏感性分析（What-if/Tornado/蒙特卡洛 §9.9）+ 可重生流水线	多引擎可插拔、方案带鲁棒性评分	3-4 周
M6 双形态与私有化	Electron 桌面端（Sidecar 打包 §14.1）+ 多模态输入（语音/图片 §6.7）+ 国产化/信创适配 + 发布流水线（§14.3）+ 全审计	内网离线部署、数据不出厂（PPT P14/P20）	3-4 周

17. 附录：关键概念速查

概念	一句话
分层 Plan 治理	把 LLM 输出约束成 L0-L3 四层，每层可独立重生
LLM 权力边界	LLM 只有提议权，写操作必经门禁
门禁 Harness	所有写操作的唯一入口：校验+确认+快照+审计
证据链	每个结论绑定到可追溯的数据/知识/算法来源
成对分叉	对话状态与世界状态同生同灭、成对快照/回滚
Explore 通道	只读/沙盒试探，永不碰主干世界
Runtime 通道	受控写入主干与外部系统
Checkpoint	成对状态的正式快照，回滚锚点
自动化档位	G0-G4 控制智能体放手程度
UI 块协议	LLM 吐结构化块，前端渲染可交互组件
视口命令集	自然语言驱动右侧可视化
房间内自动化	场景内的值守规则（事件/定时/阈值触发）
目的声明与验收	开工先对齐目标，收工逐条核验
可重生模块	每模块契约+黄金测试，可被安全重新生成
跨部署策略共享	集团→工厂→车间三级继承+覆盖
意图识别	规则快路+LLM 语义两级管线，低置信必澄清
算法库	带注册表与选型决策表的五类算法资产
约束注册表	硬/软约束目录化：主数据即约束+配置中心+SOP转译（§9.2a）
主控参数识别	紧约束/影子价+敏感性排序+冲突归因三通道定瓶颈（§9.2b）
方案优选	硬过滤→帕累托筛→偏好加权→鲁棒性并列→人拍板（§9.7a）
插单动态重排	秒级快评→影响半径判定→LNS局部修复优先，全量重排走P2（§9.11）
小样本保障	迁移先验+层次借力+案例推理+保形区间，OR兜可行性底（§8.3a）
方案生成	一次试排产出多样化方案卡组，方案即分支
参数优化	算法超参/业务参数/模型参数三层调优闭环
敏感性分析	What-if/Tornado/蒙特卡洛，产出鲁棒性评分
报告生成	快照冻结口径+LLM 叙事+证据脚注+人工审阅
项目制会话	项目→会话→分支三级组织，项目定数据边界
会话引用	@引用其他会话/方案/版本，按时点快照取值
上下文管理	固定/项目/会话/检索四层组装+滚动摘要+钉住
多模态交互	语音/图片/文件输入，低置信抽取必经确认
技能管理	声明式领域能力包，可启停/授权/重生
Sidecar 打包	Electron 壳守护 PyInstaller 冻结的 Python 后端
拖拽交互协议	拖拽与口令平权，边拖边校验，草稿暂存后过门禁
数据资产管理	上传数据五步导入，版本化+血缘+质量报告
渐进披露	一切面板可折叠，折叠态红点+Ctrl+K 直达
主动引导	建议椽/时机提示/主动预警三级，只建议不代执行
审计链	5W1H 事件+哈希链+Merkle 锚定，审计员只读
Graham 记号	α\|β\|γ 调度问题分类法，本问题为 FJSP 变体
Optimality Gap	CP-SAT 报告解距下界差距，数学信任变业务信任

本 Plan 为架构蓝图，落地时以各阶段详细设计文档（DDD）为准。所有代码实现须遵循 §12 代码规范。

15. Round 65：端到端闭环 APS 排产内核（2026-08-03）

状态：7 个首轮审计 blocking finding 已修复；本地全量回归、真实浏览器验收和最终独立复审均通过（AUDIT: PASS）。
业务链：商务订单 -> BOM/库存/供应全局净算 -> MAKE/BUY/SUBCONTRACT -> 工艺/设备/班组/模具/层级负荷准入 -> V2 求解与独立校验 -> 原子物化 -> P2 发布 -> P3 MES。
资源契约：活动可同时要求 EQUIPMENT + TEAM + TOOLING；Validator 校验组织父链累计容量、日容量、维保/日历、能力、模具兼容与寿命。
证据门禁：P2/P3 evidence 绑定完整 problem/solution/validation、活动身份、工单身份与当前资源快照；任何漂移失败关闭。
确定性：重复 MRP 的技术 ID/时间变化不再扰动 sourceHash；外部 Skill 使用业务日期落版；WMS Saga 不得沿用历史 DRAFT。
前端：/api/orders 恢复持久化闭环、精确版本和 P2/P3 状态；6 阶段不再静态显示，刷新可恢复。
真实 MOM 数据：106 MAKE、124 BUY、0 SUBCONTRACT；39 缺工艺、67 模板/缺能力；严格失败关闭且新版本 0 VL/WO。
验证：后端 979 passed；Node 60 passed；Web build passed；真实隔离 Playwright 正/负闭环 2 passed。
数据边界：旧版 GET /api/orders 曾于 2026-08-03 10:10:24 写入现场 world，已修为语义幂等和只读快照；当前 MOM hash 6b64adf6...53f7d 在本轮隔离验收前后保持一致，未擅自恢复。
剩余不得伪造的现场输入：正式 ASM 能力、工艺确认、班组/模具、采购/委外到货承诺与真实 MES/WMS/SAP 凭据。

16. Round 66：Windows 求解器进程隔离与 Fail-Closed（2026-08-03）

状态：子进程协议、CP/HYBRID 接线、运行时探针、Sidecar 入口、故障注入和真实运行已完成；新增源码 Sidecar -I 回归后，最终全量黄金计数待主 agent 复跑确认。
隔离边界：父进程发送不可变请求，child 只执行优化；父进程验证退出码、fatal marker、protocol v2、requestId/responseDigest、operation/invocation 与 runtime identity 后才允许物化；诊断 operation 永不物化。
失败语义：fatal/timeout 下 CP/HYBRID 均 UNAVAILABLE、0 PO/WO、不可发布；父进程存活、业务世界原子、HYBRID 不静默降级 RULE。
进程治理：timeout 实测 15.633 秒并回收 grandchild 进程树；默认 PATH Anaconda 稳定拒绝，.venv 与 .sidecar-venv 各连续 5 次通过。
正向运行：复制 world.json 的 CP/HYBRID 均 OPTIMAL，1 PO / 10 WO / 10 operationSlots，协议 v2、runtimeSafe=true。
源码 Sidecar：--solver-child -I 初次真实冒烟发现源码 import root 缺失；经 GitNexus LOW impact 修复为仅 bootstrap trusted source root，新测试覆盖，实际 CP 同样 OPTIMAL、1/10/10。
MOM 边界：复制 MOM 数据 CP/HYBRID 求解 OPTIMAL，但现有主数据阻断为 0 PO/WO、1 slot/1 conflict；不得宣称现场主数据或完整工厂排产已完成。
最终复审：AUDIT: PASS；旧冻结 EXE 未重建仅保留为构建后验收。
验证：post-fix focused 80 passed；最终全量黄金 1029 passed / 2 warnings；Node 60 passed；Web build、ruff、compile、node check、diff-check passed。
审计补强：临时文件 stdin 保证 Windows 大请求有界 timeout；slot 索引域与 orderNo/productId 绑定严格校验；错误 pipeline/status 有负向回归。
审计补强：父进程强制重算 responseDigest，校验非空请求与响应条目的完整排列/业务字段、pipeline/status、可行解 objective/gap 与 operationSlots 全覆盖；首轮 OPTIMAL + 空 entries 假绿现失败关闭。
服务与浏览器：8003 PID 65824、5173 PID 9808 healthy；浏览器 title=APS 智能排产工作台、root=true、无 warning/error。
数据边界：world.json hash C6E7FF...52FA、MOM hash 6B64AD...3F7D 前后不变；server/data/**、.env 无 Git 状态。master.db 可能更新 license last_seen 等运行元数据，不以文件 hash 冒充业务不变。
构建后验收：现有冻结 EXE 仅旧 --probe-child 通过，未重建，不能宣称新 --solver-child 已打包；仍需重建后冒烟、干净 Windows、签名/Defender/真实 CI。
下一 P0：全量 P2/P3 evidence 封套与审批迁移可靠性；不提交、不推送、不合并、不发布。

17. Round 67：审批迁移 Fail-Closed 与 Grant Digest 归一化（2026-08-03）

状态：本地实现、真实运行、全量回归和最终独立审计均通过（AUDIT: PASS）。
grant 迁移只存 SHA-256 digest，raw token 不落库；真实 P3 grant 迁移后可消费一次且不可重放。
损坏 JSON/schema/record/引用失败关闭；grant 无 pending 时按 terminal history 重建 APPROVED request。
QUIESCED + 同锁稳定快照；请求、grant、event 在单事务中写入，后段异常/source drift 整体回滚。
目标不可变列与 payload 同时校验；状态只允许单调前进；旧 raw-token 行一致时原子修复、冲突时拒绝。
canonical event digest 保证重跑幂等且不丢失同秒近似事件。
验证：migration 29 passed；approval related 74 passed；full golden 1053 passed / 2 warnings；真实临时 SQLite consume=true/false；现场数据 hash 不变。
后续 P0 状态：R67-B2 数据库权威 clock/TTL/CAS、sap.sync.outbound P3 evidence envelope 与 folder.schedule TOCTOU/P2 信封已完成本地合同和故障注入；下一本地优先级为 Automation G4 payload 绑定。真实 MySQL 多节点与 SAP 现场联调仍属外部验收。

15. Round 69：北海造船场景 SYNTHETIC APS 完整数据生成与验证（2026-08-04）

15.1 已落地

新增 server/shipyard_synthetic/ 与 CLI scripts/generate_beihai_shipyard_aps.py，支持 small/standard/full、固定种子、场景选择、增量、validate-only、CSV/JSON/world/Schema/Skill/RAG 导出。
Full 生成 4 个模拟船舶项目、72 里程碑、72 总段、280 分段、1,000 工作包、4,000 WBS 任务、12,000 物料、50,000 BOM、220 路线、2,400 工单、12,000 工序/槽位、150 资源、60 班组、40 供应商、550 采购建议、140 委外建议、180 风险冲突和 120 RAG 资产。
业务逻辑覆盖商务订单→WBS/工程发布→EBOM/PBOM/MBOM→库存/在途/替代料净算→MAKE/BUY/OUTSOURCE/OWNER_SUPPLIED→有限能力排产→质量/返工→MES 执行→7 方案/15 异常场景。
四类前后关系 FS/SS/FF/SF、正负 lag、技能/人数/资格、重量尺寸/吊装、运输、天气、维护、危险作业、区域密度、冻结区、质量 Hold Point 和供应商月产能均有非零样本和 fail-closed 校验。
委外严格形成前工序、送出、往返运输、加工、检验、回厂、委外槽位和后工序的统一时间事实源。
50 条 NCR 均建立独立返工 operation 和独立有限资源 slot；7 个方案和 15 个事件均产生真实 schedule version/delta。
输出目录：beihai-shipyard-aps-data/；严格声明 SYNTHETIC，不代表北海造船真实业务数据。

15.2 验收证据

Round 69 focused：49 passed；其中 26 个非法变异逐类证明硬约束能拒绝错误数据。
Full golden：1120 passed / 2 warnings。
Node：60 passed；Web build：PASS。
Full validate-only：PASS / FEASIBLE / 0 hard violations / 0 issues。
222 个文件、51 CSV、205.206 MiB；业务摘要 21838055715c...594d3；manifest d908718e...a49fe7、world 0f7fcdb3...991d；fresh full 逐文件哈希差异 0。
fresh full 生成+校验+导出+确定性比对 87.238 秒，峰值工作集 1,298.496 MiB，输出 205.206 MiB，均低于 180 秒/1,536 MiB/300 MiB 门槛。
8003/5173 HTTP 200，浏览器 title 和主界面通过，受保护 server/data 哈希未变化。
最终限定范围只读审计 AUDIT PASS；委外附件 19 字段、15 类异常、26 类约束、50 条返工、7 个方案和 manifest 闭包全部通过。

15.3 边界

这是高拟真确定性模拟数据，不是北海造船、康尼或锐扬真实生产数据；真实主数据、工时、资源日历、供应商能力和规则必须按授权接入并现场校准。
本轮不提交、推送、合并或发布。

18. Round 72：folder.schedule P2 冻结信封与 TOCTOU 关闭（2026-08-17）

状态：本地实现、故障注入、全量回归和独立复审完成，AUDIT PASS。
SQL 完整数据不再绕过 P2；folder.schedule stage 只在深拷贝沙盒分析，主业务世界和排产版本不变。
工程目录源文件一次读取为不可变 bytes；manifest SHA、Excel/CSV 解析与 SQL 规范投影共享同一字节流，执行不重读活动目录。
确认信封绑定 action/power/tenant/project/world/session/params/evidence/snapshot；决策前重算 paramsHash 与 envelopeHash，旧或损坏卡片失败关闭。
folder 专用证据绑定 source manifest、world fingerprint、frozen payload digest 与 beforeSnapshot；源文件、项目/会话、快照、证据或载荷漂移均 DENIED。
执行使用候选世界事务；import/schedule/save 任一点失败均丢弃候选并恢复原业务状态，Plan 节点仅在提交成功后 APPROVED。
验证：folder 安全专项 14 passed；审批/folder 相邻回归 108 passed / 1 warning；全量黄金 1290 passed / 2 warnings；Web build、Node 60/60、8003/5173 和浏览器真实运行通过；4 个受保护业务文件 SHA-256 前后不变。
Round 73 已完成 Automation G4 payload 绑定；P0 本地清单至此闭合。下一本地优先级转为 R71.5 算法归因/API/UI 深化；未经授权不 commit/push/merge/publish。

19. Round 73：Automation G4 授权载荷绑定（2026-08-17）

G4 升权卡强制绑定 automation-authorization.v1：完整 Rule、harnessAction、power 与 BusinessActionBinding。
request 与 grant 消费前均严格校验 schema、ruleId/room/gear、门禁动作/权力等级和 P2/P3 binding；残缺授权出卡前拒绝。
EscalationGrant 保存批准的 authorization snapshot/digest；每次执行前按当前 Rule + Binding 重算，params/action/trigger/guardrails/gear/room/binding 任一漂移都撤销旧 grant。
G4 P2/P3 禁止进程内 handler 直通，只允许已登记 Binding + business_bridge；缺失时按 P3 DENIED。
/api/actions/confirm 与 batch 已接 AutomationGate：第一重保留待办，第二名审批人后消费一次性 executionGrant、铸造绑定 grant；真实桥可发布 DRAFT 版本。
验证：Automation focused 24 passed / 1 warning；审批/治理相邻回归 92 passed / 1 warning；全量黄金 1300 passed / 2 warnings；受保护业务文件哈希不变；8003/5173 和浏览器通过；独立复审 AUDIT PASS。
下一本地优先级：R71.5 算法与约束深化；真实 MySQL/厂商系统/模型与发布环境继续保持外部阻断。

20. Round 74：归因 API 与冲突中心接线（2026-08-17）

新增项目世界、轨道、版本绑定的只读 /api/attribution；无版本和错轨版本失败关闭。
修复 flex 归因误读 fixed 产能冲突；IIS 增加稳定 ID，evidence 前后端契约一致。
冲突中心展示主控约束、IIS、逐条证据，并保留“近似影子价”标签。
项目/会话切换及加载错误清除旧报告，避免跨项目陈旧结论。
验证：focused 12 passed；Web build；full golden 1301 passed / 2 warnings；独立复审 AUDIT PASS。
下一本地优先级：CP-SAT IIS solverMeta 与生产级敏感性/Sobol。

21. Round 75：CP-SAT 原生不可行核心 solverMeta（2026-08-17）

为 C1/C2/C10/C11/C12 约束族增加 CP-SAT assumptions；全部为 true 时保持原模型可行集合。
INFEASIBLE 时调用 SufficientAssumptionsForInfeasibility()，solverMeta 输出规范约束 ID 和原生核心方法。
明确 minimality=sufficient-assumption-core、isMinimalIis=false，不冒充数学最小 IIS。
C2 标签按约束目录统一为 C2_no_overlap；测试强制所有 core ID 可由目录解析。
验证：CP focused 24、solver affected 79、full golden 1302 passed / 2 warnings；独立复审 AUDIT PASS。
下一本地优先级：生产级敏感性/Sobol。

23. Round 77：异步分析任务安全基础设施（2026-08-18）

JobQueue 完成 tenant/project 隔离、认证 actor、并发/在途上限、协作取消和线程启动回滚。
验证：专项 11、相邻 20、full golden 1358 passed / 2 warnings；AUDIT PASS。
下一本地优先级：恢复 Sobol，并同步 Sidecar 依赖、日期输入、取消循环与前端入口。

24. Round 78：Sobol 全局敏感性与冻结 Sidecar（2026-08-18）

新增独立 Sobol/Jansen 路径，既有 CRITICAL run_sensitivity 契约保持不变；5 因子、2d scrambled 采样、8~64 基础样本，结果显式包含 seed/startDate/evaluations/variance/一阶与总效应。
日期只取请求或 world.businessDate；每次评估前协作取消；sobol.recompute 创建线程前严格 422，继续复用 JobQueue tenant/project/actor/并发门禁。
零方差指数返回不可识别 null，前端显示告警；SkillConsole 提供日期、样本、指标和结果表，真实浏览器 8 样本完成 56 次评估且 console 0。
SciPy 同步 runtime/requirements/Sidecar lock；真实冻结构建发现并修复 Sobol direction npz 漏打包，第二次冻结 EXE probe 输出 scipy=1.18.0 且健康冒烟通过。
验证：full golden 1381 passed / 2 warnings；Sobol+Sidecar focused 61、相邻 62、Node 60、Web build；受保护哈希不变；独立复审关闭 1 P1/3 P2 后 AUDIT PASS。
下一本地优先级：真实 LP/CP 对偶影子价与归因校准；真实 MySQL 多节点、厂商联调、签名/Defender/干净离线机仍属外部验收。未经授权不 commit/push/merge/publish。

25. Round 79：诊断 LP 局部边际率与归因校准（2026-08-18）

保留冲突日志“近似影子价”代理；新增 GLOP diagnostic-conflict-relaxation，只对 C4/C7/C8 明确分钟 RHS 输出局部有限差分，cap dual 仅作一致性证据。
明确 exactForLpModel=true / exactForCpSat=false、one-at-a-time、跨约束不可加、输入来源/精度/覆盖率；solver error、unsupported 和输入冲突分别报告。
conflictId 在分组前全局一致性校验；不一致重复失败关闭，即使同约束还有其他有效证据也不输出 rate；一致 ID 与物理 RHS 去重独立留痕。
API 保持 schedule-attribution.v1 加法兼容；冲突中心同时展示原代理、诊断 LP 边际率、1 分钟收益、dual 校验和证据排除/去重原因。
验证：full golden 1399 passed / 5 warnings；专项 26、扩展 108、Node 60、Web build、冻结 glop=GLOP、隔离浏览器 console 0；最终独立审计 AUDIT PASS。
下一本地优先级：基于原排产变量的调度级 LP 松弛或 CP one-at-a-time 业务目标重解；未经授权不 commit/push/merge/publish。

26. Round 80：CP 整约束 one-at-a-time 业务目标重解（2026-08-18）

solver process 升级 protocol v2，普通排产与诊断 baseline/removal operation 严格隔离；诊断单元素 allowlist、随机 invocation、请求/响应摘要和父子 assumption 集合全绑定。
C1/C2/C10/C11/C12 记录真实实例数；C11 同时移除起点门槛和冻结障碍；无实例项不重解。
诊断固定单线程 seed0；OPTIMAL 给精确整约束目标改善，FEASIBLE 只给界限区间；恢复可行、UNKNOWN、MODEL_INVALID、单调性违反和 partial 分开。
JobQueue/API/UI 已接 cp-marginal.recompute；结果显式声明不是对偶/单位边际且跨约束不可加。
验收：full golden 1435 passed / 5 warnings；专项 36、扩展 144、Node 60、Web build、冻结 EXE protocol v2 diagnostic C2=28000、隔离浏览器 console0；受保护哈希不变；独立审计 AUDIT PASS。
下一本地优先级：容量/交期参数的 RHS 增量重解与现场成本校准；未经授权不 commit/push/merge/publish。

27. Round 81：CP RHS 参数增量重解与现场成本口径（2026-08-18）

protocol v2 新增独立 diagnose_rhs_baseline / diagnose_rhs_perturbation operation；生产排产、整约束移除和 RHS 诊断三者 strict schema 隔离，请求摘要、随机 invocation、响应摘要与扰动回显继续绑定。
C8 只对 fixed 轨待排条目的延期目标 late >= end-due 增加交期容差分钟，不改变 CP 可行域；C12 只对 intervalCount>=2 且真实创建 AddCumulative 的具体班组/工装资源增加 capacity。
每个 C8 全体条目或 C12 具体资源单独正向重解；固定单线程 seed0。OPTIMAL 输出精确有限差分，FEASIBLE 仅输出界限区间；模型拓扑/RHS 差值漂移、矛盾区间、C8 可行性改变和负改善均失败关闭。
cp-rhs.recompute 复用 JobQueue 的认证 actor、tenant/project、并发与取消边界；Web 支持三类增量、可选显式费率和按资源结果展示。
未配置费率时 costStatus=not_configured 且 rate/unit/currency/estimatedCost 全为 null；容量费率单位明确为每容量单位/本次计划期。加权延期分钟与货币成本不可直接相减，不输出 ROI/netValue。
验证：full golden 1478 passed / 5 warnings；RHS 专项 43、扩展 180、Node60、Web build；冻结 Sidecar RHS C8 60 分钟精确改善 18000；隔离 8021/5191 浏览器无费率/显式费率、C12 无实例不估算和 console0 通过。
C7 产线/日能力仍未进入当前 CP-SAT 可行模型，本轮不生成虚假 C7 敏感性；真实现场费率、罚则和资源成本仍需业务校准。
验收记录见 docs/round-81-cp-rhs-parameter-record.md；未经授权不 commit/push/merge/publish。

28. Round 82：C7 产线/日容量 CP 硬约束与实例增量（2026-08-19）

当前 operation-level CP-SAT 增加 C7_capacity assumption：每个候选工序的完整 setup+run 分钟、激活的顺序换型分钟及既有已发布/冻结工单固定负荷，按其开工自然日计入具体产线；单日总和不得超过 shiftCalendar 有效班次分钟。
C7 使用 start-day-full-duration.v1 与当前 Rule 物化后容量检查同口径；长工序即使跨夜也整笔记入开工日。该模型不是跨班暂停/续作，也不是 CP 时间直接物化，结果显式 isMaterializedShiftModel=false。
capacityPerDay/standardCapacity 为件/日口径，不混入分钟 RHS；工序时长已除以 efficiencyFactor，容量不再次乘效率。缺日历、非法/跨午夜/重叠班次、非法休息段均失败关闭；非工作日容量为 0，不能用 RHS 增量替代班次日历变更。
protocol v2 支持单个 C7_line_day_capacity_minutes 扰动，实例 ID 为 line-day:{lineId}:{YYYY-MM-DD}；生产、整约束移除与 RHS operation 继续隔离，固定单线程 seed0 和摘要/拓扑/RHS 差值绑定不变。
cp-rhs.recompute 增加显式 instanceIncrements / instanceCostRates；最多 128 个实例，实例费率优先于站点默认，未配置货币字段全 null。费用单位为具体产线/工作日每增加 1 个 C7 RHS 分钟，不推导人工小时费或 ROI。
CP/HYBRID 物化后按 exact C7 重算并写入 materializedC7Validation；Rule 5% 告警未覆盖的精确超载补充 CAPACITY 冲突，继续阻断发布，但不覆盖原 CP solve status。
验证：full golden 1504 passed / 5 warnings；C7 专项 26、协议/CP/Sidecar/Job 联合 206、Node60、Web build；冻结 Sidecar C7 869→929/改善51000/runtimeSafe；隔离 Web workingDates 限定、无费率/实例费率、console0 通过。
C7 专项与真实 Web 记录见 docs/round-82-c7-line-day-capacity-record.md；未经授权不 commit/push/merge/publish。

29. Round 83：C3 班次日历分段 CP 模型（2026-08-20）

cp-calendar-segmented.v1 把扣休息后的班次有效窗口接入 operation-level CP-SAT；长工序只允许在窗口边界暂停/续作，非工作日和休息段不可加工。
C1 使用逻辑工序包络；C2/C12 使用实际 processing segments；同一逻辑工序的多个段不重复激活 C2。C7 继续保留 start-day 整笔分钟口径。
operationSlots 输出 segments/processing/elapsed/pause/count/compliance/mode；日历模型超过 50,000 segment selector 时失败关闭。
C3 baseline 使用 calendar-boundary-only，整约束 removal 使用互斥 continuous；父进程绑定 calendar digest、anchor/horizon/coverage、bucket/window/segment 数和 model identity。
主求解不固定 hint；只有 UNKNOWN 后可执行经验证的固定可行 hint fallback，并在 solverMeta 记录两阶段状态和耗时。
Rule 尚未直接消费 CP segments；物化跨休息/停工窗口时生成 C3 硬冲突，关闭发布和 MES 下发但保留 CP solve status。
验收：C3 专项11、扩展245、审计聚焦117、full golden 1522 passed / 5 warnings、Node60、Web build；冻结 Sidecar 与隔离 Web 均验证 baseline/removal runtimeSafe=true、拓扑一致、模式正确、console0；受保护哈希不变，独立审计 AUDIT PASS。
本轮全量回归同时关闭累积工作区 PoolEngine 两个已声明策略被回落为 BOTTLENECK 的缺口；GitNexus class impact HIGH，最小修复后原失败3项、相邻62项及全量均通过。
下一本地优先级：让物化层直接消费经验证的 CP 时间；真实 MySQL、厂商系统、现场费率/罚则、签名/Defender/干净离线机继续保持外部边界。详见 docs/round-83-c3-calendar-segmentation-record.md；未经授权不 commit/push/merge/publish。

30. Round 84：经父进程验证的 CP 时间直接物化（2026-08-20）

状态：Round 83 的“CP 时间直接物化”本地优先项已闭合；CP/HYBRID 可行解不再由 Rule 占槽器重新计算工序时间，RuleEngine 仅作为业务对象持久化外壳消费父进程验证后的 CP timing。
父进程门禁：operationSlots 在任何写入前校验稳定订单项身份、默认工艺路线双射、产线/工位/team/tooling 主数据、segment 汇总、C1 前后序、C2/C12 容量、C3 日历拓扑与 C7 口径；诊断 C2/C12 松弛和 C12 RHS 增量按请求语义校验，不把合法反事实误拒为响应篡改。
直接物化：_prepare_cp_operation_timing 将通过校验的 slot 绑定为 _cpOperationTiming；每个 WO 精确写入 CP 的 plannedStart/End、plannedSegments、processing/elapsed/pause/count 和稳定逻辑工序键。任一预检或日历窗口漂移在创建版本/PO/WO 前失败关闭。
证据：placement=cp-calendar-segmented-direct、directlyConsumedByMaterializer=true、operationTimingValidation.passed=true；C3 cpTimingApplied=true 且逐工序精确对齐，C7 继续按 start-day-full-duration.v1 复核。
隔离浏览器：CP V20260820-001 与 HYBRID V20260820-002 均 FEASIBLE，各 7 PO / 30 WO / 30 operationSlots；C3 精确对齐 30/30、0 violation，C7 passed，无 CALENDAR/CAPACITY/ENGINE_UNAVAILABLE 硬阻断。页面可见两版结果，console 无 warning/error。
回归收口：初次全量暴露 13 项累积失败（旧固定日期夹具缺 C3/C7 日历覆盖、父校验器未识别 C2 松弛和 C12 RHS 容量）；最小修复后 CP/RHS 81 passed、CP 扩展 171 passed，最终 full golden 1540 passed / 5 warnings；既有 Round 84 聚焦 142 passed / 1 warning、Node60、Web build 和 py_compile 通过。
主项目边界：5173 已显式代理 8003；主项目 V20260820-006 为 TRIVIAL，因为当前标准排产条目为 0，不作为正向求解证据。成功 solverMeta 仍保存内部 runtime provenance 绝对路径，当前标准世界投影不公开该字段；生产若新增 solverMeta 公共接口必须先做脱敏投影。
剩余边界：真实 MySQL 多主机、MES/WMS/SAP 联调、现场费率/罚则、签名/Defender/干净离线机均需外部环境或授权；本轮未 commit/push/merge/publish。验收记录见 docs/round-84-cp-direct-materialization-record.md。

147 KiB Raw Blame History Unescape Escape