数据平台向智能平台跃迁的完整实战：构建可闭环的工业智能体

1. Fabric IQ：从一个调不动的数据大屏说起

做工厂数据平台的人，大概都经历过这种尴尬时刻：调度室里的大屏跑着漂亮的实时曲线，每一台织机的转速、停机时长、温湿度、产量全部在跳动，领导看着很满意，可车间主任问一句“那现在到底该去修哪台车、调哪个参数”，全场安静。

我在织造行业牵头做过一个叫 Fabric IQ 的数据平台项目，早期它就是一个典型的工业数据平台：现场装了传感器，PLC 和工控机把数据采上来，实时数仓里存着每台织机每 10 秒一条的运行记录，前台有看板、有报表、有预警阈值。听起来挺完整，数据量也不算小——一百多台智能织机，一天能攒下上千万条点位数据。可实际用下来，一线的人并不买账。

调度员每天早上第一件事是打开各机台报表，自己拉 Excel，根据“车速”“经轴退绕张力”“断经次数”这几个字段人工判断哪台车需要处理；保全工接任务靠微信群喊；工艺员遇到质量异常，先翻纸质的工艺卡，再去问老师傅“这种情况以前怎么调的”。平台拦截了一堆数据，却没有真正拦住问题。

后来我们做了一次大的升级，把 Fabric IQ 从“数据平台”改造成“智能平台”。这次改造不只是多接几个大模型接口、加几个智能问答框，而是把整个系统从“反映现场”变成“响应现场”。这篇文章我想把这次升级的完整思路、技术选型、踩坑过程都摊开来讲。尤其是最近总有人在讨论用低代码智能体平台搭智能体和直接用 Python 搭智能体到底有什么不一样，我也会结合 Fabric IQ 的实际改造过程，好好聊聊这个问题。

如果你正在做数据平台的智能化转型，或者你的生产制造、仓储物流、能源管理等场景里也堆了一堆数据但决策还是靠人拍脑袋，这篇内容应该能给你一些可以直接拿去用的思路。

2. 数据平台与智能平台的本质差异：从“反映”到“响应”

先说一个我自己踩过之后才想明白的道理：数据平台和智能平台的差别，不在数据量，也不在有没有算法模型，而在系统对业务结果负不负责。

2.1 数据平台的本质是“镜子”

传统数据平台做的是采集、存储、计算、展示。它把 A 机台的车速从 480 转/分掉到 390 转/分这件事，通过一张趋势图告诉人类，任务就结束了。至于为什么掉速、该不该处理、由谁以什么方式处理，那都是人的事。

这就像一面镜子，镜子把人的样子照出来了，但脸上有灰该去洗，不是镜子的职责。数据平台时代，我们把大量精力花在“照得更清晰”上：点位数从几千加到几万，报表从日报做到分钟级刷新，大屏越做越炫，但闭环始终缺最后一公里——数据没有转化成下一步动作。

我做 Fabric IQ 前三年的状态就是这样的。平台上线后，OEE（设备综合效率）统计模块做得很细，哪个班组、哪台机台、哪个班次的效率都能拆。可车间主任跟我说过一句话，我记到现在：“你给我的不是效率报表，是考试成绩单。我需要的是告诉我下次考试怎么及格。”

2.2 智能平台的本质是“教练”

智能平台做的事情，是在数据基础上往前再走两步：第一步是理解，第二步是行动。它不满足于告诉你“张力偏高”，而是会告诉你“张力高出工艺上限 6%，结合当前车间湿度 24% 和该机台近 2 小时的断经频次上升趋势，预计 1.5 小时后断经风险显著增加，建议将经轴退绕张力下调 5%，并安排保全工对该机台左幅织口位置做一次毛羽检查”。

这还是最基本的。更进一步，智能平台可以直接触发动作：自动生成维修工单、推送到责任人移动端、调整联动机构的预设参数（在权限允许的范围内）。它从一个被动的数据服务方，变成了主动的生产协同方。

我用一个表格来对比这两种平台，方便大家理解：

2.3 能力成熟度曲线：Fabric IQ 当时处在哪一级

做升级规划的时候，我把数据智能化路径拆成五个阶段，Fabric IQ 团队当时照着这个框架给自己打了分：

1. 数据采集与清洗（L1）：完成。点位、产线、班次、物料主数据都齐。
2. 可视化与指标化（L2）：完成。OEE、产量、质量、能耗指标体系健全。
3. 诊断与分析（L3）：部分完成。能做关联分析，比如“温湿度升高时断经率上升 0.8%”，但依赖数据分析师出专题报告，时效性差。
4. 决策支持（L4）：刚开始。规则引擎做了“高于阈值就告警”，但没法把多个维度综合起来形成建议。
5. 智能行动（L5）：基本没有。平台没有任何动作执行通道。

坦白说，市面上很多自称“智能平台”的产品，实际只做到 L2.5，就是加了一个自然语言查询接口，问一句“上周A车间哪台织机效率最低”能出个回答。这确实比翻报表强，但本质上还是“用聊天的方式查数据”，不是真正意义上的智能。

Fabric IQ 升级的目标设得很明确：站到 L4，试点 L5 的“低风险动作自动执行”。这个定位很重要——如果一开始就追求全自动，安全和信任问题会把你拖死。后面我会专门讲权限边界的坑。

所以这篇文章里的“智能平台转移”，核心不是“引入大模型”，而是“建立从感知到决策再到行动的完整链路”。大模型只是这条链路里的一环，而且很可能是最不可控的一环，这个后面细说。

3. 升级路线图：数据底座、领域知识与智能体编排三层改造

确定了从“反映”到“响应”的方向之后，接下来就是具体怎么改。Fabric IQ 的改造我们没有推倒重来，老平台上花了那么多钱建的采集链路和数仓还得继续用。我们做的是“三层手术”：先把数据底座做扎实，再补领域知识层，最后在云平台上编排智能体，把前两层的能力串成闭环。

3.1 数据底座：先解决“数据可信”，再谈“平台智能”

很多人以为智能平台升级的第一步是选大模型、搭智能体，大错特错。我亲眼见过一个项目，模型都调好了，喂进去的数据有 20% 是脏的，结果智能体一本正经地给出离谱建议。数据平台时代容忍脏数据，顶多是报表不准；智能平台时代容忍脏数据，模型会把错误“合理化”，而且说得头头是道，比报表错了更可怕。

Fabric IQ 在升级前专门花了近两个月做数据治理，核心做了四件事：

1. 点位归一化：之前不同批次设备接入时，点位的命名很乱，同一个“经轴退绕张力”，有人叫Tension_Warp_1，有人叫JD-TL-01，还有人叫张力01。智能体根本没法稳定语义。我们建了统一的点位主数据字典，每一个物理点位有四元组标识有物理点位的设备域、子系统、信号名、单位，并支持同义映射。
2. 时序质量打标：每一条进入实时数仓的数据都要过质量校验，比如时间戳是否单调递增、数值是否在工艺上下限范围内、是否连续缺失。质量标签会跟着数据一起进入特征计算管道，这样智能体在推理时能够知道“这个特征的数据置信度是 89%”，而不是拿到一个残缺值还在那硬算。
3. 数据血缘追踪：平台里任何指标都能回溯到原始点位、采集程序版本、清洗规则版本。这事情做起来枯燥，但没有它，后面排错就是大海捞针。我们这次升级过程中好几次查出“智能体结论异常”，最后都是靠血缘链路定位到是上游采集脚本的 bug。
4. 实时与离线口径对齐：之前实时大屏和离线报表的数据经常对不上，实时算的是“当日累计产量”，离线报表算的可能是“当班合格产量”，差了检验剔除的部分。智能体同时访问两类数据，会出现逻辑矛盾。所以我们统一了指标口径，明确了“哪一个指标用哪条链路”的映射规则。

这四件事做完后，我们对所有进入智能体的数据加了“数据可信度评分”，低于 0.8 的数据默认不进推理上下文。这条规则后来证明极其重要，它拦住了很多莫名其妙的模型幻觉——因为模型拿到的上下文至少是干净的。

3.2 领域知识：把老师傅的工艺经验变成机器可用的知识

数据可信了，接下来面临的问题是：平台懂数据，但不懂织造。要让智能体给出靠谱的“怎么办”，它必须掌握这个行业、这个工厂的领域知识。

织造车间的知识大致分两类：

第一类是确定性规则知识，工艺卡上写得明明白白的，比如“经纱断头率超过 0.5 根/千纬时，优先检查经纱毛羽积集和张力均匀性”“车间相对湿度低于 20% 时，静电引起的开口不清断经概率显著上升，应启动加湿”。这类知识我们整理成了结构化规则，存到规则引擎里，走确定性判断分支，不经过大模型推理。为什么？因为这些规则是几十年的生产经验总结，容不得模型自由发挥。

第二类是隐形经验知识，分散在老师傅脑子和历年异常处理记录里。比如“这台 12 号机夏天容易出现右侧经纱张力波动，处理方式是把后梁位置往左偏半格，但不是所有机台都适用”。这类知识没有标准文档，需要靠访谈老师傅、翻历史工单、整理维修记录来沉淀。我们把这些内容整理成非结构化的知识文档，构建了领域知识库，用向量化 + RAG（检索增强生成）的方式做检索。

Fabric IQ 知识库最终沉淀了三大块：

• 工艺知识库：各品种织物的工艺参数范围、原料特性、织造难点。覆盖了我们工厂主产的 18 类面料。
• 异常处置库：从过去三年的历史工单中提炼的 300 多条异常处理案例，每条都有现象描述、排查路径、处置动作、效果反馈。
• 设备档案库：每台织机的维护履历、易损件更换周期、历史故障模式。

知识库建好之后，智能体回答问题的质量立刻上了一个台阶。之前问“这台机报警了怎么办”，只能回“折下张力传感器，检测张力是否异常”，这种废话没人愿意看。现在它会结合设备档案说“这台机右经轴张力传感器 8 月刚换过，近一周波动频发，且当前品种换批后张力设定没有同步更新，建议先核对批次参数再检查传感器”。

这里有一个很关键的体会：智能平台的智商不取决于模型本身有多聪明，而取决于知识库有多厚、多准。大模型是应届生，反应快但不懂行；知识库是老师傅的经验笔记，把两者结合起来，才能干活。

3.3 智能体编排：感知、推理与行动闭环

第三层是智能体编排。我们把 Fabric IQ 的智能体拆成了三个串行阶段，对应人的“发现问题、想清楚、去动手”：

感知阶段：实时数据管道持续扫描各个机台的运行状态，通过规则引擎和轻量级异常检测模型，把“低车速”“高张力波动”“断经频发”“温湿度越限”等现象识别出来，生成一个标准化事件。这个事件包含设备 ID、时间窗口、现象描述、相关点位数据切片。

推理阶段：事件进入决策引擎，先走规则库判断是否有确定性结论；规则库覆盖不了的，再触发大模型结合知识库进行 RAG 检索推理，生成处置建议。推理结果统一输出为结构化决策单：建议动作（来自预定义动作集）、执行优先级、涉及设备/人员、理由说明、置信度评分。

行动阶段：决策单进入执行网关。低风险动作（比如“推送通知到班组长手机”“生成待确认工单”）自动执行；高风险动作（比如“修改织机工艺参数”）必须经过人工确认，同时所有动作都写入审计日志。

这里我贴一段当时写的简化示例代码，用来说明事件推理部分怎么把规则引擎和大模型结合起来。虽然生产环境里的版本复杂很多，但核心逻辑就是下面这样：

def handle_event(event: dict, rule_engine, llm_client, knowledge_base): device_id = event["device_id"] anomaly_type = event["anomaly_type"] data_slice = event["data_slice"] # 1. 先走确定性规则引擎 rule_actions = rule_engine.match(device_id=device_id, anomaly_type=anomaly_type, data_slice=data_slice) if rule_actions: return { "source": "rule", "confidence": 0.98, "actions": rule_actions, } # 2. 规则覆盖不了的，让大模型结合知识库做检索增强推理 context = knowledge_base.retrieve( device_id=device_id, anomaly_type=anomaly_type, top_k=8, ) prompt = build_inference_prompt(event=event, context=context) reasoning = llm_client.chat(prompt) decision = parse_decision(reasoning) return { "source": "llm", "confidence": decision.confidence_score, "actions": decision.actions, "evidence": decision.evidence, }

判断逻辑中有一点容易被忽视：规则引擎的优先级必须比大模型高。只要规则库能匹配到结论，就不让大模型参与。不是因为模型弱，而是因为规则是确定性逻辑，有明确的因果链条，出了问题可以复盘。大模型推理本质上是概率生成，就算这次答对了，下一次同样的输入可能换个说法，这对工业场景是很危险的不确定性。

Fabric IQ 上线后统计过一次，真实事件里大概 65% 走规则引擎直接出结论，只有 35% 需要大模型兜底。但就是因为这 35% 的兜底判断，才让这个平台获得了“新问题也能给个方向”的能力——这是纯规则系统做不到的。

4. 智能体构建方式之争：低代码智能体平台 vs Python 自建

先说个背景。Fabric IQ 升级到智能平台的过程中，团队内部争论最激烈的一个问题，就是用什么样的方式构建智能体。那阵子网上也天天有人问“用平台搭建的智能体与用 Python 搭建的智能体有什么不一样”。我们两种方式都实际跑过了，而且折腾得不浅，这里把真实对比和最终取舍完整分享一下。

4.1 低代码智能体平台的实际体验

当时团队里先用了低代码智能体平台做快速验证。这一类平台（我当时用的是类似 Coze、Dify 的智能体开发环境，也接触到一些放置在智能云平台上托管的智能体服务）最大的优势是快。

我们那 35% 需要大模型兜底的推理逻辑，两个工程师在低代码平台上搭了一个带知识库的智能体原型，从接入知识库文档、配置大模型参数、编排“事件触发→检索→推理→回复”的工作流，到发布成内部 API，一共用了不到一周。这在 Python 自建路径下是很难想象的。

低代码平台的几个具体好处：

• 可视化工作流：感知节点、检索节点、推理节点、回复节点在界面上拖拽连接，团队里非算法背景的工艺工程师也能看懂管道走向，沟通成本低。
• 内置 RAG 组件：不需要自己写向量化、分块、召回的后端服务，把知识库文档传上去，平台自动完成切成块、做嵌入、建索引，并且带了个调试界面可以查看每次检索命中了哪些文档片段。
• 工具插件生态：HTTP 请求、数据库查询、消息推送这些常用工具封装成了插件，直接配置即可调用，省去了从零写集成代码的时间。
• 人机协同调试：可以在对话界面上直接测试智能体，还能查看完整推理 trace，快速发现是检索不准还是提示词有问题。

但用了几天之后，问题也开始暴露。

最难受的是执行链路被平台框死。我们想对“规则引擎优先、大模型兜底”做精细控制，低代码平台的工作流虽然能编排，但要做到“规则命中时完全不走模型、且返回固定格式的结构化决策单”这种深度定制，就得不断绕开平台封装，用平台提供的高级代码节点去写胶水逻辑，优美的可视化流程反而变成了束缚。

还有审计追踪不足。工业场景里，智能体做了决策就要背上责任，出了问题得能查出来“当时为什么这样判断”。低代码平台的标准日志能查模型输入输出，但查不到我们内部数据链路里每一条质量标签、每一次知识检索的详细排序，这在我们现有的审计体系里是不够的。

4.2 Python 自建智能体的路径与门槛

所以我们在 MVP 验证完成后，启动了一个并行方案：用 Python 从零搭一套智能体服务，部署在工业内网环境里，并挂到现有 Fabric IQ 调度平台上。核心是 LangChain 生态加本地部署的嵌入模型，知识库和事件触发逻辑完全自己控制。

Python 自建的好处非常明显：

• 完全可控的逻辑编排：规则引擎和大模型的关系、动作建议的白名单约束、置信度过滤，全部写在代码里，想怎么设计怎么设计。上面那段handle_event的逻辑，只有自建才能做到这种精细度。
• 数据链路无缝衔接：智能体直接连内网的消息中间件，订阅实时数据管道，调用内部微服务执行动作，不需要经过平台抽象的“API 插件”中转，不绕路。
• 可测试、可回归：我们给核心决策逻辑写了单元测试，把历史事件作为测试集，每次改完代码跑一遍回归，确保老事件的处理结果没有退化。低代码平台很难做这种自动化的行为回归测试。
• 彻底私有化合规可控：模型调用、知识检索、日志存储全部在我们自己的内网环境里，没有数据出域的问题，审计链路完整，安全边界可控。

代价就是慢、重、杂。

要做的事非常多：向量库的选型和运维、知识文档切块策略的调整、Prompt 版本管理、模型调用限流与降级、智能体服务的部署和监控、上下文窗口超限的处理……这些工作里，每一项单看都不难，合起来就变成了一个正儿八经的软件开发项目。我们一个三个人的小团队，从选型到能稳定跑通完整链路，用了大概六周。这还是在初期低代码原型已经帮忙验证过整体设计思路的前提下。

4.3 最终选型：两者不是二选一，而是接力

你要问我的结论，那就是：先用低代码智能体平台快速验证业务假设，再用 Python 自建把核心链路沉淀成生产级服务。

Fabric IQ 的最终结构就是这样——双轨制。对外，我们把低代码平台上调试好的 Prompt、知识库配置和流程抽象成产品需求文档，同步给自助研发团队；对内，核心的生产智能体全部跑在自建服务上。低代码平台不是被抛弃了，而是继续作为“试验田”，我们会在上面快速测试新的知识库切片方式、新的提示词模板，跑通了再搬到生产代码里去。

这里也做一个直接的对比，给大家选型参考：

我个人的真实体会是：网上那些说“低代码平台就是玩具，Python 才专业”和“Python 自建都是重复造轮子，低代码才是未来”的争论，都是脱离了场景的极端话术。制造业数字化项目最忌讳非此即彼，贴身剪裁才是正解。

5. 升级部署避坑实录：误报、幻觉与权限边界的连环坑

这部分写写 Fabric IQ 升级后的三次比较严重的翻车，每一个都是真金白银买来的教训。

5.1 智能体“自信地胡说”：一次脏数据引发的系统性误报

升级后第二周，平台突然集中报警：同一个批次的 12 台织机全部被判定为“断经风险上升”，智能体建议逐台排查。可当天车间的实际断经率完全正常，保全工跑去看了一圈：机器没问题。调度群里一片质疑声：“这智能平台是不是来制造问题的？”

我带着团队开始排查。一开始怀疑模型抽风，把同样的推理请求用相同输入反复测试，可模型每次都稳定输出同样的误判——这反而说明问题不在模型，而在输入数据。

通过数据血缘追踪，找到了根因：上游有一个 PLC 点位的时间戳在交换机组网调整后发生了偏移，导致这条支线的数据晚到了约 20 分钟，而实时数仓的窗口聚合逻辑还在按正常延时计算。那一批织机在推理窗口内显示“近 30 分钟无有效张力数据”，智能体把缺失数据解释为“数据量不足以排除风险，且该批次历史上断经概率偏高”，于是全部拉高了风险评分。

这个 bug 的本质，是我们给了模型对数据缺失的解释权。模型宁可基于不完整的数据做一个保守判断，也不会主动说“我数据不够，我无法判断”。所以后来我们加了一条硬规则：数据可信度低于 0.8 的事件，不进入智能推理链路，而是进入“数据异常待排查”队列。宁可漏判，不可误判。漏判还可以靠人工兜底，误判多了平台没人信，这个信用损失是最难挽回的。

5.2 大模型幻觉：它给了一条“合理但危险”的建议

第二次踩坑，是智能体在一条高支高密品种的织机上给出了“建议将经纱张力下调 8%”的动作建议。理由看起来头头是道：最近张力偏高频发，历史上类似情况调整张力有效。可它忽略了一个关键上下文——当天车间正处在梅雨季节的湿热天气，相对湿度 78%，经纱张力反馈本来就偏高，此时下调张力极易导致开口不清、纬纱回跳，属于违反工艺纪律的操作。

这条建议是在测试环境跑出来的，没有真实下发给车间，但已经足够给我们敲了一次警钟。问题出在我们给了大模型“动作建议白名单”之外的自由发挥空间。

对策分三步：

1. 动作建议必须来自预定义动作集。智能体不能自由生成“把参数调到多少”这种具体动作，只允许选择动作集里的预设项，比如“核查批次参数”“检查张力传感器”“上调/下调某参数 X% 以内（需工艺员二次确认）”。动作集由工艺部门定期审核，不在集里的动作，智能体永远不会建议。
2. 推理时必须注入环境上下文。Prompt 里强制携带当前车间温湿度、当前品种、最近一次工艺变更记录，即使大模型没用上，也要保证它看到了相关的环境数据。
3. 增加置信度校验。当推理结果与规则库中任何一条确定性规则冲突时，系统标记为“规则冲突”，自动降级为“仅提醒，不行动”，转人工处理。

这套机制上线后，“离奇建议”基本绝迹。原理很简单：不要把自由裁量权交给概率模型，它适合做联想和归纳，不适合做零安全边界的决策。

5.3 权限边界失控：一次误操作让全车间开始提防平台

第三个坑是在试点 L5 自动执行时踩的。我们给智能体配置了一个低风险自动动作：“当车间湿度低于 25% 时自动推送加湿提醒并触发加湿器联动调整”。一次测试中，因为湿度传感器的某一个点位被误接，瞬时数据跳变到 17%，智能体自动执行了加湿操作，导致某区域湿度短时间内变化过大，引发了该区域机台上经纱因突然回潮而发生轻微粘连。

这里最讽刺的是我们一直强调“低风险动作自动执行”，结果所谓低风险动作还是搞出了事。后来复盘时安全专家提了一个观点，我很认同：判断动作风险的时候，不要只看动作本身，还要看执行后的连锁反应。加湿本身风险不大，但湿度快速变化会影响正在运行的 20 多台织机，这个连锁反应是智能体当时没有建模的。

之后的调整：

• 所有自动化动作都设置“执行前 60 秒可中断窗口”，班组长收到通知后如果不确认就自动取消动作。
• 动作影响范围评估：执行前先查询该动作涉及的设备列表和关联区域，若超过设定台数，自动转为人工确认。
• 强权限动作审计留痕：谁触发的规则、模型给的置信度、执行结果全量记录，可一键回溯到原始训练数据和数据血缘。

这些规则加完之后，平台动作执行的次数缺了明显减少，但留存下来的每一次执行都是经过完整决策链的。信任这个东西，建立起来需要几百次正确，摧毁可能只需要一次失误。

5.4 低代码平台的“黑盒感”与自建调试的控制感

还有一个偏过程性的坑：低代码平台在可视化调试时看起来很透明，但真要排查一条“为什么这个事件走了模型分支而不是规则分支”时，你会发现在平台界面里操作几万个节点上的配置描述就是找不到那个判断条件藏在哪。那种无力感，我相信用过的人都有。

换到 Python 自建之后，每个分支判断都在代码里，IDE 全局搜一下关键字就能定位，日志里也能按事件 ID 拉出完整决策 trace——走规则、走模型、中间检索了哪些知识片段，一目了然。咱们做工程的人，控制感这件事不是矫情，是在出问题的时候能不能 30 分钟内给出根因。低代码平台的控件化设计适合“演示”，生产排错还是得能被 grep 的代码更稳。

所以如果你问我 Fabric IQ 的第三次大升级还会不会再用低代码平台来承载生产链路，我的答案非常明确：不会。但是让我再推荐一次给刚起步的团队首选哪个，我仍然会说低代码。阶段对了，工具才是对的。

6. 落地效果复盘：从“能看见”到“能扛事”

写到这里，也该说说升级后的真实成效了。我不喜欢那种“大幅提升、显著优化”的空话，直接放几个硬数字：

事件响应耗时变化：升级前，从异常发生到调度员在报表里发现并通知保全工，平均耗时约 45 分钟；升级后，智能体从事件感知到推送处理建议，平均耗时不到 3 分钟。即使算上人工确认环节，整体响应速度也提升了 70% 以上。

OEE 变化：系统运行三个月后，试点区域的 OEE 从 82.5% 提升到 86.8%。这里说句公道话，智能平台不是唯一的贡献者，同期我们也做了班组激励调整，但车间主任给了一个估算：至少三分之一以上的提升，来自“异常被更早发现、处置更及时”。其中断经相关停机损失下降了 41%，这部分很难归功于其他因素，因为 Fabric IQ 的知识库和智能体在断经诊断上投入的精力是最大的一块。

知识传承变化：这个收益容易被忽略，但我觉得长期价值最高。之前车间最有价值的经验存续在三位老工艺员脑子里，他们再过几年就退休了。升级过程中，我们围绕“异常处置”“工艺调参”“设备检修”三个方向，把他们口头描述的经验整理成了知识库文档，再由智能体在每天的真实事件里反复检索和验证。有一次老师傅自己都说：“这东西把我平时干活的路数记住了，有些我自己都要想一想的地方它居然直接能调出来。”经验资产化，这句话喊了很多年，Fabric IQ 这次是真的落到了数据模型里。

人工负荷变化：调度员从每天花两小时拉数据、做 Excel、盯群消息，降到现在每天只需要花二十分钟审核智能体推送的决策单。省下来的时间他们开始做更有价值的事情——去现场跟踪那些系统标记为“低置信度、需人工确认”的疑难杂症。这件事我觉得才是智能平台该有的样子：不是替代人，而是把人从低价值的信息搬运中解放出来，去做真正需要人的判断力的事。

从技术架构上看，Fabric IQ 最终的样子大致是这样的：底层还是那套采集和数仓不动；中层是数据治理层，提供了可信的数据底座；再往上是领域知识库和规则引擎，一硬一软两个知识源；外层是智能体编排框架，负责把事件、知识、动作串起来。至于用低代码平台还是 Python 自建，放到这个架构里都是实现路径的选择，不必上纲上线。

我个人在推进整个项目过程中的体会是：数据平台向智能平台的转移，本质上不是技术升级，而是责任模型的重构。原来的系统只需要对“数据准不准”负责，升级后的系统还要对“建议好不好、动作稳不稳”负责。这一层责任的增加，会逼着你把数据治理、知识工程、权限边界这些枯燥的事情做到极致。大模型的幻觉是一个放大器，底层地基如果不扎实，它会把地基里的裂缝放大成一场崩塌。

最后分享一个很实在的小建议：如果你也准备启动类似的升级，不要一口气铺开全厂，选一个产品相对稳定、工艺人员愿意配合、数据质量最好的车间，做成样板。三个月后，让其他车间主任来样板间看效果，比任何 PPT 都管用。Fabric IQ 就是从试点车间慢慢扩展到全厂的，过程中最花时间的不是技术，而是让一线的人相信这个新系统是他们值得依赖的伙伴——这个信任的建立，比写一万行代码都难，但一旦建立起来，后面的事情就顺了。