feat: 完善智能体与行业演示方案并支持移动端多账号

Co-authored-by: Cursor <cursoragent@cursor.com>

App/src/pages/login/login.vue

@@ -9,7 +9,7 @@ import { useUserStore } from '@/stores/user';
 import { useMessageStore } from '@/stores/message';
 import { useAppStore } from '@/stores/app';
 import { startSignalR } from '@/signalr/manager';
-import { getRememberedAccount } from '@/utils/storage';
+import { getRememberedAccounts, removeRememberedAccount } from '@/utils/storage';
 import { getApiBaseUrl } from '@/utils/config';
 
 const userStore = useUserStore();
@@ -21,9 +21,12 @@ const remember = ref(true);
 const agreed = ref(false);
 const loading = ref(false);
 const serverUrl = ref('');
+const rememberedAccounts = ref<string[]>([]);
+const accountHistoryVisible = ref(false);
 
 onLoad(() => {
-  const remembered = getRememberedAccount();
+  rememberedAccounts.value = getRememberedAccounts();
+  const remembered = rememberedAccounts.value[0];
   if (remembered) {
     account.value = remembered;
     remember.value = true;
@@ -39,6 +42,7 @@ onShow(() => {
 
 async function submit(): Promise<void> {
   if (loading.value) return;
+  accountHistoryVisible.value = false;
   if (!account.value.trim()) {
     uni.showToast({ title: '请输入账号', icon: 'none' });
     return;
@@ -67,6 +71,23 @@ async function submit(): Promise<void> {
   }
 }
 
+function toggleAccountHistory(): void {
+  if (rememberedAccounts.value.length === 0) return;
+  accountHistoryVisible.value = !accountHistoryVisible.value;
+}
+
+function selectRememberedAccount(item: string): void {
+  account.value = item;
+  password.value = '';
+  remember.value = true;
+  accountHistoryVisible.value = false;
+}
+
+function deleteRememberedAccount(item: string): void {
+  rememberedAccounts.value = removeRememberedAccount(item);
+  if (rememberedAccounts.value.length === 0) accountHistoryVisible.value = false;
+}
+
 function gotoServerSetting(): void {
   uni.navigateTo({ url: '/pages/mine/server' });
 }
@@ -89,15 +110,36 @@ function gotoPrivacy(): void {
     <view class="login-card">
       <view class="field">
         <view class="field-label">账号</view>
-        <input
-          v-model="account"
-          class="field-input"
-          type="text"
-          placeholder="请输入登录账号"
-          placeholder-class="field-placeholder"
-          :maxlength="64"
-          confirm-type="next"
-        />
+        <view class="account-input-wrap">
+          <input
+            v-model="account"
+            class="field-input account-input"
+            type="text"
+            placeholder="请输入登录账号"
+            placeholder-class="field-placeholder"
+            :maxlength="64"
+            confirm-type="next"
+            @focus="accountHistoryVisible = rememberedAccounts.length > 0"
+          />
+          <view
+            v-if="rememberedAccounts.length > 0"
+            class="account-toggle"
+            @tap.stop="toggleAccountHistory"
+          >
+            <text :class="{ expanded: accountHistoryVisible }">⌄</text>
+          </view>
+        </view>
+        <view v-if="accountHistoryVisible" class="account-history">
+          <view
+            v-for="item in rememberedAccounts"
+            :key="item"
+            class="account-history-row"
+            @tap="selectRememberedAccount(item)"
+          >
+            <text class="account-history-name">{{ item }}</text>
+            <text class="account-history-delete" @tap.stop="deleteRememberedAccount(item)">×</text>
+          </view>
+        </view>
       </view>
       <view class="field">
         <view class="field-label">密码</view>
@@ -110,6 +152,7 @@ function gotoPrivacy(): void {
           placeholder-class="field-placeholder"
           :maxlength="64"
           confirm-type="done"
+          @focus="accountHistoryVisible = false"
           @confirm="submit"
         />
       </view>
@@ -215,6 +258,70 @@ function gotoPrivacy(): void {
   border-color: #0f59a4;
 }
 
+.account-input-wrap {
+  position: relative;
+}
+
+.account-input {
+  width: 100%;
+  padding-right: 88rpx;
+}
+
+.account-toggle {
+  position: absolute;
+  top: 0;
+  right: 0;
+  width: 88rpx;
+  height: 88rpx;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  color: #909399;
+  font-size: 34rpx;
+}
+
+.account-toggle text {
+  transition: transform 0.2s;
+}
+
+.account-toggle text.expanded {
+  transform: rotate(180deg);
+}
+
+.account-history {
+  margin-top: 8rpx;
+  border: 1rpx solid #dcdfe6;
+  border-radius: 6rpx;
+  background-color: #ffffff;
+  overflow: hidden;
+}
+
+.account-history-row {
+  min-height: 76rpx;
+  padding: 0 20rpx 0 24rpx;
+  display: flex;
+  align-items: center;
+  border-bottom: 1rpx solid #ebeef5;
+}
+
+.account-history-row:last-child {
+  border-bottom: 0;
+}
+
+.account-history-name {
+  flex: 1;
+  min-width: 0;
+  color: #303133;
+  font-size: 28rpx;
+}
+
+.account-history-delete {
+  width: 64rpx;
+  text-align: center;
+  color: #909399;
+  font-size: 38rpx;
+}
+
 .field-placeholder {
   color: #a8abb2;
   font-size: 30rpx;

App/src/stores/user.ts

@@ -25,8 +25,8 @@ import {
   getCachedUserInfo,
   getRefreshToken,
   getToken,
+  rememberLoginAccount,
   setCachedUserInfo,
-  setRememberedAccount,
   setTokens,
 } from '@/utils/storage';
 
@@ -76,7 +76,7 @@ export const useUserStore = defineStore('user', {
         throw new Error('登录失败，请检查账号与密码');
       }
       setTokens(token.accessToken, token.refreshToken);
-      setRememberedAccount(remember ? account : '');
+      if (remember) rememberLoginAccount(account);
       await this.fetchUserInfo();
       console.log('[login] userInfo 完成');
       // 菜单树失败不阻断基础页登录，但所有业务功能保持 fail-closed。

App/src/utils/storage.ts

@@ -7,6 +7,8 @@ export const ACCESS_TOKEN_KEY = 'access-token';
 export const REFRESH_TOKEN_KEY = 'x-access-token';
 const USER_INFO_KEY = 'aidop_user_info';
 const LOGIN_ACCOUNT_KEY = 'aidop_login_account';
+const LOGIN_ACCOUNTS_KEY = 'aidop_login_accounts';
+const MAX_LOGIN_ACCOUNTS = 8;
 
 export function getToken(): string {
   return (uni.getStorageSync(ACCESS_TOKEN_KEY) as string) || '';
@@ -101,15 +103,70 @@ export function clearCachedUserInfo(): void {
   uni.removeStorageSync(USER_INFO_KEY);
 }
 
-/** 记住的登录账号（仅存账号不存密码） */
-export function getRememberedAccount(): string {
-  return (uni.getStorageSync(LOGIN_ACCOUNT_KEY) as string) || '';
+function normalizeAccounts(value: unknown): string[] {
+  let source: unknown = value;
+  if (typeof value === 'string') {
+    try {
+      source = JSON.parse(value);
+    } catch {
+      source = value ? [value] : [];
+    }
+  }
+  if (!Array.isArray(source)) return [];
+  const seen = new Set<string>();
+  return source
+    .map((item) => String(item || '').trim())
+    .filter((item) => {
+      const key = item.toLowerCase();
+      if (!key || seen.has(key)) return false;
+      seen.add(key);
+      return true;
+    })
+    .slice(0, MAX_LOGIN_ACCOUNTS);
 }
 
-export function setRememberedAccount(account: string): void {
-  if (account) {
-    uni.setStorageSync(LOGIN_ACCOUNT_KEY, account);
+function persistAccounts(accounts: string[]): void {
+  if (accounts.length > 0) {
+    uni.setStorageSync(LOGIN_ACCOUNTS_KEY, JSON.stringify(accounts));
+    // 保留旧键，兼容尚未升级的安装包。
+    uni.setStorageSync(LOGIN_ACCOUNT_KEY, accounts[0]);
   } else {
+    uni.removeStorageSync(LOGIN_ACCOUNTS_KEY);
     uni.removeStorageSync(LOGIN_ACCOUNT_KEY);
   }
 }
+
+/** 已记住的登录账号，最近成功登录的排在最前；仅存账号，不存密码。 */
+export function getRememberedAccounts(): string[] {
+  const accounts = normalizeAccounts(uni.getStorageSync(LOGIN_ACCOUNTS_KEY));
+  if (accounts.length > 0) return accounts;
+
+  // 从历史单账号键无损迁移。
+  const legacy = String(uni.getStorageSync(LOGIN_ACCOUNT_KEY) || '').trim();
+  if (!legacy) return [];
+  persistAccounts([legacy]);
+  return [legacy];
+}
+
+export function getRememberedAccount(): string {
+  return getRememberedAccounts()[0] || '';
+}
+
+export function rememberLoginAccount(account: string): string[] {
+  const normalized = account.trim();
+  if (!normalized) return getRememberedAccounts();
+  const key = normalized.toLowerCase();
+  const accounts = [
+    normalized,
+    ...getRememberedAccounts().filter((item) => item.toLowerCase() !== key),
+  ].slice(0, MAX_LOGIN_ACCOUNTS);
+  persistAccounts(accounts);
+  return accounts;
+}
+
+export function removeRememberedAccount(account: string): string[] {
+  const key = account.trim().toLowerCase();
+  const accounts = getRememberedAccounts().filter((item) => item.toLowerCase() !== key);
+  persistAccounts(accounts);
+  return accounts;
+}

App/tests/storage.spec.ts

@@ -0,0 +1,59 @@
+import { beforeEach, describe, expect, it, vi } from 'vitest';
+import {
+  getRememberedAccounts,
+  rememberLoginAccount,
+  removeRememberedAccount,
+} from '@/utils/storage';
+
+let storage: Map<string, unknown>;
+
+beforeEach(() => {
+  storage = new Map<string, unknown>();
+  vi.stubGlobal('uni', {
+    getStorageSync: (key: string) => storage.get(key) ?? '',
+    setStorageSync: (key: string, value: unknown) => storage.set(key, value),
+    removeStorageSync: (key: string) => storage.delete(key),
+  });
+});
+
+describe('remembered login accounts', () => {
+  it('migrates the legacy single-account value', () => {
+    storage.set('aidop_login_account', 'UATAdminA');
+
+    expect(getRememberedAccounts()).toEqual(['UATAdminA']);
+    expect(JSON.parse(String(storage.get('aidop_login_accounts')))).toEqual(['UATAdminA']);
+  });
+
+  it('keeps the most recently used account first and removes duplicates case-insensitively', () => {
+    rememberLoginAccount('UATAdminA');
+    rememberLoginAccount('AIDOPDemoTenant');
+    rememberLoginAccount('uatadmina');
+
+    expect(getRememberedAccounts()).toEqual(['uatadmina', 'AIDOPDemoTenant']);
+  });
+
+  it('limits history to eight accounts', () => {
+    for (let index = 1; index <= 10; index += 1) {
+      rememberLoginAccount(`user${index}`);
+    }
+
+    expect(getRememberedAccounts()).toEqual([
+      'user10',
+      'user9',
+      'user8',
+      'user7',
+      'user6',
+      'user5',
+      'user4',
+      'user3',
+    ]);
+  });
+
+  it('removes one account without clearing the remaining history', () => {
+    rememberLoginAccount('first');
+    rememberLoginAccount('second');
+
+    expect(removeRememberedAccount('SECOND')).toEqual(['first']);
+    expect(storage.get('aidop_login_account')).toBe('first');
+  });
+});

doc/README.md

@@ -59,7 +59,7 @@
 | [plan/系统集成/Ai-DOP第三方系统集成指南.md](./plan/系统集成/Ai-DOP第三方系统集成指南.md) | 给第三方系统看的对接指南：入站对象、DB 同步与 API 约定、回写与联调验收 |
 | [plan/系统集成/Ai-DOP第三方对接业务数据详表-业务页.md](./plan/系统集成/Ai-DOP第三方对接业务数据详表-业务页.md) | 对接详表（业务）：九宫格/详情看板/诊断/ChatBI 需要哪些业务数据，不含库表名 |
 | [plan/系统集成/Ai-DOP第三方对接业务数据详表-技术页.md](./plan/系统集成/Ai-DOP第三方对接业务数据详表-技术页.md) | 对接详表（技术）：源字段落到中台哪张表、哪个栏位 |
-| [plan/Ai-DOP本体驱动智能体建设方案.md](./plan/Ai-DOP本体驱动智能体建设方案.md) | **智能体建设方案（待评审）**：以「本体驱动数据治理」四要素（实体/属性/关联/动作）为语义中枢，在现有 ChatBI/S9 诊断改善/数据中台/审批流之上增量建设四类智能体（数据感知/关系推理/风险预警/执行调度），含本体四表 DDL、四规则巡检引擎、工具注册闸门、P0~P4 分阶段计划与治理红线 |
+| [plan/Ai-DOP本体驱动制造业数据智能运营平台产品方案.md](./plan/Ai-DOP本体驱动制造业数据智能运营平台产品方案.md) | **本体驱动产品顶层方案（待评审）**：在“独立工业数据中台 + S0–S9 + 智能体运营平台”基础上增加业务语义控制面，定义通用制造本体、行业扩展、工厂原型和客户覆盖分层，说明数据中台、S0–S9、智能体、知识体系及行业化价值演示平台的调整，包含新旧方案变动对照、P0–P5 路线图和治理红线 |
 | [Windows后端WinSW守护重启方案.md](./Windows后端WinSW守护重启方案.md) | Windows 服务器上使用 WinSW 守护后端服务、自动重启与日志落盘 |
 | [plan/S1/S1-订单管理-审批流程实施方案.md](./plan/S1/S1-订单管理-审批流程实施方案.md) | S1 订单审批实施方案 |
 | [plan/S1-S3业务逻辑测试与数据准备方案.md](./plan/S1-S3业务逻辑测试与数据准备方案.md) | S1-S3 完整业务逻辑测试 case 与测试数据准备方案 |

doc/plan/Ai-DOP本体驱动制造业数据智能运营平台产品方案.md

@@ -0,0 +1,887 @@
+# Ai-DOP 本体驱动制造业数据智能运营平台产品方案
+
+| 项目 | 内容 |
+|---|---|
+| 文档定位 | Ai-DOP 本体驱动产品顶层方案 |
+| 当前状态 | 讨论稿，待产品、业务、数据与研发联合评审 |
+| 编制日期 | 2026 年 10 月 26 日 |
+| 适用范围 | 独立工业数据中台、Ai-DOP S0–S9、智能体运营平台、行业化价值演示平台 |
+| 核心主张 | 本体驱动、数据为事实、服务做计算、智能体做编排 |
+
+---
+
+## 一、方案摘要
+
+### 1.1 调整背景
+
+Ai-DOP 已形成“独立工业数据中台 + S0–S9 制造运营平台 + 智能体运营平台”的总体方向，并具备 MDP 接入、标准层、DWD、KPI、智慧诊断、业务证据、S8 异常、改善闭环、审批和部分 ChatBI 能力。
+
+随着产品进入跨模块分析、多智能体协同、行业化复制和客户 PoC 阶段，仅依靠数据库表、接口 DTO、页面字段和自然语言提示词表达业务含义，会逐步出现以下问题：
+
+- 同一业务对象在不同模块、数据源和智能体中含义不一致。
+- 订单、工单、物料、采购、生产、质量、交付和 KPI 之间的关系散落在 SQL、服务和文档中。
+- 智能体需要重复理解字段、状态和业务关系，容易产生口径冲突。
+- 行业方案可能复制业务模型、问题库和智能体，难以形成稳定产品能力。
+- 结论虽然能展示数据，但难以稳定解释影响路径、适用范围和允许动作。
+
+因此，本方案在既有三层产品架构基础上引入统一的**业务本体层**，将实体、属性、关系、事件、指标、动作、约束和证据形成可治理、可版本化、可调用的业务语义契约。
+
+### 1.2 一句话定位
+
+Ai-DOP 是以可信工业数据为事实基础、以制造业业务本体为语义中枢、以 S0–S9 领域服务为执行能力、以受控智能体推动分析与协同的制造业数据智能运营平台。
+
+### 1.3 核心原则
+
+1. **本体驱动，不是本体替代一切**：本体统一业务含义，不替代数据中台、领域服务、业务流程和知识文档。
+2. **数据为事实**：所有业务事实来自受治理的数据链和正式服务，模型不得生成或修改事实。
+3. **服务做计算**：排程、齐套、KPI、风险评分、诊断和状态转换由确定性规则、算法或领域服务完成。
+4. **智能体做编排**：大模型负责理解目标、选择工具、组织过程、解释结果和草拟行动。
+5. **所有结论有证据**：结论必须关联对象、关系路径、数据时间、口径、来源和适用范围。
+6. **所有动作受控制**：动作必须经过工具白名单、服务端权限、风险分级、人工确认或审批。
+7. **核心稳定、扩展分层**：建立通用制造本体，通过行业包、工厂原型包和客户覆盖层表达差异。
+8. **场景牵引、渐进建设**：首期围绕订单交付风险主链建设最小完整本体，不一次覆盖全部制造业。
+
+---
+
+## 二、什么是 Ai-DOP 业务本体
+
+### 2.1 定义
+
+Ai-DOP 业务本体是对制造运营领域中“有什么、有什么特征、如何关联、发生什么、可以做什么以及受到什么约束”的统一、显式、可计算定义。
+
+本体至少包括：
+
+| 要素 | 含义 | 示例 |
+|---|---|---|
+| 实体 | 稳定的业务对象类型 | 订单、工单、物料、采购单、供应商、异常、KPI |
+| 属性 | 对象的标准特征 | 数量、状态、要求日期、承诺日期、风险等级 |
+| 关系 | 对象之间的业务联系 | 订单驱动工单、工单消耗物料、采购补充物料 |
+| 事件 | 对象在某时间发生的事实 | 订单变更、计划发布、采购延期、检验不合格 |
+| 指标 | 对对象或过程的量化评价 | 准时交付率、齐套率、计划达成率 |
+| 动作 | 平台或用户允许执行的业务行为 | 评估交期、模拟排程、创建催交草稿、提交审批 |
+| 约束 | 对属性、关系和动作的限制 | 状态前提、角色权限、风险等级、审批要求 |
+| 证据 | 支撑事实和结论的可追溯信息 | 来源、主键、数据时间、口径、服务版本、页面入口 |
+
+### 2.2 与其他能力的边界
+
+| 能力 | 负责内容 | 与本体的关系 |
+|---|---|---|
+| 数据库/数据中台 | 保存和治理业务事实 | 将来源数据映射为本体所定义的业务对象和属性 |
+| 主数据 | 企业确认的基础对象与编码 | 是本体实体的重要实例和权威来源 |
+| 知识图谱 | 对实体实例和关系进行图式表达与查询 | 可作为本体实例关系的一种投影，不是本体本身 |
+| 规则与算法 | 根据事实进行计算和判断 | 使用本体对象作为标准输入输出 |
+| 知识库/RAG | 保存制度、SOP、案例和文档 | 文档通过本体对象、动作和适用范围建立关联 |
+| 智能体 | 理解目标、调用工具、组织结果 | 消费本体，不自行定义业务含义 |
+
+以下内容不直接作为本体定义：
+
+- 每日产生的大量业务实例数据；
+- 算法临时计算结果；
+- 大段 SOP、制度和行业报告原文；
+- 未审核的聊天内容和模型记忆；
+- 场景运行状态、运行日志和临时客户参数。
+
+---
+
+## 三、调整后的总体产品架构
+
+### 3.1 总体架构
+
+```text
+用户、岗位、业务事件
+          ↓
+┌──────────────────────────────────────────────┐
+│ 智能体运营平台                               │
+│ 运营指挥官、领域技能、场景编排、解释与交互   │
+└──────────────────────────────────────────────┘
+          ↓ 结构化对象上下文、关系、证据、动作
+┌──────────────────────────────────────────────┐
+│ Ai-DOP S0–S9 制造运营平台                    │
+│ 领域服务、规则、算法、流程、异常、审批、改善 │
+└──────────────────────────────────────────────┘
+          ↑
+┌──────────────────────────────────────────────┐
+│ 业务本体层                                   │
+│ 实体、属性、关系、事件、指标、动作、约束、证据│
+└──────────────────────────────────────────────┘
+          ↑
+┌──────────────────────────────────────────────┐
+│ 独立工业数据中台                             │
+│ 接入、标准化、质量、血缘、数据产品、数据服务 │
+└──────────────────────────────────────────────┘
+          ↑
+ERP / MES / WMS / QMS / SRM / 设备 / 文件 / API
+
+横向治理：租户、Domain、组织、权限、审批、审计、
+版本、质量、幂等、监控、评测、灰度、回滚
+```
+
+### 3.2 三个产品层保持不变
+
+本体层是横跨既有三个产品层的业务语义控制面，不新增一套孤立业务系统：
+
+1. **独立工业数据中台**继续负责数据接入、标准化、质量、血缘、加工和服务。
+2. **Ai-DOP S0–S9**继续负责业务规则、确定性计算、流程、异常、审批和改善闭环。
+3. **智能体运营平台**继续负责理解、分析、编排、解释和受控调用工具。
+
+### 3.3 新增的稳定关系
+
+```text
+数据中台回答：事实是什么、从哪里来、质量如何
+业务本体回答：事实代表什么、与什么相关、允许做什么
+领域服务回答：如何确定性计算、校验和执行
+智能体回答：用户要解决什么、应调用哪些能力、如何解释和协同
+审批审计回答：谁可以做、是否确认、如何追踪和回滚
+```
+
+---
+
+## 四、本体分层与扩展机制
+
+### 4.1 通用制造本体
+
+通用制造本体定义跨行业稳定的核心语义：
+
+- 客户、订单、订单行、产品；
+- 工单、工序、资源、计划版本；
+- 物料、BOM、需求、库存、占用、在途；
+- 采购申请、采购单、交货计划、供应商；
+- 收货、检验、批次、报工、入库、发运；
+- 异常、任务、审批、改善计划、行动项；
+- KPI、目标、诊断节点、业务证据。
+
+通用本体由平台统一维护，已有编码不得因某个行业或客户随意重排或改义。
+
+### 4.2 行业扩展包
+
+行业扩展包只表达行业差异，不复制核心对象：
+
+- 先进装备：项目、设计变更、长周期件、项目交付节点；
+- 汽车零部件：车型项目、客户排程、追溯批次；
+- 电子信息：料号版本、替代料、委外和变更控制；
+- 新材料：配方、批次、收率和过程参数；
+- 医药：批号、有效期、放行和合规约束。
+
+行业扩展需要声明：
+
+- 基于哪个通用本体版本；
+- 新增或扩展哪些对象、属性、关系和规则；
+- 适用的二级行业、工厂原型和制造模式；
+- 来源、审核人、生效期和兼容范围。
+
+### 4.3 工厂原型包
+
+工厂原型包描述 ETO、MTO、MTS、高混低量、大批量流水、批次流程制造、项目制造等模式下：
+
+- 使用哪些业务对象和关系；
+- 典型流程和关键事件；
+- 适用 KPI、问题和诊断路径；
+- 允许动作及其业务约束；
+- 场景和数据的最小闭包。
+
+### 4.4 客户覆盖层
+
+客户覆盖层用于表达客户差异：
+
+- 源系统编码和字段映射；
+- 企业术语和显示名称；
+- 组织、工厂和责任体系；
+- 状态、单位和枚举映射；
+- KPI 目标和阈值；
+- 经评审的客户特有对象、关系和动作。
+
+客户覆盖层不得静默修改平台核心语义；与核心定义冲突时必须显式记录差异并经过评审。
+
+### 4.5 运行实例
+
+正式客户数据、UAT 数据和虚拟工厂数据均为本体实例，通过以下信息隔离和追溯：
+
+- `tenantId`；
+- `domain`；
+- 组织与工厂作用域；
+- 数据来源；
+- 业务主键；
+- 数据身份：行业模拟、客户假设、客户实测；
+- 场景 `runId`（仅场景运行）；
+- 本体版本与数据时间。
+
+---
+
+## 五、统一业务对象与关系主线
+
+### 5.1 首期主线
+
+首期选择“订单交付风险”作为最小完整本体范围：
+
+```text
+客户需求
+→ 销售订单/订单行
+→ 产品与交付要求
+→ 生产工单/工序/计划
+→ 物料需求
+→ 库存、在检、在途、占用、欠料
+→ 采购申请/采购单/交货计划/供应商
+→ 生产、质量、成品入库与发运
+→ 异常
+→ KPI
+→ 改善计划与业务动作
+```
+
+### 5.2 统一对象引用
+
+跨模块、跨智能体和跨服务传递对象时，至少包含：
+
+```text
+objectType
+objectId
+businessKey
+tenantId
+domain
+sourceSystem
+sourceRecordId
+version
+asOfTime
+```
+
+对象引用不得只传显示名称或自然语言描述。
+
+### 5.3 关系路径
+
+关键业务结论需要保留关系路径。例如：
+
+```text
+采购单延期
+→ 影响采购交货计划
+→ 导致物料预计可用时间晚于需求时间
+→ 阻塞生产工单开工
+→ 影响销售订单承诺日期
+→ 造成订单交付 KPI 风险
+```
+
+每一跳关系都必须能回到确定性服务或受治理数据证据。
+
+---
+
+## 六、独立工业数据中台调整
+
+### 6.1 保留能力
+
+继续保留并增强现有“采、存、治、服、管”能力：
+
+- DB 同步、API 推送/拉取、文件、消息和设备接入；
+- RAW/STG、STD、DWD/DWS、KPI 和历史批次；
+- 数据质量、编码映射、元数据、血缘和版本；
+- 标准 API、指标服务、事件服务和服务目录；
+- 调度、日志、告警、重试、对账和健康度。
+
+### 6.2 新增能力
+
+数据中台增加本体映射能力：
+
+- 来源表和字段到标准属性的映射；
+- 来源单据到统一业务对象的映射；
+- 来源关系到标准关系的映射；
+- 来源事件到标准业务事件的映射；
+- 跨来源业务键解析；
+- 对象和关系完整性检查；
+- 数据质量等级、来源和时间的统一证据；
+- 对象、关系、事件和证据的标准服务。
+
+### 6.3 MDP 与业务本体的边界
+
+`mdp_entity` 表达数据接入和同步实体，不直接等同于业务本体实体：
+
+- 一个业务对象可能由多个 MDP 实体共同形成；
+- 一个 MDP 实体可能只提供业务对象的部分属性；
+- 不同来源的多个 MDP 实体可映射到同一业务对象；
+- 技术同步状态不等于业务对象状态。
+
+### 6.4 存储和查询策略
+
+首期采用：
+
+- 关系型本体元数据；
+- JSON Schema 输入输出契约；
+- 统一对象引用；
+- 关系查询与对象上下文服务；
+- 必要的关系索引或物化投影。
+
+首期不将图数据库设为前置条件。只有当多跳关系查询的规模、性能和维护收益得到验证后，再引入图数据库作为可替换的关系投影。
+
+---
+
+## 七、S0–S9 产品调整
+
+### 7.1 S0 运营建模
+
+S0 扩展为业务本体的主要治理入口，管理：
+
+- 业务对象、属性和枚举目录；
+- 关系类型和方向；
+- 业务事件目录；
+- 指标与业务对象关联；
+- 动作、风险等级、前置条件和审批要求；
+- 对象权威来源和业务负责人；
+- 本体版本、评审、发布、停用和影响分析。
+
+职责划分：
+
+- 数据中台负责技术来源和字段映射；
+- S0 负责业务定义和语义治理；
+- 各领域负责人负责口径与动作边界审核；
+- 智能体只能消费已发布定义。
+
+### 7.2 S1–S7
+
+S1–S7 不改变既有业务职责，逐步将接口和服务标准化为统一本体对象：
+
+- S1：订单、客户需求、产品、交期和交付关系；
+- S2：工单、工序、资源、产能、计划版本和订单关系；
+- S3：物料需求、库存、在检、在途、占用、欠料和替代关系；
+- S4：采购、供应商承诺、到货、催交和订单影响；
+- S5：物料批次、IQC、库存和领退料；
+- S6：生产批次、投产、报工、过程检验、设备和人员；
+- S7：FQC、成品批次、入库、库存、发货和交付。
+
+### 7.3 S8 异常监控
+
+S8 异常需要标准关联：
+
+- 异常类型和触发事件；
+- 直接异常对象；
+- 受影响对象及关系路径；
+- 责任组织和责任角色；
+- 处置动作、风险等级和审批要求；
+- 恢复条件、验证证据和影响 KPI。
+
+不新增第二套异常中心。
+
+### 7.4 S9 运营绩效
+
+S9 KPI 和智慧诊断需要标准关联：
+
+- KPI 评价的对象或过程；
+- 公式、方向、目标和阈值；
+- 适用租户、工厂、行业和时间范围；
+- 指标树与业务关系路径；
+- 贡献对象和业务证据；
+- 改善动作及效果验证对象。
+
+不允许由大模型重新解释或计算正式 KPI。
+
+---
+
+## 八、智能体运营平台调整
+
+### 8.1 总体模式
+
+继续采用“一个运营指挥官 + 多个领域技能”的架构。首期不追求多个自治智能体自由对话，而是通过统一对象上下文和结构化契约协同。
+
+### 8.2 领域技能契约
+
+每个领域技能必须声明：
+
+```text
+技能编码与版本
++ 可处理的对象类型
++ 标准输入和输出
++ 可读取的属性、关系和证据
++ 可调用工具
++ 确定性分析流程
++ 权限与风险策略
++ 人工确认或审批要求
++ 失败、超时和降级规则
++ 评测用例
+```
+
+### 8.3 智能体运行上下文
+
+智能体之间传递的上下文至少包含：
+
+```text
+tenantId / domain / orgScope
++ ontologyVersion
++ objectRefs
++ eventRefs
++ relationPaths
++ evidenceRefs
++ asOfTime
++ allowedActions
++ taskId / approvalId（如有）
+```
+
+不得仅通过自由文本猜测上下文。
+
+### 8.4 本体支持的运行能力
+
+- 对象识别和消歧；
+- 对象上下文组装；
+- 关系路径查询；
+- 指标和证据定位；
+- 动作候选筛选；
+- 工具输入输出校验；
+- 风险和权限校验；
+- 结论适用范围校验；
+- 跨智能体结构化交接；
+- 会话、对象、任务和结果关联。
+
+### 8.5 模型边界
+
+模型可以：
+
+- 理解用户目标；
+- 识别相关业务对象；
+- 选择已登记工具；
+- 组织分析步骤；
+- 解释确定性结果；
+- 草拟通知、任务和改善方案。
+
+模型不得：
+
+- 自由生成生产 SQL；
+- 绕过服务端租户和组织权限；
+- 自行计算正式 KPI、库存、齐套或排程结果；
+- 自行认定正式根因；
+- 直接修改数据库或第三方系统；
+- 把未确认对话写成正式本体、规则或制度。
+
+---
+
+## 九、动作、工具、权限和审批
+
+### 9.1 动作与工具绑定
+
+动作定义描述业务意图，工具负责实际查询或执行。示例：
+
+```text
+动作：调整订单交期
+风险等级：高
+适用对象：SalesOrder
+前置条件：订单有效且已完成影响评估
+执行工具：正式订单评审/变更领域服务
+允许角色：经授权的销售负责人、运营负责人
+控制方式：正式审批
+禁止方式：直接写表
+证据：订单版本、原交期、新交期、影响对象和评估结果
+```
+
+### 9.2 风险分级
+
+| 风险 | 示例 | 控制方式 |
+|---|---|---|
+| 低 | 查询、摘要、导航、普通提醒 | 可自动执行并审计 |
+| 中 | 创建草稿、催办、白名单重算预检 | 人工确认后执行 |
+| 高 | 发布计划、修改交期、采购变更、质量放行 | 正式审批后由领域服务执行 |
+| 禁止 | 跨租户访问、直接写库、模型自由 SQL、绕审批 | 永久禁止 |
+
+### 9.3 工具注册门禁
+
+工具上线前必须验证：
+
+- 输入输出引用已发布本体对象；
+- 服务端解析租户和组织作用域；
+- 风险等级与审批方式已配置；
+- 写操作具备幂等、审计、补偿或回滚；
+- 输出包含数据时间、来源和证据；
+- 有权限、越权、失败和重试测试；
+- 有明确责任团队和版本。
+
+---
+
+## 十、知识体系调整
+
+### 10.1 四类知识分层
+
+| 层次 | 内容 | 主要形式 |
+|---|---|---|
+| 本体知识 | 对象、属性、关系、事件、指标、动作、约束 | 结构化、版本化定义 |
+| 规则知识 | 公式、阈值、诊断规则、状态转换、审批要求 | 配置、规则或确定性服务 |
+| 方法知识 | 问题、根因候选、改善方法、验证方式、案例 | 结构化知识和审核案例 |
+| 文档知识 | 制度、SOP、标准、手册、行业资料 | 文档库和 RAG |
+
+### 10.2 知识关联
+
+每条正式知识至少关联：
+
+- 适用的对象、关系、事件或动作；
+- 租户、行业、工厂原型和角色范围；
+- 来源、作者、审核人；
+- 版本、生效期和失效期；
+- 审核状态；
+- 引用场景和评测用例。
+
+模型不得把未审核知识当作正式制度或业务规则。
+
+---
+
+## 十一、行业化价值演示平台的适配
+
+### 11.1 定位
+
+行业化价值演示平台是本体方案的首个重要验证场，但本体不能只为演示服务。正式 Ai-DOP、客户 PoC 和虚拟工厂应使用同一套通用制造本体及相同的领域服务契约。
+
+### 11.2 已确定的调整原则
+
+现有行业化价值演示平台保留以下核心设计：
+
+- 独立虚拟工厂租户、Domain、来源和 `runId`；
+- 模拟数据经过正式接入、标准层、DWD、KPI 和 S8 链路；
+- 禁止直接写 KPI；
+- 基础演示在大模型不可用时仍可完整运行；
+- 不建设第二套看板、诊断、异常中心、改善台账和任务系统；
+- 智能体不得直接修改业务数据；
+- 行业模拟、客户假设和客户实测严格区分。
+
+需要按本体架构调整：
+
+1. 行业运营知识中心拆分为本体、规则、方法和文档四类知识。
+2. `IndustryPack` 作为通用本体的行业扩展，不复制核心业务对象。
+3. `FactoryArchetype` 描述制造模式下的对象、流程、KPI 和约束组合。
+4. `ProblemTemplate` 关联症状对象、影响路径、根因候选、证据和改善动作。
+5. `ScenarioPack` 引用本体对象、关系、事件和动作编码，不直接依赖具体表字段。
+6. 模拟器按照本体对象闭包生成事实，再映射到正式数据链。
+7. 五问价值链使用可追溯关系路径解释问题传导。
+8. 顾问助手、诊断改善助手和场景角色智能体使用相同的对象上下文与动作权限。
+9. 场景运行记录本体版本，保证回放、重置、断言和报告可追溯。
+10. 行业扩展采用“通用核心 + 行业扩展 + 工厂原型 + 客户覆盖”，禁止复制整套问题库和智能体。
+
+### 11.3 方案边界
+
+本节只记录目前已经讨论确认的本体适配原则。行业化价值演示平台还存在其他待调整内容，需要后续专题讨论并统一修订其顶层方案；本轮不提前替代该专题决策。
+
+---
+
+## 十二、产品管理与治理机制
+
+### 12.1 责任划分
+
+| 责任方 | 主要责任 |
+|---|---|
+| 产品团队 | 产品边界、对象体系、用户体验和路线图 |
+| 领域负责人 | 业务定义、口径、规则、动作边界和验收 |
+| 数据团队 | 来源映射、数据质量、血缘、数据产品和服务 SLA |
+| S0/平台团队 | 本体治理、版本、发布和影响分析 |
+| Ai-DOP 研发 | 领域服务、工具、审批、执行和审计 |
+| 智能体团队 | 运行时、编排、模型路由、知识检索和评测 |
+| 行业专家 | 行业扩展、适用条件、来源和审核 |
+| 安全与运维 | 身份、隔离、监控、成本、稳定性和回滚 |
+
+### 12.2 生命周期
+
+```text
+提出定义
+→ 业务评审
+→ 数据映射确认
+→ 契约与影响分析
+→ 测试环境发布
+→ 场景和回归验证
+→ 生产发布
+→ 使用与质量监控
+→ 版本升级或停用
+```
+
+### 12.3 版本策略
+
+- 本体、行业扩展、工具、知识和场景分别版本化。
+- 场景、智能体结论和工具调用记录所使用的版本。
+- 兼容性变更可原版本迭代；破坏性变更必须创建新版本并迁移。
+- 已发布对象编码不得重用。
+- 停用定义保留历史解释能力，不直接物理删除。
+
+---
+
+## 十三、分阶段路线图
+
+### P0：可信基线与语义盘点
+
+目标：确认现有事实、口径、对象和责任边界。
+
+主要交付：
+
+- 多租户、工厂、外部接口和权威来源收口；
+- 现有 S0–S9、MDP、KPI、诊断证据和工具目录盘点；
+- 业务术语冲突清单；
+- 订单交付主链对象和关系草案；
+- 本体治理责任矩阵；
+- 智能体工具风险分级和评测基线。
+
+### P1：订单交付最小本体
+
+目标：建立第一条可验证的统一语义主链。
+
+主要交付：
+
+- 订单、工单、物料、采购、生产、质量、发运、异常和 KPI 对象目录；
+- 属性、状态、关系和事件目录；
+- 权威来源和 MDP 映射；
+- 统一对象引用和证据契约；
+- 本体版本、评审和发布机制；
+- 跨模块业务键闭包测试。
+
+### P2：关系、证据和知识服务
+
+目标：使页面、诊断和智能体能够消费统一语义。
+
+主要交付：
+
+- 对象上下文服务；
+- 关系路径查询服务；
+- 指标与业务对象关联；
+- S1–S7、S8、S9 同口径证据覆盖；
+- 规则、方法和文档知识分层；
+- 订单交付风险分析的确定性组合服务。
+
+### P3：动作与工具治理
+
+目标：建立从理解问题到受控行动的产品能力。
+
+主要交付：
+
+- 动作目录和风险分级；
+- 动作与领域工具绑定；
+- 工具注册门禁；
+- 权限、确认、审批、审计、幂等和回滚；
+- 工具输入输出本体契约测试。
+
+### P4：智能体与行业场景试点
+
+目标：验证本体对智能体可靠性和行业复用的实际价值。
+
+主要交付：
+
+- 运营指挥官；
+- 经营分析和 S8 异常响应技能；
+- 订单交付风险领域技能；
+- 一个二级行业、一个工厂原型和一条主演示故事；
+- 顾问助手和诊断改善助手；
+- 跨智能体结构化交接；
+- 连续真实试点和价值评估。
+
+### P5：多领域与多行业扩展
+
+目标：扩展到计划、供应、质量、仓储、生产和数据运维。
+
+主要交付：
+
+- 更多领域技能；
+- 行业扩展包和工厂原型包；
+- 客户覆盖层治理；
+- 多工厂复制；
+- 必要时引入关系图投影；
+- 白名单低风险动作的有界自治。
+
+---
+
+## 十四、验收和评价指标
+
+### 14.1 本体与数据
+
+- 核心对象权威来源覆盖率；
+- 来源字段到标准属性映射覆盖率；
+- 跨模块业务键闭包通过率；
+- 关键关系完整率；
+- 对象、关系和事件的数据新鲜度；
+- 破坏性版本变更拦截率；
+- 同一对象跨页面、接口和智能体语义一致率。
+
+### 14.2 业务与证据
+
+- 关键 KPI 业务证据覆盖率；
+- 结论关系路径完整率；
+- 证据来源、数据时间和口径标注率；
+- 订单交付影响对象召回率和准确率；
+- 人工业务核验一致率；
+- 改善动作与验证结果关联率。
+
+### 14.3 智能体与工具
+
+- 对象识别和消歧准确率；
+- 工具选择正确率；
+- 工具调用成功率、幂等率和可追溯率；
+- 无证据结论拦截率；
+- 高风险动作审批覆盖率 100%；
+- 跨租户数据或动作事故 0；
+- 建议采纳率及采纳后有效率；
+- 模型不可用时核心业务降级可用率。
+
+### 14.4 行业化复制
+
+- 通用本体复用率；
+- 行业扩展与核心模型冲突数；
+- 新行业场景配置周期；
+- 同场景由模拟数据替换为客户数据的契约复用率；
+- 场景版本、本体版本和运行结果可重放率；
+- 行业模拟、客户假设和客户实测标识完整率。
+
+---
+
+## 十五、相对现有产品方案的主要变动
+
+### 15.1 总体架构变动
+
+| 现有方案 | 调整后方案 |
+|---|---|
+| 数据中台 → S0–S9 → 智能体 | 增加横向业务本体层，形成统一语义控制面 |
+| 业务含义分散在表、接口、服务和文档 | 对象、关系、事件、动作和证据统一定义并版本化 |
+| 数据对象统一主要依赖标准层和接口约定 | 数据标准与业务语义分别治理并建立映射 |
+
+### 15.2 数据中台变动
+
+| 现有方案 | 调整后方案 |
+|---|---|
+| 重点管理数据源、实体、字段、任务和数据产品 | 增加业务对象、关系、事件和证据映射 |
+| MDP 实体作为主要配置单元 | 明确 MDP 技术实体不等于业务本体实体 |
+| 标准 API 主要输出数据结构 | 同时输出对象引用、来源、时间、版本和证据 |
+
+### 15.3 S0–S9 变动
+
+| 现有方案 | 调整后方案 |
+|---|---|
+| S0 管理主数据、规则、质量标准和指标 | S0 增加本体目录、动作、版本和影响分析 |
+| 各模块按自身 DTO 和服务表达业务对象 | 逐步使用统一对象引用和关系契约 |
+| S8/S9 通过现有字段关联业务事实 | 统一关联对象、关系路径、事件、证据和验证动作 |
+
+### 15.4 智能体变动
+
+| 现有方案 | 调整后方案 |
+|---|---|
+| 指挥官调用领域技能和受控工具 | 增加对象上下文、关系查询和本体约束 |
+| 技能以标准输入输出和证据为主 | 输入输出必须声明对象、关系、事件、动作和版本 |
+| 工具白名单控制可调用能力 | 升级为“动作—工具—权限—审批—证据”绑定 |
+| 智能体记忆以会话和任务为主 | 记忆引用对象、事件、任务和结果，不只保存文本 |
+
+### 15.5 知识体系变动
+
+| 现有方案 | 调整后方案 |
+|---|---|
+| 企业知识库和行业知识中心承载结构化知识与文档 | 拆分本体、规则、方法和文档四类知识 |
+| RAG 负责知识检索和解释 | RAG 仅补充文档，正式对象和规则由结构化服务提供 |
+| 行业知识按行业组织 | 通用核心 + 行业扩展 + 工厂原型 + 客户覆盖 |
+
+### 15.6 行业化价值演示平台变动
+
+| 现有方案 | 调整后方案 |
+|---|---|
+| 行业包组织行业术语、问题和目标 | 行业包扩展通用本体，不复制核心对象 |
+| 场景 manifest 组织数据、事件和断言 | manifest 引用标准对象、关系、事件和动作编码 |
+| 模拟器按正式数据链生成场景数据 | 先保证本体对象闭包，再映射到正式数据链 |
+| 智能体按场景和角色调用工具 | 统一使用对象上下文、关系路径和动作权限 |
+
+### 15.7 路线图变动
+
+| 现有方案 | 调整后方案 |
+|---|---|
+| 数据中台、知识、智能体依次建设 | 在智能体试点前增加最小本体和关系证据服务 |
+| 智能体工具目录先行设计 | 对象、动作和工具契约同步设计 |
+| 行业平台 P1 冻结知识、场景和智能体对象模型 | 应同时冻结最小本体版本和行业扩展边界 |
+
+### 15.8 明确不变
+
+- 三个产品层的基本定位不变；
+- S0–S9 业务职责不变；
+- 数据中台仍是可信事实基础；
+- 确定性规则和算法不交给大模型；
+- 智能体不直接查写数据库；
+- 风险分级、人工确认、审批和审计原则不变；
+- 行业化平台复用正式看板、诊断、异常和改善能力；
+- 基础产品和基础演示不依赖大模型可用性。
+
+---
+
+## 十六、主要风险与应对
+
+| 风险 | 表现 | 应对 |
+|---|---|---|
+| 过度建模 | 长期讨论概念，迟迟不能交付场景 | 以订单交付主链为首期边界，按场景扩展 |
+| 本体与数据库重复 | 形成第二套事实存储 | 本体存定义和映射，业务实例留在现有事实表 |
+| 本体与主数据冲突 | 对象编码和权威来源不一致 | S0 业务治理、数据中台技术映射、领域负责人审核 |
+| 行业模型复制 | 每个行业形成独立对象和智能体 | 通用核心 + 行业扩展 + 客户覆盖 |
+| 版本失配 | 场景、工具和智能体引用不同语义 | 全链记录本体版本并建立兼容门禁 |
+| 图技术先行 | 技术复杂度高但业务价值不清 | 首期关系型元数据和服务，图投影按需要引入 |
+| 模型越权 | 通过本体关系发现不应访问的数据或动作 | 服务端租户作用域、对象级权限、工具门禁和审计 |
+| 本体定义正确但数据缺失 | 智能体仍无法形成可靠结论 | 显式标记未知、缺失和不可计算，不允许模型补猜 |
+| 规则混入本体 | 频繁变化导致模型不稳定 | 本体、规则、方法和文档分层治理 |
+
+---
+
+## 十七、当前建设基础
+
+### 17.1 代码层
+
+- 已有 MDP 接入、标准层、DWD、KPI、S1–S7 转换服务、S8、S9、诊断证据、审批和部分 ChatBI 能力。
+- 已有领域服务和受控工具可复用基础。
+- 当前 `server/` 范围内未检索到正式的 ontology/本体定义与运行服务。
+- 结论：**业务基础代码有，本体运行层代码无。**
+
+### 17.2 配置层
+
+- 开发库当前已有 `mdp_entity` 227 条、`mdp_source` 16 条，可作为来源和映射盘点基础。
+- 当前未发现 ontology 命名配置表，只存在 `ado_s9_chatbi_semantic` 语义表。
+- 结论：**数据接入配置已形成规模，正式本体配置未开通。**
+
+### 17.3 数据层
+
+- `ado_s9_chatbi_semantic` 当前非删除记录为 0。
+- 该结果只表示此语义表尚无数据，不代表 S0–S9 业务数据为空。
+- 结论：**正式语义数据未通；既有业务事实需按首期本体范围另行盘点和映射。**
+
+---
+
+## 十八、跨模块影响
+
+- **独立数据中台**：增加本体映射、对象关系、事件和证据服务。
+- **S0**：增加业务语义治理、动作目录、版本和影响分析。
+- **S1–S7**：逐步统一对象引用、关系和事件契约。
+- **S8**：异常与标准对象、影响路径、处置动作和验证证据关联。
+- **S9**：KPI、诊断、证据、改善和本体对象统一。
+- **审批与任务**：动作风险、责任角色和审批契约统一。
+- **知识体系**：拆分本体、规则、方法和文档。
+- **智能体平台**：增加对象上下文、关系查询、本体约束和结构化交接。
+- **行业化价值演示平台**：行业包、场景、模拟器和角色智能体引用统一语义；其他方案调整另行讨论。
+- **导出和报告**：显示对象、来源、时间、版本、证据和适用范围。
+
+涉及上述模块的实施工作必须按批次单独评审，不因本顶层方案发布而自动进入开发。
+
+---
+
+## 十九、反向影响推演
+
+- **代码调用面 → 需同步改**：后续实施时反查 MDP、S0–S9、诊断证据、审批、任务、智能体工具、场景引擎和模拟器的全部调用方；本轮仅形成方案，不修改代码。
+- **数据契约面 → 需同步改**：统一对象引用、关系、事件、动作、指标、证据和版本契约，并覆盖看板、查询、S8、S9、ChatBI、智能体和导出。
+- **多数据源面 → 需同步改**：T8、165 MES/WMS、自建单、标准 API 入站及模拟来源均映射到统一语义；来源缺字段时必须标记未知或不可计算。
+- **多租户/Domain 面 → 需同步改**：平台核心定义、行业扩展、客户覆盖和运行实例分层；所有实例、关系、知识、工具和动作继承服务端可信租户与组织作用域。
+- **运行面 → 需同步改**：后续需建设本体版本发布、缓存刷新、迁移、兼容、回滚、监控和工具注册门禁；场景运行记录本体版本。
+- **验证面 → 需同步改**：建立映射完整性、业务键闭包、关系路径、口径一致性、工具契约、跨租户隔离、版本兼容和端到端场景守卫测试。
+
+---
+
+## 二十、后续决策门
+
+本方案进入实施设计前，需要依次确认：
+
+1. 通用制造本体、行业扩展、工厂原型和客户覆盖四层结构；
+2. 首期是否以订单交付风险主链为唯一建设范围；
+3. S0、数据中台、领域团队和智能体团队的治理责任；
+4. 第一批对象、关系、事件、指标和动作编码；
+5. 本体元数据、对象引用和关系服务的技术契约；
+6. 首个智能体试点和首个行业化演示场景；
+7. 行业化价值演示平台其他待调整内容及其独立修订范围；
+8. 代码、配置、数据迁移和 UAT 的分批实施任务书。
+
+---
+
+## 二十一、结论
+
+引入业务本体后，Ai-DOP 的总体方向不被推翻，而是由“数据、模块和智能体相互连接”升级为“在统一业务语义约束下协同工作”：
+
+```text
+工业数据中台提供可信事实
+→ 业务本体统一对象、关系、事件和动作
+→ S0–S9 完成确定性分析、流程和执行
+→ S8/S9 形成异常、诊断、改善和验证闭环
+→ 智能体理解目标并受控编排领域能力
+→ 权限、审批、证据和审计保证全链可信
+→ 行业扩展与客户覆盖实现规模化复制
+```
+
+最佳建设方式不是先完成一个覆盖全部制造业的庞大知识图谱，而是以订单交付风险为首期场景，建立最小完整本体、关系证据服务和动作工具契约，在正式 Ai-DOP 与行业化价值演示平台中共同验证，再逐步扩展到更多领域、行业和客户。

doc/plan/行业化Ai-DOP价值演示平台/Ai-DOP行业化价值演示平台P0业务交互Demo三日工作计划.md

@@ -0,0 +1,561 @@
+# Ai-DOP 行业化价值演示平台 P0 业务交互 Demo 三日工作计划
+
+| 项目 | 内容 |
+|---|---|
+| 计划定位 | P0 业务交互 Demo 快速制作与评审计划 |
+| 制作周期 | 2026 年 10 月 27–29 日，共 3 个工作日 |
+| 业务展示 | 2026 年 10 月 30 日（第 4 天） |
+| 主要目标 | 用可点击高保真 Demo 与业务快速确认产品构想、主路径、信息表达和动态改善体验 |
+| 交付性质 | 前端交互原型，不代表正式功能、正式数据或真实行业收益 |
+| 依据方案 | [`Ai-DOP行业化价值演示平台顶层方案.md`](./Ai-DOP行业化价值演示平台顶层方案.md) |
+
+---
+
+## 一、目标
+
+在 3 个制作日内完成一套可稳定展示的业务交互 Demo，使业务人员能够直观看到：
+
+```text
+选择行业/工厂原型/体量
+→ 查看合成健康参考
+→ 选择问题病例
+→ 查看问题发生和传导
+→ 查看诊断依据
+→ 动态播放措施 A/B/C
+→ 查看每项措施的直接表征和延迟结果
+→ 查看恢复、部分有效或反弹
+→ 查看价值摘要和 PoC 建议
+```
+
+本阶段主要回答以下问题：
+
+1. 业务人员是否理解“行业—工厂原型—体量—问题”的选择方式。
+2. 合成健康参考是否能帮助客户理解“好的应该是什么样”。
+3. 病例是否能清楚展示问题如何发生、暴露和传导。
+4. 措施 A/B/C 与业务事实、领先指标、结果指标和保护指标的对应关系是否清楚。
+5. 动态播放是否比静态页面更容易说明 Ai-DOP 的价值。
+6. “场景实验室—场景资产中心—价值演示平台”的边界是否容易理解。
+7. 业务希望第一批优先建设哪些行业、问题和改善过程。
+
+---
+
+## 二、成功标准
+
+第 4 天展示前必须达到：
+
+- Demo 可在指定演示电脑稳定启动。
+- 主路径无断链、无空白页、无明显布局错误。
+- 不依赖后端、数据库、大模型和外部网络即可完成核心演示。
+- 同一操作顺序每次得到相同展示结果。
+- 支持播放、暂停、上一步、下一步、重置和检查点跳转。
+- 能完整展示“健康—恶化—暴露—诊断—措施 A/B/C—验证”的过程。
+- 每项措施至少有一个直接业务表征和一个结果变化。
+- 页面明确标识“合成演示数据/交互原型”，不冒充真实行业样本。
+- 准备主讲脚本、备用路线和异常恢复方式。
+- 形成业务待确认问题清单和会议记录模板。
+
+---
+
+## 三、范围控制
+
+### 3.1 本次必须完成
+
+- 桌面端高保真可点击原型。
+- 一种示例行业表达。
+- 一种工厂原型和一种体量。
+- 一套合成健康参考。
+- 一个完整问题病例。
+- 三项代表性改善措施 A/B/C。
+- 一条从差到好的主播放轨道。
+- 一个部分有效或反弹检查点。
+- 管理、业务、技术三个观察视角的概念呈现。
+- 价值摘要和 PoC 建议页。
+- 第 4 天业务展示材料和反馈记录模板。
+
+### 3.2 本次不做
+
+- 不建设正式虚拟工厂、实验规划和批量仿真。
+- 不建设问题自动发现、改善搜索和多目标优化。
+- 不建设场景资产中心后台。
+- 不接入 MDP、STD、DWD、KPI 或 S8 正式链路。
+- 不建设真实数据生成、场景编译和发布服务。
+- 不建设完整智能体、知识库或 RAG。
+- 不实现真实权限、审批、审计和多租户数据隔离。
+- 不实现 15/30/60 分钟三套完整播放内容；本次先完成一条约 10–15 分钟主路线。
+- 不制作正式发布版本和客户宣传材料。
+
+### 3.3 原型实现原则
+
+- 使用前端静态 JSON 或 TypeScript 数据描述场景。
+- 使用前端状态机模拟虚拟时间和检查点切换。
+- 使用预设快照展示 KPI、对象、异常和措施变化。
+- 自动导航、高亮和字幕由应用内部状态驱动。
+- 不使用浏览器录屏、外部鼠标宏或直接修改图表 DOM 冒充动态过程。
+- 所有数值只用于体验确认，并显示“合成演示”标识。
+
+---
+
+## 四、Demo 页面与交互清单
+
+### 4.1 首页/客户画像
+
+展示：
+
+- 客户类型和关注角色。
+- 行业、二级行业。
+- 工厂原型。
+- 企业体量。
+- 关注问题。
+
+交互：
+
+- 逐步选择。
+- 推荐健康参考和病例。
+- 一键进入演示。
+
+### 4.2 合成健康参考
+
+展示：
+
+- 工厂运营概况。
+- 订单、产能、物料、采购、生产、质量和交付健康状态。
+- 结果、驱动和保护指标。
+- 适用行业、工厂原型和体量。
+- 数据身份、假设和可信度。
+
+交互：
+
+- 查看指标解释。
+- 查看业务对象关系。
+- 与病例初始状态切换对比。
+
+### 4.3 病例总览
+
+展示：
+
+- 问题名称和影响摘要。
+- 症状、根因假设和传导路径。
+- 受影响订单、工单、物料和采购单。
+- 当前 KPI、S8 异常和风险等级。
+- “不采取措施”的后续趋势。
+
+交互：
+
+- 进入问题发生过程。
+- 查看业务依据。
+- 进入诊断。
+
+### 4.4 动态改善播放器
+
+检查点：
+
+1. 健康基线。
+2. 问题发生。
+3. 问题暴露。
+4. 诊断与根因假设。
+5. 措施 A。
+6. 措施 A 的直接表征。
+7. 措施 B。
+8. 措施 B 的延迟结果。
+9. 措施 C。
+10. 恢复验证。
+11. 部分有效或反弹。
+
+播放控制：
+
+- 播放、暂停。
+- 上一步、下一步。
+- 1 倍、2 倍速度。
+- 检查点跳转。
+- 从头播放。
+- 一键重置。
+
+同步展示：
+
+- 虚拟业务日期和当前阶段。
+- 当前措施、责任角色和作用对象。
+- 措施前后业务事实。
+- 领先、结果和保护指标。
+- S8 异常和改善任务变化。
+- 问题与改善关系路径。
+- 自动讲解字幕。
+
+### 4.5 改善措施详情
+
+每项措施展示：
+
+- 措施名称和目标。
+- 作用对象。
+- 前置条件。
+- 直接动作。
+- 直接表征。
+- 生效延迟。
+- 预期结果。
+- 副作用和保护指标。
+- 成功、部分有效和失效条件。
+
+### 4.6 三态对比
+
+同时比较：
+
+- 病例初始状态。
+- 当前改善状态。
+- 合成健康参考。
+
+重点比较：
+
+- 订单交付风险。
+- 工单开工和进度。
+- 物料齐套。
+- 采购到货。
+- 库存。
+- 质量。
+- 成本或资源负荷。
+
+### 4.7 产品边界说明
+
+用简化视图说明：
+
+```text
+行业运营场景实验室
+生成和验证问题、改善及数据
+        ↓ 发布
+场景资产中心
+管理场景版本和可信度
+        ↓ 分发
+行业化价值演示平台
+稳定播放和客户沟通
+```
+
+该页面只用于确认产品边界，不制作实验室和资产中心的完整后台原型。
+
+### 4.8 价值摘要与 PoC 建议
+
+展示：
+
+- 识别的问题假设。
+- Ai-DOP 能力映射。
+- 改善措施及模拟效果。
+- 当前结论的可信度和适用范围。
+- 客户需要提供的数据。
+- 建议 PoC 范围和验证指标。
+
+---
+
+## 五、示例故事要求
+
+为保证 3 天可完成，本次只选择一条跨模块故事。具体业务内容在第 1 天上午冻结，建议优先采用：
+
+> 关键物料采购延期 → 物料齐套不足 → 工单开工风险 → 订单交付风险
+
+候选措施：
+
+- 措施 A：采购催交与分批交付。
+- 措施 B：跨仓库存调拨。
+- 措施 C：启用替代料或调整生产顺序。
+
+每项措施必须展示不同类型的表征：
+
+- A：供应商回复、承诺日期、在途日期变化。
+- B：调拨任务、在途数量、可用库存和缺料量变化。
+- C：替代关系或计划调整、工单齐套和开工日期变化。
+
+最终展示：
+
+- 订单交付风险是否恢复。
+- 库存、成本、质量或其他订单是否受到副作用影响。
+- 哪些措施有效、部分有效或存在适用条件。
+
+---
+
+## 六、三日制作计划
+
+### 第 1 天：范围冻结、故事与交互骨架
+
+日期：2026 年 10 月 27 日
+
+#### 上午：冻结业务故事
+
+任务：
+
+- 确定示例行业、工厂原型和体量。
+- 确定问题、传导路径和影响对象。
+- 确定合成健康参考。
+- 确定措施 A/B/C。
+- 确定结果、驱动和保护指标。
+- 确定健康、问题、诊断、改善和验证检查点。
+- 确定第 4 天业务待确认问题。
+
+交付：
+
+- 一页业务故事卡。
+- 对象关系和问题传导图。
+- 指标清单。
+- 措施—表征对照。
+- 场景检查点清单。
+
+完成门槛：
+
+- 当天中午后不再增加第二个病例。
+- 措施 A/B/C 和最终结果不再做结构性变更。
+
+#### 下午：信息架构和可点击骨架
+
+任务：
+
+- 完成页面导航和主路径。
+- 完成首页、健康参考、病例总览、播放器、价值摘要页面骨架。
+- 建立静态场景数据结构。
+- 建立检查点状态机。
+- 完成基础视觉规范和“合成演示”标识。
+
+交付：
+
+- 可启动的 Demo 骨架。
+- 从首页进入病例和播放器的完整点击路径。
+- 第一版静态 JSON/TypeScript 场景数据。
+
+当日评审：
+
+- 15 分钟内部走查。
+- 只确认路径、信息层次和核心术语。
+
+### 第 2 天：高保真页面与动态改善播放
+
+日期：2026 年 10 月 28 日
+
+#### 上午：核心业务页面
+
+任务：
+
+- 完成合成健康参考页面。
+- 完成病例总览和问题传导。
+- 完成改善措施详情。
+- 完成三态对比。
+- 完成管理、业务、技术观察视角的关键内容。
+
+交付：
+
+- 核心页面达到业务评审所需的信息完整度。
+- 指标、对象和措施之间能够相互追溯。
+
+#### 下午：动态播放器
+
+任务：
+
+- 实现播放、暂停、上一步、下一步、倍速、跳转和重置。
+- 实现虚拟业务日期推进。
+- 实现措施 A/B/C 的逐步变化。
+- 实现 KPI、业务事实、S8 和改善任务的同步变化。
+- 实现页面聚焦、高亮和自动讲解字幕。
+- 增加恢复、部分有效或反弹检查点。
+
+交付：
+
+- 可从健康状态连续播放到改善验证。
+- 可从任意检查点恢复播放。
+- 相同路径重复播放结果一致。
+
+当日评审：
+
+- 完整播放一遍。
+- 记录理解困难、节奏过快、信息过载和业务逻辑断点。
+
+### 第 3 天：收口、验证和业务展示准备
+
+日期：2026 年 10 月 29 日
+
+#### 上午：产品收口
+
+任务：
+
+- 修正第 2 天走查问题。
+- 统一术语、颜色、数字格式和状态表达。
+- 完成产品边界说明。
+- 完成价值摘要和 PoC 建议。
+- 补齐来源、假设、可信度和适用范围标识。
+- 删除无法在第 4 天稳定展示的非核心交互。
+
+交付：
+
+- 功能冻结版 Demo。
+- 主路径和备用路径。
+
+#### 下午：演示验证与材料
+
+任务：
+
+- 按主讲脚本连续演练至少 3 次。
+- 验证启动、刷新、跳转、重置和异常恢复。
+- 准备离线运行包或本地启动说明。
+- 准备页面截图备用材料。
+- 编写 10–15 分钟主讲脚本。
+- 编写业务待确认问题清单。
+- 准备会议纪要和反馈记录模板。
+- 建立问题分级：阻断、重要、建议。
+
+交付：
+
+- 最终演示包。
+- 启动和恢复说明。
+- 主讲脚本。
+- 业务确认清单。
+- 会议记录模板。
+- 已知问题清单。
+
+完成门槛：
+
+- 当天下午功能冻结。
+- 只修复阻断演示的问题，不再增加页面和功能。
+
+---
+
+## 七、第 4 天业务展示与沟通计划
+
+日期：2026 年 10 月 30 日
+
+建议总时长：60–90 分钟。
+
+### 7.1 开场与目标，5 分钟
+
+- 说明本次是业务交互原型。
+- 说明数据为合成演示，不代表真实行业收益。
+- 说明会议目标是确认产品方向和优先范围。
+
+### 7.2 完整演示，15 分钟
+
+按主路径连续展示：
+
+```text
+选择行业/体量
+→ 健康参考
+→ 问题发生
+→ 诊断
+→ 措施 A/B/C
+→ 恢复/反弹
+→ 价值摘要
+```
+
+第一次播放中途不讨论，确保业务先看到完整故事。
+
+### 7.3 分段讨论，30–45 分钟
+
+按以下主题回到对应页面讨论：
+
+1. 行业、工厂原型和体量选择是否合理。
+2. 健康参考需要展示哪些内容。
+3. 问题发生和传导是否符合业务认知。
+4. 改善措施的直接表征是否清楚。
+5. 动态播放速度、信息密度和讲解方式是否合适。
+6. 是否需要交互选择不同措施。
+7. 哪些问题最值得优先进入实验室。
+8. 客户最关心的价值和 PoC 证据是什么。
+
+### 7.4 产品边界确认，10 分钟
+
+确认：
+
+- 实验室负责发现和生产场景。
+- 资产中心负责审核和发布。
+- 演示平台负责稳定消费和展示。
+- 第一阶段不依赖完整智能体。
+
+### 7.5 结论与下一步，10 分钟
+
+输出：
+
+- 已确认项。
+- 需修改项。
+- 暂缓项。
+- 第一批问题候选。
+- P1 范围和优先级。
+- 下一次评审时间。
+
+---
+
+## 八、业务确认清单
+
+第 4 天需逐项形成结论：
+
+- [ ] 产品定位和目标用户是否正确。
+- [ ] 三个子产品的边界是否清楚。
+- [ ] 行业、工厂原型和体量选择是否易懂。
+- [ ] 合成健康参考是否有业务价值。
+- [ ] 病例总览是否能形成问题共鸣。
+- [ ] 问题传导路径是否容易理解。
+- [ ] 措施 A/B/C 与具体数据表征是否对应。
+- [ ] 从差到好的动态过程是否可信。
+- [ ] 是否需要展示无效、部分有效和反弹。
+- [ ] 管理、业务、技术三个视角是否必要。
+- [ ] 价值摘要是否有助于推动 PoC。
+- [ ] 第一批优先探索的问题是什么。
+- [ ] 第一批需要的故障和改善动作原语是什么。
+- [ ] P1 是否可以进入详细设计。
+
+---
+
+## 九、人员与协作建议
+
+最小团队建议：
+
+- 产品/业务设计 1 人：故事、术语、页面信息和会议主持。
+- 交互/视觉 1 人：页面布局、视觉和动态表达。
+- 前端 1–2 人：Demo、状态机、播放器和演示包。
+- 技术负责人按检查点参与：确认未来架构可实现，防止原型形成错误承诺。
+
+三日内采用单一负责人做范围裁决。任何新增需求必须替换现有范围，不得只增不减。
+
+---
+
+## 十、风险与应对
+
+- **三天范围过大**：只做一个病例、一套健康参考和三项措施。
+- **业务故事未及时冻结**：第 1 天中午设置硬门槛，未确认部分使用明确假设。
+- **把前端动画误认为正式能力**：全程显示原型和合成数据标识，并说明正式架构。
+- **页面太多导致主线不完整**：优先保证播放器和五问闭环，辅助页面可合并。
+- **动态效果影响稳定性**：使用前端状态机和检查点快照，不依赖网络和实时生成。
+- **业务临时要求多个行业**：只展示行业选择框架，不增加第二套完整场景。
+- **第 4 天现场故障**：准备本地离线包、重置入口、备用路线和关键页面截图。
+- **讨论发散为实施细节**：会议先确认业务价值和交互，技术问题记录到 P1。
+
+---
+
+## 十一、交付物
+
+第 3 天结束时交付：
+
+1. 可点击高保真业务交互 Demo。
+2. 静态场景数据和检查点定义。
+3. 一条动态改善主播放轨道。
+4. 合成健康参考、病例和措施 A/B/C 页面。
+5. 价值摘要和 PoC 建议页。
+6. 产品边界说明。
+7. 主讲脚本和备用演示路线。
+8. 启动、重置和异常恢复说明。
+9. 业务确认清单和会议记录模板。
+10. 已知问题及 P1 待办候选。
+
+第 4 天会议后补充：
+
+11. 业务评审纪要。
+12. 已确认/需修改/暂缓清单。
+13. P1 范围建议。
+
+---
+
+## 十二、反向影响推演
+
+- **代码调用面 → 无影响**：本计划只建设独立前端交互 Demo，不接入正式领域服务；原型中使用的未来接口概念需在 P1 重新评审。
+- **数据契约面 → 需同步记录**：静态场景需按本体对象、问题、措施、效果、检查点和播放轨道组织，作为 P1 契约输入，但不视为正式契约。
+- **多数据源面 → 无运行影响**：本阶段不调用 DB_SYNC、API_PULL、API_INBOUND；页面需保留三种正式入站的技术表达。
+- **多租户/Domain 面 → 无运行影响**：本阶段无真实租户数据；所有页面显示“合成演示”，不得混入 Demo、UAT 或客户数据。
+- **运行面 → 需同步准备**：提供本地启动、离线运行、重置和备用截图，保证第 4 天展示稳定。
+- **验证面 → 需同步执行**：验证主路径、播放器控制、检查点一致性、重复播放、重置、数据身份标识和演示恢复。
+
+---
+
+## 十三、完成定义
+
+本 P0 不以“完成正式产品功能”为完成标准，而以以下结果为准：
+
+> 第 4 天业务人员能够在一套稳定、可操作的 Demo 中看到完整价值故事，明确指出哪些设计正确、哪些需要修改、第一批问题和改善过程应该优先做什么，并据此形成可以进入 P1 的范围基线。

doc/plan/行业化Ai-DOP价值演示平台/Ai-DOP行业化价值演示平台P0业务交互Demo开发执行任务书.md

@@ -0,0 +1,549 @@
+# Ai-DOP 行业化价值演示平台 P0 业务交互 Demo 开发执行任务书
+
+| 项目 | 内容 |
+|---|---|
+| 任务定位 | 可直接交给开发人员或 AI 编码工具执行的 P0 前端 Demo 任务书 |
+| 交付性质 | 高保真业务交互原型，不是正式生产功能 |
+| 技术范围 | Web 前端、静态场景数据、确定性动态播放器 |
+| 计划依据 | [`Ai-DOP行业化价值演示平台P0业务交互Demo三日工作计划.md`](./Ai-DOP行业化价值演示平台P0业务交互Demo三日工作计划.md) |
+| 顶层依据 | [`Ai-DOP行业化价值演示平台顶层方案.md`](./Ai-DOP行业化价值演示平台顶层方案.md) |
+
+---
+
+## 一、任务目标
+
+在现有 Ai-DOP Web 工程中建设一套可独立运行、可点击、可重复播放的行业化价值演示 Demo，完整表达以下业务故事：
+
+```text
+选择行业/工厂原型/企业体量
+→ 查看匹配的合成健康参考
+→ 选择并进入问题病例
+→ 展示问题发生、暴露和跨模块传导
+→ 展示诊断依据与根因假设
+→ 依次播放改善措施 A/B/C
+→ 展示每项措施对应的业务事实和指标变化
+→ 展示恢复、部分有效或反弹
+→ 输出价值摘要和 PoC 建议
+```
+
+Demo 用于与业务人员确认产品方向、业务表达和交互体验，不用于证明真实行业收益。
+
+---
+
+## 二、完成定义
+
+满足以下条件视为任务完成：
+
+- 有一个可直接访问的 Ai-DOP 隐藏路由或受控 Demo 入口。
+- 不依赖后端接口、数据库、大模型和外部网络即可完成核心演示。
+- 有一套完整合成健康参考和一个完整问题病例。
+- 有措施 A/B/C 及其直接表征、延迟结果和保护指标。
+- 动态播放器支持播放、暂停、单步、倍速、检查点跳转和重置。
+- 能展示健康、恶化、暴露、诊断、改善、恢复和反弹/部分有效。
+- 所有页面和导出内容明确标识“合成演示数据/交互原型”。
+- 同一版本、同一操作顺序重复播放结果一致。
+- 刷新、重置和重复进入不会残留计时器或错误状态。
+- 项目可正常构建，新增测试通过，浏览器控制台无阻断错误。
+- 有演示启动、主路径、重置和故障恢复说明。
+
+---
+
+## 三、范围
+
+### 3.1 必须实现
+
+1. 行业、工厂原型、企业体量和关注问题选择。
+2. 合成健康参考。
+3. 病例总览和问题传导。
+4. 动态改善播放器。
+5. 措施 A/B/C 详情。
+6. 病例初始、当前改善、合成健康三态对比。
+7. 管理、业务、技术三个观察视角。
+8. “实验室—资产中心—演示平台”产品边界说明。
+9. 价值摘要和 PoC 建议。
+10. 一条约 10–15 分钟的完整演示主路径。
+11. 一条部分有效或反弹路径。
+
+### 3.2 明确不做
+
+- 不建设正式虚拟工厂和仿真引擎。
+- 不建设实验规划、问题自动发现、改善搜索和场景资产中心后台。
+- 不连接 MDP、STD、DWD、KPI、S8 或其他后端 API。
+- 不新增后端接口、数据库表、种子数据或定时任务。
+- 不建设完整智能体、知识库、RAG 或模型调用。
+- 不使用真实客户数据、Demo/UAT 数据或生产凭据。
+- 不实现真实权限审批和多租户数据隔离。
+- 不使用外部鼠标宏、录屏或固定视频代替应用内交互。
+- 不为多个行业分别制作完整病例。
+- 不为了原型顺手重构现有 Ai-DOP 公共组件或业务模块。
+
+---
+
+## 四、开发基线和建议位置
+
+### 4.1 技术基线
+
+沿用现有 Web 技术栈：
+
+- Vue 3；
+- TypeScript；
+- Vite；
+- Element Plus；
+- ECharts；
+- Pinia 或组合式函数；
+- Vitest。
+
+原则上不新增第三方依赖。现有依赖可以满足卡片、步骤条、图表、关系展示和动画需要。
+
+### 4.2 建议目录
+
+开发人员可根据现有工程结构微调，建议集中在：
+
+```text
+Web/src/views/aidop/industry-value-demo/
+├─ index.vue
+├─ components/
+├─ composables/
+├─ data/
+├─ types.ts
+└─ *.spec.ts
+```
+
+建议至少拆分：
+
+- 选择与客户画像；
+- 健康参考；
+- 病例总览；
+- 问题传导；
+- 动态播放器；
+- 措施详情；
+- 三态对比；
+- 价值摘要。
+
+组件粒度由开发人员自行决定，避免把整套 Demo 写入一个超大 Vue 文件。
+
+### 4.3 路由与 FUNC
+
+- P0 建议增加隐藏前端路由，避免新增后端菜单种子和授权依赖。
+- 路由名称、路径和组件名称保持一致、可追溯。
+- 隐藏业务路由仍须按仓库规则登记 `Web/src/constants/aidopFuncCodes.ts`。
+- FUNC 编号按实施时 S9 扩展段最大编号加一，不重排已有编号。
+- 若业务决定加入正式菜单，需另行评审 `sys_menu` 种子、权限和跨模块影响，不在本任务中默认实施。
+
+---
+
+## 五、静态场景数据契约
+
+### 5.1 数据组织原则
+
+- 使用 TypeScript 类型和静态 JSON/TS 数据统一描述场景。
+- 页面只消费场景状态，不在各组件内分别写死数字。
+- 所有检查点共享同一组稳定业务对象标识。
+- 检查点只产生后续事实，不回写或篡改历史坏数据。
+- 数值变化必须能从措施和表征关系中解释。
+- 当前阶段数据仅用于体验确认，不宣称行业真实性。
+
+### 5.2 最小对象
+
+至少定义：
+
+- `DemoProfile`：行业、工厂原型、体量和角色。
+- `HealthyReference`：合成健康参考、指标和适用范围。
+- `ProblemCase`：问题、根因假设、影响和传导关系。
+- `BusinessObjectRef`：订单、工单、物料、采购单等对象引用。
+- `MetricSnapshot`：结果、驱动和保护指标。
+- `InterventionStep`：措施、前置条件、动作、表征、延迟和副作用。
+- `ScenarioCheckpoint`：阶段、虚拟日期、业务事实、指标、异常和任务。
+- `ReplayTrack`：检查点顺序、停留时间、讲解和页面聚焦。
+- `ValueSummary`：能力映射、模拟效果、可信度和 PoC 建议。
+
+类型名称可以调整，但职责不可丢失。
+
+### 5.3 必须具备的检查点
+
+1. 健康基线。
+2. 问题发生。
+3. 问题暴露。
+4. 诊断与根因假设。
+5. 措施 A 执行。
+6. 措施 A 直接表征。
+7. 措施 B 执行。
+8. 措施 B 延迟结果。
+9. 措施 C 执行。
+10. 恢复验证。
+11. 部分有效或反弹。
+
+### 5.4 示例故事
+
+建议采用：
+
+> 关键物料采购延期 → 物料齐套不足 → 工单无法按期开工 → 订单交付风险
+
+措施示例：
+
+- A：采购催交与分批交付。
+- B：跨仓库存调拨。
+- C：启用替代料或调整生产顺序。
+
+开发人员可在不改变因果链和验收目标的前提下优化名称和数据。
+
+---
+
+## 六、页面和业务能力
+
+### 6.1 选择页
+
+实现：
+
+- 行业、二级行业；
+- 工厂原型；
+- 企业体量；
+- 关注问题；
+- 推荐健康参考和病例；
+- 一键开始演示。
+
+本次只需一个选项组合具备完整内容，其他选项可显示“规划中”，不得伪装为已完成场景。
+
+### 6.2 合成健康参考
+
+展示：
+
+- 工厂运营概况；
+- 订单、产能、物料、采购、生产、质量和交付状态；
+- 结果、驱动和保护指标；
+- 适用行业、工厂原型和体量；
+- 数据身份、参数假设和可信度；
+- 与病例初始状态的对比入口。
+
+必须使用“合成健康参考”，不使用“行业最佳”“最佳实践样本”等未经验证的表述。
+
+### 6.3 病例总览
+
+展示：
+
+- 症状和根因假设；
+- 受影响订单、工单、物料、采购单；
+- 跨模块传导关系；
+- KPI 和 S8 异常状态；
+- 不采取措施时的趋势；
+- 进入动态播放的入口。
+
+### 6.4 动态改善播放器
+
+必须具备：
+
+- 播放、暂停；
+- 上一步、下一步；
+- 1 倍、2 倍速度；
+- 检查点跳转；
+- 从头播放；
+- 一键重置；
+- 当前虚拟业务日期和阶段；
+- 自动讲解字幕；
+- 当前措施和责任角色；
+- KPI、业务事实、异常和任务同步变化；
+- 页面或区域高亮。
+
+实现要求：
+
+- 使用集中状态机或组合式函数管理播放器。
+- 禁止在多个组件中分散使用不可控的 `setTimeout` 链。
+- 组件卸载、路由离开和重置时必须释放计时器。
+- 切换检查点后所有展示必须来自同一检查点快照。
+- 自动播放与人工单步使用同一状态转换逻辑。
+
+### 6.5 措施详情
+
+每项措施展示：
+
+- 目标和作用对象；
+- 前置条件；
+- 业务动作；
+- 直接表征；
+- 生效延迟；
+- 结果变化；
+- 保护指标；
+- 副作用；
+- 成功、部分有效或失效条件。
+
+### 6.6 三态对比
+
+对比：
+
+- 病例初始状态；
+- 当前改善状态；
+- 合成健康参考。
+
+至少覆盖：
+
+- 订单交付风险；
+- 工单开工或进度；
+- 物料齐套；
+- 采购到货；
+- 库存；
+- 质量或成本保护指标。
+
+### 6.7 三种观察视角
+
+- 管理视图：结果、风险、措施和价值。
+- 业务视图：订单、工单、物料、采购和任务。
+- 技术视图：合成数据身份、检查点、来源通道、本体/场景版本概念。
+
+三种视角必须对应同一场景和检查点，不能展示互相冲突的数据。
+
+### 6.8 产品边界
+
+用简洁视图说明：
+
+```text
+行业运营场景实验室
+→ 场景资产中心
+→ 行业化价值演示平台
+```
+
+只需说明职责、资产流转和边界，不建设实验室或资产中心的详细操作后台。
+
+### 6.9 价值摘要
+
+展示：
+
+- 客户问题假设；
+- Ai-DOP 能力映射；
+- 措施和模拟结果；
+- 可信度和适用范围；
+- 客户需要提供的数据；
+- PoC 建议范围和验证指标。
+
+---
+
+## 七、工作包
+
+工作包按依赖顺序执行，不绑定具体天数。
+
+### WP1：范围和故事冻结
+
+输出：
+
+- 选定行业、工厂原型和体量；
+- 一套健康参考；
+- 一个问题病例；
+- 措施 A/B/C；
+- 问题传导和改善路径；
+- 指标、对象和检查点清单。
+
+未完成 WP1，不开始大面积页面开发。
+
+### WP2：工程骨架
+
+输出：
+
+- 页面目录；
+- 隐藏路由；
+- FUNC 登记；
+- 页面容器和导航；
+- 基础样式和“合成演示”标识。
+
+### WP3：场景契约与静态数据
+
+输出：
+
+- TypeScript 类型；
+- 合成健康参考；
+- 病例对象；
+- 措施 A/B/C；
+- 全部检查点；
+- 主播放轨道；
+- 反弹/部分有效分支。
+
+### WP4：核心页面
+
+输出：
+
+- 选择页；
+- 健康参考；
+- 病例总览；
+- 问题传导；
+- 措施详情；
+- 三态对比；
+- 价值摘要。
+
+### WP5：动态播放器
+
+输出：
+
+- 集中播放器状态；
+- 播放控制；
+- 虚拟时间；
+- 检查点转换；
+- 数据同步；
+- 高亮和讲解；
+- 重置和资源释放。
+
+### WP6：产品边界与演示体验
+
+输出：
+
+- 三个子产品边界说明；
+- 管理、业务和技术视角；
+- 主演示路线；
+- 备用路线；
+- 启动和恢复入口。
+
+### WP7：验证和交付
+
+输出：
+
+- 单元测试；
+- 构建结果；
+- 浏览器走查；
+- 演示说明；
+- 已知问题；
+- 关键页面备用截图。
+
+---
+
+## 八、开发人员可自行决定的内容
+
+在不改变任务范围、业务主线和验收要求的前提下，可自行决定：
+
+- 组件拆分和文件命名；
+- 使用 Pinia 或组合式函数管理局部状态；
+- 卡片、步骤条、时间线和图表的具体实现；
+- ECharts 图形类型；
+- 动画时长和缓动方式；
+- 局部响应式布局；
+- 静态数据文件拆分；
+- 普通样式和交互细节；
+- 测试文件组织方式。
+
+以下事项不得自行改变：
+
+- 不接后端、不新增数据库；
+- 不改变问题因果主线；
+- 不删除“合成演示”标识；
+- 不直接把 KPI 颜色当作唯一动态结果；
+- 不省略保护指标、副作用和反弹；
+- 不把 Demo 描述成真实行业样本；
+- 不修改现有 S1–S9 业务逻辑；
+- 不引入影响全局的大型依赖或框架。
+
+---
+
+## 九、测试与验收用例
+
+### TC1：选择与进入
+
+- 可以完成行业、工厂原型、体量和问题选择。
+- 只有完整场景可进入，规划项有清晰提示。
+
+### TC2：健康参考
+
+- 页面显示数据身份、适用范围和可信度。
+- 可以进入病例并返回。
+
+### TC3：完整播放
+
+- 从健康基线连续播放到恢复验证。
+- 措施 A/B/C 顺序正确。
+- 业务事实和指标变化一致。
+
+### TC4：播放控制
+
+- 播放、暂停、单步、倍速和跳转正常。
+- 暂停后状态不继续推进。
+- 跳转后视图无残留。
+
+### TC5：重置与可重复性
+
+- 任意阶段重置后回到统一初始状态。
+- 连续播放两次结果一致。
+- 重复进入和离开页面不产生多个计时器。
+
+### TC6：分支和反弹
+
+- 可以展示至少一个部分有效或反弹检查点。
+- 保护指标和副作用同步呈现。
+
+### TC7：数据身份
+
+- 所有主要页面均能看到“合成演示”标识。
+- 不出现“真实收益”“行业最佳”等无依据表述。
+
+### TC8：离线运行
+
+- 关闭后端或网络后，核心演示仍可运行。
+- 页面没有持续失败的 API 请求和错误提示。
+
+### TC9：构建与质量
+
+- 新增测试通过。
+- 前端构建通过。
+- 无新增高优先级 lint 或 TypeScript 错误。
+- 主路径无浏览器控制台阻断错误。
+
+---
+
+## 十、交付物
+
+1. Demo 前端源码。
+2. 隐藏路由和 FUNC 登记。
+3. 静态场景类型与数据。
+4. 动态播放器及测试。
+5. 一套完整健康参考和问题病例。
+6. 措施 A/B/C 和反弹/部分有效分支。
+7. 主演示路线和备用路线。
+8. 本地启动、重置和故障恢复说明。
+9. 已知问题和后续 P1 建议。
+10. 关键页面备用截图。
+
+---
+
+## 十一、提交与版本要求
+
+本任务实施时属于前端代码变更：
+
+- 提交前按仓库规则递增 `Web/package.json` 的 patch 版本。
+- 若锁文件因版本或依赖发生变化，保持锁文件与 `package.json` 一致。
+- 不因本任务递增后端版本，除非经确认后实际修改了后端代码或配置。
+- 不默认提交构建产物、缓存、真实凭据或临时截图。
+- 用户要求“提交”时按仓库规则执行 commit 并 push。
+
+---
+
+## 十二、跨模块影响
+
+- **S1–S7 页面 → 无直接改动**：Demo 使用独立静态视图，不修改现有业务页面和看板。
+- **S8/S9 → 无直接改动**：只在 Demo 中表达异常、指标、诊断和改善概念，不调用正式服务。
+- **数据中台 → 无直接改动**：技术视图展示未来正式链路，不新增来源和任务。
+- **菜单与权限 → 最小影响**：只增加隐藏前端路由和 FUNC 登记；正式菜单另行决策。
+- **公共组件 → 原则上无影响**：可复用现有能力，禁止为 Demo 大范围调整全局样式和公共框架。
+
+实施中若发现必须修改公共组件、后端菜单种子或现有业务路由，先列出跨模块影响并等待确认。
+
+---
+
+## 十三、反向影响推演
+
+- **代码调用面 → 需同步核查**：新增路由、播放器组合式函数和共享组件的全部引用；禁止污染现有 S1–S9 页面状态。
+- **数据契约面 → 需同步改**：静态场景统一使用对象、指标、措施、检查点和播放轨道类型，避免各页面分别硬编码。
+- **多数据源面 → 无运行影响**：Demo 不调用真实来源；技术展示明确区分 DB_SYNC、API_PULL 和 API_INBOUND 概念。
+- **多租户/Domain 面 → 无运行影响**：不读取真实租户数据；所有页面必须显示合成数据身份。
+- **运行面 → 需同步改**：处理计时器释放、路由离开、刷新、重置、离线启动和演示恢复。
+- **验证面 → 需同步改**：增加播放器状态、检查点一致性、重置、重复播放、数据身份和离线运行测试。
+
+---
+
+## 十四、禁止交付情形
+
+出现以下任一情况不得认定完成：
+
+- 只能靠录屏完成演示。
+- 页面数字散落硬编码，检查点之间无法一致切换。
+- 播放暂停后仍在后台推进。
+- 重置后数据或高亮残留。
+- KPI 直接从红色跳绿色，没有措施表征和业务事实。
+- 所有措施都固定成功，没有副作用或反弹表达。
+- 需要后端、模型或外部网络才能演示核心路径。
+- 合成数据被描述成客户实测或行业最佳。
+- 为 Demo 修改了现有业务模块且未做影响评审。
+- 构建失败或存在阻断演示的控制台错误。

doc/plan/行业化Ai-DOP价值演示平台/Ai-DOP行业化价值演示平台顶层方案.md

@@ -2,14 +2,23 @@
 
 | 项目 | 内容 |
 |---|---|
-| 文档定位 | 行业化价值演示平台顶层方案 |
-| 当前状态 | 讨论确认稿，尚未进入实施 |
-| 目标用户 | Ai-DOP 业务顾问、售前顾问、行业专家、产品与研发团队 |
-| 首期策略 | 只选择一个二级行业和一种工厂原型试点 |
+| 文档定位 | 行业运营场景实验室、场景资产中心与行业化价值演示平台顶层方案 |
+| 当前状态 | 讨论修订稿，尚未进入实施 |
+| 目标用户 | 内部产品/研究/场景人员，Ai-DOP 业务顾问、售前顾问、产品与研发团队 |
+| 首期策略 | 选择一个工厂原型和一条订单交付价值链，先验证“自动实验发现—场景发布—确定性动态演示”闭环 |
+| 语义基线 | [`Ai-DOP本体驱动制造业数据智能运营平台产品方案.md`](../Ai-DOP本体驱动制造业数据智能运营平台产品方案.md) |
 
 ## 1. 产品定位
 
-建设面向业务顾问的“行业化 Ai-DOP 价值演示平台”，以业务运营级虚拟工厂承载案例，以现有 Ai-DOP 正式数据链、看板、智慧诊断、S8 异常协同和改善闭环证明价值。
+建设由“行业运营场景实验室、场景资产中心、行业化价值演示平台”组成的产品体系：
+
+- **行业运营场景实验室**面向内部研究和产品人员，使用运营级虚拟工厂自动生成健康运行基线、扰动业务过程、批量实验、发现候选问题，并搜索可能的改善措施与过程。
+- **场景资产中心**负责对合成问题、改善分支、健康参考和动态演示轨道进行版本化、校验、审核、发布和分发。
+- **行业化价值演示平台**面向顾问和客户，只消费已经发布的场景资产，以确定性动态回放展示“从差到好”的业务过程。
+
+三者共享制造业业务本体、工厂原型、业务对象与事件契约、故障原语、改善动作原语、KPI、证据和场景包规范，但实验数据、草稿资产和现场演示运行相互隔离。
+
+本体系以业务运营级虚拟工厂承载合成案例，以现有 Ai-DOP 正式数据链、看板、智慧诊断、S8 异常协同和改善闭环证明产品能力。它不宣称自动获得真实行业规律；在没有专家和真实客户样本的阶段，产出是经过模型内验证的**合成问题假设和改善方案假设**。
 
 最终目的不是展示功能菜单，也不是建设设备物理级数字孪生，而是帮助顾问在潜在客户现场完成：
 
@@ -26,15 +35,19 @@
 ## 2. 已确认的顶层决策
 
 - 首批行业目录：先进装备、新材料、汽车零部件、电子信息、医药。
-- 实施时只选择一个行业的一个二级行业和一种工厂原型试点；顶层阶段暂不确定具体产品。
+- 首期不承诺覆盖全部行业，只选择一种工厂原型和订单交付主链验证通用机制；行业扩展在机制成立后逐步增加。
 - 目标听众为老板/运营、业务负责人、IT/数字化负责人混合听众。
 - 典型现场时间为 60 分钟，同时使用同一场景兼容 15/30 分钟路径。
 - 使用独立虚拟工厂租户、独立 Domain 和独立模拟来源，不污染 Demo、UAT 或真实客户数据。
 - 数据必须经过正式接入与计算链路，禁止直接写 KPI 制造演示效果。
-- 首期采用确定性业务场景回放，不做生产节拍、设备物理参数级仿真。
-- 新增“行业运营知识中心”；结构化知识是核心，文档/RAG 作为辅助。
-- 顶层预留智能体能力，但基础演示在模型不可用时仍须完整运行。
+- 场景实验室和演示平台产品上分开；实验平台允许高计算、长任务和失败分支，演示平台不依赖实验室在线。
+- 首期建设运营级轻量仿真，不做设备物理参数级数字孪生；使用状态机、业务规则、离散事件、约束/优化和蒙特卡洛等机制。
+- 不暴力穷举全部组合；使用约束过滤、实验设计、随机抽样、敏感性分析、聚类和多目标优化控制组合爆炸。
+- 演示前完成“批量实验—场景编译—正式链路校验—审核发布”，现场采用确定性动态回放。
+- 新增“行业运营知识与本体中心”；结构化本体、规则、问题、改善和场景资产是核心，文档/RAG 作为辅助。
+- 第一阶段不依赖完整智能体，只冻结智能体可消费的对象、证据和工具契约；模型不可用时实验、发布和演示主链完整运行。
 - 不新建第二套看板、诊断、异常中心、改善台账或任务系统。
+- 没有真实数据支撑的健康状态统一称为“合成健康参考”，不得宣传为行业最佳或客户真实收益。
 
 ## 3. 五问价值链
 
@@ -73,6 +86,7 @@
 - 客户自身稳定优秀历史。
 - 同二级行业、同工厂原型的可比参考。
 - 行业标准或经审核的专家参考。
+- 在业务约束、守恒关系和稳定性测试下形成的合成健康参考。
 - 趋势稳定性、异常关闭时效和任务达成率。
 - 结果、驱动和保护指标之间的平衡。
 
@@ -84,7 +98,13 @@
 
 > 九宫格 → 模块看板 → 异常指标 → L1–L4 诊断树 → 贡献指标 → 业务依据 → 根因确认 → 改善计划 → 行动项
 
-改善计划至少包含问题指标、基线、目标、根因、责任人、截止日、行动项、领先指标、结果指标、保护指标、验证窗口和复发条件。
+改善计划至少包含问题指标、基线、目标、根因假设、责任人、截止日、行动项、领先指标、结果指标、保护指标、验证窗口和复发条件。
+
+正式演示需要动态表现：
+
+> 病例初始状态 → 问题发生与传导 → 诊断 → 措施 A → A 的直接表征与延迟结果 → 措施 B → 措施 C → 恢复/部分有效/无效/反弹
+
+每项措施都必须关联作用对象、前置条件、生成的业务事件、直接表征、生效延迟、结果指标、保护指标、副作用和失效条件。
 
 ### 3.5 如何验证
 
@@ -101,10 +121,17 @@
 
 ```mermaid
 flowchart LR
-  Consultant[业务顾问] --> DemoCenter[顾问演示中心]
-  DemoCenter --> Knowledge[行业运营知识中心]
-  DemoCenter --> Scenario[场景编排与虚拟时钟]
-  Scenario --> Simulator[第三方系统模拟器]
+  Researcher[内部产品与研究人员] --> Lab[行业运营场景实验室]
+  Lab --> Ontology[业务本体_规则_原语]
+  Lab --> Factory[虚拟工厂生成器]
+  Factory --> Experiment[实验规划与批量仿真]
+  Experiment --> Discovery[问题发现与改善搜索]
+  Discovery --> Validation[守恒_因果_稳健性校验]
+  Validation --> Registry[场景资产中心]
+  Registry --> Demo[行业化价值演示平台]
+  Consultant[业务顾问] --> Demo
+  Demo --> Player[动态演示播放器]
+  Player --> Simulator[模拟ERP_MES_WMS]
   Simulator --> Inbound[DB_SYNC_API_PULL_API_INBOUND]
   Inbound --> MDP[贴源_标准_DWD]
   MDP --> KPI[KPI与S8规则]
@@ -113,46 +140,82 @@ flowchart LR
   Diagnosis --> Improvement[改善计划与行动项]
   Improvement --> Verify[效果验证]
   Verify --> Report[价值报告与PoC建议]
-  Knowledge --> Diagnosis
-  Knowledge --> Improvement
-  Knowledge --> Report
-  Agent[受控智能体层] --> DemoCenter
-  Agent --> Knowledge
 ```
 
-### 4.1 行业知识层
+### 4.1 行业运营场景实验室
+
+实验室负责生产场景资产，不承担客户现场演示：
+
+- 基于制造业本体、工厂原型和体量参数生成虚拟工厂。
+- 生成满足业务键闭包、数量守恒和时间约束的健康运行基线。
+- 组合故障原语形成扰动，使用实验设计和随机种子批量运行。
+- 从 KPI、业务事实、S8 和运行轨迹中发现候选问题。
+- 对相似轨迹聚类，沉淀问题原型和因果路径。
+- 组合改善动作原语，建立不改善、单措施、组合措施和不同顺序的反事实分支。
+- 使用多目标评价搜索交付、库存、产能、质量、成本和稳定性的候选平衡方案。
+- 保留失败、部分有效、副作用和反弹分支，不只保留“从红变绿”的结果。
+
+### 4.2 场景资产中心
+
+场景资产中心是实验室与演示平台之间唯一发布边界，负责：
+
+- 健康参考、问题原型、改善病例和反事实分支登记。
+- 本体、规则、生成器、参数、随机种子和来源版本。
+- 自动校验、人工评审、发布、撤回、废止和兼容性检查。
+- 场景包签名、完整性校验、分发和缓存。
+- 草稿、失败实验与已发布资产隔离。
 
-管理行业、二级行业、工厂原型、制造模式、运营特征、问题知识、健康目标、改善方法和顾问讲解知识。
+演示平台不得直接读取实验数据库，只能导入已发布且兼容的不可变场景包。
 
-### 4.2 问题与场景资产层
+### 4.3 行业化价值演示平台
 
-管理通用问题模板、行业问题画像、可组合扰动、场景包、检查点、预期诊断断言和验证规则。
+演示平台负责稳定消费和展示场景资产：
 
-### 4.3 虚拟工厂运行层
+- 选择行业、工厂原型、体量、问题和演示路线。
+- 展示匹配的合成健康参考和适用范围。
+- 加载已发布改善病例。
+- 通过虚拟时钟、检查点和播放轨道确定性展示问题发生、措施实施和结果变化。
+- 复用正式看板、诊断、S8、改善和验证能力。
+- 输出客户问题假设、能力映射、数据需求和 PoC 建议。
 
-管理虚拟工厂实例、场景版本、参数、随机种子、虚拟业务日、事件、runId、暂停续跑、检查点和安全重置。
+实验室可以离线或执行长任务，演示平台不依赖实验室在线。
 
-### 4.4 Ai-DOP 价值验证层
+### 4.4 共享语义与知识层
 
-复用 S1–S7 动态看板、S8 异常协同、S9 九宫格、智慧诊断、业务依据、改善计划、工作台和有效性评价。
+统一管理：
 
-### 4.5 顾问售前层
+- 通用制造本体、行业扩展、工厂原型和客户覆盖。
+- 行业、二级行业、制造模式、体量和产品复杂度。
+- 故障原语、改善动作原语、业务约束和效果机制。
+- KPI、健康区间、问题假设、因果路径、改善候选和验证规则。
+- 场景讲解知识、公开资料和操作说明。
 
-提供客户画像、行业/问题选择、场景推荐、演示导演台、讲解卡、管理/业务/技术视图、一键跳转、一键恢复和 PoC 报告。
+结构化定义是运行依据，RAG 只用于补充文档检索和解释。
+
+### 4.5 Ai-DOP 价值验证层
+
+复用 S1–S7 动态看板、S8 异常协同、S9 九宫格、智慧诊断、业务依据、改善计划、工作台和有效性评价，不建设第二套价值验证系统。
 
 ### 4.6 受控智能体层
 
-分阶段提供顾问助手、诊断改善助手和场景角色智能体；所有事实查询和动作均通过受控工具，不允许模型直接修改业务数据或自行认定根因。
+第一阶段不把智能体作为实验和演示必需项。后续可增加：
+
+- 实验助手：整理公开资料、提出参数和实验候选、解释模拟结果。
+- 顾问助手：场景推荐、讲解导航、知识问答和报告草拟。
+- 诊断改善助手：基于已验证事实和工具形成根因及改善草稿。
+- 场景角色智能体：在已发布场景和权限范围内模拟角色交接。
+
+智能体不作为数据真相、因果正确性或改善有效性的依据。
 
 ### 4.7 主要技术点
 
-- 前端交互原型：先用可点击高保真 Demo 快速确认行业选择、问题选择、五问价值链、场景控制和顾问演示路径。
-- 结构化知识库：以行业、工厂原型、问题、KPI、健康目标、根因、改善方法和验证规则为主数据；RAG 仅用于补充文档检索和解释。
-- 场景运行引擎：场景包版本、参数化扰动、虚拟时钟、事件编排、随机种子、runId、检查点、断言、失败续跑和安全重置。
-- 数据模拟与正式接入：模拟 ERP/MES/WMS，通过 DB_SYNC、API_PULL、API_INBOUND 进入贴源、标准、DWD、KPI 和 S8 正式链路。
-- 指标与诊断引擎：复用现有 KPI、诊断树、业务依据、S8 规则、改善计划和有效性验证，不直接写入 KPI 结果。
-- 智能体与工具调用：大模型负责组织、解释和草拟；通过受控工具查询事实、检索知识和提交待确认动作，并保留 ToolTrace。
-- 隔离与治理：独立租户、Domain、来源和 runId；知识版本、提示词版本、权限、审计、人工确认和无模型降级。
+- 虚拟工厂生成：按本体、工厂原型、体量和参数范围生成闭合业务网络。
+- 自动实验：约束过滤、实验设计、蒙特卡洛、敏感性分析、聚类和多目标优化。
+- 场景编译：将实验结果编译为事件流、检查点快照、断言和动态播放轨道。
+- 正式数据链：模拟 ERP/MES/WMS 通过三种入站进入贴源、标准、DWD、KPI 和 S8。
+- 动态演示：应用内导演式导航、高亮和讲解；不以浏览器录屏、鼠标宏或直接改图表作为正式机制。
+- 场景治理：版本、可信度、审核、签名、兼容性、发布和回滚。
+- 运行隔离：实验、资产发布和现场演示使用不同数据空间、角色、队列和资源限额。
 
 ## 5. 行业与工厂原型
 
@@ -177,50 +240,88 @@ flowchart LR
 
 行业用于客户识别和市场表达，工厂原型用于决定场景、数据、规则和 KPI。禁止为每个行业复制一套重复问题库。
 
-## 6. 行业运营知识中心
+## 6. 行业运营知识与本体中心
 
-知识中心不是普通文档库，而是驱动问题地图、场景、诊断解释、改善候选和顾问表达的结构化权威来源。
+知识与本体中心不是普通文档库，而是驱动虚拟工厂、自动实验、问题发现、改善搜索、场景发布和顾问表达的结构化来源。在缺少专家和真实客户的阶段，它提供的是可追溯的模型假设，不冒充行业事实。
 
 ### 6.1 知识范围
 
 - 行业知识：行业、二级行业、工厂原型、流程、角色、术语和运营目标。
-- 问题知识：症状、根因、影响、S1–S7 映射、数据表现和传导路径。
+- 本体知识：对象、属性、关系、事件、指标、动作、约束和证据。
+- 故障知识：需求、数量、时间、状态、产能、供应、质量和数据异常原语。
+- 问题知识：症状、根因假设、影响、S1–S7 映射、数据表现和传导路径。
 - 健康知识：目标、合理区间、平衡关系、优秀实践及适用条件。
-- 改善知识：改善方法、适用根因、行动模板、责任角色、副作用和验证方法。
+- 改善知识：动作原语、效果机制、适用根因、行动模板、责任角色、生效延迟、副作用和验证方法。
 - 场景知识：故事、初始条件、扰动、检查点、数据依赖、讲解卡和客户追问。
-- 来源证据：行业资料、客户确认、专家评审、指标口径、版本和适用范围。
+- 实验知识：参数空间、随机种子、分支、敏感性、结果分布和适用条件。
+- 来源证据：公开资料、系统规则、模拟假设、指标口径、版本和适用范围。
 
 ### 6.2 知识治理
 
-每条正式知识至少包含编码、版本、适用行业/工厂原型、来源、作者、审核人、生效期、状态和引用场景。
+每条正式知识至少包含编码、版本、适用行业/工厂原型/体量、来源、假设、作者、审核人、生效期、状态、可信度和引用场景。
 
 - 平台专家维护通用知识。
-- 行业专家维护行业模板。
+- 内部产品与研究人员维护行业候选模板和模拟参数。
 - 顾问可复制并调整客户参数，不能直接修改已发布权威知识。
 - 状态分为草稿、待审、已发布、已废止。
-- 未审核知识不得进入正式演示。
+- 未通过模型内校验和发布审核的知识不得进入正式演示。
+
+可信度分为：
+
+- `S0 模型生成`：自动探索产生，尚未通过完整内部校验。
+- `S1 内部验证`：通过守恒、因果、敏感性、稳健性和重复运行检查。
+- `S2 公开资料校准`：参数与可引用公开资料进行了校准。
+- `S3 客户数据校准`：未来使用客户真实数据完成验证。
+- `S4 多客户验证`：未来在多个客户中验证并明确适用边界。
+
+当前无专家和真实客户时，正式演示资产最高主要处于 S1/S2，不得标记为 S3/S4。
 
 ### 6.3 结构化优先
 
 第一阶段先建设结构化知识关系；全文/向量检索只补充行业报告、案例、FAQ 和操作说明。所有生成式回答显示来源、版本、适用范围和审核状态。
 
-## 7. 问题与 KPI 的来源治理
+## 7. 问题发现、改善搜索与 KPI 治理
+
+### 7.1 自动问题发现
+
+在缺少专家和真实客户样本的阶段，问题主要通过模型驱动实验发现：
+
+1. 根据工厂原型和体量生成可行健康基线。
+2. 对业务对象、关系和事件组合需求波动、供应延期、产能下降、质量异常、数据错误等故障原语。
+3. 使用约束过滤、实验设计和随机抽样选择有代表性的参数组合，不做无边界暴力穷举。
+4. 执行模拟并由正式 KPI、S8 和业务规则识别异常结果。
+5. 通过对照实验、单因素消融、敏感性分析和因果路径定位问题机制。
+6. 对重复轨迹聚类，沉淀问题原型。
+7. 组合改善动作，形成“不处理、单措施、组合措施、不同顺序”的反事实分支。
+8. 通过多目标评价和稳健性测试筛选候选改善方案。
 
-### 7.1 问题来源
+候选问题必须满足：
 
-问题由以下证据共同形成：
+- 可重复：同版本、参数和随机种子得到相同结果。
+- 有对照：移除扰动后问题不再以相同机制出现。
+- 有路径：能够追踪对象、事件和影响关系。
+- 有敏感性：扰动强度变化与问题程度具有合理关系。
+- 有稳定区间：不是单次随机噪声。
+- 有业务影响：至少影响一个结果指标。
+- 非模型错误：不是数据不闭合、数量不守恒或时间穿越造成。
 
-- 业务目标和流程失效分析。
-- 历史客户访谈、项目记录和异常台账。
-- 实际订单、供应、库存、生产、质量和 S8 数据。
-- 行业资料、标准和可比企业经验。
-- 顾问与行业专家评审。
+通过上述检查后，才可进入“合成问题原型”候选库。
 
-正式问题必须满足：可度量、可诊断、可改善、可验证。
+### 7.2 改善措施搜索
 
-优先级综合考虑发生频率、经营影响、跨部门影响、客户共鸣、数据可得性、Ai-DOP 覆盖度和演示价值。
+改善动作由催交、分批交付、调拨、替代、换源、库存策略、优先级、重排、加班、转线、外协、返工、复检、隔离、放行和数据修复等原语组合。
 
-### 7.2 KPI 组合
+每项措施需要定义：
+
+- 作用对象、前置条件和约束。
+- 直接生成的业务事件和事实。
+- 生效延迟、作用范围和效果参数。
+- 领先指标、结果指标和保护指标。
+- 资源消耗、成本、副作用、失败和反弹条件。
+
+系统输出一组候选平衡方案，不宣称存在脱离目标权重的唯一最佳方案。
+
+### 7.3 KPI 组合
 
 每个问题配置：
 
@@ -228,30 +329,62 @@ flowchart LR
 - 2–5 个驱动指标：解释为什么。
 - 1–3 个保护指标：防止牺牲库存、质量、成本或其他订单换取表面改善。
 
-### 7.3 健康目标来源
+### 7.4 健康目标与合成健康参考
 
-优先级为：
+未来具备真实资料时，健康目标优先级为：
 
 > 客户正式目标 → 客户优秀历史 → 同二级行业/工厂原型可比样本 → 行业标准/专家参考 → 明确标识的演示参考
 
-目标模型需表达方向、健康区间、红黄阈值、适用行业/工厂原型、样本说明、来源、可信度、生效期和审核状态。虚拟场景只使用经审核的演示参考，不宣称行业最佳。
+当前阶段根据业务约束、目标函数、合理参数边界、稳定运行和保护指标生成“合成健康参考”。它只能说明在当前模型下可行且稳定，不能称为行业标杆。
+
+目标模型需表达方向、健康区间、红黄阈值、适用行业/工厂原型/体量、样本说明、来源、假设、可信度、生效期和审核状态。
 
 ## 8. 场景产品模型
 
-核心对象：
+### 8.1 核心对象
 
 - `IndustryPack`：行业知识、术语、问题适用性和目标模板。
 - `FactoryArchetype`：制造模式、规模、产品复杂度和关键约束。
+- `FactoryScaleProfile`：订单量、SKU、物料、产线、人员、供应商、提前期和库存覆盖等体量参数。
+- `VirtualFactoryModel`：一次可计算的虚拟工厂拓扑、资源、约束和基线。
+- `FailurePrimitive`：需求、供应、产能、质量、库存、流程和数据故障原语。
+- `InterventionPrimitive`：可组合的改善动作及其效果机制。
+- `ExperimentPlan`：参数空间、抽样方法、运行预算、随机种子和停止条件。
+- `ExperimentRun`：一次实验的输入、事件、结果、日志和资源消耗。
 - `ProblemTemplate`：通用问题、症状、根因、数据表现和影响。
 - `IndustryProblemProfile`：问题在特定行业/工厂原型中的表现。
-- `ScenarioComponent`：工程变更、供应延期、IQC 不合格等可组合扰动。
+- `ProblemCandidate`：实验发现但尚未发布的问题假设。
+- `CausalPath`：扰动、对象、事件、指标和结果的因果路径。
+- `InterventionPlan`：针对问题的候选改善措施组合和顺序。
+- `InterventionStep`：单项措施、前置条件、事件、表征、延迟、副作用和验证。
+- `CounterfactualBranch`：不处理、单措施、组合措施和不同顺序的对照分支。
+- `EffectManifest`：措施到直接事实、领先指标、结果指标和保护指标的映射。
 - `ScenarioPack`：版本化故事、参数、事件、依赖、检查点和断言。
 - `ScenarioRun`：租户、Domain、runId、随机种子、虚拟业务日和状态。
 - `Checkpoint`：健康、发生、暴露、诊断、改善、恢复、反弹。
+- `ReplayTrack`：检查点、页面、播放速度、导航、高亮和讲解提示。
 - `DemoScript`：15/30/60 分钟讲解路线、讲解卡和常见追问。
 - `ValueReport`：演示证据、能力映射、数据清单和 PoC 建议。
 
-场景使用声明式 manifest，按“主数据闭包 → 订单 → 工单/排程 → 采购/库存/质量 → 报工/成品 → S8”生成业务事实。
+### 8.2 实验组合模型
+
+一次实验由以下要素组合：
+
+> 行业扩展 × 工厂原型 × 体量参数 × 健康基线 × 故障扰动 × 改善措施组合 × 参数与随机种子
+
+实验室对组合空间进行约束过滤和有预算搜索，不承诺枚举数学意义上的全部可能性。
+
+### 8.3 场景编译
+
+场景使用声明式 manifest，按“主数据闭包 → 订单 → 工单/排程 → 采购/库存/质量 → 报工/成品 → S8”生成业务事实，并编译形成：
+
+- 健康基线事件包。
+- 问题扰动事件包。
+- 措施 A、B、C 等分阶段后续事件包。
+- 不改善和不同措施组合的反事实分支。
+- KPI、S8、诊断、业务证据和保护指标断言。
+- 检查点快照和动态播放轨道。
+- 本体、规则、生成器、参数和随机种子版本。
 
 每个问题场景统一采用：
 
@@ -259,52 +392,83 @@ flowchart LR
 
 禁止根据期望颜色直接写 KPI；只能生成业务事实并让正式计算链得出结果。
 
+### 8.4 场景包发布
+
+正式场景包必须是不可变版本，至少包含：
+
+- 适用行业、工厂原型、体量和数据身份。
+- 本体、规则、生成器和兼容版本。
+- 假设、参数范围、随机种子和可信度等级。
+- 业务事件、数据、分支、检查点、断言和播放轨道。
+- 自动校验报告、审核记录、签名和校验值。
+
+演示平台导入时必须完成完整性和兼容性检查。
+
 ## 9. 数据与运行架构
 
-### 9.1 正式数据链
+### 9.1 实验运行与正式数据链
 
 复用 [`tools/integration-simulator`](../../../tools/integration-simulator/README.md)：
 
 > 模拟 ERP/MES/WMS → DB_SYNC/API_PULL/API_INBOUND → mdp_stg → mdp_std/DWD → KPI/S8 → 看板/诊断/改善
 
+实验室内部可以使用轻量状态和事件模型进行大批量候选搜索，但候选场景进入发布前，必须将代表性分支转换成正式模拟来源数据，并跑通上述正式链路。实验室内部评分不得替代 Ai-DOP 正式 KPI、S8 和诊断结果。
+
 相关基础方案：
 
 - [`Ai-DOP第三方对接模拟器建设方案.md`](../系统集成/Ai-DOP第三方对接模拟器建设方案.md)
 - [`Ai-DOP第三方对接业务数据详表-业务页.md`](../系统集成/Ai-DOP第三方对接业务数据详表-业务页.md)
 - [`Ai-DOP第三方对接业务数据详表-技术页.md`](../系统集成/Ai-DOP第三方对接业务数据详表-技术页.md)
 
-### 9.2 隔离
+### 9.2 隔离与产品边界
 
+- 实验空间、场景资产发布空间和虚拟演示租户分别隔离。
+- 实验任务与演示运行使用不同队列、资源池和并发限制。
 - 独立虚拟工厂租户和 Domain。
 - DB_SYNC、API_PULL、API_INBOUND 使用独立 `source_code`。
 - 每次运行使用 `VF-{factoryCode}-{runId}` 业务键前缀。
 - 权威来源登记不得覆盖 T8、165、自建单或真实第三方来源。
 - 清理和重置必须同时限定租户、Domain、runId 和场景版本。
+- 演示平台不读取实验临时表、失败结果和未发布场景。
+
+### 9.3 自动实验与改善搜索
 
-### 9.3 确定性回放
+- 批量运行必须设置实验预算、并发上限、停止条件和资源配额。
+- 同实验版本、参数和种子可重现。
+- 通过约束过滤排除不可能组合。
+- 通过敏感性分析和聚类减少重复问题。
+- 通过反事实分支比较措施的增量作用。
+- 通过交付、库存、产能、质量、成本和稳定性进行多目标评价。
+- 保留适用条件、失效条件、副作用和结果分布，不只保留最优单点。
+
+### 9.4 场景编译与确定性回放
 
 - 同场景版本、参数和随机种子得到一致结果。
 - 日期按演示当天整体平移。
 - 支持初始化、暂停、推进、检查点跳转、失败续跑和重置。
 - 改善阶段生成后续事实，不篡改历史坏数据。
 - 场景未达到 KPI、证据和状态断言时禁止标记为可演示。
+- 演示现场只回放已发布场景，不执行无边界自动搜索。
+- 常见反事实分支预先编译；现场选择不同措施时切换到已验证分支。
+- 后续如开放现场临时分支计算，必须明确显示“模拟计算中”和结果可信度，不得影响既有演示版本。
 
 ## 10. 顾问演示体系
 
 ### 10.1 演示前
 
 - 建立客户画像。
-- 选择行业、二级行业、工厂原型和关注问题。
-- 推荐场景、参数和讲解路径。
+- 选择行业、二级行业、工厂原型、企业体量和关注问题。
+- 推荐合成健康参考、已发布病例、改善分支和讲解路径。
 - 执行数据、KPI、诊断依据、S8 和下钻健康检查。
 
 ### 10.2 60 分钟主路径
 
 - 0–8 分钟：客户画像、问题地图和管理层价值。
-- 8–30 分钟：同一业务故事在 S1–S7 的发生和传导。
-- 30–43 分钟：智慧诊断、贡献分析和业务依据。
-- 43–51 分钟：改善计划、行动项和恢复验证。
-- 51–57 分钟：数据接入、租户隔离和实施可行性。
+- 8–15 分钟：展示匹配的合成健康参考及其适用范围。
+- 15–30 分钟：同一业务故事在 S1–S7 的发生、恶化和传导。
+- 30–40 分钟：智慧诊断、贡献分析、业务依据和根因假设。
+- 40–52 分钟：逐项播放措施 A/B/C、直接表征、延迟结果、副作用和恢复验证。
+- 52–57 分钟：数据接入、租户隔离和实施可行性。
 - 57–60 分钟：客户问题摘要、PoC 范围和下一步。
 
 同一场景裁剪为：
@@ -313,7 +477,21 @@ flowchart LR
 - 30 分钟：一个主问题和智慧诊断。
 - 60 分钟：完整问题、诊断、改善、验证、技术和 PoC。
 
-### 10.3 三种观察层
+### 10.3 动态演示模式
+
+- **自动讲解模式**：按发布的播放轨道自动推进时间、页面、聚焦、高亮和讲解。
+- **交互决策模式**：顾问或客户选择已发布的措施分支，比较不同结果。
+- **检查点模式**：直接跳转健康、发生、暴露、诊断、措施、恢复或反弹阶段。
+
+播放器支持播放、暂停、单步、倍速、检查点跳转和安全重置，并同步展示：
+
+- 改善前、当前状态和合成健康参考三态对比。
+- 当前措施、责任角色、前置条件和执行状态。
+- 业务事实、领先指标、结果指标和保护指标。
+- 问题与改善的对象关系路径。
+- 数据身份、虚拟业务日、场景版本和可信度等级。
+
+### 10.4 三种观察层
 
 - 管理视图：交付、库存、效率、质量和风险。
 - 业务视图：订单、工单、物料、供应商、批次和任务。
@@ -321,40 +499,41 @@ flowchart LR
 
 三种视图必须读取同一场景运行的同一批事实。
 
-### 10.4 演示后
+### 10.5 演示后
 
 输出客户行业画像、确认问题、Ai-DOP 能力映射、演示证据、改善方向、数据接入清单、PoC 验证指标和下一步行动。
 
 ## 11. 智能体路线
 
-智能体让虚拟工厂中的组织和角色“活起来”，但不是数据真相和场景规则的来源。
+智能体可以帮助实验和演示更易使用，但不是虚拟工厂、问题发现、因果正确性和场景规则的来源。
 
-### 11.1 基础演示不依赖智能体
+### 11.1 第一阶段不交付完整智能体
 
-先完成知识、场景、数据、诊断、改善和验证的确定性闭环。
+先完成本体和原语、虚拟工厂、自动实验、问题发现、改善搜索、场景发布和确定性动态回放闭环。第一阶段冻结智能体未来可消费的对象、关系、证据、动作和工具契约。
 
-### 11.2 顾问助手
+### 11.2 实验助手
 
-辅助客户访谈、场景推荐、讲解导航、行业知识问答和报告生成；以只读工具为主。
+后续辅助读取公开资料、结构化故障和改善候选、推荐下一轮实验、解释敏感性和分支结果。所有参数和结论仍需确定性校验。
 
-### 11.3 诊断改善助手
+### 11.3 顾问与诊断改善助手
 
-受控调用 KPI、诊断、业务依据和知识中心，生成根因候选及改善计划草稿；所有写操作需要人工确认。
+后续辅助场景推荐、讲解导航、知识问答和报告生成；受控调用 KPI、诊断、业务依据和知识中心生成根因候选及改善计划草稿。模型不可用时退回已发布讲解卡和模板报告。
 
 ### 11.4 场景角色智能体
 
-模拟销售、PMC、采购、供应商、仓储、质量、生产等角色，按照场景事件、权限、可见信息、可用动作和交接规则运行，形成“原有方式 / Ai-DOP / Ai-DOP＋Agent”对照。
+在后续阶段模拟销售、PMC、采购、供应商、仓储、质量、生产等角色，按照已发布场景事件、权限、可见信息、可用动作和交接规则运行，形成“原有方式 / Ai-DOP / Ai-DOP＋Agent”对照。
 
 角色智能体不得直接改库；所有动作通过正式接口或受控模拟工具并保留 ToolTrace。外部执行明确标记为模拟，关键业务动作由人工确认。
 
 ## 12. 场景成熟度
 
-- L1 问题知识：能说明问题、原因、影响和 Ai-DOP 对应能力。
-- L2 数据预览：能展示预期数据表现、KPI 变化和诊断路径。
-- L3 完整模拟：正式数据链跑通五问价值链，能够复演和重置。
-- L4 客户 PoC：替换为客户数据，验证实际问题和价值。
+- L0 实验候选：自动实验发现，尚未完成模型内验证。
+- L1 问题原型：可重复、有对照、有因果路径，已排除明显模型错误。
+- L2 改善候选：完成反事实分支、多目标评价和稳健性测试。
+- L3 合成演示：代表性分支跑通正式数据链、五问价值链、动态回放和重置。
+- L4 客户 PoC：未来替换或校准为客户数据，验证实际问题和价值。
 
-只有 L3/L4 可作为正式深度价值案例。
+只有已发布的 L3/L4 场景可作为正式深度价值案例。L3 必须明确标识为合成假设，不得宣传为行业真实收益。
 
 ## 13. 现有能力边界
 
@@ -366,81 +545,87 @@ flowchart LR
 - 已有三种入站方式和独立第三方模拟器。
 - ChatBI 当前主要做 KPI 聚合问答和导航，不是完整智能体。
 - 未见通用行业知识、问题、根因、改善方法和验证规则中心。
+- 未见虚拟工厂生成、批量实验、问题发现、改善搜索、反事实分支和场景资产发布能力。
 - S5/S6/S7 部分二级看板仍为占位；正式场景必须按实际成熟能力设门禁。
 
 ### 13.2 配置层
 
 - 运行租户的 KPI、菜单、看板、诊断依据、来源和入站授权需逐项实测。
-- 尚未建立行业包、问题库、健康目标、场景版本和智能体工具授权配置。
+- 尚未建立本体扩展、工厂原型、体量参数、故障/改善原语、实验计划、场景资产和智能体工具授权配置。
 
 ### 13.3 数据层
 
 - 目标虚拟工厂租户尚未建立。
-- 尚未形成贯穿五问的 S1–S7 行业场景数据。
+- 尚未形成合成健康参考、实验结果、问题原型、改善分支及贯穿五问的 S1–S7 场景数据。
 - 实施前必须核查目标表行数、来源分布、最新业务日期、流水和 KPI 结果。
 
 ## 14. 建设阶段
 
-本计划先安排 P0 一周前端交互 Demo，用于与业务负责人直观确认产品构想；其后以六周完成正式范围，P0–P4 共七周。各阶段以范围冻结和阶段评审控制风险，发现关键主链缺口时在阶段评审点及时处理。
+本次调整将产品从单一演示平台扩大为“实验室—资产中心—演示平台”体系，原 P0–P4 共七周的正式建设假设不再成立。阶段工期需在对象模型、仿真范围、计算预算和现有链路核查后重新估算，避免用固定日期掩盖研发不确定性。
 
-### P0 第 1 周：前端交互 Demo 与构想确认
+### P0：前端交互 Demo 与构想确认
 
-- 以可点击高保真前端 Demo 呈现“选行业—选问题—看数据—诊断—改善—验证”的完整主路径。
-- 展示客户画像、行业/二级行业、S1–S7 问题地图、五问价值页、场景导演台和管理/业务/技术三种观察层。
+- 以可点击高保真前端 Demo 呈现“选行业/体量—健康参考—选择问题—动态诊断—措施 A/B/C—恢复/反弹—验证”的完整主路径。
+- 分别展示场景实验室、资产发布和顾问演示三个产品边界。
 - 使用明确标识的静态模拟数据，不建设正式知识库、场景引擎、数据接入和智能体后台。
-- 组织业务负责人评审，记录术语、流程、内容密度、演示顺序和页面交互反馈。
-- 交付可演示原型、页面清单、交互说明、评审纪要和 P1–P4 范围基线；P0 评审通过后进入正式建设。
+- 交付可演示原型、页面清单、交互说明和后续范围基线。
 
-### P1 第 2 周：试点确认与方案冻结
+### P1：共享语义、实验边界与场景包标准
 
 - 完成现有 S1–S9、数据中台、诊断、改善、ChatBI 和模拟器的快速核查。
-- 选择一个二级行业和工厂原型，建立 S1–S7 问题地图和 KPI 组合。
-- 确定 1 套健康基线、3 个深度场景和 1 条跨模块主演示故事。
-- 冻结知识、场景、运行、演示和智能体对象模型及页面原型。
-- 形成“问题—事实—通道—标准层—KPI—证据—S8—改善—验证”矩阵。
+- 选择一个工厂原型和订单交付价值链，冻结首期目标函数与保护指标。
+- 冻结最小制造本体、体量参数、故障原语、改善动作原语和效果机制。
+- 定义实验、场景资产、场景包、播放轨道和智能体就绪契约。
+- 形成“扰动—事实—通道—标准层—KPI—证据—S8—措施—验证”矩阵。
 
-### P2 第 3 周：知识与场景底座
+### P2：最小行业运营场景实验室
 
-- 建设最小完整的结构化行业运营知识中心，覆盖问题、KPI、健康目标、改善方法和验证规则。
-- 建设场景、版本、运行、虚拟时钟、检查点、断言和安全重置能力。
-- 建立独立虚拟工厂租户、Domain 和模拟来源，跑通健康基线及第一条正式数据链。
-- 扩展 [`tools/integration-simulator`](../../../tools/integration-simulator/) 的依赖排序、参数生成和全链对账。
-- 完成顾问演示中心前端骨架及智能体受控工具契约。
+- 建设虚拟工厂和合成健康基线生成器。
+- 建设首批故障扰动、批量实验、问题检测、因果路径和聚类能力。
+- 建设首批改善动作、反事实分支、多目标评价和稳健性测试。
+- 生成少量 L1/L2 合成问题与改善候选。
+- 不建设完整智能体。
 
-### P3 第 4–5 周：完整演示平台
+### P3：场景资产中心与正式链路验证
 
-- 建设客户画像、行业问题地图、场景推荐、五问价值总览和场景控制台。
-- 完成 3 个深度场景、1 条跨 S1–S7 组合故事及健康基线。
-- 复用看板、诊断、S8、改善台账和工作台，形成同一 runId 下的管理、业务、技术三种观察层。
-- 建设演示导演台、讲解卡、15/30/60 分钟路线、价值报告和 PoC 建议。
-- 完成失败续跑、重置、场景断言和演示健康检查；第 5 周末冻结功能范围。
+- 建设场景审核、发布、版本、签名、兼容、撤回和废止。
+- 将代表性实验分支转换为 DB_SYNC、API_PULL 或 API_INBOUND 模拟数据。
+- 跑通贴源、标准、DWD、KPI、S8、看板、诊断、改善和验证。
+- 编译事件包、检查点快照、断言和播放轨道，发布首批 L3 合成场景。
 
-### P4 第 6–7 周：智能体、集成验证与发布
+### P4：行业化价值演示平台
 
-- 建设顾问助手、诊断改善助手，并在主演示故事中完成一条场景角色智能体交接主链。
-- 智能体通过受控工具访问事实和知识，所有关键写操作保留人工确认和 ToolTrace。
-- 完成端到端集成、数据守恒、租户隔离、重置幂等、智能体越权和降级测试。
-- 完成业务试讲、顾问手册、常见问题、应急预案和发布评审。
-- 形成可用于受控客户现场的完整范围演示版本。
+- 建设行业/体量选择、合成健康参考、病例和分支推荐。
+- 建设自动讲解、交互决策和检查点三种模式。
+- 复用正式页面形成管理、业务和技术三种观察层。
+- 建设演示导演台、动态播放器、讲解卡、15/30/60 分钟路线、价值报告和 PoC 建议。
+- 完成离线/弱网、场景导入、兼容检查、一键恢复和演示健康检查。
 
-### P5 第 8 周以后：增强与行业扩展
+### P5：验证、增强与行业扩展
 
-- 增加问题、场景、诊断依据和角色智能体覆盖。
-- 加强性能、监控、运维、安全和客户真实数据 PoC 能力。
-- 复用通用问题和场景组件扩展其它行业。
-- 新材料、药品等流程/合规特征明显的行业，在补齐数据语义后再进入 L3。
+- 扩展工厂原型、故障/改善原语、问题、场景和诊断依据。
+- 加强实验调度、性能、监控、运维、安全和真实数据校准能力。
+- 在核心闭环稳定后增加实验助手、顾问助手、诊断改善助手和角色智能体。
+- 复用通用本体、原语和场景组件扩展其它行业。
+- 新材料、药品等流程或合规特征明显的行业，在补齐语义、约束和验证后再进入 L3。
 
 ## 15. 验收标准
 
 - P0 前端交互 Demo 已由业务负责人完成评审，主路径、页面信息、业务术语和正式建设范围得到确认。
+- 实验室、资产中心和演示平台权限、数据和运行资源隔离。
+- 合成健康参考满足业务键闭包、数量守恒、时间约束、稳定性和保护指标要求。
+- 候选问题具备对照、可重复、因果路径、敏感性和稳定区间。
+- 改善候选完成不处理、单措施和组合措施反事实比较，并显示副作用和适用条件。
+- 场景资产发布包含版本、假设、参数、随机种子、可信度、校验报告、签名和兼容范围。
 - 新顾问经简要培训能够独立完成 15/30/60 分钟演示。
 - 客户在前 5–8 分钟能够识别与自身相关的问题。
 - 每个 L3 场景完整回答五问，并保持同一筛选范围、runId 和业务事实。
 - KPI 异常可下钻到真实业务事实，诊断与事实一致，无直写 KPI。
-- 健康目标显示来源、适用范围和可信度，不冒充客户真实目标或行业最佳。
-- 改善后同时验证 KPI、业务事实、S8 状态、行动项和副作用。
+- 健康目标显示来源、假设、适用范围和可信度，不冒充客户真实目标或行业最佳。
+- 动态播放器逐项展示措施、直接表征、生效延迟、KPI、业务事实、S8、行动项、保护指标和副作用。
 - 同版本、参数、种子重复执行结果一致；日期可平移。
 - 初始化、推进、续跑和重置幂等；重置只影响目标租户和 runId。
+- 演示平台不依赖实验室在线，不能读取草稿和失败实验。
 - 外部系统不可用时，已准备的核心演示仍可稳定运行。
 - 演示后能够生成可推动 PoC 的客户问题与数据接入摘要。
 - 运行报告明确区分代码有/无、配置开/未开、数据通/未通。
@@ -448,6 +633,11 @@ flowchart LR
 ## 16. 风险与边界
 
 - 场景资产爆炸：用通用问题模板、工厂原型和可组合扰动控制。
+- 组合空间爆炸：使用约束过滤、实验设计、抽样、敏感性分析、聚类、搜索预算和停止条件。
+- 模型内正确冒充现实正确：所有结果标注为合成假设和可信度，明确模型边界。
+- 自循环证明：实验室评分只用于筛选，发布前代表性分支必须跑通正式数据链。
+- 虚拟工厂规则错误：建立守恒、时间、状态、业务键闭包和基准场景守卫测试。
+- 单指标最优伤害整体：使用结果、驱动和保护指标进行多目标评价。
 - 固定动画冒充仿真：所有时长、指标和差异来自运行记录；无证据标“待验证”。
 - 模拟收益冒充客户收益：严格标记行业模拟、客户假设和客户实测。
 - 智能体幻觉：事实、诊断、知识和建议分层展示并附来源。
@@ -458,7 +648,8 @@ flowchart LR
 
 本顶层方案明确不做：
 
-- 设备物理级数字孪生和复杂离散事件仿真。
+- 设备物理级数字孪生、三维工厂和控制系统级仿真。
+- 声称穷举全部行业问题或发现现实世界唯一最优方案。
 - 生产环境自动写配置或使用生产凭据。
 - 未经确认自动认定根因、审批改善或执行关键业务动作。
 - 第二套看板、诊断、异常中心或任务系统。
@@ -470,27 +661,33 @@ flowchart LR
 - S8：由正式规则生成异常并关联场景运行，不新增异常中心。
 - S9：复用九宫格、KPI 目标、智慧诊断、改善计划、工作台和 ChatBI。
 - 数据中台：新增专用来源、实体配置、租户权威来源、同步任务和重算负载。
-- 平台能力：新增行业知识、场景运行、顾问演示和受控智能体工具网关。
+- S0/本体治理：新增工厂原型、体量、故障、改善、因果、指标和动作语义。
+- 实验平台：新增虚拟工厂、实验规划、批量仿真、问题发现、改善搜索和多目标评价。
+- 场景资产中心：新增审核、发布、签名、兼容、分发、撤回和废止。
+- 演示平台：新增健康参考、病例、反事实分支、导演台和动态播放器。
+- 平台能力：新增实验/演示资源隔离、任务队列、对象存储、版本和审计。
 - 导出与报告：新增模拟/假设/实测身份、来源和适用范围标记。
 
 ## 18. 反向影响推演
 
-- 代码调用面 → **需同步改**：行业知识、场景控制、模拟器编排、模块重算、看板/诊断跳转、改善关联、报告和智能体工具；实施前反查新增对象和字段的全部调用方。
-- 数据契约面 → **需同步改**：行业、问题、KPI、场景 manifest、runId、虚拟业务日、来源身份须覆盖标准层、DWD、诊断证据、S8、改善、ChatBI 和导出。
-- 多数据源面 → **需同步改**：三种入站建立独立测试来源并登记唯一权威来源；不得覆盖 T8、165、自建单或真实第三方。
-- 多租户/Domain 面 → **需同步改**：独立租户和 Domain；查询、写入、清理、重算、知识覆盖、S8 和改善均使用可信租户上下文。
-- 运行面 → **需同步改**：DDL/迁移、种子、租户初始化、任务队列、重算并发、缓存、凭据、健康检查、失败恢复和重置审计；同租户大型重算需串行限流。
-- 验证面 → **需同步改**：为问题/KPI 知识治理、数据守恒、业务键闭包、KPI 区间、诊断依据、S8 状态、改善有效性、智能体工具权限和重置幂等建立守卫测试。
+- 代码调用面 → **需同步改**：反查本体、虚拟工厂、实验调度、问题检测、改善搜索、场景发布、模拟器编排、模块重算、播放器、看板/诊断跳转、改善关联和报告的全部调用方。
+- 数据契约面 → **需同步改**：行业、工厂原型、体量、故障/改善原语、实验、因果路径、分支、场景包、播放轨道、runId、虚拟业务日和来源身份须覆盖标准层、DWD、诊断证据、S8、改善、ChatBI 和导出。
+- 多数据源面 → **需同步改**：代表性实验分支通过三种入站建立独立模拟来源并登记唯一权威来源；不得覆盖 T8、165、自建单或真实第三方。
+- 多租户/Domain 面 → **需同步改**：实验空间、资产发布空间和演示租户隔离；查询、写入、清理、重算、知识覆盖、S8 和改善均使用可信租户上下文。
+- 运行面 → **需同步改**：DDL/迁移、种子、实验队列、搜索预算、资源限额、对象存储、资产签名、发布分发、重算并发、缓存、健康检查、失败恢复和重置审计；实验负载不得影响演示运行。
+- 验证面 → **需同步改**：增加业务键闭包、数量守恒、时间约束、对照、因果、敏感性、稳健性、多目标评价、正式链路断言、场景兼容、动态播放和重置幂等守卫测试。
 
 ## 19. 后续决策门
 
 顶层方案评审通过后，再依次确认：
 
-1. 首个二级行业及工厂原型。
-2. 试点问题地图和 KPI 组合。
-3. 健康基线、3 个深度场景和 1 条主演示故事。
-4. 知识中心和场景运行的详细数据模型。
-5. 代码层、配置层、数据层能力审计结果。
-6. 分期任务书、工作量和实施排期。
+1. 首个工厂原型、订单交付主线和体量参数边界。
+2. 最小本体、目标函数、保护指标、故障原语和改善动作原语。
+3. 实验预算、仿真精度、问题判定、聚类和多目标评价方法。
+4. 实验室、场景资产中心和演示平台的详细对象及部署边界。
+5. 场景包、签名、兼容、发布、撤回和可信度规范。
+6. 首批合成健康参考、问题原型、改善分支和主演示故事。
+7. 代码层、配置层、数据层能力审计结果。
+8. 分期任务书、工作量和实施排期。
 
 未经上述决策，不进入代码、配置或数据库实施。

doc/plan/许继S1-S4智能体协同建设方案.md

@@ -0,0 +1,601 @@
+# 许继 S1–S4 智能体协同建设方案
+
+> 文档版本：V1.0<br>
+> 编制日期：2026 年 10 月 26 日<br>
+> 文档定位：业务需求与产品建设方案<br>
+> 适用对象：客户管理层、业务负责人、产品负责人、实施团队与研发团队<br>
+> 规划依据：《Ai-DOP 制造业数据智能运营平台整体产品规划》《Ai-DOP 产品规划方案（业务版）》及《AI-DOP 本体驱动智能体建设方案》
+
+---
+
+## 一、方案摘要
+
+### 1.1 建设背景
+
+许继本次提出的需求，表面上包含需求预测、动态排程、物料齐套、供应商选择、采购执行、异常分析和绩效改善等多项智能能力，实质上希望解决一个更完整的经营问题：
+
+> 当客户需求、订单交期、生产能力、物料供应或采购执行发生变化时，系统能够及时发现影响，组织销售、计划、物控和采购等角色共同判断，形成可执行方案，并持续跟踪结果。
+
+这一目标不能依靠一个无边界的“万能智能体”一次完成，也不能仅建设一个问答机器人。最佳建设路径是：先把 S1–S4 每个业务领域建设成职责清晰、独立可用、结果可验证的领域智能体，再由订单交付指挥官组织跨领域协同；S8 负责异常闭环，S9 负责绩效评价和持续改善。
+
+### 1.2 总体建设思路
+
+本方案采用“统一底座、领域自治、跨域协同、横向闭环”的产品架构：
+
+1. **统一底座**：Ai-DOP S0、数据中台、知识库、权限、审批、证据和审计能力由所有智能体共同使用。
+2. **领域自治**：分别建设 S1 订单与交付承诺、S2 制造计划、S3 物料与供应、S4 采购执行四个领域智能体。
+3. **跨域协同**：建设订单交付指挥官，围绕订单目标编排 S1–S4，形成统一方案。
+4. **横向闭环**：S8 监测异常和处置过程，S9 评价经营结果与改善效果。
+5. **分级授权**：先分析、再协同、后执行；高风险业务动作始终由有权人员确认或审批。
+
+### 1.3 预期业务结果
+
+- 订单交期变化能够快速形成产能、物料、采购和交付影响清单。
+- 计划人员能够比较多个排程方案，而不是依赖人工逐项查找。
+- 物控人员能够快速回答工单是否齐套、缺什么、何时到、影响什么。
+- 采购人员能够聚焦真正影响订单的延期和短交事项。
+- 管理人员能够看到风险、责任、方案、执行进度和最终效果。
+- 每项分析都有业务数据和规则依据，每项行动都有责任人和过程记录。
+
+---
+
+## 二、需求理解与范围澄清
+
+### 2.1 原始需求归纳
+
+原始材料提出的业务诉求可归纳为六类：
+
+| 需求领域 | 主要诉求 | 期望结果 |
+|---|---|---|
+| 需求与订单 | 综合历史需求、产品和外部因素进行预测；分析交期变化 | 提前识别需求波动，给出可信交付承诺 |
+| 制造计划 | 结合 BOM、工艺、产能、报工和质量动态排程 | 提升计划可执行性，降低频繁人工调整 |
+| 物料供应 | 识别 BOM 和齐套异常，分析替代料和供应风险 | 提前暴露缺料，形成保供方案 |
+| 供应商协同 | 评价交期、质量、配额和历史履约，推荐货源 | 提高选供质量和供应稳定性 |
+| 采购执行 | 衔接采购订单、交货计划、送货、收货和催交 | 减少例行跟踪，提高异常处理效率 |
+| 经营闭环 | 解释“发生了什么、为什么、将会怎样、怎么办” | 从发现问题走向协同决策和结果验证 |
+
+### 2.2 本期建设范围
+
+本方案聚焦 S1–S4：
+
+- S1：订单需求、订单评审、交期承诺与交付影响。
+- S2：制造计划、产能、排程、工序资源与人员需求。
+- S3：物料需求、齐套、替代料、供应风险、供应商与配额。
+- S4：采购订单、交货计划、供应商答复、送货、收货、催交与异常处置。
+- 跨域：围绕订单交付进行 S1–S4 协同。
+- 横向引用：S0 提供统一业务语言，S8 承接异常，S9 评价效果。
+
+### 2.3 不直接等同于本期范围的内容
+
+以下内容属于后续专项，不应在缺少数据和业务确认的情况下直接承诺效果：
+
+- 基于天气、舆情、宏观趋势的完整需求预测模型。
+- 全自动发布生产计划、修改订单交期或调整供应商配额。
+- 无人工审批的采购下单、质量放行和跨系统写入。
+- 未经实际数据验证的“提前 72 小时”“准时率提升 15%”等固定收益指标。
+- 一次性建设覆盖 S1–S9 的全部智能体。
+
+### 2.4 项目启动前必须确认的客户条件
+
+- 许继本期涉及的组织、工厂、产品和业务范围。
+- ERP、MES、WMS、QMS、SRM 等系统的实际分工和权威数据边界。
+- 订单、工单、BOM、工艺、库存、采购和供应商数据的可获得性。
+- 当前订单评审、排程、齐套、采购和异常处理流程。
+- 各岗位的决策权限、审批要求和跨部门协同机制。
+- 典型订单、异常案例、历史数据时间范围和验收样本。
+
+---
+
+## 三、总体业务蓝图
+
+### 3.1 面向订单交付的协同主线
+
+```text
+客户需求与订单
+→ S1 判断交付要求和承诺风险
+→ S2 判断产能、工序和排程可行性
+→ S3 判断物料齐套和供应可行性
+→ S4 判断采购交付和催交可行性
+→ 订单交付指挥官汇总方案
+→ 责任人确认或审批
+→ 各领域执行并持续反馈
+→ S8 监控异常
+→ S9 评价交付和改善效果
+```
+
+### 3.2 五个业务角色
+
+| 角色 | 主要责任 | 智能体提供的帮助 |
+|---|---|---|
+| 销售/订单人员 | 接收需求、确认订单和客户交期 | 交期影响、承诺建议、风险说明 |
+| 计划人员 | 制定生产计划、平衡产能和资源 | 负荷分析、排程方案、瓶颈提示 |
+| 物控人员 | 计算物料需求、保证工单齐套 | 四量分析、缺料原因、保供方案 |
+| 采购人员 | 下达采购、跟踪供应商和到货 | 延期识别、催交清单、选供建议 |
+| 运营负责人 | 协调跨部门冲突、确认优先级 | 风险排序、方案比较、闭环跟踪 |
+
+角色是智能体的服务对象，不等于每个岗位都单独部署一个技术系统。同一个领域智能体可以按照岗位权限呈现不同信息和动作。
+
+### 3.3 产品组成
+
+```text
+订单交付指挥官
+├─ S1 订单与交付承诺智能体
+├─ S2 制造计划智能体
+├─ S3 物料与供应智能体
+└─ S4 采购执行智能体
+
+横向控制：
+S8 异常监控与责任闭环
+S9 绩效评价与持续改善
+
+公共底座：
+S0 业务建模 + 数据中台 + 企业知识库
++ 权限 + 审批 + 证据 + 审计
+```
+
+---
+
+## 四、S1 订单与交付承诺智能体
+
+### 4.1 服务对象
+
+销售、订单管理、产销计划、项目经理和运营负责人。
+
+### 4.2 业务职责
+
+- 汇总订单、客户要求、产品、历史交付和现有计划信息。
+- 识别新增订单、数量变化、优先级变化和交期提前带来的影响。
+- 调用 S2、S3、S4 的评估结果，形成可承诺交期建议。
+- 给出不同方案对产能、物料、采购和其他订单的影响。
+- 生成订单评审意见、风险清单和协同任务草稿。
+
+### 4.3 典型问题
+
+- 订单 A 能否按客户要求日期交付？
+- 客户要求提前 10 天，会影响哪些工单和采购单？
+- 哪些订单当前承诺存在较高风险？
+- 如果订单 A 优先生产，哪些订单需要顺延？
+- 新产品缺少完整历史数据时，应如何进行需求判断？
+
+### 4.4 输出结果
+
+- 建议承诺日期及其依据。
+- 受影响订单、工单、物料、采购和发货清单。
+- 风险等级、风险原因和待确认事项。
+- 可选方案及方案间的业务取舍。
+- 经人工确认后形成的订单评审或变更任务。
+
+### 4.5 权限边界
+
+- 可自动完成查询、计算、解释和风险提示。
+- 可起草交期调整、评审意见和协同任务。
+- 不可自行向客户承诺新交期。
+- 不可绕过审批直接修改正式订单或已发布计划。
+
+---
+
+## 五、S2 制造计划智能体
+
+### 5.1 服务对象
+
+主计划员、生产计划员、车间管理者和运营负责人。
+
+### 5.2 业务职责
+
+- 汇总订单需求、BOM、工艺路线、设备、产线、班次、人员和工作日历。
+- 比较理论产能、可用产能和实际完成能力。
+- 识别瓶颈工序、资源冲突、换型损失和计划不可执行项。
+- 生成多个排程方案，说明各方案对交期、效率和在制品的影响。
+- 根据计划任务和标准工时给出人员与班次建议。
+- 跟踪计划发布后的执行偏差并触发重新评估。
+
+### 5.3 典型问题
+
+- 本周哪些产线超过可用负荷？
+- 订单 A 提前后怎样重排影响最小？
+- 今日计划需要多少人、分几个班次？
+- 理论产能与实际产出差距来自设备、人员还是物料？
+- 某关键设备停机后有哪些替代方案？
+
+### 5.4 输出结果
+
+- 产线和工序负荷图。
+- 瓶颈资源及影响订单。
+- 可比较的排程备选方案。
+- 人员、班次、加班和转线建议。
+- 计划变更草稿和需要协同的物料、采购事项。
+
+### 5.5 权限边界
+
+- 可自动完成产能分析、计划模拟和风险提示。
+- 可起草排程调整方案。
+- 正式计划发布、工单优先级调整和跨订单资源抢占必须由计划负责人确认。
+
+---
+
+## 六、S3 物料与供应智能体
+
+### 6.1 服务对象
+
+物控、计划、供应链管理、采购和运营负责人。
+
+### 6.2 业务职责
+
+- 按订单和工单分析物料需求、齐套状态和缺料时间窗口。
+- 汇总在库、在检、在途、占用及欠料数量。
+- 识别 BOM、单位、替代关系和供应参数异常。
+- 判断缺料对工单开工、生产连续性和订单交付的影响。
+- 结合历史履约、交期、质量和配额评价供应商。
+- 生成替代料、调拨、催交、改配额或重新选供建议。
+
+### 6.3 典型问题
+
+- 工单 WO001 是否齐套，缺什么、缺多少？
+- 物料 A 的在库、在检、在途和占用分别是多少？
+- 哪些缺料会真正阻断本周生产？
+- 能否使用替代料，替代后有哪些质量或工艺限制？
+- 新需求应优先分配给哪个供应商？
+
+### 6.4 输出结果
+
+- 工单齐套结论和四量明细。
+- 缺料影响订单、工单和开工日期。
+- 缺料原因及证据。
+- 替代料、库存调拨、采购催交和供应商调整建议。
+- 待采购执行智能体处理的任务清单。
+
+### 6.5 口径原则
+
+- 欠料必须引用企业确认的权威计算口径。
+- 在库、在检、在途、占用不得由大模型自行推算。
+- 替代料建议必须校验产品、工艺、质量和客户限制。
+- 供应商推荐必须展示评分依据，不能只输出结论。
+
+### 6.6 权限边界
+
+- 可自动完成齐套、缺料和供应风险分析。
+- 可起草替代、调拨、配额和选供建议。
+- 替代料启用、正式货源变更和配额调整必须由有权人员审批。
+
+---
+
+## 七、S4 采购执行智能体
+
+### 7.1 服务对象
+
+采购员、采购经理、供应商协同人员、物控和运营负责人。
+
+### 7.2 业务职责
+
+- 跟踪采购申请、采购订单、交货计划、供应商答复、送货、收货和检验全过程。
+- 识别未答复、未发货、短交、延期、到货未检和质量异常。
+- 将采购异常与受影响的订单、工单和物料建立关联。
+- 根据订单优先级和缺料时间窗口生成催交优先级。
+- 起草催交通知、交期变更、分批交付、加急运输和替代供应建议。
+- 记录供应商反馈，持续更新预计到货和风险判断。
+
+### 7.3 典型问题
+
+- 今天最需要催交的是哪些采购单？
+- 供应商承诺日期是否满足工单开工时间？
+- PO001 延期会影响哪些订单？
+- 供应商只能交付一部分，应该优先满足哪些工单？
+- 某物料应催交、改期、分批送货还是更换供应商？
+
+### 7.4 输出结果
+
+- 按订单影响排序的采购风险清单。
+- 未答复、延期、短交和质量异常清单。
+- 催交任务及推荐沟通内容。
+- 交货调整、分批交付和替代供应方案。
+- 供应商响应、任务进展和最终到货跟踪。
+
+### 7.5 权限边界
+
+- 普通提醒和内部任务可在授权范围内自动发起。
+- 对外催交信息可先生成草稿，由采购人员确认发送。
+- 采购订单变更、价格变更、供应商切换和正式交期修改必须审批。
+
+---
+
+## 八、订单交付指挥官与多智能体协同
+
+### 8.1 产品定位
+
+订单交付指挥官是跨领域协同入口，不替代 S1–S4 的专业判断，也不重复建设它们的计算能力。它负责理解目标、拆分任务、组织分析、处理冲突、形成综合方案并跟踪结果。
+
+### 8.2 协同职责
+
+1. 识别用户提出的是订单、产能、物料还是采购问题。
+2. 建立统一的订单协同任务和业务上下文。
+3. 向相关领域智能体发出结构化分析请求。
+4. 汇总结论，识别领域之间的矛盾。
+5. 生成一到多个可比较的综合方案。
+6. 将需要决策的事项提交给相应责任人。
+7. 跟踪行动执行、异常变化和最终交付结果。
+
+### 8.3 协同原则
+
+- 围绕同一订单、同一版本、同一数据时间点协同。
+- 智能体之间传递结构化业务结果，不依赖自由对话猜测含义。
+- 每个结论保留来源、时间和适用范围。
+- 发生冲突时不自动覆盖，由业务责任人确认优先级。
+- 跨领域行动通过任务、审批和业务服务执行，不由智能体直接修改数据库。
+
+### 8.4 典型场景一：客户要求提前交货
+
+```text
+客户提出交期提前
+→ S1 识别订单范围和新目标
+→ S2 评估产能、工序与重排影响
+→ S3 评估齐套、缺料、替代与供应风险
+→ S4 评估催交、分批到货和供应商调整
+→ 指挥官形成方案 A/B/C
+→ 运营负责人组织确认
+→ 各领域执行获批行动
+→ S8 监控执行异常
+→ S9 评价是否按新目标完成
+```
+
+综合方案至少说明：
+
+- 新交期是否可实现。
+- 需要改变哪些计划和采购安排。
+- 会影响哪些其他订单。
+- 需要增加哪些成本或资源。
+- 剩余风险及责任人。
+
+### 8.5 典型场景二：工单缺料处置
+
+```text
+齐套检查或生产准备发现缺料
+→ S3 给出四量、欠料和影响
+→ S4核对采购答复、在途和可催交空间
+→ S2判断工单能否调整顺序或部分开工
+→ S1判断订单承诺是否受影响
+→ 指挥官形成调拨/替代/催交/重排组合方案
+→ 责任人确认并执行
+→ 持续复检直至齐套或关闭
+```
+
+### 8.6 典型场景三：产能不足与人员调整
+
+```text
+S2 发现理论产能与实际产能偏差
+→ 分析设备、换型、人员、质量和来料影响
+→ S3确认物料是否限制增产
+→ S1确认受影响订单优先级
+→ 输出加班、换班、转线、重排或交期协商方案
+→ 人员与计划负责人确认
+→ 执行后持续比较计划与实际结果
+```
+
+---
+
+## 九、S8 异常与 S9 绩效的横向闭环
+
+### 9.1 S8 异常协同
+
+S8 不是第五个普通业务助手，而是覆盖 S1–S4 的异常控制中心：
+
+- 接收规则监测、业务事件和人工上报。
+- 统一异常类型、等级、责任和时限。
+- 关联订单、工单、物料、采购单和供应商。
+- 记录发现、响应、处理、验证和关闭全过程。
+- 对超时、重复和影响扩大的异常进行升级。
+- 将异常处理结果反馈给各领域智能体。
+
+### 9.2 S9 绩效与改善
+
+S9 负责判断智能体协同是否真正改善经营：
+
+- 订单按期交付率。
+- 计划达成率和排程稳定性。
+- 工单齐套率和缺料停工时长。
+- 供应商交付满足率。
+- 采购异常响应与关闭时长。
+- 智能建议采纳率和采纳后有效率。
+- 从发现问题到形成可执行方案的平均时长。
+
+### 9.3 完整闭环
+
+```text
+业务变化或异常
+→ 智能体发现并分析
+→ 形成综合方案
+→ 人工确认或审批
+→ 业务执行
+→ S8 跟踪异常是否解除
+→ S9 评价经营结果是否改善
+→ 经复核的经验沉淀为规则、SOP 和案例
+```
+
+---
+
+## 十、单智能体成熟路径与授权边界
+
+### 10.1 第一级：分析助手
+
+- 查询业务事实。
+- 解释指标和状态。
+- 识别风险并展示证据。
+- 给出候选建议。
+- 默认只读，由用户决策。
+
+验收重点：数据正确、口径一致、证据完整、回答稳定。
+
+### 10.2 第二级：任务智能体
+
+- 创建分析任务和协同任务。
+- 生成方案和业务草稿。
+- 发起确认、审批、催办和通知。
+- 跟踪任务状态并提醒超时。
+
+验收重点：任务可追踪、责任清楚、审批完整、失败可恢复。
+
+### 10.3 第三级：有界执行智能体
+
+- 在明确授权下执行白名单低风险动作。
+- 中风险动作经用户确认。
+- 高风险动作经正式审批。
+- 执行后自动验证结果，异常时停止、补偿或转人工。
+
+验收重点：权限正确、审计完整、幂等可控、结果可验证。
+
+### 10.4 动作分级示例
+
+| 风险级别 | 业务动作 | 控制方式 |
+|---|---|---|
+| 低风险 | 查询、摘要、内部提醒、页面导航 | 可自动执行并记录 |
+| 中风险 | 创建任务、生成草稿、普通催办 | 用户确认后执行 |
+| 高风险 | 修改交期、发布排程、变更配额、采购订单变更 | 正式审批后执行 |
+| 禁止 | 跨权限访问、直接写库、绕过审批、模型自由生成查询 | 永久禁止 |
+
+---
+
+## 十一、实施路线、交付物与验收
+
+### 11.1 建设策略
+
+采用“场景牵引、单域先行、协同验证、逐级授权”的方式，不以一次建设全部算法和全部智能体为目标。
+
+### 11.2 建议实施阶段
+
+| 阶段 | 建设重点 | 主要交付物 | 业务验收 |
+|---|---|---|---|
+| M0 需求与数据确认 | 流程、角色、对象、口径、系统和样例确认 | 需求基线、数据清单、场景清单、权限矩阵 | 业务范围和验收样本签字确认 |
+| M1 公共底座 | 统一业务对象、知识、工具、证据、权限和审计 | 对象目录、工具目录、知识目录、审计规则 | 同一对象跨模块含义一致，权限有效 |
+| M2 单智能体试点 | S1–S4 只读分析能力；优先缺料和交期影响 | 四个领域助手、证据报告、场景测试 | 关键结论与业务人员人工结果一致 |
+| M3 任务协同 | 方案、任务、审批、通知和进度跟踪 | 协同工作台、任务流、审批流 | 端到端任务完整可追踪 |
+| M4 多智能体协同 | 订单交付指挥官编排 S1–S4 | 综合方案、冲突处理、订单协同视图 | 完成交期提前和缺料两个跨域场景 |
+| M5 有界执行与运营 | 白名单动作、效果评价和持续优化 | 授权策略、自动执行、运营报告 | 高风险审批 100%，执行结果可验证 |
+
+具体工期应在 M0 完成后，依据数据质量、接口条件、现有能力复用程度和客户投入共同确定，不在需求未确认前承诺固定周期。
+
+### 11.3 首批两个端到端试点
+
+#### 试点 A：订单交期提前影响分析
+
+- 覆盖 S1→S2→S3→S4。
+- 验证跨领域数据、方案比较和责任协同。
+- 验收结果：能够形成完整影响清单和至少两个可比较方案。
+
+#### 试点 B：工单缺料分析与处置
+
+- 覆盖四量、缺料原因、采购到货、排程调整和订单影响。
+- 验证证据、任务、审批和结果复检。
+- 验收结果：从发现缺料到关闭形成完整可追溯链路。
+
+### 11.4 交付物
+
+- S1–S4 智能体业务说明和使用手册。
+- 订单交付指挥官协同工作台。
+- 统一业务对象、关系和事件目录。
+- 领域工具与权限目录。
+- 指标、规则、SOP 和案例知识目录。
+- 典型场景配置与测试用例。
+- 数据对账、模型评测、权限测试和 UAT 报告。
+- 智能体运行、审计和价值运营报告。
+
+### 11.5 验收原则
+
+#### 业务正确
+
+- 分析结果与已确认的业务规则一致。
+- 订单、工单、物料、采购等关联正确。
+- 方案由相应业务负责人确认可执行。
+
+#### 数据可信
+
+- 关键结论带数据时间、口径和证据来源。
+- 同一指标在页面、智能体和报表中结果一致。
+- 数据缺失时明确说明，不猜测、不虚构。
+
+#### 权限可控
+
+- 不同角色只能查看和执行授权范围内的内容。
+- 高风险动作审批覆盖率 100%。
+- 所有调用和执行均有日志。
+
+#### 过程可追踪
+
+- 能查看智能体做了什么、依据什么、由谁确认以及执行结果。
+- 失败任务可重试、终止或转人工。
+
+#### 价值可评价
+
+项目启动时记录改善前基线，上线后按实际数据评价：
+
+- 交期影响分析耗时。
+- 缺料定位和处置耗时。
+- 人工跨系统查询次数。
+- 采购催交有效率。
+- 智能建议采纳率和有效率。
+- 订单按期交付、计划达成和工单齐套变化。
+
+不以未经基线验证的固定百分比作为首期验收承诺。
+
+---
+
+## 十二、实施保障、风险与影响边界
+
+### 12.1 数据保障
+
+- 明确每个业务对象的权威来源和责任人。
+- 建立源系统、数据中台、Ai-DOP 页面和智能体结果之间的对账机制。
+- 数据未达到要求时，优先治理数据，不通过提示词掩盖问题。
+- 对历史数据不足的新产品采用相似产品、人工输入和场景假设，并明确置信范围。
+
+### 12.2 知识保障
+
+- 只使用经过负责人确认的制度、SOP、指标口径和业务规则。
+- 知识按组织、岗位、版本和有效期治理。
+- 智能体回答引用知识来源，不把日常对话自动当成正式制度。
+
+### 12.3 技术与运行保障
+
+- 智能体只通过登记并授权的领域工具访问业务能力。
+- 业务计算由确定性服务完成，大模型负责理解、组织和解释。
+- 采用统一运行适配层，避免绑定单一模型或运行平台。
+- 支持超时、重试、幂等、熔断、灰度、回滚和全链路审计。
+- 所有能力按租户、组织、角色和场景逐步启用。
+
+### 12.4 主要风险与应对
+
+| 风险 | 主要表现 | 应对 |
+|---|---|---|
+| 范围过大 | 同时建设预测、排程、选供和自动执行 | 以两个端到端场景起步，分阶段扩展 |
+| 数据不可用 | 对象关联缺失、口径不一致、更新不及时 | 先完成数据盘点、对账和质量门禁 |
+| 智能体职责重叠 | 多个智能体重复分析或结论冲突 | 明确领域边界，由指挥官协调冲突 |
+| 模型给出错误建议 | 结论无证据或误解规则 | 确定性计算、证据强制、人工确认 |
+| 自动化越权 | 未经授权修改计划、交期或采购 | 动作分级、最小权限和审批闸门 |
+| 用户不采纳 | 结果不能融入现有工作方式 | 以岗位工作台、真实任务和业务验收推进 |
+| 价值难衡量 | 只有演示，没有经营改善 | 建立上线前基线和上线后持续评价 |
+
+### 12.5 组织机制
+
+- 客户业务负责人确认场景优先级、规则和验收结果。
+- 销售、计划、物控和采购分别指定领域负责人。
+- IT 与数据团队负责系统、接口、口径和数据质量。
+- Ai-DOP 产品团队负责智能体边界、协同体验和产品一致性。
+- 实施团队负责数据映射、场景配置、培训和上线运行。
+- 每个阶段设置业务确认门，未确认不批量展开。
+
+### 12.6 反向影响推演
+
+- **代码调用面 → 需同步核查**：实施前检索并确认 S1–S4、ChatBI、S8、S9、审批、通知和领域服务的全部调用方。
+- **数据契约面 → 需同步改**：统一订单上下文、对象关系、业务事件、工具输入输出及证据格式。
+- **多数据源面 → 需项目确认**：明确许继 ERP、MES、WMS、QMS、SRM 的权威边界和缺字段处理方式。
+- **多租户与 Domain 面 → 需同步改**：所有智能体、工具、知识、任务和审计继承服务端租户及组织作用域。
+- **运行面 → 需同步改**：纳入发布、调度、监控、告警、灰度、回滚和模型成本管理。
+- **验证面 → 需同步改**：先完成单智能体准确性、权限和工具测试，再进行跨智能体场景 UAT。
+
+---
+
+## 结论
+
+许继需求的最终目标不是增加若干 AI 功能，而是让订单交付过程形成可感知、可分析、可协同、可执行、可评价的智能运营闭环。
+
+本方案建议先建设 S1–S4 四个边界明确的领域智能体，使其分别在订单、计划、物料和采购领域独立创造价值；再通过订单交付指挥官组织跨领域协同，以 S8 管理异常、以 S9 评价结果，并在统一数据、知识、权限和审批约束下逐步开放有界执行能力。
+
+这一建设路径既承接 Ai-DOP 的完整产品规划，也能从许继真实业务场景出发分步验收、控制风险，并为后续扩展到 S5–S9 和更多工厂保留统一架构。