半导体晶圆厂 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

---

目录

1. 背景：为什么 RTD 需要大模型
2. 项目定位：一个诚实的最小可行产品
3. 系统架构：六段式 Agent 流水线
4. 感知 Agent：规则引擎的边界与价值
5. RAG 知识库：让模型"翻手册"再回答
6. 诊断 Agent：结构化输出的工程实践
7. 调度 Agent：约束下的策略生成
8. RL 仿真评估：奖励函数的建模哲学
9. 执行 Agent：风险分级与人工审批
10. 审计 Agent：全链路可追溯
11. 贯穿始终的优雅降级设计
12. 客观评析：亮点与局限
13. 从 MVP 到生产的路线图
14. 结语

---

1. 背景：为什么 RTD 需要大模型

半导体 12 英寸晶圆厂（FAB）的制造执行系统（MES）之上，有一个被低估但极其关键的模块——RTD（Real-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. 项目定位：一个诚实的最小可行产品

先说结论，避免误导：这是一个 MVP（Minimum Viable Product）演示项目，不是生产级系统。

维度	项目实际情况
数据来源	内置工厂模拟器（8 台设备、8 个批次），非真实产线数据
模型调用	真实调用 DeepSeek（推理）+ 阿里千问（向量化）API
状态存储	Streamlit session_state（内存级，进程重启即失）
RL 模块	启发式奖励函数 + 策略扰动探索，非真正的策略梯度训练
审批/审计	内存实现，无持久化、无不可篡改性

明确这一点很重要——它的价值在于验证技术链路（RAG + LLM 决策 + 风险管控 + 审计闭环能否跑通），而不是声称已经解决了真实 FAB 的调度问题。下文所有技术分析都基于代码事实，优点不夸大，局限不回避。

---

3. 系统架构：六段式 Agent 流水线

项目将 RTD 决策过程拆解为六个职责单一、接口清晰的 Agent：

① 感知(规则阈值)
   → ② 诊断(千问RAG + DeepSeek 推理)
   → ③ 调度(DeepSeek 推理, 硬约束)
   → ④ RL 仿真(启发式奖励 + 扰动探索)
   → ⑤ 执行(L1~L4 风险分级 + 人工审批)
   → ⑥ 审计(全链路 trace_id 日志)

环节	Agent	决策方式	模型/机制	输入 → 输出
①	perception_agent	确定性规则	阈值扫描 + 告警映射 + Q-Time 扫描	工厂状态 → 标准化事件列表
②	diagnosis_agent	LLM + RAG	DeepSeek v4-pro + 千问 Embedding	事件 → 根因/质量影响/调度建议
③	scheduling_agent	LLM + 约束	DeepSeek v4-pro	状态压缩 + 诊断摘要 → 派工策略
④	rl_simulator	规则评估	加权奖励函数 + 扰动探索	候选策略 → 评分排名
⑤	execution_agent	规则分级	L1~L4 + 审批流	策略 → 自动执行 / 审批单
⑥	audit_agent	日志记录	内存 trace 日志	全链路事件 → 可追溯记录

设计思想值得注意：LLM 只负责"需要理解力和生成力"的两环（诊断、调度），而感知（确定性检测）、评估（量化打分）、执行（风险管控）、审计（追溯）全部用规则实现。这是一种务实的架构取向——把大模型放在它擅长的位置，把确定性留给确定性的系统，既控制了成本与延迟，也保证了关键环节的可解释性。

界面展示：

---

4. 感知 Agent：规则引擎的边界与价值

感知 Agent（perception_agent.py）不做任何"智能"工作，全部是确定性阈值判断：

设备参数阈值扫描（仅对 RUNNING 设备）：

# 温度漂移：偏离配方中心 ≥0.5°C；≥1.0°C 升级为 HIGH
if abs(dev) >= limit:
    severity = "HIGH" if abs(dev) >= 1.0 else "MEDIUM"
# 压力异常：偏离配方中心 ≥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）——一本正经地编造不存在的处置流程。

**RAG（Retrieval-Augmented Generation，检索增强生成）**的解决思路是：回答前先检索相关文档，把检索结果拼进提示词，让模型"带着手册回答问题"。

5.2 实现细节

项目使用千问 Embedding + 余弦相似度：

# 启动时：10 篇工艺知识文档批量向量化（约 1~2 次 API 调用）
vectors = embed_texts([d["content"] for d in docs], text_type="document")
# 查询时：query 向量化后与文档向量点积（向量已归一化 → 点积即余弦相似度）
sims = _KB_VECTORS @ query_vec
idx = np.argsort(sims)[::-1][:top_k]   # Top-3

值得关注的技术细节：

1. text_type 区分 query/document：千问接口通过 extra_body={"text_type": ...} 区分查询文本与文档文本的编码策略，这是中文检索场景下常见的调优手段，对相似度质量有实际影响。
2. 维度显式指定：dimensions=1024，明确向量维度，保证与伪向量降级方案对齐。
3. 批向量化 + 排序：sorted(resp.data, key=lambda item: item.index) 防止多文档并发返回乱序。
4. 纯 NumPy 检索：10 篇文档的场景用矩阵乘法即可，无需引入向量数据库——这个取舍非常务实。文档规模到千级以上时才值得引入 FAISS / Milvus。
5. 知识文档预置 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 模型；
  • 知识库是进程内内存索引，文档更新需要重启或 force=True 强制重建。

---

6. 诊断 Agent：结构化输出的工程实践

6.1 Prompt 设计与结构化输出

诊断 Agent 的 prompt 是典型的系统角色 + 任务约束 + 输出格式约束三段式：

DIAGNOSIS_SYSTEM_PROMPT = (
    "你是半导体 12 英寸晶圆厂的高级设备与工艺工程师，服务于 RTD 实时派工系统。"
    "请基于「实时事件 + 检索到的工艺知识库」进行根因诊断，输出结构化 JSON。注意：\n"
    "1. 只输出 JSON，不要输出任何解释文字；\n"
    "2. root_causes 中每条 cause 需给出 0~1 的 confidence；\n"
    "3. hold_equipment 表示是否需要将该设备置 HOLD（停止进片）。"
)

用户消息则拼上实时事件 + RAG 检索结果，并给出期望的 JSON Schema 示例。调用参数值得注意：

chat_deepseek(
    messages=[...],
    model=DEEPSEEK_HEAVY_MODEL,     # deepseek-v4-pro
    temperature=0.2,                 # 低温度：诊断任务要求确定性
    response_format={"type": "json_object"},  # 强制 JSON 模式
    max_tokens=1500,
)

temperature=0.2 与 response_format=json_object 是两个关键工程决策：诊断结果要进入下游决策链，必须低随机性、可解析。

6.2 容错解析

模型输出 JSON 经常带 Markdown 围栏或前后缀文本，parse_json_response 做了三层容错：

# ① 剥离 ```json ... ```围栏
fence = re.search(r"```(?:json)?\s*(.*?)```", cleaned, flags=re.S)
# ② 截取首个 { 到最后一个 } 之间的内容
start, end = cleaned.find("{"), cleaned.rfind("}")
# ③ json.loads 解析，失败抛 ValueError 由上层降级

6.3 规则降级

诊断的兜底逻辑是规则式诊断（_fallback_diagnosis）：根据事件类型映射预设根因，置信度固定 0.55，HOLD 建议按事件类型白名单判定。降级时在结果中写入 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 * utilization
    + 0.8 * cycle_time
    + 1.5 * otd
    - 2.0 * quality_risk
    - 10.0 * qtime_violations
)

从权重设计可以读出业务优先级排序：Q-Time 违例（−10.0/次）是绝对红线，远高于其他项；OTD（+1.5）比利用率（+1.0）重要；质量风险是惩罚项而非激励项。

8.2 扰动探索（模拟 RL 的 exploration）

# 三种扰动方式（模拟探索）：
# ① 交换两条派工的设备（换设备）
# ② 单条派工换线（寻找替代设备）
# ③ 补充一条新派工（覆盖更多批次）
variants = perturb_strategy(strategy, state, n_variants=3)
# 评估：1 条 LLM 原始策略 + 3 条扰动变体，按 reward 降序排名
results = evaluate_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_id = helpers.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):
    vec = np.zeros(dim, dtype=np.float32)
    for i, ch in enumerate(text):
        h = int(hashlib.md5(f"{ch}{i}".encode("utf-8")).hexdigest(), 16)
        vec[h % dim] += 1.0
    return vec / np.linalg.norm(vec)

为什么重要：LLM 应用的现实是 API 会失败、Key 会过期、网络会抖动。try/except → 降级 → 标注降级原因 的三件套，保证了演示不中断、生产不挂死，同时不掩盖"这次用了降级"的事实。这是 LLM 工程中failover 设计的正面教材。

---

12. 客观评析：亮点与局限

✅ 设计亮点

1. 架构职责分离正确：LLM 只负责诊断与调度两环，感知/评估/执行/审计全部规则化——成本可控、关键环节可解释；
2. 事件标准化契约：统一的 event 数据结构解耦了异构数据源与下游智能环节；
3. 结构化输出工程化：JSON 模式 + 低温度 + 容错解析 + Schema 归一化，是 LLM 输出的工业级处理模板；
4. 风险分级 + 人工审批：把"LLM 建议权"与"人类决定权"分离，是合规落地的关键设计；
5. 三层优雅降级：无 Key 可演示、失败可恢复、降级有标注；
6. 全链路 trace 审计：一条 trace_id 还原完整决策链。

⚠️ 工程局限（同样重要）

1. RL 名不副实：无训练、无环境交互，实为"启发式奖励评估 + 随机局部搜索"，对外宣称需谨慎；
2. 约束是软约束：调度 prompt 中的硬约束没有代码层强制校验，模型可能产出违规策略；
3. 内存级状态：审批单、审计日志、工厂状态全在 session_state，重启即失，无法多人协作（虽然审批语义上支持多人，但存储不支持分布式）；
4. 静态阈值与静态权重：感知阈值与奖励权重均未数据校准；
5. 无持久化知识：知识库重建成本高，无增量更新；
6. 无成本/延迟控制：每个事件一次 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 进入高约束工业系统的可行路径：

感知用规则（确定性检测）→ 理解用 LLM（RAG + 推理）→ 决策受约束（风险分级）→ 执行要审批（人机协同）→ 全程可审计（trace 追溯）→ 失败了能降级（failover）

大模型不是来替代 RTD 的，而是来补齐 RTD 的知识理解能力；规则与审批不是拖后腿的，而是让 LLM 走出 Demo、走进产线的护栏。这六个字可以概括这套架构的哲学——让聪明的部分聪明，让确定的部分确定，让危险的部分有人把关。