半导体晶圆厂 RTD 实时派工系统 × LLM Agent从架构设计到工程落地的完整拆解关键词半导体制造 · RTD 实时派工 · LLM Agent · RAG 检索增强生成 · 强化学习 · 风险分级审批 · 全链路审计本文以一个可运行的 MVP 项目Python Streamlit DeepSeek 阿里千问为样本从系统架构、Agent 链路、RAG 实现、奖励函数设计、风险审批到降级策略逐层拆解并客观评析其设计亮点与工程局限。github:https://github.com/BumbleBee-ZDS/fab_ai_rtd_mvp目录背景为什么 RTD 需要大模型项目定位一个诚实的最小可行产品系统架构六段式 Agent 流水线感知 Agent规则引擎的边界与价值RAG 知识库让模型翻手册再回答诊断 Agent结构化输出的工程实践调度 Agent约束下的策略生成RL 仿真评估奖励函数的建模哲学执行 Agent风险分级与人工审批审计 Agent全链路可追溯贯穿始终的优雅降级设计客观评析亮点与局限从 MVP 到生产的路线图结语1. 背景为什么 RTD 需要大模型半导体 12 英寸晶圆厂FAB的制造执行系统MES之上有一个被低估但极其关键的模块——RTDReal-Time Dispatching实时派工。它的职责是回答一个动态规划问题当前时刻哪个批次Lot该进哪台设备Tool这个问题的复杂度远超直觉设备异构同一区域存在多台设备Recipe工艺配方兼容性各不相同不能随意替换批次状态机每个批次有自己的优先级URGENT/HIGH/NORMAL/LOW、Q-Time工序间队列时间上限、HOLD 状态、交期压力动态事件设备宕机、PM预防性维护到期、工艺参数漂移、告警随时发生派工决策必须实时响应约束耦合Q-Time 违例会导致批次报废PM 窗口是硬约束HOLD 设备禁止派工瓶颈设备决定整线吞吐。传统 RTD 依赖规则引擎 运筹优化如贪心、匈牙利算法、混合整数规划。规则引擎可解释、可运维但面对温度漂移 两台 PM 临期 一个 Q-Time 超时批次 交期最紧批次挤在瓶颈设备这样的复合场景时规则组合呈指数膨胀维护成本极高且难以把非结构化知识SOP、工程师经验、返工决策历史纳入决策。LLM Agent 的价值主张恰好在此把理解非结构化工艺知识 生成带约束的策略交给大模型把确定性判断 风险控制 审计留给规则层形成人机协同的闭环。2. 项目定位一个诚实的最小可行产品先说结论避免误导这是一个 MVPMinimum Viable Product演示项目不是生产级系统。维度项目实际情况数据来源内置工厂模拟器8 台设备、8 个批次非真实产线数据模型调用真实调用 DeepSeek推理 阿里千问向量化API状态存储Streamlitsession_state内存级进程重启即失RL 模块启发式奖励函数 策略扰动探索非真正的策略梯度训练审批/审计内存实现无持久化、无不可篡改性明确这一点很重要——它的价值在于验证技术链路RAG LLM 决策 风险管控 审计闭环能否跑通而不是声称已经解决了真实 FAB 的调度问题。下文所有技术分析都基于代码事实优点不夸大局限不回避。3. 系统架构六段式 Agent 流水线项目将 RTD 决策过程拆解为六个职责单一、接口清晰的 Agent① 感知(规则阈值) → ② 诊断(千问RAG DeepSeek 推理) → ③ 调度(DeepSeek 推理, 硬约束) → ④ RL 仿真(启发式奖励 扰动探索) → ⑤ 执行(L1~L4 风险分级 人工审批) → ⑥ 审计(全链路 trace_id 日志)环节Agent决策方式模型/机制输入 → 输出①perception_agent确定性规则阈值扫描 告警映射 Q-Time 扫描工厂状态 → 标准化事件列表②diagnosis_agentLLM RAGDeepSeek v4-pro 千问 Embedding事件 → 根因/质量影响/调度建议③scheduling_agentLLM 约束DeepSeek v4-pro状态压缩 诊断摘要 → 派工策略④rl_simulator规则评估加权奖励函数 扰动探索候选策略 → 评分排名⑤execution_agent规则分级L1~L4 审批流策略 → 自动执行 / 审批单⑥audit_agent日志记录内存 trace 日志全链路事件 → 可追溯记录设计思想值得注意LLM 只负责需要理解力和生成力的两环诊断、调度而感知确定性检测、评估量化打分、执行风险管控、审计追溯全部用规则实现。这是一种务实的架构取向——把大模型放在它擅长的位置把确定性留给确定性的系统既控制了成本与延迟也保证了关键环节的可解释性。界面展示4. 感知 Agent规则引擎的边界与价值感知 Agentperception_agent.py不做任何智能工作全部是确定性阈值判断设备参数阈值扫描仅对 RUNNING 设备# 温度漂移偏离配方中心 ≥0.5°C≥1.0°C 升级为 HIGHifabs(dev)limit:severityHIGHifabs(dev)1.0elseMEDIUM# 压力异常偏离配方中心 ≥15%≥25% 升级为 HIGH# Overlay量测值 规格限超 2 倍为 CRITICAL# EPD终点检测信号 0.3 → 判定丢失显式告警转化设备告警TOOL_DOWN / PM_OVERDUE / PARTICLE_UP 等通过ALARM_TYPE_MAP映射为事件类型并与参数扫描结果去重(equipment_id, event_type)集合。Q-Time 风险扫描批次维度剩余时间 30min 触发0已超时升级为 HIGH。关键设计事件标准化Event Normalization。感知层输出的是结构统一的事件字典{event_id:EVT-20260820-143052-001,event_type:temperature_drift,severity:HIGH,equipment_id:CVD-001,description:...,raw_parameters:{...},# 原始传感器数据current_lot:LOT-A-101,suggested_action:...# 预设的初始动作建议}这一步是整个链路的契约基础——下游诊断、调度、审计都依赖这个稳定的数据结构与具体设备、传感器类型解耦。这在工程上对应着典型的Adapter/Facade 模式感知层是异构数据源的统一入口。客观评析✅优点阈值规则零成本、零延迟、完全可解释且天然适合固定规格的检测Overlay 规格就是 3.0nm不需要模型去猜。⚠️局限阈值是静态的无法捕捉趋势性漂移如温度连续 30 分钟缓慢上升但未到 0.5°C多参数联合异常温度压力同时偏移被拆成两条独立事件丢失了相关性。真实 FDC故障检测与分类系统会结合 SPC 控制图、PCA 降维等方法做多变量监测——这是规则感知的天然边界。5. RAG 知识库让模型翻手册再回答5.1 为什么需要 RAG诊断任务的难点在于工艺根因判断依赖领域知识“CVD 压力偏 15% 可能是什么原因”而这些知识散落在 SOP、PM 规范、返工记录中。直接让模型凭空回答会出现幻觉hallucination——一本正经地编造不存在的处置流程。**RAGRetrieval-Augmented Generation检索增强生成**的解决思路是回答前先检索相关文档把检索结果拼进提示词让模型带着手册回答问题。5.2 实现细节项目使用千问 Embedding 余弦相似度# 启动时10 篇工艺知识文档批量向量化约 1~2 次 API 调用vectorsembed_texts([d[content]fordindocs],text_typedocument)# 查询时query 向量化后与文档向量点积向量已归一化 → 点积即余弦相似度sims_KB_VECTORS query_vec idxnp.argsort(sims)[::-1][:top_k]# Top-3值得关注的技术细节text_type区分 query/document千问接口通过extra_body{text_type: ...}区分查询文本与文档文本的编码策略这是中文检索场景下常见的调优手段对相似度质量有实际影响。维度显式指定dimensions1024明确向量维度保证与伪向量降级方案对齐。批向量化 排序sorted(resp.data, keylambda item: item.index)防止多文档并发返回乱序。纯 NumPy 检索10 篇文档的场景用矩阵乘法即可无需引入向量数据库——这个取舍非常务实。文档规模到千级以上时才值得引入 FAISS / Milvus。知识文档预置 10 篇覆盖 CVD、光刻、刻蚀、PM、Q-Time、FDC/SPC、瓶颈派工、HOLD 放行八大领域每篇都是处置流程 派工约束的复合内容与下游调度约束形成呼应。5.3 客观评析✅优点检索结果直接展示在诊断报告的retrieved_kb字段含 doc_id、title、相似度分数让用户能看到模型基于哪篇知识做的判断——这是 RAG 相对纯 prompt 的重要优势可引用、可核查。⚠️局限相似度检索是词汇/语义层面的匹配temperature_drift事件检索到的可能是 Overlay 相关文档如果相似度计算有偏差需要靠 prompt 里的候选文档数量Top-3来兜底无重排序rerank环节Top-3 质量完全依赖 embedding 模型知识库是进程内内存索引文档更新需要重启或forceTrue强制重建。6. 诊断 Agent结构化输出的工程实践6.1 Prompt 设计与结构化输出诊断 Agent 的 prompt 是典型的系统角色 任务约束 输出格式约束三段式DIAGNOSIS_SYSTEM_PROMPT(你是半导体 12 英寸晶圆厂的高级设备与工艺工程师服务于 RTD 实时派工系统。请基于「实时事件 检索到的工艺知识库」进行根因诊断输出结构化 JSON。注意\n1. 只输出 JSON不要输出任何解释文字\n2. root_causes 中每条 cause 需给出 0~1 的 confidence\n3. hold_equipment 表示是否需要将该设备置 HOLD停止进片。)用户消息则拼上实时事件 RAG 检索结果并给出期望的 JSON Schema 示例。调用参数值得注意chat_deepseek(messages[...],modelDEEPSEEK_HEAVY_MODEL,# deepseek-v4-protemperature0.2,# 低温度诊断任务要求确定性response_format{type:json_object},# 强制 JSON 模式max_tokens1500,)temperature0.2与response_formatjson_object是两个关键工程决策诊断结果要进入下游决策链必须低随机性、可解析。6.2 容错解析模型输出 JSON 经常带 Markdown 围栏或前后缀文本parse_json_response做了三层容错# ① 剥离 json ... 围栏fencere.search(r(?:json)?\s*(.*?),cleaned,flagsre.S)# ② 截取首个 { 到最后一个 } 之间的内容start,endcleaned.find({),cleaned.rfind(})# ③ json.loads 解析失败抛 ValueError 由上层降级6.3 规则降级诊断的兜底逻辑是规则式诊断_fallback_diagnosis根据事件类型映射预设根因置信度固定 0.55HOLD 建议按事件类型白名单判定。降级时在结果中写入fallback_reason让用户明确知道这次是降级结果——透明性是这里最重要的设计。6.4 客观评析✅优点结构化 JSON 输出 置信度 容错解析 降级标注构成了一个完整的LLM 结果工程化模板这套模式可以复用到任何需要 LLM 产出机器可读结果的场景。⚠️局限confidence是模型自报的置信度不可作为真实概率使用LLM 校准性差根因分析是单轮一次性输出没有多轮追问或证据链验证降级规则是手写映射覆盖面有限。7. 调度 Agent约束下的策略生成7.1 约束建模Prompt 即约束声明调度 Agent 把派工问题建模为约束满足 优先级排序问题约束以自然语言写死在系统提示词中硬约束 1. Q-Time已超时或即将超时的批次必须最优先处理 2. Recipe 兼容批次 recipe 必须在目标设备 supported_recipes 中 3. PM / DOWN / HOLD状态为 PM、DOWN 或诊断建议 HOLD 的设备不可派工 4. 优先级URGENT HIGH NORMAL LOW 5. 每批最多派往一台设备每台设备本轮最多接收一个批次。7.2 上下文压缩给 LLM 的报表LLM 的上下文窗口有限且昂贵调度 Agent 做了状态压缩compress_state把完整的工厂状态设备、批次、瓶颈负载、PM 计划压缩成紧凑文本再附上诊断摘要。压缩不是丢弃信息而是按 LLM 决策所需的信息粒度重组——例如设备只保留状态/当前配方/支持配方/下一批次批次只保留优先级/配方/Q-Time剩余/片数/HOLD。7.3 输出归一化与降级LLM 输出的策略经_normalize_strategy清洗补全lot_priority从状态字典反查不信任模型、归一化otd_estimate_min为整数、过滤非法派工条目。失败时降级到启发式贪心派工heuristic_strategy按(Q-Time 是否超时, 优先级, Q-Time 剩余时间)排序逐批匹配可用设备。7.4 客观评析✅优点约束全部显式化输出带constraints_checked字段声明已检查哪些约束策略的可解释性优于黑盒优化器启发式降级与 LLM 主路径共用同一套输出 Schema下游完全无感。⚠️局限约束靠 prompt 声明是软约束——模型可能违反如把批次派给不兼容设备代码层没有做硬校验拦截单轮生成无生成-校验-重试循环调度只输出建议没有与运筹优化如求解器融合复杂场景下难保最优性。8. RL 仿真评估奖励函数的建模哲学8.1 奖励函数设计RL 仿真模块rl_simulator.py是最容易被误读的部分——它并不是强化学习训练而是启发式奖励函数评估 策略扰动探索REWARD_WEIGHTS{utilization:1.0,# 利用率区域瓶颈负载均值cycle_time:0.8,# 周期派工覆盖率覆盖率越高等效周期越短otd:1.5,# 交期URGENT 批次满足率quality_risk:2.0,# 质量风险风险等级归一化惩罚qtime_violation:10.0# Q-Time 违例未覆盖的超时批次每次 -10}reward(1.0*utilization0.8*cycle_time1.5*otd-2.0*quality_risk-10.0*qtime_violations)从权重设计可以读出业务优先级排序Q-Time 违例−10.0/次是绝对红线远高于其他项OTD1.5比利用率1.0重要质量风险是惩罚项而非激励项。8.2 扰动探索模拟 RL 的 exploration# 三种扰动方式模拟探索# ① 交换两条派工的设备换设备# ② 单条派工换线寻找替代设备# ③ 补充一条新派工覆盖更多批次variantsperturb_strategy(strategy,state,n_variants3)# 评估1 条 LLM 原始策略 3 条扰动变体按 reward 降序排名resultsevaluate_multiple([strategy]variants,state)这本质上是局部搜索local search的随机采样版——以 LLM 策略为起点在邻域内采样变体并用统一奖励函数排序选择奖励最高的执行。8.3 客观评析这里必须说透✅优点把策略评估从主观判断变成可量化打分且给 LLM 策略提供了一个反事实比较基准——即使 LLM 策略不是最优系统也能证明在奖励函数定义下它比扰动变体好。⚠️局限重要这不是强化学习没有环境交互、没有策略梯度/价值迭代、没有回报累积。叫它启发式评估 随机局部搜索更准确。若对外宣称用 RL 做派工是名不副实的奖励函数是手写静态权重未经过真实产线数据校准覆盖率把cycle_time简化为派了多少批与真实周期时间cycle time相去甚远扰动策略可能生成违反 Recipe 兼容性的交换交换设备时未校验supported_recipes评估层也未做合法性过滤。9. 执行 Agent风险分级与人工审批9.1 L1~L4 风险分级执行 Agent 用规则把策略映射到四级风险判定规则取最高级 - 诊断建议 HOLD 设备 → 至少 L3 - 涉及 URGENT/HIGH 批次派工 → 至少 L3 - 调度模型声明的风险等级取更高值 - 多重高风险因素叠加≥2 项HOLD/高优先级/模型声明/派工规模≥4→ L4 - 调度模型要求人工确认但等级 L2 → L2 执行策略 - L1/L2系统自动执行 - L3需 2 人审批 - L4需 3 人审批9.2 审批流实现ApprovalStore.submit_decision实现了三个关键规则同一审批人重复提交被忽略防止一人刷满人数任一拒绝 → 单据立即 REJECTED一票否决复审REVIEW不计数保持 PENDING支持打回重审。审批单与执行动作都写入审计日志create_approval_ticket/execute_approved_strategy实现谁批的、批了什么、何时执行全程留痕。9.3 客观评析✅优点风险分级把 LLM 的自由裁量权限制在自动执行 L1/L2的范围内高风险动作强制人工介入——这是LLM 落地的安全闸门值得所有 LLM 决策系统借鉴审批规则去重、一票否决是真实工单系统的常见语义。⚠️局限审批存储是内存 dict重启即失无审批超时、无代理审批、无通知机制required_approvals是静态表未考虑不同风险类型需要不同审批角色的细粒度授权。10. 审计 Agent全链路可追溯审计 Agent 是这条链路的黑匣子每个 Agent 的关键动作都调用audit.log_event(trace_id, agent, action, input_summary, decision, evidence)落一条记录。核心设计是trace_id 贯穿全链路trace_idhelpers.generate_trace_id()# TRACE-20260819-143052-4F2A# 感知 → 诊断 → 调度 → RL → 执行全部携带同一 trace_id从感知检出 N 个事件、到诊断完成 M 份报告、到策略生成、到 RL 最优选择、到审批单创建与执行——一条 trace_id 即可还原完整决策链。这在生产环境对应的是分布式追踪类似 OpenTelemetry 的 trace/span 模型的简化版。客观评析内存日志 JSON 导出满足演示与教学需求但真实 FAB 的审计要求是不可篡改、留存合规周期如 SEC/GEM 规范、半导体行业审计要求需要落库 签名/区块链或 WORM 存储项目当前未覆盖。11. 贯穿始终的优雅降级设计这是整个项目最值得称道的工程品质没有 API Key 也能完整跑通。降级分三层层级触发条件降级方案透明性知识库向量化无千问 Key / API 失败本地哈希伪向量_pseudo_embedding字符哈希累加归一化状态标注本地哈希伪向量降级诊断无 Key / 网络 / JSON 解析失败规则式诊断预设根因映射结果带fallback_reason调度无 Key / 调用失败启发式贪心派工策略带llm_error字段# 伪向量的设计很巧妙确定性哈希 → 相同文本永远得到相同向量# 这保证了降级模式下 RAG 检索的可复现性def_pseudo_embedding(text,dim):vecnp.zeros(dim,dtypenp.float32)fori,chinenumerate(text):hint(hashlib.md5(f{ch}{i}.encode(utf-8)).hexdigest(),16)vec[h%dim]1.0returnvec/np.linalg.norm(vec)为什么重要LLM 应用的现实是 API 会失败、Key 会过期、网络会抖动。try/except → 降级 → 标注降级原因的三件套保证了演示不中断、生产不挂死同时不掩盖这次用了降级的事实。这是 LLM 工程中failover 设计的正面教材。12. 客观评析亮点与局限✅ 设计亮点架构职责分离正确LLM 只负责诊断与调度两环感知/评估/执行/审计全部规则化——成本可控、关键环节可解释事件标准化契约统一的event数据结构解耦了异构数据源与下游智能环节结构化输出工程化JSON 模式 低温度 容错解析 Schema 归一化是 LLM 输出的工业级处理模板风险分级 人工审批把LLM 建议权与人类决定权分离是合规落地的关键设计三层优雅降级无 Key 可演示、失败可恢复、降级有标注全链路 trace 审计一条 trace_id 还原完整决策链。⚠️ 工程局限同样重要RL 名不副实无训练、无环境交互实为启发式奖励评估 随机局部搜索对外宣称需谨慎约束是软约束调度 prompt 中的硬约束没有代码层强制校验模型可能产出违规策略内存级状态审批单、审计日志、工厂状态全在session_state重启即失无法多人协作虽然审批语义上支持多人但存储不支持分布式静态阈值与静态权重感知阈值与奖励权重均未数据校准无持久化知识知识库重建成本高无增量更新无成本/延迟控制每个事件一次 LLM 调用事件多时成本线性增长无缓存、无批处理、无并发控制。13. 从 MVP 到生产的路线图如果把这个 MVP 往真实 FAB 系统推进大致路径如下阶段关键改造数据层对接真实 MES/FDC 数据流Kafka 等消息队列替代内置模拟器状态落库PostgreSQL/Redis审批与审计改用关系库 WORM 存储决策层调度引入LLM 生成 规则硬校验 求解器优化三明治架构感知引入 SPC 控制图与多变量监测诊断支持多轮追问与证据链RL 层要么坦率改名为策略评估器要么引入真实仿真环境如 AnyLogic/SimPy 离散事件仿真 策略梯度训练让RL名副其实工程化Prompt 版本管理LangSmith 等、评测集golden set、成本/延迟监控、缓存、异步化引入重排序模型提升 RAG 精度合规与安全审批角色化授权RABC、审计不可篡改、Prompt 注入防护、模型输出合规审查14. 结语这个项目最大的价值不在于做了一个派工 Agent而在于它示范了一条LLM 进入高约束工业系统的可行路径感知用规则确定性检测→ 理解用 LLMRAG 推理→ 决策受约束风险分级→ 执行要审批人机协同→ 全程可审计trace 追溯→ 失败了能降级failover大模型不是来替代 RTD 的而是来补齐 RTD 的知识理解能力规则与审批不是拖后腿的而是让 LLM 走出 Demo、走进产线的护栏。这六个字可以概括这套架构的哲学——让聪明的部分聪明让确定的部分确定让危险的部分有人把关。
半导体晶圆厂 RTD 实时派工系统 × LLM Agent：从架构设计到工程落地的完整拆解
半导体晶圆厂 RTD 实时派工系统 × LLM Agent从架构设计到工程落地的完整拆解关键词半导体制造 · RTD 实时派工 · LLM Agent · RAG 检索增强生成 · 强化学习 · 风险分级审批 · 全链路审计本文以一个可运行的 MVP 项目Python Streamlit DeepSeek 阿里千问为样本从系统架构、Agent 链路、RAG 实现、奖励函数设计、风险审批到降级策略逐层拆解并客观评析其设计亮点与工程局限。github:https://github.com/BumbleBee-ZDS/fab_ai_rtd_mvp目录背景为什么 RTD 需要大模型项目定位一个诚实的最小可行产品系统架构六段式 Agent 流水线感知 Agent规则引擎的边界与价值RAG 知识库让模型翻手册再回答诊断 Agent结构化输出的工程实践调度 Agent约束下的策略生成RL 仿真评估奖励函数的建模哲学执行 Agent风险分级与人工审批审计 Agent全链路可追溯贯穿始终的优雅降级设计客观评析亮点与局限从 MVP 到生产的路线图结语1. 背景为什么 RTD 需要大模型半导体 12 英寸晶圆厂FAB的制造执行系统MES之上有一个被低估但极其关键的模块——RTDReal-Time Dispatching实时派工。它的职责是回答一个动态规划问题当前时刻哪个批次Lot该进哪台设备Tool这个问题的复杂度远超直觉设备异构同一区域存在多台设备Recipe工艺配方兼容性各不相同不能随意替换批次状态机每个批次有自己的优先级URGENT/HIGH/NORMAL/LOW、Q-Time工序间队列时间上限、HOLD 状态、交期压力动态事件设备宕机、PM预防性维护到期、工艺参数漂移、告警随时发生派工决策必须实时响应约束耦合Q-Time 违例会导致批次报废PM 窗口是硬约束HOLD 设备禁止派工瓶颈设备决定整线吞吐。传统 RTD 依赖规则引擎 运筹优化如贪心、匈牙利算法、混合整数规划。规则引擎可解释、可运维但面对温度漂移 两台 PM 临期 一个 Q-Time 超时批次 交期最紧批次挤在瓶颈设备这样的复合场景时规则组合呈指数膨胀维护成本极高且难以把非结构化知识SOP、工程师经验、返工决策历史纳入决策。LLM Agent 的价值主张恰好在此把理解非结构化工艺知识 生成带约束的策略交给大模型把确定性判断 风险控制 审计留给规则层形成人机协同的闭环。2. 项目定位一个诚实的最小可行产品先说结论避免误导这是一个 MVPMinimum Viable Product演示项目不是生产级系统。维度项目实际情况数据来源内置工厂模拟器8 台设备、8 个批次非真实产线数据模型调用真实调用 DeepSeek推理 阿里千问向量化API状态存储Streamlitsession_state内存级进程重启即失RL 模块启发式奖励函数 策略扰动探索非真正的策略梯度训练审批/审计内存实现无持久化、无不可篡改性明确这一点很重要——它的价值在于验证技术链路RAG LLM 决策 风险管控 审计闭环能否跑通而不是声称已经解决了真实 FAB 的调度问题。下文所有技术分析都基于代码事实优点不夸大局限不回避。3. 系统架构六段式 Agent 流水线项目将 RTD 决策过程拆解为六个职责单一、接口清晰的 Agent① 感知(规则阈值) → ② 诊断(千问RAG DeepSeek 推理) → ③ 调度(DeepSeek 推理, 硬约束) → ④ RL 仿真(启发式奖励 扰动探索) → ⑤ 执行(L1~L4 风险分级 人工审批) → ⑥ 审计(全链路 trace_id 日志)环节Agent决策方式模型/机制输入 → 输出①perception_agent确定性规则阈值扫描 告警映射 Q-Time 扫描工厂状态 → 标准化事件列表②diagnosis_agentLLM RAGDeepSeek v4-pro 千问 Embedding事件 → 根因/质量影响/调度建议③scheduling_agentLLM 约束DeepSeek v4-pro状态压缩 诊断摘要 → 派工策略④rl_simulator规则评估加权奖励函数 扰动探索候选策略 → 评分排名⑤execution_agent规则分级L1~L4 审批流策略 → 自动执行 / 审批单⑥audit_agent日志记录内存 trace 日志全链路事件 → 可追溯记录设计思想值得注意LLM 只负责需要理解力和生成力的两环诊断、调度而感知确定性检测、评估量化打分、执行风险管控、审计追溯全部用规则实现。这是一种务实的架构取向——把大模型放在它擅长的位置把确定性留给确定性的系统既控制了成本与延迟也保证了关键环节的可解释性。界面展示4. 感知 Agent规则引擎的边界与价值感知 Agentperception_agent.py不做任何智能工作全部是确定性阈值判断设备参数阈值扫描仅对 RUNNING 设备# 温度漂移偏离配方中心 ≥0.5°C≥1.0°C 升级为 HIGHifabs(dev)limit:severityHIGHifabs(dev)1.0elseMEDIUM# 压力异常偏离配方中心 ≥15%≥25% 升级为 HIGH# Overlay量测值 规格限超 2 倍为 CRITICAL# EPD终点检测信号 0.3 → 判定丢失显式告警转化设备告警TOOL_DOWN / PM_OVERDUE / PARTICLE_UP 等通过ALARM_TYPE_MAP映射为事件类型并与参数扫描结果去重(equipment_id, event_type)集合。Q-Time 风险扫描批次维度剩余时间 30min 触发0已超时升级为 HIGH。关键设计事件标准化Event Normalization。感知层输出的是结构统一的事件字典{event_id:EVT-20260820-143052-001,event_type:temperature_drift,severity:HIGH,equipment_id:CVD-001,description:...,raw_parameters:{...},# 原始传感器数据current_lot:LOT-A-101,suggested_action:...# 预设的初始动作建议}这一步是整个链路的契约基础——下游诊断、调度、审计都依赖这个稳定的数据结构与具体设备、传感器类型解耦。这在工程上对应着典型的Adapter/Facade 模式感知层是异构数据源的统一入口。客观评析✅优点阈值规则零成本、零延迟、完全可解释且天然适合固定规格的检测Overlay 规格就是 3.0nm不需要模型去猜。⚠️局限阈值是静态的无法捕捉趋势性漂移如温度连续 30 分钟缓慢上升但未到 0.5°C多参数联合异常温度压力同时偏移被拆成两条独立事件丢失了相关性。真实 FDC故障检测与分类系统会结合 SPC 控制图、PCA 降维等方法做多变量监测——这是规则感知的天然边界。5. RAG 知识库让模型翻手册再回答5.1 为什么需要 RAG诊断任务的难点在于工艺根因判断依赖领域知识“CVD 压力偏 15% 可能是什么原因”而这些知识散落在 SOP、PM 规范、返工记录中。直接让模型凭空回答会出现幻觉hallucination——一本正经地编造不存在的处置流程。**RAGRetrieval-Augmented Generation检索增强生成**的解决思路是回答前先检索相关文档把检索结果拼进提示词让模型带着手册回答问题。5.2 实现细节项目使用千问 Embedding 余弦相似度# 启动时10 篇工艺知识文档批量向量化约 1~2 次 API 调用vectorsembed_texts([d[content]fordindocs],text_typedocument)# 查询时query 向量化后与文档向量点积向量已归一化 → 点积即余弦相似度sims_KB_VECTORS query_vec idxnp.argsort(sims)[::-1][:top_k]# Top-3值得关注的技术细节text_type区分 query/document千问接口通过extra_body{text_type: ...}区分查询文本与文档文本的编码策略这是中文检索场景下常见的调优手段对相似度质量有实际影响。维度显式指定dimensions1024明确向量维度保证与伪向量降级方案对齐。批向量化 排序sorted(resp.data, keylambda item: item.index)防止多文档并发返回乱序。纯 NumPy 检索10 篇文档的场景用矩阵乘法即可无需引入向量数据库——这个取舍非常务实。文档规模到千级以上时才值得引入 FAISS / Milvus。知识文档预置 10 篇覆盖 CVD、光刻、刻蚀、PM、Q-Time、FDC/SPC、瓶颈派工、HOLD 放行八大领域每篇都是处置流程 派工约束的复合内容与下游调度约束形成呼应。5.3 客观评析✅优点检索结果直接展示在诊断报告的retrieved_kb字段含 doc_id、title、相似度分数让用户能看到模型基于哪篇知识做的判断——这是 RAG 相对纯 prompt 的重要优势可引用、可核查。⚠️局限相似度检索是词汇/语义层面的匹配temperature_drift事件检索到的可能是 Overlay 相关文档如果相似度计算有偏差需要靠 prompt 里的候选文档数量Top-3来兜底无重排序rerank环节Top-3 质量完全依赖 embedding 模型知识库是进程内内存索引文档更新需要重启或forceTrue强制重建。6. 诊断 Agent结构化输出的工程实践6.1 Prompt 设计与结构化输出诊断 Agent 的 prompt 是典型的系统角色 任务约束 输出格式约束三段式DIAGNOSIS_SYSTEM_PROMPT(你是半导体 12 英寸晶圆厂的高级设备与工艺工程师服务于 RTD 实时派工系统。请基于「实时事件 检索到的工艺知识库」进行根因诊断输出结构化 JSON。注意\n1. 只输出 JSON不要输出任何解释文字\n2. root_causes 中每条 cause 需给出 0~1 的 confidence\n3. hold_equipment 表示是否需要将该设备置 HOLD停止进片。)用户消息则拼上实时事件 RAG 检索结果并给出期望的 JSON Schema 示例。调用参数值得注意chat_deepseek(messages[...],modelDEEPSEEK_HEAVY_MODEL,# deepseek-v4-protemperature0.2,# 低温度诊断任务要求确定性response_format{type:json_object},# 强制 JSON 模式max_tokens1500,)temperature0.2与response_formatjson_object是两个关键工程决策诊断结果要进入下游决策链必须低随机性、可解析。6.2 容错解析模型输出 JSON 经常带 Markdown 围栏或前后缀文本parse_json_response做了三层容错# ① 剥离 json ... 围栏fencere.search(r(?:json)?\s*(.*?),cleaned,flagsre.S)# ② 截取首个 { 到最后一个 } 之间的内容start,endcleaned.find({),cleaned.rfind(})# ③ json.loads 解析失败抛 ValueError 由上层降级6.3 规则降级诊断的兜底逻辑是规则式诊断_fallback_diagnosis根据事件类型映射预设根因置信度固定 0.55HOLD 建议按事件类型白名单判定。降级时在结果中写入fallback_reason让用户明确知道这次是降级结果——透明性是这里最重要的设计。6.4 客观评析✅优点结构化 JSON 输出 置信度 容错解析 降级标注构成了一个完整的LLM 结果工程化模板这套模式可以复用到任何需要 LLM 产出机器可读结果的场景。⚠️局限confidence是模型自报的置信度不可作为真实概率使用LLM 校准性差根因分析是单轮一次性输出没有多轮追问或证据链验证降级规则是手写映射覆盖面有限。7. 调度 Agent约束下的策略生成7.1 约束建模Prompt 即约束声明调度 Agent 把派工问题建模为约束满足 优先级排序问题约束以自然语言写死在系统提示词中硬约束 1. Q-Time已超时或即将超时的批次必须最优先处理 2. Recipe 兼容批次 recipe 必须在目标设备 supported_recipes 中 3. PM / DOWN / HOLD状态为 PM、DOWN 或诊断建议 HOLD 的设备不可派工 4. 优先级URGENT HIGH NORMAL LOW 5. 每批最多派往一台设备每台设备本轮最多接收一个批次。7.2 上下文压缩给 LLM 的报表LLM 的上下文窗口有限且昂贵调度 Agent 做了状态压缩compress_state把完整的工厂状态设备、批次、瓶颈负载、PM 计划压缩成紧凑文本再附上诊断摘要。压缩不是丢弃信息而是按 LLM 决策所需的信息粒度重组——例如设备只保留状态/当前配方/支持配方/下一批次批次只保留优先级/配方/Q-Time剩余/片数/HOLD。7.3 输出归一化与降级LLM 输出的策略经_normalize_strategy清洗补全lot_priority从状态字典反查不信任模型、归一化otd_estimate_min为整数、过滤非法派工条目。失败时降级到启发式贪心派工heuristic_strategy按(Q-Time 是否超时, 优先级, Q-Time 剩余时间)排序逐批匹配可用设备。7.4 客观评析✅优点约束全部显式化输出带constraints_checked字段声明已检查哪些约束策略的可解释性优于黑盒优化器启发式降级与 LLM 主路径共用同一套输出 Schema下游完全无感。⚠️局限约束靠 prompt 声明是软约束——模型可能违反如把批次派给不兼容设备代码层没有做硬校验拦截单轮生成无生成-校验-重试循环调度只输出建议没有与运筹优化如求解器融合复杂场景下难保最优性。8. RL 仿真评估奖励函数的建模哲学8.1 奖励函数设计RL 仿真模块rl_simulator.py是最容易被误读的部分——它并不是强化学习训练而是启发式奖励函数评估 策略扰动探索REWARD_WEIGHTS{utilization:1.0,# 利用率区域瓶颈负载均值cycle_time:0.8,# 周期派工覆盖率覆盖率越高等效周期越短otd:1.5,# 交期URGENT 批次满足率quality_risk:2.0,# 质量风险风险等级归一化惩罚qtime_violation:10.0# Q-Time 违例未覆盖的超时批次每次 -10}reward(1.0*utilization0.8*cycle_time1.5*otd-2.0*quality_risk-10.0*qtime_violations)从权重设计可以读出业务优先级排序Q-Time 违例−10.0/次是绝对红线远高于其他项OTD1.5比利用率1.0重要质量风险是惩罚项而非激励项。8.2 扰动探索模拟 RL 的 exploration# 三种扰动方式模拟探索# ① 交换两条派工的设备换设备# ② 单条派工换线寻找替代设备# ③ 补充一条新派工覆盖更多批次variantsperturb_strategy(strategy,state,n_variants3)# 评估1 条 LLM 原始策略 3 条扰动变体按 reward 降序排名resultsevaluate_multiple([strategy]variants,state)这本质上是局部搜索local search的随机采样版——以 LLM 策略为起点在邻域内采样变体并用统一奖励函数排序选择奖励最高的执行。8.3 客观评析这里必须说透✅优点把策略评估从主观判断变成可量化打分且给 LLM 策略提供了一个反事实比较基准——即使 LLM 策略不是最优系统也能证明在奖励函数定义下它比扰动变体好。⚠️局限重要这不是强化学习没有环境交互、没有策略梯度/价值迭代、没有回报累积。叫它启发式评估 随机局部搜索更准确。若对外宣称用 RL 做派工是名不副实的奖励函数是手写静态权重未经过真实产线数据校准覆盖率把cycle_time简化为派了多少批与真实周期时间cycle time相去甚远扰动策略可能生成违反 Recipe 兼容性的交换交换设备时未校验supported_recipes评估层也未做合法性过滤。9. 执行 Agent风险分级与人工审批9.1 L1~L4 风险分级执行 Agent 用规则把策略映射到四级风险判定规则取最高级 - 诊断建议 HOLD 设备 → 至少 L3 - 涉及 URGENT/HIGH 批次派工 → 至少 L3 - 调度模型声明的风险等级取更高值 - 多重高风险因素叠加≥2 项HOLD/高优先级/模型声明/派工规模≥4→ L4 - 调度模型要求人工确认但等级 L2 → L2 执行策略 - L1/L2系统自动执行 - L3需 2 人审批 - L4需 3 人审批9.2 审批流实现ApprovalStore.submit_decision实现了三个关键规则同一审批人重复提交被忽略防止一人刷满人数任一拒绝 → 单据立即 REJECTED一票否决复审REVIEW不计数保持 PENDING支持打回重审。审批单与执行动作都写入审计日志create_approval_ticket/execute_approved_strategy实现谁批的、批了什么、何时执行全程留痕。9.3 客观评析✅优点风险分级把 LLM 的自由裁量权限制在自动执行 L1/L2的范围内高风险动作强制人工介入——这是LLM 落地的安全闸门值得所有 LLM 决策系统借鉴审批规则去重、一票否决是真实工单系统的常见语义。⚠️局限审批存储是内存 dict重启即失无审批超时、无代理审批、无通知机制required_approvals是静态表未考虑不同风险类型需要不同审批角色的细粒度授权。10. 审计 Agent全链路可追溯审计 Agent 是这条链路的黑匣子每个 Agent 的关键动作都调用audit.log_event(trace_id, agent, action, input_summary, decision, evidence)落一条记录。核心设计是trace_id 贯穿全链路trace_idhelpers.generate_trace_id()# TRACE-20260819-143052-4F2A# 感知 → 诊断 → 调度 → RL → 执行全部携带同一 trace_id从感知检出 N 个事件、到诊断完成 M 份报告、到策略生成、到 RL 最优选择、到审批单创建与执行——一条 trace_id 即可还原完整决策链。这在生产环境对应的是分布式追踪类似 OpenTelemetry 的 trace/span 模型的简化版。客观评析内存日志 JSON 导出满足演示与教学需求但真实 FAB 的审计要求是不可篡改、留存合规周期如 SEC/GEM 规范、半导体行业审计要求需要落库 签名/区块链或 WORM 存储项目当前未覆盖。11. 贯穿始终的优雅降级设计这是整个项目最值得称道的工程品质没有 API Key 也能完整跑通。降级分三层层级触发条件降级方案透明性知识库向量化无千问 Key / API 失败本地哈希伪向量_pseudo_embedding字符哈希累加归一化状态标注本地哈希伪向量降级诊断无 Key / 网络 / JSON 解析失败规则式诊断预设根因映射结果带fallback_reason调度无 Key / 调用失败启发式贪心派工策略带llm_error字段# 伪向量的设计很巧妙确定性哈希 → 相同文本永远得到相同向量# 这保证了降级模式下 RAG 检索的可复现性def_pseudo_embedding(text,dim):vecnp.zeros(dim,dtypenp.float32)fori,chinenumerate(text):hint(hashlib.md5(f{ch}{i}.encode(utf-8)).hexdigest(),16)vec[h%dim]1.0returnvec/np.linalg.norm(vec)为什么重要LLM 应用的现实是 API 会失败、Key 会过期、网络会抖动。try/except → 降级 → 标注降级原因的三件套保证了演示不中断、生产不挂死同时不掩盖这次用了降级的事实。这是 LLM 工程中failover 设计的正面教材。12. 客观评析亮点与局限✅ 设计亮点架构职责分离正确LLM 只负责诊断与调度两环感知/评估/执行/审计全部规则化——成本可控、关键环节可解释事件标准化契约统一的event数据结构解耦了异构数据源与下游智能环节结构化输出工程化JSON 模式 低温度 容错解析 Schema 归一化是 LLM 输出的工业级处理模板风险分级 人工审批把LLM 建议权与人类决定权分离是合规落地的关键设计三层优雅降级无 Key 可演示、失败可恢复、降级有标注全链路 trace 审计一条 trace_id 还原完整决策链。⚠️ 工程局限同样重要RL 名不副实无训练、无环境交互实为启发式奖励评估 随机局部搜索对外宣称需谨慎约束是软约束调度 prompt 中的硬约束没有代码层强制校验模型可能产出违规策略内存级状态审批单、审计日志、工厂状态全在session_state重启即失无法多人协作虽然审批语义上支持多人但存储不支持分布式静态阈值与静态权重感知阈值与奖励权重均未数据校准无持久化知识知识库重建成本高无增量更新无成本/延迟控制每个事件一次 LLM 调用事件多时成本线性增长无缓存、无批处理、无并发控制。13. 从 MVP 到生产的路线图如果把这个 MVP 往真实 FAB 系统推进大致路径如下阶段关键改造数据层对接真实 MES/FDC 数据流Kafka 等消息队列替代内置模拟器状态落库PostgreSQL/Redis审批与审计改用关系库 WORM 存储决策层调度引入LLM 生成 规则硬校验 求解器优化三明治架构感知引入 SPC 控制图与多变量监测诊断支持多轮追问与证据链RL 层要么坦率改名为策略评估器要么引入真实仿真环境如 AnyLogic/SimPy 离散事件仿真 策略梯度训练让RL名副其实工程化Prompt 版本管理LangSmith 等、评测集golden set、成本/延迟监控、缓存、异步化引入重排序模型提升 RAG 精度合规与安全审批角色化授权RABC、审计不可篡改、Prompt 注入防护、模型输出合规审查14. 结语这个项目最大的价值不在于做了一个派工 Agent而在于它示范了一条LLM 进入高约束工业系统的可行路径感知用规则确定性检测→ 理解用 LLMRAG 推理→ 决策受约束风险分级→ 执行要审批人机协同→ 全程可审计trace 追溯→ 失败了能降级failover大模型不是来替代 RTD 的而是来补齐 RTD 的知识理解能力规则与审批不是拖后腿的而是让 LLM 走出 Demo、走进产线的护栏。这六个字可以概括这套架构的哲学——让聪明的部分聪明让确定的部分确定让危险的部分有人把关。
