Industry
/
aps-agent
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
aps-agent/docs/round-65-aps-end-to-end-par...

12 KiB
Raw Blame History

第 65 轮多 agent 并行实施方案：端到端闭环 APS 排产内核

更新日期：2026-08-02

1. 并行实施总览

本轮任务重量：重型。

规模依据：同时涉及 MRP/库存净算、制造需求图、求解器原子性、DTO/Validator、工作流/API、P2/P3 门禁、MES、前端和真实数据验证；核心影响面为 CRITICAL。

确认来源：用户已明确回复“确认 Round 65 推荐方案”。

本轮使用 3 个第一波 worker、1 个第二波前端 worker和 1 个独立审计 worker。主 agent 负责 GitNexus 门禁、计划审计修复、接线集成、真实运行、浏览器验收和最终判断。

因用户明确禁止提交/推送/合并，且当前 289 项工作区变更是权威基线，本轮采用无提交适配：内部 worker 在 forked workspace 修改互斥文件，回传精确 diff/文件清单；主 agent 仅接收经过审查的改动，不创建或推进目标分支。

W1：制造需求 / 供应事件 / 全局净算内核（新文件为主）
W2：原子柔性排产 + 发布/MES 安全门禁
W3：SchedulingProblemV2 + 独立 Validator + 外部 Skill 验证边界
主 agent：API/工作流接线、兼容层、数据迁移、集成验证
W4（第二波）：前端阶段状态、阻断与真实浏览器流程
Audit：只读集成审计

2. 依赖图

计划审计 PASS
├─ W1 制造需求与供应图
├─ W2 原子排产 / MES fail-closed
└─ W3 V2 契约 / Validator
        ↓
主 agent 接线：prepare → solve → validate → materialize → publish → dispatch
        ↓
Focused backend tests PASS
        ↓
W4 前端阶段状态与 API 消费
        ↓
MOM 负向 + 康尼/fixture 正向 + 浏览器验收
        ↓
全量黄金 / Node / Web build / diff / GitNexus detect_changes
        ↓
独立审计 → 修复 → 复验 → 收口

3. Worktree / 工作区规划

已确认的无提交适配

标准 round 协议通常从目标分支创建 round/worktree 并提交 worker 成果。本项目当前不能照搬：

  • main HEAD 不包含现有 289 项权威成果；
  • 用户禁止提交、推送、合并；
  • 从旧 HEAD 创建干净 worktree 会得到错误基线。

因此采用：

  • 主工作区 D:\ItemSpace\14.工业智核\aps-agent：受保护集成区。
  • multi-agent forked workspace：继承当前会话上下文，worker 只写指定文件。
  • 禁止任何 worker 使用 git checkout/reset/clean/stash/commit/push/merge。
  • worker 回传修改路径、focused tests、diff 范围和残余风险。
  • 主 agent 接收前运行 git diff -- <paths>，发现越界立即拒收。
  • 现场数据 server/data/**、.env、数据库、release 产物和日志全部只读保护。

4. Worker 划分

W1：制造需求与供应事件内核

目标：把商务订单、多层 BOM、库存/在途、采购/委外和 MAKE 子件转换为唯一、可守恒的制造需求图。

写入范围（互斥）：

  • server/aps_domain/closed_loop_problem.py（新）
  • server/aps_domain/supply_netting.py（新）
  • tests/golden/test_closed_loop_scheduling.py（新）

禁止修改：

  • mrp.py、flex.py、pool_engine.py、workflow.py、gateway/app.py
  • 现场数据和现有测试

验收：

  • 跨订单共享库存只分配一次。
  • MAKE/BUY/SUBCONTRACT 数量与 pegging 守恒。
  • 时间分段在途/采购/委外供应事件生效。
  • BOM 环、缺失路线和不可信供应显式阻断。
  • 当前 MOM 数据只产生需求/阻断，不产生生产订单或工单。

W2：原子排产与发布/MES 安全门禁

目标：修复部分工单写入并统一柔性发布/下发失败关闭。

写入范围（互斥）：

  • server/engines/pool_engine.py
  • server/aps_domain/mes.py
  • tests/golden/test_flex_atomic_schedule.py（新）
  • tests/golden/test_flex_publish_mes_gate.py（新）

禁止修改：

  • MRP/需求图、DTO/Validator、API、前端、现场数据

验收：

  • 第 N 道硬失败时，本订单 0 VL、0 WO、0 资源/模具/计数残留。
  • 每个 WO 都有唯一 VL；woCount 等于实际工单数。
  • DRAFT、孤儿、不完整、硬阻断或证据漂移的柔性版本不能进入 MES 预览/确认/执行。
  • 现有幂等、补偿和固定轨行为保持兼容。

W3：V2 契约与独立 Validator

目标：建立所有本地/外部算法共享的完整输入输出和失败关闭验证器。

写入范围（互斥）：

  • server/aps_domain/scheduling_problem_v2.py（新）
  • server/aps_domain/scheduling_validator.py（新）
  • tests/golden/test_scheduling_validator_v2.py（新）

禁止修改：

  • 现有 scheduling_dto.py、引擎、API、前端和现场数据

验收：

  • V2 包含 Requirement、SupplyEvent、OperationActivity、Resource、ObjectivePolicy、ConstraintPolicy。
  • Solution 包含 activity identity、时间、资源、未排需求、硬违反、assumptions 和 provenance。
  • Validator 拒绝重叠、错序、越日历/维保、错能力、物料未齐套、孤儿、重复 activity、证据哈希漂移。
  • 可把合法 solution 转为待物化活动，但本 worker 不直接写 world。

主 agent：接线与兼容层

写入范围：

  • server/aps_domain/flex.py
  • server/aps_domain/orders.py
  • server/aps_domain/mrp.py（仅必要接线/全局净算兼容）
  • server/aps_domain/workflow.py
  • server/gateway/app.py
  • server/contracts.py、shared/schemas/**（如新增 HTTP 契约）
  • apps/web/src/api/types.ts、apps/web/src/api/client.ts（契约阶段）
  • 迁移/初始化和集成测试

责任：

  • 修改前逐符号 impact，API handler 修改前 api_impact。
  • 收敛为唯一 prepare → solve → validate → materialize 事务边界。
  • 建立 P2 flex.schedule.publish，保留固定轨兼容。
  • 提供制造准入/阶段/阻断/负荷/未排需求 API。
  • 不在接线中伪造 ASM、班组、模具或到货。

W4：前端阶段化业务流程（第二波）

依赖：后端契约和 focused tests 稳定后开始。

写入范围（互斥）：

  • apps/web/src/orders/OrderPanel.tsx
  • 新增 apps/web/src/orders/* 阶段/阻断组件
  • apps/web/e2e/closed-loop-scheduling.spec.ts（新）
  • 必要样式仅限闭环排产命名空间

禁止修改：

  • 后端、通用认证、全局布局、现场数据

验收：

  • UI 区分“已分解 / 准入通过或阻断 / 排产草案 / 已发布 / 已排生产 / MES 可下发”。
  • MAKE 建议不得冒充生产订单。
  • 显示 39 缺路线、67 模板/缺能力等聚合和逐项原因。
  • 硬阻断时不展示绿色“排产完成”；提供数据维护/候选确认入口。
  • Playwright 覆盖 MOM 负向与完整 fixture 正向阶段。

Audit worker：独立集成审计

只读范围：本轮计划、全部 diff、测试输出、真实运行与浏览器证据。

验收：严格按 AUDIT: PASS|FAIL 输出；无 blocking finding 才可收口。

5. 主 agent 先行门禁

实施前必须完成：

  1. impact(run_flex_schedule)、impact(sync_flex_orders_to_sales)、impact(PoolEngine.solve) 已有结果复核；CRITICAL 已向用户报告。
  2. 对 preview_dispatch、stage_dispatch、apply_dispatch、发布执行函数运行 impact。
  3. 若修改 /api/flex/schedule、MRP、发布或 MES 路由，先运行 api_impact。
  4. 保存现场 world/master.db 和关键源文件 SHA 清单。
  5. 记录当前 8003/5173 健康和浏览器基线。

6. 分阶段集成顺序

  1. 集成 W1 新模型和测试；不接生产路径，先证明需求/供应守恒。
  2. 集成 W3 Validator；用 fixtures 验证非法 solution 全部失败关闭。
  3. 集成 W2 原子性与 MES 门禁；优先消除 P0 执行风险。
  4. 主 agent 接线到 run_flex_schedule 和 P2 发布；运行后端 focused tests。
  5. 接入 W4 前端；运行 Web build 与 Playwright。
  6. 执行真实数据、全量回归、detect_changes 和独立审计。

7. Worker 回传格式

每个 worker 必须报告：

  • 完成状态；
  • 修改文件；
  • focused 测试命令和结果；
  • 验收标准逐项结果；
  • git diff -- <write scope> 范围检查；
  • 关键问题、解决方案、残余风险；
  • 明确声明未提交、未推送、未合并、未触碰现场数据。

发现跨边界依赖时先 send_input 通知主 agent 或相关 worker，不得自行修改对方文件。

8. 测试与证据资产

本轮必须保留可重放资产：

  • 跨订单共享库存 fixture；
  • MAKE/BUY/SUBCONTRACT 多层 BOM fixture；
  • 第五工序缺能力的原子性 fixture；
  • 合法/恶意外部 Skill solution fixtures；
  • MOM--00280 隔离负向验收脚本/断言；
  • 康尼或完整隔离 fixture 正向验收；
  • Playwright 闭环阶段测试。

9. 审计与修复

  • Worker 自检后，主 agent 运行 focused + 集成 + 全量验证。
  • 独立 audit worker 检查目标覆盖、集成风险、验证充分性、越界改动和文档证据。
  • 仅 blocking findings 触发修复；优先回给原 worker，最多三轮同类修复。
  • 修复后重跑直接测试、受影响测试和全量门禁。

10. 用户进度事件

需要报告：

  • 计划审计通过并开始实施；
  • worker 完成或出现阻断；
  • P0 MES 风险修复完成；
  • 制造需求/Validator 接线完成；
  • 真实数据和浏览器验收完成；
  • 独立审计结果与修复；
  • 最终收口或外部阻断。

11. 清理与保护

  • 不删除、移动或重置用户/未知变更。
  • 不清理 server/data/** 现场状态，不执行 git clean/reset/checkout。
  • 关闭完成/失效 agent，清理仅由本轮产生且已确认无用的临时文件。
  • 不提交、不推送、不合并、不发布。
  • 结束时复核 8003/5173、git status、world/master.db 摘要和 agent 状态。

12. Worker focused 验证命令

  • W1：.venv\Scripts\python.exe -X utf8 -m pytest tests/golden/test_closed_loop_scheduling.py -q
  • W2：.venv\Scripts\python.exe -X utf8 -m pytest tests/golden/test_flex_atomic_schedule.py tests/golden/test_flex_publish_mes_gate.py -q
  • W3：.venv\Scripts\python.exe -X utf8 -m pytest tests/golden/test_scheduling_validator_v2.py -q
  • W4：npm run build --prefix apps/web；npx playwright test e2e/closed-loop-scheduling.spec.ts --project=chromium（在 apps/web 下，隔离后端）
  • 主 agent 接线：上述 focused 集合 + tests/golden/test_contract_sync.py + 受影响 MES/MRP/审批测试。

13. Pre-target-merge 停止点

全量验证和独立审计通过后，主 agent 必须先形成 pre-target-merge 总体报告，自问并说明：哪些结论依赖 fixture、哪些真实数据仍阻断、是否存在未覆盖的外部系统/硬件/权限风险、当前 dirty 基线是否出现无关变化。本轮默认保持未提交、未合并；没有新的用户明确授权，不执行 commit/merge/push/publish。

14. 执行结果（2026-08-03）

  • 第一波 W1/W2/W3、第二波 W4 与首轮 Audit 已结束；Audit 返回 7 个 blocking finding。
  • 审计修复按互斥边界追加 W-EVIDENCE、W-V2RES、W-PROVENANCE、W-E2E；主 agent 独立完成 WMS 精确版本、订单读幂等、API/UI 集成与全量验证。
  • W-EVIDENCE：完整 V2/资源快照 evidence，TEAM/TOOLING/层级/寿命漂移失败关闭。
  • W-V2RES：多资源契约、组织层级容量、班组并发与模具寿命。
  • W-PROVENANCE：稳定 sourceHash/problemId 与外部 Skill 业务日期。
  • W-E2E：生产 create_app() + 内存 world 的隔离服务，真实浏览器正负闭环 2 passed。
  • 主 agent：WMS Saga 不沿用旧 DRAFT；/api/orders 恢复真实状态；订单 GET 不再无条件写现场 world。
  • 全量门禁：黄金 979 passed、Node 60 passed、Web build passed、Playwright 2 passed。
  • 所有 worker 已关闭；最终独立复审 AUDIT: PASS。未提交、未推送、未合并、未发布，保留 pre-target-merge 状态。