用Kubernetes控制论闭环重构晶圆厂调度：C9S Agent实践

1. 一开始我以为这是个强行拼凑的概念第一次看到“用 Kubernetes 的控制论思想做晶圆厂调度”这个说法我的第一反应是——这八成又是把两个热词硬凑在一起。毕竟半导体制造这个行当调度系统已经卷了三十多年从早期的规则派工到后来的 APS 排程、遗传算法、强化学习派工能试的路线基本都试遍了。而 Kubernetes 本质上是容器编排系统它的调度器只管把 Pod 塞到 Node 上一次绑定就结束跟晶圆厂那种“一片晶圆要走八百道工序、反复回到同一台机台”的场景从表面看完全不是一回事。后来真正把 C9S Agent 这套东西跑起来、调了几个月参数之后我改变了看法。这两个领域真正相通的地方不在“调度算法”这个层面而在更底层的控制论结构它们都在处理一个持续被扰动、永远收敛不到完美稳态的系统都在用“观测—比较—修正”的闭环去逼近一个不断变化的目标。Kubernetes 把这件事叫 reconcile晶圆厂把它叫 dispatching控制论把它叫负反馈。名字不同骨架是同一副。这篇东西想讲清楚三件事晶圆厂调度的物理约束到底卡在哪里、C9S Agent 是怎么把这个控制闭环搭起来的、以及真上线之后哪些地方一定会翻车。适合做 MES 二次开发、产线自动化、或者对调度系统感兴趣的朋友看不需要你精通半导体工艺但最好有一点分布式系统的直觉理解起来会快很多。说明C9S Agent 是内部给这套调度代理起的代号下文提到的具体参数、机台编号、产线规模都做了脱敏或虚构处理逻辑是真的数字别照抄。2. 晶圆厂调度的难点不在算法在约束的密度很多人对调度系统的想象是给一堆任务和一堆机器算出一个最优排布。教科书里确实是这么讲的但真实的晶圆厂完全不是这个形状。你在产线上待一周就会明白真正让你头疼的不是“算不出来”而是“算出来也执行不了”。2.1 重入流同一片晶圆会反复回到同一台机台这是半导体制造和传统离散制造最本质的差别。一个 Lot一批通常 25 片晶圆从投料到出货要经过几百道工序而光刻区可能有几十层每一层都要回到光刻机台。也就是说同一台机台一天之内会接待同一个 Lot 好几次中间隔着几十道其他工序。这个特性直接把调度问题的复杂度从“作业车间调度”推到了“重入式流水车间”NP-hard 里的硬骨头。更麻烦的是它在工程上带来的副作用排队长度不能作为拥塞信号。在普通工厂里一条产线前面堆了五十个任务说明它堵了应该分流但在晶圆厂一台光刻机前面堆五十个 Lot 是完全正常的因为它们处于不同层次、不同优先级、还有不同的 Q-time 约束。我在做第一版的时候就在这儿栽了跟头用 WIP在制品数量做负载均衡的输入结果系统疯狂把 Lot 往外围机台赶光刻区反而饿死。后来改成用“分层次的 WIP 剩余处理时间”才正常。这个教训很朴素你不能用一个标量去描述一个多维的状态空间。2.2 批处理与 Setup一次决策影响后面十次炉管、清洗、湿法刻蚀这些工序是批处理设备一次能装好几盒甚至十几盒晶圆。这意味着调度决策不是“一个 Lot 去哪台机台”而是“要不要等一等凑一批再跑”。等还是不等是个典型的两难。等批次数减少、机台利用率上去、单位成本下来不等Q-time 不会被拖爆但是机台空转。实际产线上常见的做法是设一个“最大等待时间”加“最小批量”的门槛凑齐就发车。这本身不难难的是这个决策和后面的决策是耦合的你为了凑批把某个 Lot 压了四十分钟它后面那道 Q-time 只剩两小时的工序就可能因此超时然后触发返工返工又占用了本来紧张的产能。Setup 同理。同一台机台从 A 产品切到 B 产品中间要做换型、校准、首件验证耗时从几十分钟到几小时不等。所以调度器在打分时必须把“换型成本”作为一种惩罚放进目标函数里而不是单纯追求“最早开始”。2.3 光刻区机台和光罩是两重稀缺资源光刻区是整个 Fab 的瓶颈几乎没例外。这个区的调度难点在于它同时受两类资源约束机台本身和 Reticle光罩。一台光刻机同一时刻只能装一套光罩换罩需要时间而且光罩数量有限某些层可能全厂只有两三套。所以一个 Lot 能不能上某台机台取决于三个条件同时成立机台空闲、对应层的光罩可用、机台的工艺能力匹配不同机型能做的节点不同。这是一个三维的匹配问题任何一维不满足就卡住。更隐蔽的问题是光罩的争用会跨产品传导。两个不同产品的 Lot 如果需要同一套光罩它们就形成了隐性的串行依赖。如果你的调度器只看机台不看光罩就会出现“排了一堆任务上去结果全在那儿等罩子”的假繁忙。我见过一条线因为这个问题光刻区的名义利用率 95%实际有效产出只有 70% 出头。2.4 时间约束链Q-time 是一根会断的链Q-time也叫 Queue Time 或者 Hold Time指的是某道工序加工完之后必须在规定时间内进入下一道工序否则晶圆表面会氧化、污染或者性质劣化只能返工甚至报废。常见的有 2 小时、4 小时、8 小时、24 小时几档具体数值取决于工艺。这个东西彻底改变了调度的性质它把一串本来独立的决策变成了一条有硬期限的链。你在上游为了优化利用率做的一个“聪明”决定可能在下游变成一个不可挽回的超时。表里是我在实际项目中见过的几类典型约束以及它们对调度决策的影响方式约束类型典型量级对调度的影响违反后果Q-time2h / 4h / 8h必须优先保证下游承接能力返工或报废Reticle 切换10–40 min需按光罩分组排序机台空转批处理最小批量6–25 盒需要在等待与凑批之间权衡利用率下降产品换型 Setup30–180 min需做族聚family grouping产能损失PM 保养窗口固定时段作为不可用时间硬约束计划失效机台可用性波动突发需要重调度触发机制全线连锁看着这张表你就明白了晶圆厂调度的本质不是“求最优解”而是“在几十个互相打架的约束里找一个能执行下去的可行解”。这也解释了为什么很多 APS 系统在演示环境里表现漂亮一上线就没法用——它们优化的是纸面目标产线要的是能落地的动作序列。2.5 局部最优在这里特别危险最后说一个思维层面的坑。传统派工规则比如 FIFO、EDD、Critical RatioCR都是局部的。CR 的计算是(交期 - 当前时间) / 剩余处理时间小于 1 说明要赶。这套规则简单、可解释、执行快在产线上用了几十年确实有效。但它有个致命缺陷每条规则默认其他 Lot 的行为不变。当所有机台都按 CR 派工时那些 CR 值相近的 Lot 会同时涌向同一个瓶颈机台形成“共振”。我在一条线上见过最夸张的一次光刻区在半小时内涌入四十多个 Lot全是因为它们的 CR 在同一时刻一起掉到了 0.9 附近。所以真正可用的调度系统必须有全局视角的阻尼机制不能每条决策都独立做。这就引出了下面要说的控制论结构。3. C9S Agent 的骨架把调度做成一个闭环控制器理解 C9S Agent 最简单的办法是别把它当调度器看把它当控制器看。传统派工规则是开环的——给定输入直接输出动作不看结果C9S Agent 是闭环的——它持续观测产线状态跟期望状态做差然后修正动作。3.1 三个世界共用的那套语言Kubernetes 的 reconcile loop 是这样的读期望状态 → 读实际状态 → 算差异 → 执行动作把差异缩小 → 回到第一步。控制论的负反馈是测量输出 → 和目标比较得到误差 → 按误差调整输入。晶圆厂的调度是看当前 WIP 分布和产出进度 → 和计划比 → 调整派工优先级。三者的映射关系我用一张表摊开更清楚概念Kubernetes控制论晶圆厂调度目标Desired State设定值 r日计划 / 目标产出观测实际状态输出 yWIP 分布、机台状态、Move 数误差Diffe r − y计划偏差、Cycle Time 偏差动作创建 / 删除 / 更新控制量 u派工、插单、批处理决策扰动节点故障、Pod 崩溃外部干扰 d机台宕机、来料波动、返工控制器Controller Manager调节器C9S Agent这个表不是为了好看它是有实际指导意义的。一旦你把调度当成控制器很多设计问题就变成了控制论里的经典问题采样周期多长合适增益给多大不会振荡要不要加积分项消除稳态误差要不要设死区避免频繁抖动这些问题都有成熟的分析方法。3.2 感知层别直接对着 MES 数据库开火第一版我们干过一件蠢事Agent 每次决策前直接查 MES 数据库拉当前 WIP 和机台状态。听起来没问题实际跑起来数据库直接被拖垮而且读到的是脏数据——因为在读的过程中产线还在变。后来改成事件驱动加分层的结构。MES 和机台 SECS/GEM 接口产生的事件Lot 到达、加工开始、加工结束、机台下线、返工触发先进入一个消息总线Agent 通过类似 List-Watch 的机制订阅事件流本地维护一份内存里的状态快照再加一个周期性的全量对账比如每 5 分钟一次来纠正偏差。这个设计直接抄的是 Kubernetes 的 Informer 模式因为它解决的是同一个问题如何在分布式环境下维护一份足够新的本地视图。核心点有三个事件流是增量的保证低延迟但不是权威的可能有丢失全量对账是权威的但慢用来兜底本地缓存必须带版本号对应 K8s 里的resourceVersion对账时只接受更新版本的数据防止旧数据覆盖新数据。提示全量对账的周期不要拍脑袋定。经验值是取“决策周期”的 5 到 10 倍。如果 Agent 每 10 秒决策一次对账就设 50 到 100 秒。太频繁会给 MES 压力太稀疏则状态漂移会超出容忍范围。3.3 决策层从期望状态拆到具体动作Agent 拿到状态之后不能直接开始派工中间要先做一次“意图翻译”。这一步是把上游 APS 给的日计划我要在今天产出多少片、各产品占比翻译成本地可执行的优先级和约束。具体做法是给每个 Lot 算一个综合得分然后按分数从高到低排产。得分函数的形态大致是这样def dispatch_score(lot, tool, ctx): score 0.0 # 1) 紧迫度CR 越小越急做个有界映射避免极值主导 cr (lot.due_at - ctx.now) / max(lot.remaining_proc_time, 1e-6) score W_CR * clamp(2.0 - cr, 0.0, 2.0) # 2) Q-time 裕度裕度越窄分数越高这是硬约束的软表达 margin_ratio lot.qtime_margin / max(lot.qtime_window, 1e-6) score W_QTIME * clamp(1.5 - margin_ratio, 0.0, 1.5) # 3) 换型惩罚当前机台配置与该 Lot 是否需要 setup if tool.current_recipe ! lot.recipe: score - W_SETUP * tool.setup_cost_minutes / 60.0 # 4) 光罩可用性不满足直接判负无穷硬过滤 if lot.reticle_id not in ctx.available_reticles[tool.id]: return float(-inf) # 5) 瓶颈保护非瓶颈机台不要把瓶颈区的料提前吃掉 if tool.is_bottleneck and lot.next_step_is_bottleneck: score W_BOTTLENECK * 0.5 # 6) 老化项等待时间越久补偿越多防饥饿 score W_AGE * min(lot.waiting_minutes / 120.0, 1.0) return score这里有几点值得说清楚。第一为什么用 clamp 把各项压到有界区间。不加约束的话CR 在极端情况下会算出几百一项就压过其他所有项得分函数退化成“只看交期”。有界化之后各项权重才有意义。第二Q-time 的处理是“软表达 硬过滤”两层。裕度还够的按比例给分裕度已经为负理论上不该发生但现实中因为状态延迟会短暂出现的直接拉到最高优先级跳过正常排序。第三换型惩罚的系数。这个值不是拍脑袋定的。我们的做法是拿历史数据算一套光罩切换平均浪费多少产出机会把这个机会成本折算成分数和 CR 的量纲对齐。不同产线这个系数差很多几百片的小线可能 0.3 就够了几万片的大线要到 1.5 以上。3.4 执行层Agent 和 MES 的边界必须画清楚这一块是工程上最容易出事的地方。Agent 是“建议”还是“直接执行”两种模式我们都跑过。全自动模式下Agent 直接向 MES 下发派工指令MES 再驱动 AMHS 去搬货。效率高但一旦 Agent 判断失误错误会立刻变成物理动作——货已经搬过去了再改成本很高。半自动模式下Agent 输出的是排序建议由现场操作员确认。稳但人的反应速度跟不上很多优化窗口就错过了。最后采用的是分场景的混合模式场景模式理由常规批处理工序全自动决策空间小、风险低、频率高光刻区派工半自动默认接受影响面大保留人工否决权返工 Lot 插单人工确认涉及质量判断不能纯算法机台宕机后重调度全自动本来就是应急越快越好新产品首次上线全人工没有历史数据模型不可信这个表不是拍出来的是踩出来的。最惨的一次是让 Agent 全自动处理返工 Lot结果它按常规优先级把一批需要质量复判的货直接推上了产线虽然最后没出事但工艺部门那边的信任度掉了很久才补回来。注意Agent 的权限边界要写成配置不要写死在代码里。产线上不同工序的风险等级会变今天全自动没问题的环节明天上了新工艺就得收回来。这跟 Kubernetes 里的 PodDisruptionBudget 是一个思路——用声明式的策略去约束系统的自由度而不是靠代码逻辑硬编码。3.5 协调层多个 Agent 抢同一台机台怎么办产线规模上去之后单个 Agent 管不过来决策延迟会飙到几秒以上跟不上节拍就得拆成多个 Agent 分区管理。一分区就有冲突A 区的 Agent 和 B 区的 Agent 同时想把各自的 Lot 塞进光刻区的同一台机台。这个问题的解法思路跟 Kubernetes 的乐观并发控制一模一样每个资源带版本号写入时校验版本冲突就重试。具体实现上我们用了类似 Lease 对象的机制——Agent 想占用某台机台的下一个时间槽先申请一个带 TTL 的租约拿到租约才能下派工指令TTL 到期自动释放。apiVersion: scheduling.internal/v1 kind: ToolLease metadata: name: litho-tool-07-slot-1421 spec: toolId: LITHO-07 slotStart: 2024-06-11T09:20:0008:00 ttlSeconds: 45 holder: agent-zone-a status: phase: Bound resourceVersion: 88213TTL 设 45 秒是有讲究的。太短Agent 还没执行完租约就过期了别的 Agent 抢进来造成双写太长某个 Agent 卡死之后这段时间槽就白白浪费。45 秒大致等于“决策耗时 下发耗时”的 3 倍留了足够余量又不至于浪费太多。租约拿不到怎么办不能死等。我们的策略是降级重排拿不到租约的 Agent 把该 Lot 从本轮候选里剔除等下一个决策周期再试。这样做的代价是可能错过最优解但保证了系统整体不死锁。4. 借 Kubernetes 的骨架但有三处必须改把控制论讲完回到工程实现。C9S Agent 大量借用了 Kubernetes 的现成机制但有几处如果照抄系统一定跑不起来。4.1 可以直接抄的三样东西第一样是 Filter/Score 两阶段调度。K8s 的调度器先做 Filter过滤掉不满足硬约束的节点再做 Score给剩下的节点打分排序。这个结构用在晶圆厂特别合适Filter 阶段处理硬约束机台能力不匹配、光罩不可用、PM 窗口内、Q-time 已经不可能满足Score 阶段处理软偏好换型成本、负载均衡、交期紧迫度。分开的好处是性能。硬约束过滤掉 90% 的候选之后打分只需要在很小的集合里做延迟能压到毫秒级。我们实测下来一台机台 200 个候选 Lot 的场景Filter 后剩 15 个左右整个决策 8 毫秒以内完成。第二样是 Taint/Toleration 的等价物。K8s 里给节点打污点只有带对应容忍度的 Pod 才能调度上去。晶圆厂里这个机制对应的是“机台资质”某些机台只允许特定产品、特定客户、或者特定工艺阶段的 Lot 上去。用污点表达比在代码里写 if-else 干净太多而且可以动态改。第三样是 PriorityClass 加抢占。紧急插单在晶圆厂是常态客户催货、工程验证批、良率异常需要快速验证。用优先级类别的思路把 Lot 分成几档正常、加急、工程批、返工高优先级的可以抢占低优先级已经占用的时间槽。抢占的代价要显式记录作为后续复盘的依据。4.2 必须推翻的一条绑定不是终态这是最大的差异点也是最容易照抄错的地方。Kubernetes 的调度是一次性绑定Pod 被分配到 Node 上除非 Pod 挂了或者 Node 不可用否则不会再动。这个设计是对的因为容器的迁移成本高要重新拉镜像、重建网络频繁迁移得不偿失。晶圆厂完全相反。一个 Lot 被“分配”到某台机台之后在真正加工之前这段等待时间里它随时可以被重新分配而且应该被重新分配。因为机台可能突然宕机有更紧急的 Lot 进来了上游的 Q-time 情况变了原来那台机台前面的队列变长了。所以 C9S Agent 的调度结果不是“绑定”而是“带有效期的意图”。每个派工决策都带一个 TTL默认是 3 分钟。3 分钟内没被执行的决策自动失效重新参与下一轮决策。这个改动的代价是系统要处理大量的“决策撤销”状态管理复杂度上升。但收益也很明显面对扰动时的响应速度从一个调度周期我们设的是 10 秒缩短到了秒级。class DispatchIntent: def __init__(self, lot_id, tool_id, created_at, ttl_sec180): self.lot_id lot_id self.tool_id tool_id self.created_at created_at self.ttl_sec ttl_sec self.revoked False def is_valid(self, now): if self.revoked: return False return (now - self.created_at).total_seconds() self.ttl_sec def revoke(self, reason): self.revoked True # 撤销原因要落库这是后续调参的唯一依据 log_revocation(self.lot_id, self.tool_id, reason)revoke里那个日志很关键。上线初期我们天天盯着撤销原因看发现 70% 的撤销是因为“上游来料延迟”——这说明问题根本不在调度层而在上游的产能规划。这种洞察是只看最终指标看不出来的。4.3 打分函数的权重怎么定别用网格搜索权重调参是整个项目里最耗时的部分。一开始想得很美用历史数据做离线仿真网格搜索找最优权重组合。结果跑了两周发现行不通原因是权重的最优值随产线状态漂移。瓶颈在光刻区的时候光刻相关的权重该高瓶颈转移到 CMP 之后同一套权重就变成了拖累。所以最后改成了在线自适应Agent 每 30 分钟做一次小规模的参数微调依据是最近一段时间的实际产出和计划偏差。具体做法是给每个权重配一个调整方向和一个步长用类似梯度下降的思路朝“偏差减小”的方向挪一点点。步长必须很小我们用的是 0.02否则会引起振荡。权重项初始值调整步长调整依据W_CR1.00.02交期达成率偏差W_QTIME1.20.03Q-time 超时次数W_SETUP0.80.02换型次数 / 产出W_BOTTLENECK0.60.015瓶颈区利用率偏差W_AGE0.50.01最长等待时间这张表里的初始值是反复试出来的不是理论推的。步长和调整频率是权衡的结果调太勤系统不稳定调太慢跟不上产线变化。30 分钟这个周期大致对应产线状态的一个“半衰期”。提示自适应调参一定要加限幅。我们给每个权重设了上下界超过就钳住。没加限幅之前出过一次事故——某天上午来料集中涌入W_AGE 被一路推到了 8.0结果全天都在优先处理老货新投的料全部堵在开头。5. 闭环跑起来之后振荡、饥饿、死锁一个都不会少控制系统最怕的不是精度不够而是不稳定。C9S Agent 上线第一个月这三个问题我们全碰到了。5.1 振荡决策周期给太快反而更糟最典型的现象是这样的Agent 每 10 秒决策一次某台机台的候选 Lot 排序在两次决策之间来回翻转Lot A 和 Lot B 轮流排第一。AMHS 的小车被指挥着往两个方向跑最后两边都没送到。根因不难理解。Lot A 和 Lot B 的得分非常接近差 0.01 分。每次决策时因为 Q-time 裕度在实时变化这个差距在正负之间抖动排序就跟着抖动。这就是控制论里的极限环。解决办法有三个我们全用上了第一加死区deadband。如果两个候选的得分差小于阈值我们设 0.05不改变原有排序顺序保持上一次的决策。这一条治好了 60% 的抖动。第二加滞环hysteresis。只有当某个 Lot 的得分超过当前排头 0.15 分以上才允许它顶上去掉下来的时候也要低于 0.15 才让位。上下阈值不同形成滞环。第三降低决策频率。从 10 秒改成 15 秒同时把“事件触发”和“周期触发”结合起来——有新事件机台完工、Lot 到达立刻触发没有事件就走周期。这一条把无效决策量压下去了一半。改完之后抖动基本消失。这件事给我的启发是调度系统的质量不只看决策有多优还看决策有多稳。一个次优但稳定的方案产线执行起来比一个最优但乱跳的方案好得多。5.2 饥饿低优先级 Lot 会一直排不上优先级机制一上线立刻出现了饥饿。某些低优先级的量产 Lot 连着两天没被派上去因为总有加急单插在前面。这个问题的经典解法是老化agingLot 每等待一段时间优先级往上提一档。听起来简单实际做的时候有两个坑。第一个坑老化速度给太快会破坏优先级体系。最初设的是每 30 分钟提升 0.1 分结果低优先级 Lot 等 5 小时之后分数就超过了加急单加急单反而被饿死了。后来改成每 60 分钟 0.05 分并且给老化分设上限——最高只能提到“加急单之下、正常单之上”这一档不能越级。第二个坑不同工序的老化速度应该不一样。光刻区这种瓶颈工序等待成本高占着 WIP 不出货会拖累整条线老化要快清洗这种非瓶颈等待成本低老化可以慢很多。表里是我们的最终配置工序类别老化速率分/小时老化上限说明光刻0.081.2瓶颈区快速提升刻蚀0.051.0次瓶颈薄膜 / CMP0.040.8常规清洗 / 炉管0.020.5批处理等待可接受5.3 死锁光刻区的循环等待这个是最隐蔽的也是最难排查的。现象是光刻区突然不动了机台显示 idle但派工队列里明明有几十个 Lot 等着。查日志发现每个 Lot 的得分都是-inf被 Filter 阶段全部过滤掉了。原因是一个循环等待Lot A 需要 Reticle-1Reticle-1 目前装在 LITHO-03 上而 LITHO-03 正在跑 Lot BLot B 跑完需要立刻进入下一道工序但下一道工序的机台正被 Lot C 占着Lot C 等的是 Reticle-2而 Reticle-2 正在被清洗PM 期间换罩。四个资源和四个任务形成的环任何一个环节不动整个环就卡死。这跟操作系统的资源死锁是同一类问题。我们的解法借鉴了数据库的做法检测 强制打破。Agent 每 30 秒跑一次循环依赖检测本质上是构建资源等待图然后找环一旦发现环选一个“代价最小”的环节强制推进——具体做法是给环上某个 Lot 临时提升光罩优先级或者触发一次计划外的光罩调拨。代价最小怎么算我们用的是“打破这个环需要多久”作为度量选耗时最短的那个环节下手。这条规则没什么理论依据纯粹是实践中试出来的效果还行。注意死锁检测本身也会消耗资源。产线规模大的时候等待图的节点数会上千30 秒跑一次全图遍历会明显挤占决策线程的 CPU。我们的做法是只对“最近 10 分钟内没有状态变化”的资源子图做检测把范围缩小一个量级。6. 真上线之后才知道的几件事前面讲的都是能写进设计文档的东西。下面这几条是跑起来之后才知道的文档里不会写。6.1 影子模式有陷阱它会给你虚假的信心上线前我们跑了整整三周影子模式——Agent 照常决策但决策结果不下发只做记录然后拿它和人工派工的结果对比。三周下来Agent 的模拟指标比人工好 8%看起来很稳于是全量上线。结果上线第一周就出事了。原因是影子模式有一个根本性的保真度缺口影子模式不产生真实的物理反馈。Agent 在影子模式下做的决策不会真的让 AMHS 去搬货也不会真的占住机台所以它看到的“下一步状态”是人工派工产生的新状态而不是它自己决策会产生的新状态。这就好比让一个棋手在别人的棋局上下“如果是我会怎么走”但他永远看不到自己走了之后对手会怎么应。真正有效的验证方式是小范围闭环选一两个非瓶颈的工序区间让 Agent 真实接管跑个三五天看实际指标。范围小、出问题影响可控但反馈是真的。6.2 指标口径不统一所有优化都是自嗨这件事我踩得最狠。上线一个月Agent 报告说 Move 数提升了 12%Cycle Time 下降了 8%各项指标一片大好。但财务和计划部门那边给的反馈是“没什么感觉”。追下去查了两周发现是口径问题。Agent 算 Move 数的时候统计的是“加工完成事件”的条数产线报表算的是“通过关键工序的 Lot 数”两者差异在返工 Lot 和分批/合批的处理上。Cycle Time 更离谱Agent 用的是从投料到当前的时间报表用的是从投料到入库的时间中间差了整个后段。这种问题不解决你优化的是自己的数字不是产线的数字。后来的做法是在 Agent 内部直接用产线报表的口径哪怕那个口径在算法上不那么漂亮。宁可代码难看也不要指标打架。6.3 一定要给现场留一票否决权而且要留得方便最后一个也是最实用的。不管算法多好现场操作员一定有他知道而系统不知道的信息某台机台今天声音不对、某个批次看起来颜色有点偏、某个客户昨天打过电话说这单特别急。如果 Agent 的界面做得让人难以干预比如要层层菜单才能改一个优先级操作员就会绕过系统用“物理手段”干预——手动贴标签、直接把货搬到别的机台前面、甚至临时把机台标成不可用。这些操作在 Agent 看来都是“环境扰动”但它无法区分这是真实扰动还是人为干预于是会做出错误的补偿。我们的做法是在派工界面顶部放一个常驻的“干预”入口操作员可以给某个 Lot 打“锁定”标记Agent 不再改动它的排序给某个机台打“降速”标记算分时按 70% 产能计一键暂停整个区域的自动派工。所有干预都记日志、都带操作人、都可以事后回溯。这套东西上线之后操作员的抵触情绪明显下降Agent 的实际采纳率从 62% 涨到了 89%。这个数字比任何算法优化都值钱。6.4 一个可以继续往下做的方向目前 C9S Agent 做的还是“秒级到分钟级”的派工决策。再往上走一层——小时级的机台产能重分配、天级的投料节奏调整——现在是靠 APS 人工跑批中间有明显的断档。我个人的判断是这一层其实也可以用同样的闭环结构来做只是采样周期从秒变成小时控制对象从 Lot 变成产能配额。不过这是下一步的事了。眼下这套东西能把派工这一层稳住、能扛住扰动、能让操作员愿意用就已经解决了最痛的问题。做调度系统这么多年我越来越觉得把一个环节做扎实比把所有环节都做半成品有价值得多。