用 LLM Multi-Agent 重构半导体晶圆厂时序预测：一个从 Idea 到 MVP 的完整实践

关键词：LLM Agent · 多智能体协作 · 时间序列预测 · 半导体制造 · AutoML · Flask · 强化学习
适合读者：对 LLM 应用开发、AutoML、工业时序数据分析感兴趣的开发者和算法工程师

---

github: https://github.com/BumbleBee-ZDS/time_series_llm_agent

一、为什么我要做这件事？

1.1 一个被忽视的痛点

半导体晶圆制造是全球最复杂的工业生产过程之一。一块 12 寸晶圆从投料到出货，要经历数百道工序，涉及上千个工艺参数——温度、压力、气体流量、刻蚀速率、离子注入剂量……每一个参数的微小波动，都可能让良率从 99% 跌到 80% 以下。

痛点很明确：工程师每天面对海量时序数据，却缺乏高效的自动化工具来完成"数据清洗 → 特征工程 → 模型选型 → 超参调优 → 评估验证"这条流水线。现有的 AutoML 工具（如 AutoGluon、H2O）虽然强大，但有两个致命问题：

1. 不懂时序：它们把时序数据当普通表格数据处理，shuffle 划分训练集/测试集，导致严重的数据泄漏
2. 不懂业务：它们不知道"晶圆厂的压力传感器数据有周期性维护噪声"、“良率受节假日排产影响”

1.2 一个朴素的 Idea

LLM 不擅长直接建模时序，但 LLM 极其擅长"编排专家团队"。

这就像晶圆厂的工艺工程师——他不需要自己动手拧阀门，但他知道什么时候该让清洗组上场、什么时候该让刻蚀组介入、什么时候该叫质量部门来验收。

核心 Idea：构建一个 LLM-driven Multi-Agent 系统，让多个"专家 Agent"各司其职，协作完成时序预测的完整流水线。LLM 做指挥官和协调者，底层计算交给专业的时序库和模型。

这个 Idea 的灵感来源于三个前沿工作的交叉：

参考项目	核心思想	本项目借鉴点
AutoML-Agent (ICML 2025)	五智能体协作完成端到端 ML 流水线	Agent 角色划分与编排范式
ML-Agent (上海交大 2025)	用强化学习训练 LLM 自主做 ML 实验	Reflector 经验积累与自我进化
AutoResearch (Karpathy 2026)	棘轮循环：只保留改进、丢弃退步	实验迭代的"只进不退"机制

---

二、系统架构设计

2.1 整体架构图

用户输入 CSV
     │
     ▼
┌─────────────────────────────────────────────────┐
│              Orchestrator (总指挥)               │
│         理解任务 → 拆解步骤 → 分配工作            │
└────────────────┬────────────────────────────────┘
                 │
     ┌───────────┼───────────┬───────────┐
     ▼           ▼           ▼           ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Data    │→│Feature  │→│Modeling │→│ Eval    │
│Engineer │ │Engineer │ │Agent    │ │Agent    │
│数据清洗  │ │特征工程  │ │模型训练  │ │评估验证  │
│异常检测  │ │周期分解  │ │超参搜索  │ │指标计算  │
│平稳性检验│ │滞后特征  │ │模型对比  │ │防泄漏审计│
└─────────┘ └─────────┘ └────┬────┘ └────┬────┘
                             │           │
                             ▼           ▼
                    ┌─────────────────────────┐
                    │      Reflector (反思)    │
                    │  总结经验 → 生成报告     │
                    │  → 指导下一轮迭代        │
                    └─────────────────────────┘

2.2 六个 Agent 的角色设计

每个 Agent 都有明确的输入、职责、输出，就像晶圆厂里每个工位的标准作业程序（SOP）：

Agent 1：Orchestrator（总指挥）

• 职责：接收用户任务，维护全局状态字典 state，按顺序调度各 Agent
• 关键设计：进度管理（0-100%），异常处理，失败回滚
• 类比：晶圆厂的生产主管，不亲手操作设备，但确保每道工序按时完成

Agent 2：Data Engineer（数据工程师）

• 职责：
  • 时间列解析与索引设置
  • 缺失值处理（>30% 删除，≤30% 线性插值）
  • IQR 异常值检测与修复
  • ADF 平稳性检验，不平稳则自动一阶差分
  • 按时间顺序 80/20 划分训练集/测试集（严禁 shuffle）
• 关键设计：所有操作记录到 state['data_report']，供 Reflector 使用
• 类比：晶圆厂的来料检验员，确保进入产线的材料合格

Agent 3：Feature Engineer（特征工程师）

• 职责：
  • 滞后特征（lag_1, lag_2, lag_3）
  • 滑动窗口统计（rolling_mean_3, rolling_std_3）
  • 时间特征（month, dayofweek, is_month_start/end）
  • 可选 tsfresh 自动特征提取
• 关键设计：特征有效性追踪——记录每个特征与目标变量的相关系数
• 类比：晶圆厂的工艺参数优化师，从原始数据中提炼出最有用的信号

Agent 4：Modeling Agent（建模师）

• 职责：
  • 候选模型池：LinearRegression + RandomForest + Prophet/ARIMA
  • TimeSeriesSplit 交叉验证 + GridSearchCV 超参搜索
  • 选择验证集 MAE 最小的模型
• 关键设计：模型选型矩阵，记录每个模型的 CV 分数
• 类比：晶圆厂的设备工程师，根据工艺需求选择最合适的机台

Agent 5：Eval Agent（评估师）

• 职责：计算 MAE / RMSE / MAPE，输出标准化评估报告
• 关键设计：防数据泄漏检查（验证特征中是否含有未来信息）
• 类比：晶圆厂的质量检验部门，用统一标准验收每一批产品

Agent 6：Reflector（反思者）

• 职责：这是整个系统的灵魂 Agent，生成自然语言分析报告：
  • 数据质量摘要（缺失率、异常数、平稳性）
  • 特征工程有效性评价
  • 模型表现对比与原因分析
  • 可操作的改进建议
• 关键设计：维护"经验库"，每次实验的 (数据特征, 动作, 结果) 都被记录
• 类比：晶圆厂的工艺改进委员会，每次异常后开复盘会，积累 know-how

2.3 为什么是六个 Agent 而不是一个"全能 Agent"？

这是本项目最核心的设计决策之一。原因有三：

1. 关注点分离（Separation of Concerns）
   数据清洗的逻辑和模型训练的逻辑差异巨大，强行塞进一个 Agent 会导致代码臃肿、难以调试。

2. 可扩展性
   新增一个模型？只需修改 Modeling Agent。新增一种特征工程方法？只需修改 Feature Engineer。各 Agent 独立演进，互不影响。

3. 为 LLM 驱动做准备
   当前 MVP 中 Agent 的逻辑是硬编码规则，但架构已经为 LLM 接入预留了接口。未来每个 Agent 的 run() 方法可以替换为"LLM + 工具调用"模式，而无需改动整体编排逻辑。

---

三、技术亮点

亮点 1：时序感知的全流水线设计

市面上绝大多数 AutoML 工具把时序数据当表格数据处理，这是根本性错误。本项目从第一天起就把"时间依赖性"刻进了每个 Agent 的 DNA：

• Data Engineer 严格按时间顺序划分数据集
• Feature Engineer 的滞后特征和滑动窗口天然编码了时间依赖
• Modeling Agent 使用 TimeSeriesSplit 而非随机 K-Fold
• Eval Agent 专门检查"未来信息泄漏"

亮点 2：Reflector —— 让系统"越用越聪明"

Reflector 不只是生成报告，它是经验积累的载体。每次实验结束后，Reflector 记录：

experience = {
    "data_characteristics": {
        "n_samples": 500,
        "missing_rate": 0.05,
        "is_stationary": False,
        "dominant_frequency": "weekly"
    },
    "actions_taken": {
        "differencing": True,
        "lag_features": [1, 2, 3],
        "rolling_window": 3
    },
    "results": {
        "best_model": "RandomForest",
        "MAE": 0.52,
        "MAPE": 0.56
    },
    "reflection": "数据存在周度周期性，添加 lag_7 特征可能进一步提升效果"
}

这些经验数据就是未来做强化学习微调的训练样本——这正是 ML-Agent 论文的核心思想。

亮点 3：Flask + 原生前端，零前端框架依赖

整个前端只用 HTML + CSS + 原生 JavaScript，通过 Fetch API 与后端通信，Chart.js 做可视化。没有 React、没有 Vue、没有 Node.js——一个 Python 开发者就能全栈搞定。

进度实时推送通过简单的轮询实现：

// 前端每 1 秒轮询一次
setInterval(async () => {
    const res = await fetch(`/status/${taskId}`);
    const data = await res.json();
    updateProgressBar(data.progress);
    appendLogs(data.logs);
    if (data.status === 'completed') {
        showResults(data.result);
    }
}, 1000);

亮点 4：Mock 数据真实可用

generate_mock_data.py 生成的模拟数据不是随机噪声，而是有物理意义的仿真数据：

• 包含季节性趋势（周度周期 + 月度趋势）
• 模拟真实缺失模式（5% 随机缺失）
• 注入工业场景特有的异常值（设备偶发故障）
• 特征间存在已知因果关系（温度↑ → 良率↓）

上传这个 CSV，系统跑出来的结果是有业务解释力的。

---

四、MVP 效果展示

4.1 流水线执行流程

[00:00] 用户上传 wafer_mock_data.csv (500行 × 9列)
[00:01] Data Engineer 开始处理...
         → 检测到 5% 缺失值，线性插值修复
         → 检测到 3 个异常值 (speed 列)，IQR 法修复
         → ADF 检验 p=0.032 < 0.05，数据平稳，无需差分
         → 按时间顺序划分: 训练集 400 行 / 测试集 100 行
[00:15] Feature Engineer 开始处理...
         → 生成 lag_1, lag_2, lag_3 特征
         → 生成 rolling_mean_3, rolling_std_3 特征
         → 提取时间特征: month, dayofweek
         → 共新增 8 个特征
[00:30] Modeling Agent 开始训练...
         → LinearRegression:    CV-MAE = 1.23
         → RandomForest:        CV-MAE = 0.58  ← 最佳
         → Prophet/ARIMA:       CV-MAE = 0.71
         → 最佳模型: RandomForest (n_estimators=200, max_depth=10)
[00:45] Eval Agent 计算指标...
         → MAE  = 0.52
         → RMSE = 0.78
         → MAPE = 0.56%
[00:50] Reflector 生成报告...
         → "数据质量良好，建议尝试添加 lag_7 特征捕获周度周期"
[00:55] 前端展示结果，用户下载预测 CSV ✅

全程约 1 分钟，全程无人值守。

4.2 前端界面

• 文件上传区（拖拽 / 点击）
• 参数配置面板（预测步数、目标列、时间列）
• 实时进度条 + 日志流
• 结果展示区（模型信息 + 评估指标 + 预测图表 + 反思报告）
• 一键下载预测结果
  

---

五、当前局限性与下一步规划

5.1 坦诚地说，MVP 有局限

局限	说明	改进方向
Agent 逻辑是硬编码	不是真正的 LLM 驱动	接入 LLM API，让 Agent 自主决策
模型池较浅	只有 3 个候选模型	加入 XGBoost、LightGBM、TFT、N-BEATS
无强化学习	Reflector 只记录不学习	用经验库微调 LLM 决策能力
串行执行	Agent 依次运行	引入异步消息队列，并行探索
无概率预测	只输出点预测	加入分位数回归 / DeepAR

5.2 下一步：从 MVP 到 Production

Phase 2：LLM 真正入驻

• 用 DeepSeek / GPT-4o-mini 替换硬编码的 Agent 决策逻辑
• Orchestrator 用 LLM 做任务规划
• Reflector 用 LLM 生成更深刻的洞察报告
• Modeling Agent 用 LLM 做"模型选型推理"

Phase 3：强化学习闭环

• 积累 100+ 次实验经验
• 用 (state, action, reward) 对微调 7B 级别 LLM
• 让 Agent 在"提出特征工程操作"这一动作上学会更精准的决策

Phase 4：工业级部署

• Docker 容器化
• Kubernetes 编排多 Agent 并行
• 接入实时数据流（Kafka）
• 模型版本管理与 A/B 测试

---

六、核心源码结构

wafer_forecast_mvp/
├── app.py                    # Flask 主入口
├── agents/
│   ├── orchestrator.py       # 总指挥
│   ├── data_engineer.py      # 数据清洗
│   ├── feature_engineer.py   # 特征工程
│   ├── modeling_agent.py     # 模型训练
│   ├── eval_agent.py         # 评估
│   └── reflector.py          # 反思报告
├── utils/
│   ├── logger.py             # 进度与日志
│   └── data_loader.py        # 数据加载
├── templates/
│   └── index.html            # 前端页面
├── generate_mock_data.py     # Mock 数据生成
└── requirements.txt

每个 Agent 的接口高度统一：

class BaseAgent:
    def run(self, state: dict) -> dict:
        """接收全局状态，执行本 Agent 的职责，返回更新后的状态"""
        raise NotImplementedError

这种统一接口 + 共享状态的设计，让新增 Agent 或替换 Agent 实现变得极其简单。

---

七、总结与思考

这个项目验证了什么？

1. LLM Multi-Agent 做时序 AutoML 是可行的——即使不接入真正的 LLM API，仅用"角色分离 + 规则引擎"的架构，已经能跑通完整的自动化流水线。

2. 架构比模型更重要——六个 Agent 各司其职的协作模式，比"一个巨大模型解决所有问题"更可控、可解释、可扩展。

3. Reflector 是灵魂——它让系统从"一次性工具"进化为"经验积累系统"，为未来的强化学习闭环奠定基础。

给想做类似项目的同学几点建议

• 先跑通 MVP，再谈 LLM 接入。硬编码的规则 Agent 能跑通，LLM 驱动的 Agent 才能跑好。
• 时序数据的特殊性必须从头贯彻。从数据划分到特征工程到模型评估，每一步都要尊重时间依赖性。
• 经验积累机制要尽早设计。从第一行代码开始就记录 (输入, 动作, 结果)，这些就是未来的训练数据。
• 垂直场景优于通用框架。先做好"半导体晶圆厂"这一个场景，再考虑泛化到其他工业领域。

---

参考资料

1. AutoML-Agent: 多智能体协作的端到端 AutoML 框架 (ICML 2025)
2. ML-Agent: 用强化学习训练 LLM 自主完成 ML 实验 (上海交大 / 上海 AI Lab, 2025)
3. AutoResearch: Karpathy 的 LLM 自主研究框架 (2026)
4. MLE-Dojo: LLM Agent 的 ML 工程训练环境 (Georgia Tech + Stanford, 2025)
5. Prophet: Facebook 开源时间序列预测库
6. Darts: 统一的时间序列处理与预测 Python 库

---

如果这篇文章对你有启发，欢迎点赞、收藏、转发。也欢迎在评论区交流你的 Multi-Agent 实践心得！

---