ARTICLE · 1318226

AI 原生智造的下一步:未解问题与路线图

发布时间：2026-11-06 07:49:13 最近访问：2026-11-06 07:49:14

系列回顾

走到这一步，哪些已经能用、哪些还得等——还有没解的问题

在过去 25 篇中，我们走过了完整的 AI 原生智造技术栈：

阶段	篇目	核心内容
基础篇	01-10	Agent 概念、工具调用、制造场景
进阶篇	11-20	RAG、Text2SQL、预测维护、工作流
高级篇	21-24	本体论、多 Agent、测试、生产模式
终章	25	路线图、未解问题、未来方向

如果你只读了一半，建议从第 1 篇开始——它们是递进关系。

当前的"伪智能"清单

诚实是这一系列的一贯原则。所以我们把系统里仍然是"看起来像 AI"而不是"真的是 AI" 的地方列出来——不是为了自我批评，而是为了划清边界。

先说一个重要更新：本季早些时候（第 19、20 篇）记录的"伪智能"清单，有几项已经在代码里落地了：

早期状态	当前实现	证据
预测维护 = 规则打分	IsolationForest 无监督异常检测 + RUL 剩余寿命，规则作 fallback	`predictive_engine.py:67-93`
RAG = token overlap	BM25 + 向量余弦 → RRF 融合 → rerank，含 CJK bigram 分词	`rag.py:287-329`

下面是仍未解决、依然是"伪智能"的部分：

标称能力	实际实现	改进方向
Text2SQL	关键词 → 模板映射	LLM schema linking
IoT 实时遥测	`random.uniform` 模拟（`iot_routes.py:13-17`）	OPC UA / Modbus 真实接入
智能告警	阈值规则	事件驱动 + ML 异常检测
专项智能体选路	关键词匹配选 focus（`agent_runtime.py:231`）	LLM planner 语义规划
RAG 向量后端	默认 `local` 特征哈希（无语义）	生产切 `AETHON_EMBED_BACKEND=api`
机器视觉质检	✅ 已接入 `InspectImageQualityTool`（走 vision_client.py，未启用时降级）	图像证据接入 AgentAction

这不是批评，而是诚实的自评。 从"伪智能"到"真智能"，需要解决这些未解问题。

未解问题一：数字孪生 —— 从"伪"到"真"

当前状态

先纠正一个容易被误解的点："预测维护 = 规则打分"这个判断已经过时了。

predictive_engine.py:63-93 现在是双轨的：

# 优先走 IsolationForest 无监督异常检测from sklearn.ensemble import IsolationForestmodel = IsolationForest(contamination=0.1, random_state=42).fit(X)# sklearn 不可用时，才回退规则引擎（可解释基线）# compute_rul(...) 输出剩余寿命天数 + 置信区间

规则打分没有删除——它是 ML 不可用时的 fallback，也是给工程师看的可解释基线。这个"ML 优先、规则兜底"的结构，比"纯规则"或"纯 ML"都更工程化。

但真正的数字孪生还差得远。machine_health_twin 目前是 health = 100 - 罚分——一个健康度评分，不是物理模型。它能回答"这台设备该不该关注"，回答不了"这台设备的轴承还剩多少度寿命"。

真正的数字孪生需要什么？

能力	当前	目标
物理模型	无（健康度评分）	热力学/力学/振动模型
实时同步	模拟数据（`iot_routes.py:11-18`）	OPC UA / Modbus 真实数据
预测	IsolationForest + RUL	物理模型驱动的 RUL + 置信区间
根因分析	无	设备→工艺→参数→缺陷因果链

下一步的三个具体动作：

(a)
IoT 遥测从 random.uniform 换成真实协议接入（Modbus TCP 已就绪，见 backend/app/industrial/modbus_tcp_client.py）
(b)
RUL 从统计外推升级为物理模型融合
(c)
用本体论（ai/ontology/）串起设备→工艺→参数→缺陷的因果链，让根因分析可推理

前两条是数据工程，第三条是本文第 21 篇讲过的本体论——这也是为什么本季要把本体论放在算法之后讲：算法给出"什么时候会坏"，本体论给出"为什么会坏"。

顺便说一句，iot_routes.py 里那七个信号（spindle_speed_rpm、feed_rate_mm_min、load_percent、temperature_c、vibration_mm_s、power_kw、runtime_hours）的范围都是随手写的（比如温度固定在 25-65°C）。有意思的是，这七个信号里有三个和第 19 篇预测引擎用的完全一样——temperature_c、vibration_mm_s、load_percent。也就是说，模拟数据的接口已经按真实预测引擎的需要设计好了，换成真实采集时，预测逻辑一行都不用改。这是做原型时值得注意的顺序：先按下游需求定接口，再填数据源。

未解问题二：多模态输入

当前状态

Agent 只能处理文本。但在制造业中，大量信息是非文本的：

AOI 缺陷图像
：自动光学检测的缺陷照片
工艺卡 PDF
：设备参数、操作规程
设备振动频谱
：时序数据
视频监控
：车间实时画面

目标

docs/INTELLIGENT_AGENT_ROADMAP.md:235-236 里的 Phase R2-11 写得很直接：

接多模态 LLM（GLM / Qwen-VL）处理 AOI 缺陷图
OCR 解析 PDF 工艺卡入库 RAG

应用场景：

质检 Agent 看到缺陷照片，自动判断缺陷类型
维护 Agent 读取设备手册，给出维修步骤
排程 Agent 识别工艺卡参数，自动调整排程

第二条（OCR 工艺卡入库）和第 20 篇讲的那个坑直接相关：很多厂的 SOP 就是十年前的扫描件。OCR 是让这些文档能被检索的第一步，但第一步不等于够了——第 20 篇那个"检索到作废版本"的教训在这里同样适用，旧版工艺卡被 OCR 进来，危害比不进库更大。

未解问题三：多站点协调

当前状态

Aethon 是单工厂架构。但很多企业有多个工厂：

总部需要看到所有工厂的汇总数据
跨工厂调拨物料
统一质量标准
知识共享（一个工厂的经验，其他工厂能复用）

目标

分四层做：

层	内容
数据层	跨工厂数据湖
Agent 层	工厂级 Agent + 总部级 Agent
知识层	跨工厂 RAG 语料库
决策层	总部审批 + 工厂执行

架构上是总部 Agent 挂多个工厂 Agent：

总部 Agent（战略决策）    ├── 工厂 A Agent（生产执行）    ├── 工厂 B Agent（生产执行）    └── 工厂 C Agent（生产执行）

最难的不是技术，是租户模型。 现在整套系统是单租户隔离的（tenancy.py 的 effective_tenant 会拒绝跨租户 header），而多站点协调恰恰需要受控的跨租户读取。这个矛盾不解决，"总部看所有工厂"就只能靠人工导出汇总表——那就没有 AI 了。多站点是第 16 篇讲的治理问题里最难啃的一块。

未解问题四：能源优化

当前状态

能源管理在 Aethon 中是缺失的。但制造业的能源成本占总成本的 10-30%。

目标

四件事：

实时监测
：电、气、水、蒸汽
异常检测
：能源浪费模式识别
优化建议
：峰谷电价调度、设备启停优化
碳足迹
：碳排放追踪与报告

与设备 Agent 的联动链路：

设备 Agent 发现某台设备能耗异常
通知能源 Agent 分析原因
能源 Agent 给出节能建议
排程 Agent 调整生产计划（避开用电高峰）

第 4 步是这套联动的价值所在，也是最难的一步：排产（第 18 篇）目前只优化延期、换模、负载三个目标，能耗不在适应度函数里。要联动，得往 _fitness_from_result 里加一项——而加进去之后，权重怎么定就成了新问题：省一度电和延一小时产，工厂更在意哪个？这个权重不该由工程师拍脑袋，该由厂里的电费和延期成本算出来。

关键路径

这些任务不是并列的，有明确的依赖顺序：

起点	解锁	为什么是它先
R0-1 报工入库	R2-5 成本核算、R2-6 追溯自动化	数据进不来，后面全是空转
R0-2 反馈闭合	R1-2 预测 ML	没有反馈数据，模型学不到东西
R1-1 RAG 向量化	R1-6 可解释、R2-11 多模态、R2-12 知识图谱	检索质量决定 LLM 决策质量
R2-1 OT 网关	R2-2 遥测闭环、R1-2 预测 ML	没有真实数据，预测只能用模拟

最短落地路径：

R0-1 报工入库（闭环命脉）
R0-2 反馈闭合（智能核心）
R1-1 RAG 向量化（制约 LLM 决策质量）
R2-1 OT 网关（对接真实车间）

这四条恰好就是 R0 剩下的那件（R0-5）加上 R1/R2 的三个入口。其余二十多项都可以在这四条铺好之后并行推进——这也回答了开头那个问题：为什么"先做哪一项"值得反复讨论。

里程碑

里程碑	内容	达成标志
MR0	智能回路 + 闭环闭合	反馈落库、报工入库、安全修复
MR1	智能升级 + 计划落地	RAG 向量、预测 ML、APS→派工、可解释
MR2	真实接入 + 规模化	OT 真实接入、MCP 双向、HA、可试点

对系列读者的建议

如果你是技术决策者

先看 MR0 的验收标准
：反馈落库、报工入库、安全修复——这些是"真生产"的底线
评估当前完成度
：约 55%，数据模型优秀，但智能层多处理"伪智能"
关注关键路径
：R0-1 + R0-2 是最短路径，完成后进入 MR1

如果你是技术实现者

从 rule_engine.py 和 schema.py 开始
：理解本体论和规则引擎的完整链路
用 sober.py 扫描你的代码
：看看你的代码处于什么健康等级
尝试 swarm_tool.py
：用并行模式分析一个多维度问题

如果你是制造业从业者

关注"报工→入库断链"
：这是制造闭环的命脉，库存账实一致的基础
关注"预测维护 ML 化"
：从规则阈值到真 ML，这才是"智造"的起点
关注"OT 真实接入"
：从模拟数据到真实 PLC 数据，这是"落地车间"的标志

系列总结

AI 原生智造不是"给 MES 加个 ChatBot"，而是从架构层面重新设计：让 AI 拥有感知、推理、行动、学习的完整能力，并与制造执行系统深度融合。

最后一件事：谁来决定不做

写路线图最容易写成许愿清单。所以这一篇最后想说的不是"接下来该做什么"，而是"接下来哪些事该拒绝"。

这是一家做精密结构件的公司，2024 年底做完了本系列讲的绝大部分内容——35 个制造工具接好了、异常检测上线了、排产 GA 跑起来了、风险看板挂在了车间大屏上。年底复盘的时候，厂长问了一个问题：

"明年这个项目还要投多少钱？"

技术负责人的清单列了 11 项：多站点、能源优化、数字孪生物理模型、多模态、Text2SQL 深化……每项后面都跟着人天和预算。厂长听完说："这些都对。但你告诉我，明年车间少停一次线、多省一次错检，能拿回多少钱？"

答不上来。清单上的 11 项，一项都算不出这个数。

后来他们做了一件反直觉的事：把 11 项砍到 2 项，只留下"OT 真实接入"和"报工入库闭环"——恰好是关键路径上的前两条。理由很朴素：这两项做完，预测维护才有真数据可训，RAG 才有真文档可检索。其余 9 项在模拟数据上继续优化，收益无法验证。

砍掉的那 9 项并没有消失，它们变成了"等条件成熟再启动"的清单，附上了各自的触发条件：数字孪生物理模型要等 OT 接入后有半年真实数据；多站点要等第二家工厂的 OA 系统先跑起来；能源优化要等电费计量细化到工序级。

给每项"暂不做"标上触发条件，比列一张"要做"的清单更有用——因为前者可以在项目评审会上被质询和追踪，后者只能被一遍遍点头。

这也回答了开头那个"伪智能"清单的用法。它不是自我批评，是待办清单的底稿：每一条"实际实现 vs 标称能力"的差距，都对应一个"要到什么程度才算真的"的问题。把这个问题回答清楚，才谈得上排优先级。

如果只从这个系列里带走一句话，我建议是这句：技术路线图的价值不在于列得多全，而在于敢于写下"这条暂时不做，等什么条件"。 没有这一栏的路线图，本质上是许愿单。

后续系列

本系列到这一篇结束，但这套方法论不止于此。《智造进化论》系列（27 篇）是它的前置——从"为什么制造企业现在必须谈 AI"讲起，把物料、工艺、排产、质检、追溯、订单回款整条链路串了一遍。如果你是刚进坑，建议从那个系列开始读。

另外，视觉质检这条线本系列只在第 17、15 篇提过算法（AE vs PatchCore），没有展开工程细节。《慧眼造物》系列专门讲这件事——怎么让机器看懂产品：打光标定、缺陷判级、边缘推理，以及一个绕不开的问题：模型准不准要怎么量化（MSA / Gage R&R）。顺带一句，视觉擅长"看起来不对"，不擅长"尺寸偏差 0.02mm"——后者要靠测量系统分析。

本系列完结。感谢一路同行。