249 lines
20 KiB
Markdown
249 lines
20 KiB
Markdown
# Pi 调度中心驱动的计划员助手：产品与实施蓝图
|
||
|
||
日期：2026-09-09。依据：用户对重复排产提示、数据混乱、专业术语、计划员经验学习及工厂系统可插拔接入的要求。
|
||
|
||
本文中的调度中心、经验学习完整闭环和统一工厂接入层是待实施目标，不代表已经上线。本次已落地的修复和验证见末尾。
|
||
|
||
## 1. 产品定位与验收口径
|
||
|
||
一个熟悉本工厂做法的计划员助手。计划员告诉它要排哪些订单、什么时候交货、有哪些变化，助手负责查数据、理解规则、协调计算、解释结果；需要业务判断时提出具体选择。
|
||
|
||
普通用户面对一个助手。Pi Agent 是任务调度中心，后台按任务调用专业 Agent 和业务工具；用户不需要先选智能体、求解器或内部接口。
|
||
|
||
完成度按计划员能否完成整件事验收：从真实订单和现有生产安排开始，得到可解释方案，经确认下发，收到执行反馈，出现偏差后能调整。目录有文件、算法返回成功、测试通过，分别只是其中一个步骤。
|
||
|
||
## 2. 截图反映的问题与当前代码证据
|
||
|
||
| 问题 | 已核实原因 | 应有行为 |
|
||
|---|---|---|
|
||
| 已经做过排产，仍不断提示再次排产 | 数据卡只判断 canSchedule；历史卡一直保留操作按钮；guidance 原先只看固定轨版本 | 下一步由当前方案和待确认事项决定；历史检查报告只供回看 |
|
||
| 工作簿各类数量对不上 | folder_pack 把首类当作后续 sheet 的汇总类别，又把文件有效总行数回填到该类别 | 每个 sheet 归属一个明确业务类别；总数与分项可核对 |
|
||
| 一次确认产生多版 | execute_confirmed 的 folder.schedule 分支先在候选世界求解，提交后又求解一次 | 一次确认只提交一版经过校验的结果，重试不重复执行 |
|
||
| 同样的数据铺满对话 | Markdown 正文、folder-pack 和 project-analyze 重复展示 | 一个简短结论、一张主卡；完整数据和诊断可展开 |
|
||
| 演示产品和真实数据难区分 | 快捷口令含 PDU、示例料号；数据来源和用途未统一展示 | 正式项目默认空数据；示例、推断、人工确认、系统同步分别标明来源 |
|
||
| 很多内部术语直接给计划员 | P2、Plan、虚拟产线、原始字段、算法代码进入默认界面 | 用户看业务意义，技术字段在管理员诊断中查看 |
|
||
| “分析”也可能改变项目数据 | analyze_project_deep 会导入记录、调用知识模板补全并保存知识资料 | 后续将纯读取检查、待确认补全、正式入库分开；本次保留既有业务语义并说明数据整理行为 |
|
||
|
||
截图下部实际呈现的是“等待确认”的卡片，不能据此证明已经生成方案。页面未解释清楚这一区别，正是需要修复的状态表达问题。
|
||
|
||
当前数据来源隔离还需独立验收。本次只识别 DEMO 前缀并提示，没有根据前缀删除、改写任何用户数据，也不能据此判定所有数据的真实来源。
|
||
|
||
## 3. 以真实计划员工作流组织应用
|
||
|
||
### 3.1 首次接入工厂：先学会工厂怎么排
|
||
|
||
1. 收集最近一段时间的订单、手工排程、班次表、设备台账、工艺卡、缺料记录、插单/延期处理记录。
|
||
2. Pi 让数据 Agent 对齐订单、产品、工序、设备与日历；只对影响当前任务的缺项提问。
|
||
3. 经验 Agent 归纳计划员做法，逐条附上来源、适用产品/产线、适用条件、例外和置信度。
|
||
4. 用计划员的语言确认，例如：“你们是否通常先排同色产品，以减少清洗？遇到急单可以打断吗？”
|
||
5. 将确认后的做法转成规则候选，用历史订单回放，比较交期、换型次数、加班和设备负荷。
|
||
6. 计划员看懂差异并确认后，规则版本生效；原规则可恢复。
|
||
|
||
不能把一次手动调整自动固化为长期规则。订单临时偏好、车间制度和不可违反的设备限制应分别管理。
|
||
|
||
### 3.2 日常排产
|
||
|
||
用户：“把本周这些订单排一下，急单先保证，尽量别加班。”
|
||
|
||
- 助手先显示：本次选中的订单、数据更新时间、已有生产安排、已确认规则。
|
||
- 发现缺项时只问关键问题：“这两个产品缺加工时间，请提供，或允许用哪份历史记录估算？”
|
||
- 信息齐全后展示简短任务计划：“核对库存和在制品 → 计算安排 → 检查交期”，后台自动执行无副作用任务。
|
||
- 结果首屏回答四件事：排了哪些单、多少能按时交、哪些有风险、需要用户决定什么。
|
||
- 推荐一个方案；需要取舍时最多先给两三个可解释选项，如“交期优先”“少换型”“少加班”。
|
||
- 用户可用自然语言调整：“这张单晚一天也行”“这台机明天停半天”，只重新计算受影响部分。
|
||
- 发布、下发及下发后的执行状态分开显示；没有工厂回执，不显示“已下发成功”。
|
||
|
||
### 3.3 状态与唯一推荐动作
|
||
|
||
| 真实状态 | 用户看到的说明 | 主要操作 |
|
||
|---|---|---|
|
||
| 缺数据 | 还差哪些信息、会影响哪些单、如何补齐 | 补充信息 |
|
||
| 规则待确认 | 从现有做法整理出哪些规则、有何依据 | 确认本次规则 |
|
||
| 数据已检查 | 已读到数据，尚未生成方案 | 确认生成方案 |
|
||
| 正在排产 | 当前阶段和已完成检查；支持取消 | 查看进度 |
|
||
| 方案已生成 | 版本、订单、交期风险、尚未下发 | 检查方案 |
|
||
| 有待决策事项 | 清楚列出冲突和取舍 | 选择调整方式 |
|
||
| 等待发布确认 | 将影响的订单、范围和版本 | 确认发布 |
|
||
| 已发布但未下发 | 哪个车间/系统仍未接收 | 查看下发状态 |
|
||
| 已接收/执行中 | 厂商回执与进度，数据更新时间 | 跟踪生产 |
|
||
| 发生变化 | 插单、缺料、设备变化及影响 | 查看调整建议 |
|
||
| 中断或结果未知 | 哪一步未完成、哪些结果已保存 | 恢复或核对状态 |
|
||
|
||
状态依据服务器业务事实，不能根据助手文字猜测。实施时引入 SchedulingCase：tenantId/projectId/sessionId/caseId、订单选择、dataSnapshotId、ruleVersion、planVersionId、pendingActionId、revision、stage、allowedActions、来源证据。
|
||
|
||
旧卡保存当时的快照，主要操作绑定当前 revision。数据或规则变化后，旧推荐失效但原计划不自动改写。阶段只能在动作真实完成后推进。
|
||
|
||
## 4. 充分发挥 Pi Agent：一个调度中心与六类专业协作者
|
||
|
||
### 4.1 职责划分
|
||
|
||
| 角色 | 负责什么 | 交付结果 |
|
||
|---|---|---|
|
||
| Pi 调度中心 | 理解目标、制定任务图、选择 Agent/工具、追踪依赖、判断何时提问、组织异常恢复 | 任务计划、统一进度、下一步、面向用户的答复 |
|
||
| 数据 Agent | 读文件和工厂系统、字段映射、校验来源与关联、识别缺项 | 数据快照、问题清单、待确认映射 |
|
||
| 经验与规则 Agent | 整理访谈/SOP/历史排程与调整理由，形成规则候选 | 带依据、适用范围和例外的规则候选 |
|
||
| 排产 Agent | 组装标准排产问题、选择算法、调用求解工具、生成候选方案 | 有明确数据和规则版本的排产结果 |
|
||
| 方案检查 Agent | 独立验证资源、日历、前后序、齐套和交期，比较现有安排 | 可复核的通过/不通过、风险及调整建议 |
|
||
| 系统对接 Agent | 识别插件能力、读取状态、组织字段问题、准备下发/对账任务 | 标准数据、下发草案、回执和差异 |
|
||
| 结果讲解 Agent | 将经过验证的结果整理成业务语言、排产表与复盘 | 可追溯解释、表格、需用户决定的事项 |
|
||
|
||
角色是能力边界，不要求每次都启动六个 LLM 进程。简单任务由 Pi 直接调工具；跨来源核验、复杂规则整理、多方案比较才拆给多个 Agent。
|
||
|
||
### 4.2 可执行编排方式
|
||
|
||
Pi 输出受校验的任务图，每步声明 taskId、role、inputRefs、dependsOn、capability、预计副作用、成功条件、超时、重试上限。模型提出计划，由调度服务校验和执行。
|
||
|
||
1. 订单、库存、设备、规则检索等互不依赖的读取可以并行。
|
||
2. 来源对齐完成后冻结输入，各方案求解使用隔离快照，可并行计算。
|
||
3. 方案检查依赖求解完成，检查失败自动回到调整任务；重试次数有限。
|
||
4. 最终只由一个提交服务写入已选方案，防止多个 Agent 同时修改生产安排。
|
||
5. 影响主数据、规则生效、方案采用/发布/下发的动作进入既有确认机制。
|
||
6. Pi 不持有人工确认令牌；同一个 Agent 不能靠自报“检查通过”完成批准。
|
||
7. 重启恢复读取持久化任务状态和工具回执；副作用结果未知时先查询再决定是否重试。
|
||
|
||
共享信息采用任务产物引用，不把所有 Agent 的对话互相复制。每次工具调用绑定 tenant/project/case/run/task/call、输入版本、幂等键、输出证据。后台页面可展开 Agent 分工；普通对话只显示“数据检查完成，正在计算方案”等进度。
|
||
|
||
### 4.3 Pi 的兜底能力
|
||
|
||
- 文件结构未知：探索表头和样例，提出映射候选；不能自动猜测单位、库存或工时后当真使用。
|
||
- 数据不足：检索历史资料和知识库，列出具体可选来源，请计划员确认关键假设。
|
||
- 排产不可行：调用约束诊断，分别比较加班、换设备、延交和分批交货的影响。
|
||
- 插单或设备故障：先定位影响范围，优先局部调整，展示会改变哪些已有承诺。
|
||
- 外部系统断连：保存任务进度，区分本地记录、待同步、外部已接收；恢复后先对账再补推。
|
||
- 工具失败：有限重试、切换到明确等价的工具或生成待处理事项，不编造成功结果。
|
||
|
||
### 4.4 现有代码复用与缺口
|
||
|
||
| 当前资产 | 可复用部分 | 接入调度中心前必须补齐 |
|
||
|---|---|---|
|
||
| server/integrations/pi_bridge.py | Pi 运行、工具登记、快照、调用日志与引用校验 | 专业角色的任务输入/输出契约、受控任务委派与任务产物引用 |
|
||
| server/agent_core/fallback_lane.py | Pi 主回复、受控计划、检查点、偏差校验、失败处理 | 与 SchedulingCase 统一任务状态，主流程和兜底共用一次任务上下文 |
|
||
| server/agent_core/mesh.py | 角色、任务依赖、任务存储、运行线程、看门狗 | 当前模板含自动批准 P2 和固定下达步骤；须改成待人工确认/显式授权，才能接到正式生产主流程 |
|
||
| server/agent_core/plan_runtime.py、plan_orchestration.py | 计划节点、执行记录、确认关联 | 和 Pi 任务图对齐，避免再造一套互不一致的任务状态 |
|
||
| server/agent_core/tool_runtime.py、harness.py | 统一业务执行与确认机制 | 所有 Agent 经过该入口，禁止新建旁路写通道 |
|
||
| server/aps_domain/sop_rules.py | 已审批 SOP 到规则补丁的预览/应用 | 当前为模板与关键词编译；补全真实经验提取、规则冲突检测与历史回放 |
|
||
|
||
Round 85 的完整外部 Pi 接入仍需与当前主线受控整合。其历史验收不能代替修改后主线的真实 Pi 多任务验收。
|
||
|
||
## 5. 从经验到可执行知识和约束
|
||
|
||
知识库保存“为什么”，规则库保存“怎么计算”。同一条经验同时关联出处和可执行约束，不能只做文本检索。
|
||
|
||
RuleCandidate 至少包含：自然语言描述、sourceRefs、适用产品/工厂/产线、触发条件、硬约束或偏好、参数及单位、例外、有效期、置信度、确认人、回放结果。
|
||
|
||
示例：“换颜色要清洗半小时，同色尽量连续排。”拆成：同设备异色切换增加 30 分钟；同色连续为优化偏好。工艺员确认清洗时长，计划员确认偏好优先级；急单是否允许打断单独确认。
|
||
|
||
规则生命周期：候选 → 待核对 → 回放验证 → 已确认 → 生效 → 停用/替换。每个排产版本冻结使用的规则版本。
|
||
|
||
计划员移动工单时，记录移动前后、原因、适用范围和结果，供后续归纳；积累案例后提出“是否将这一做法用于同类订单”，不悄悄修改通用规则。
|
||
|
||
上线验收：同一规则在历史数据上可复现；相互矛盾的规则能定位到来源；无法执行的自然语言规则标为待澄清，不能显示已生效。
|
||
|
||
## 6. ERP / MES / WMS 标准模型与可插拔接入
|
||
|
||
### 6.1 分层
|
||
|
||
```text
|
||
ERP / MES / WMS / 文件
|
||
↓ 厂商适配器：鉴权、分页、增量读取、字段和状态映射
|
||
标准业务模型 + 来源与版本 + 数据质量校验
|
||
↓ 冻结本次输入
|
||
Pi 调度中心 → 数据/规则/排产/检查 Agent → 标准排产问题与结果
|
||
↓ 人工确认后的下发请求
|
||
连接器调用 → 厂商回执 → 执行反馈 → 对账 → 调整建议
|
||
```
|
||
|
||
MCP 是工具发现与调用机制；还需要统一业务语义、映射、同步和回执，才构成标准接入层。
|
||
|
||
### 6.2 内部标准对象
|
||
|
||
| 对象 | 关键字段 | 常见权威来源 |
|
||
|---|---|---|
|
||
| CustomerOrder / OrderLine | 外部订单/行号、产品、数量/单位、交期、优先级、状态 | ERP |
|
||
| Product / Material / BOM | 编码、规格、单位换算、版本、生效日期、用量、替代关系 | ERP / PLM |
|
||
| Routing / Operation | 工序顺序、标准工时/单位、批量、前后序、资源要求 | MES / 工艺系统 |
|
||
| Resource / Capability | 设备/人员/模具、可加工能力、容量、维护状态 | MES / 设备系统 |
|
||
| Calendar | 时区、班次、休息、加班、停工窗口 | MES / 排班 |
|
||
| Inventory / Reservation / Supply | 实物库存、预留、可用量、仓库/批次、在途量与预计到达 | WMS / ERP |
|
||
| WorkOrder / WIP | 生产工单、已完成量、在制位置、实际开始/结束、冻结标记 | MES |
|
||
| SchedulePlan / Assignment | 排产版本、订单/工序、资源、时间、输入快照、规则版本 | APS |
|
||
| DispatchRequest / Receipt | 幂等键、外部单号、接受/拒绝/部分接受、原因 | APS 请求 / MES 回执 |
|
||
| ProductionEvent | 来源事件 ID、顺序/版本、发生与接收时间、报工/停机/缺料 | MES / WMS |
|
||
|
||
每个对象共有 tenantId、siteId、sourceSystem、sourceRecordId、sourceVersion、observedAt、schemaVersion、qualityIssues。内部 ID 与外部编码通过映射表关联，不能按名称猜测。
|
||
|
||
### 6.3 插件合同
|
||
|
||
以下为待实现接口设计，当前未宣称支持任意厂商即插即用：
|
||
|
||
```text
|
||
describe() -> 插件版本、标准模型版本、能力、只读/写入分类
|
||
validate_config(configRef) -> 缺少配置项与可操作提示（不返回密钥）
|
||
health() -> 配置状态、连通性、最后成功时间
|
||
read_snapshot(entity, scope, cursor) -> 标准对象、下一页、来源版本
|
||
read_changes(entity, watermark) -> 增量对象/事件、下一水位
|
||
validate_mapping(samples, mappingVersion) -> 类型/单位/关联/状态问题
|
||
prepare_dispatch(planRef) -> 将写入什么、拒绝项、确认所需证据
|
||
dispatch(approvedRequest, idempotencyKey) -> 接受/拒绝/未知及回执
|
||
query_receipt(requestId) -> 外部真实状态
|
||
```
|
||
|
||
供应商差异留在适配器中，排产算法只消费标准模型。插件通过 manifest 登记，配置引用受保护凭据，读取和写入能力分别授权。
|
||
|
||
字段映射必须可预览、可校验、可版本化。库存为 0、库存未知、接口未返回三者分开；分钟与小时、件与套、时区与日期边界必须显式转换。
|
||
|
||
同一字段有冲突来源时使用工厂确认的权威来源规则。同步失败保留最后成功快照并显示时间和影响；生产计算是否可使用过期数据需明确策略。
|
||
|
||
### 6.4 正式接入必须验证的语义
|
||
|
||
- 同一消息重复到达不重复创建工单；乱序和删除事件不覆盖更新状态。
|
||
- 一个批次部分成功时逐项保存回执，不能整批标为成功。
|
||
- 超时不等于失败：写入结果未知时先查回执，防止自动重发造成重复生产单。
|
||
- 库存预留、在途和在制数量口径与工厂确认；禁止将缺失字段补成“可用”。
|
||
- 断点、分页、水位、映射版本和对账差异可追溯；异常不会推进同步水位。
|
||
- MES/WMS 等真实接口不可用时显式提示，不自动切换演示数据。
|
||
|
||
当前已有 mes_http、SAP/WMS stub、MCP 总线及导入 profile。建议先以文件适配器和一家真实工厂的订单/库存/在制接口验证标准模型，再增加厂商适配器；每个新适配器跑同一组合同测试。
|
||
|
||
## 7. 默认界面与术语规范
|
||
|
||
默认入口：今日任务、排产方案、订单与数据、排产经验、系统连接。专业设置和算法诊断放到高级设置。
|
||
|
||
| 内部术语 | 普通用户表达 |
|
||
|---|---|
|
||
| P2 / P3 | 需要你确认 / 需要双人确认 |
|
||
| DRAFT / trial | 待检查方案 / 试排方案，尚未下发 |
|
||
| WO / PO / BOM | 生产工单 / 生产计划 / 产品用料表，按真实对象区分 |
|
||
| 虚拟产线 / 能力池 | 本次生产分组 / 可用设备；说明它不一定是真实固定产线 |
|
||
| 约束、硬约束、软约束 | 排产规则、必须遵守、尽量满足 |
|
||
| KPI / makespan | 交期和负荷指标 / 最后一项预计完成时间 |
|
||
| sourceManifest / checkpoint | 本次使用的数据 / 可恢复的保存点 |
|
||
| MCP / Provider / Adapter | 系统连接 / 接入方式；技术名只在管理员页展示 |
|
||
|
||
结果页先显示摘要和异常，再显示订单排程；避免默认展示整张原始数据库表。任何“成功”必须说明完成了哪一步，不能将读取成功、生成成功、发布成功和外部接收成功混用。
|
||
|
||
## 8. 实施顺序与可执行验收
|
||
|
||
| 顺序 | 交付内容 | 通过标准 |
|
||
|---|---|---|
|
||
| A：主流程可信 | 修正计数、一次批准一次排产、消除重复卡、按状态推荐 | 165 条混合记录不会显示成 165 台设备；重复确认只有一版；已有方案不推荐首次排产 |
|
||
| B：统一任务状态 | SchedulingCase 与现有计划/确认/结果绑定 | 刷新、切会话、数据变化、取消和重启后状态一致；旧操作不会修改新方案 |
|
||
| C：Pi 调度中心 | 任务图、角色工具边界、并行读取、隔离候选、持久化恢复 | 真实 Pi 完成数据核验→规则检索→计算→检查→解释；工具失败和并发冲突能恢复；未确认不能写业务 |
|
||
| D：计划员经验学习 | 资料归纳、规则候选、确认、回放、版本与效果反馈 | 至少一条真实工厂规则有原始依据、人工确认、历史回放及生效排产结果 |
|
||
| E：标准系统接入 | 标准模型、manifest、映射、快照/增量、回执与对账 | 同一排产流程换文件/真实连接器无需改算法；完成一组真实下发与回流、重试/乱序/断连测试 |
|
||
| F：全应用体验统一 | 默认入口、术语、渐进明细、异常处理、交付手册 | 计划员无需知道算法/接口名称，能独立完成一次排产和一次插单调整 |
|
||
|
||
B/C 先复用现有 Plan、Mesh、Pi Bridge 和 Harness，避免重复建设状态存储和执行入口。模型不掌握最终写入权限，用户的业务确认不能由后台角色自动替代。
|
||
|
||
## 9. 本次交付记录
|
||
|
||
本次已修改：工作簿按业务类别计数；目录确认后复用候选求解结果；已有方案的状态建议；数据卡概要/明细分层；历史数据卡操作收起；等待确认时停止推荐再次排产；移除默认示例快捷口令；查看结果按当前排产类型定位。
|
||
|
||
同时保留本轮开始时已有的 7 个文件改动。没有合并 Round 85、提交、推送、发布或修改用户的工厂数据。
|
||
|
||
已验证：后端聚焦 56 passed / 1 warning；扩展审批、发布、契约、Saga 与 MOM 回归 108 passed / 4 skipped / 1 warning；Node 64 passed（含新增数据卡渲染 4 项）；Web TypeScript 和生产构建通过。
|
||
|
||
浏览器控制通道两次返回 nodeRepl.fetch request failed，当前不能提供本次页面交互与截图验收。13 项依赖外部康尼文件的测试在未配置数据路径时跳过，不能算真实客户数据验收。
|
||
|
||
本次完成 A 的具体修复及 B–F 的可实施设计。Pi 多专业 Agent 调度中心、经验学习全闭环、任意 ERP/MES/WMS 标准插件和全应用术语统一尚未实现，不以本文或本次局部测试替代完整交付。
|