aps-agent/docs/product/pi-planner-agent-blueprint.md

20 KiB
Raw Blame History

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 分层

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 插件合同

以下为待实现接口设计,当前未宣称支持任意厂商即插即用:

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 标准插件和全应用术语统一尚未实现,不以本文或本次局部测试替代完整交付。