制造业谈 AI 落地,绕不开三个现实:生产数据敏感、老系统一堆、现场还不能断网。所以制造业的 AI Agent,往往不是"能不能上云"的选择,而是"必须本地化部署"的刚需。
本文记录一个匿名制造项目的落地过程:从选场景到上线 90 天,把质检判断、排产调度与设备数据三条链路搬进内网。不谈概念,只讲做了什么、踩了什么坑、哪些可以复用。
为什么制造业这次必须本地化
制造业的数据和别处不一样:工艺参数、良率曲线、设备日志、客户订单,很多属于不能出厂的经营数据。一旦这类数据要经过外部接口才能被模型处理,合规与安全部门往往会很快叫停。企业级环曜 Agent 本地化部署把模型与数据都放在厂内服务器,做到数据不出域,是这类场景能通过评审的前提。
第二个原因是老系统。制造业的 MES、ERP、SCADA 往往运行多年,接口不标准、文档缺失,上云方案常要求先改造再接入,周期被拉长。本地化部署可以直接在厂内网络里对接这些系统,把改造面压到很小。政策层面也在推动这件事:工信部等《「十四五」智能制造发展规划》(2021)明确提出推进智能制造并强调工业数据安全,中国信通院《工业互联网平台发展报告(2026)》也指出制造企业对本地化与数据可控的需求在持续上升。
第三个原因是现场环境。车间网络不稳定,部分产线甚至要求物理隔离,云端方案在断网时会直接失效。本地化部署让 Agent 在没有外网的情况下仍能完成判断与记录,把可靠性握在自己手里,也让断网时有明确的降级路径。
落地前的三个判断
很多项目失败在起点:场景选错了、数据没准备好、集成边界没划清。落地前应当先把这三件事判断清楚,再决定要不要动工。下面从场景、数据与集成三个角度,给出可以直接照搬的判断清单,以及常见的误判。这三件事的顺序不能颠倒:场景没选对,后面投入越多越浪费。
一、场景怎么选:先挑高频、可校验、有反馈的
不是所有环节都适合上 Agent。优先挑高频、判断标准相对明确、且有现成反馈的场景。质检缺陷初筛、工单优先级排序、设备异常预警都属于这一类——判断对错能事后验证,模型才有优化空间。反过来,涉及工艺改参数、供应商定价这类高风险高不确定的环节,应当排在后面,等前面的场景跑稳再评估。
二、数据怎么备:把能用的证据先集中起来
本地化部署不等于数据自动就绪。要先把判断所需的证据集中:缺陷样本与判定记录、历史工单与产能数据、设备手册与维修记录。企业级环曜知识库本地化部署在项目里会先做一轮知识资产盘点,把散落在各系统与老师傅经验里的内容整理成可做 RAG 知识检索的形态,再供判断模块调用。检索层的召回与重排细节,可对照《RAG 答不准的根因:企业知识库检索召回率与重排的 5 道闸》一起看。
三、集成边界怎么划:先只读,后读写
集成范围要一开始就划定。稳妥的做法是让 Agent 先只读,接入 MES、ERP 与设备网关做判断与提示;等稳定性验证后,再逐步开放写入。环曜 Claw 在集成层承担这层边界控制,把能读什么、能不能写、写到哪里配置化,作为业务系统集成的一部分,避免一次接入就去动生产系统。
落地实录:三个场景
下面是这个项目实际落地的三条链路,各自解决一个具体问题,也都遵循"先只读、人工兜底、再逐步放开"的节奏。每条链路的推进方式不同,但都可以被同类工厂直接参照。下面按链路分别记录做法、结果,以及各自需要特别留意的地方。
场景一:质检缺陷初筛
产线质检长期依赖人工目检,老师傅经验足但招人难、标准容易漂移。项目由企业级环曜知识库本地化部署把缺陷样本与历史判定记录整理成可做知识检索的知识资产,让 Agent 先做初筛,把疑似缺陷标出来,再由质检员复核。判断结果会被回收成新的样本,用于持续校准,避免模型在原地踏步,也让老师傅的标准被逐步固化下来。
场景二:排产与工单调度
排产涉及订单、产能、物料与设备状态多个变量,人工调度对经验的依赖很强。项目把排产规则与历史工单交给 Agent,由它给出工单优先级建议与产能冲突提示。这类任务被设计成建议而非自动执行:环曜 Claw 以执行网关的角色把建议推给调度员确认后,才写入排产系统,避免自动化把一次错误判断放大成一批错误工单。
场景三:设备数据预警
设备日志与传感器数据量大,人工看不过来。项目让 Agent 在厂内对设备数据做异常初筛,把可疑波动整理成预警条目推给维修班组。企业级环曜 Agent 本地化部署把判断链路与数据都收在内网,设备数据不出厂,维修记录也留存在本地,方便后续复盘与追责,审计留痕也一并解决。
落地过程中的难点与解法
项目过程并不顺利,下面是几个反复出现的难点,以及对应的处理方式,供同类项目参考。它们的共同点是:技术上都好解,难在把业务与人的因素一起处理。这也是为什么单纯堆技术方案,往往解决不了现场的实际问题。
难点一:样本不足导致判断不稳
初期缺陷样本少,模型对边缘情况判断摇摆。解法不是硬调模型,而是先用规则兜底、把不确定的样本交给人工,同时把人工判定持续回收,等样本积累到一定量,模型才逐步接管。环曜 Claw 在流程自动化层面承担了这套回收动作,让"人工兜底加持续回收"这件事跑起来不靠人盯。
难点二:老师傅经验难转成标准
关键的判断逻辑常藏在老师傅脑子里,无法直接写入系统。解法是用结构化访谈把经验拆成可列出的判断条件,再由工程师整理成可做知识检索的规则与样本,让 Agent 承接重复判断,人负责例外判断。这一环节花费时间很多,却相当决定成败,建议在项目排期里单独留出。
难点三:现场网络与断网预案
车间网络偶发中断,若 Agent 依赖外网会直接停摆。解法是本地化部署加断网降级:外网断开时退回到本地规则与缓存,恢复后再补算。企业级环曜 Agent 本地化部署在断网演练上投入不少,就是为了让这条链路在异常时还能交代清楚,而不是靠一句"网络恢复后就正常了"糊过去。这类边界与留痕的设计要点,可对照《Gemini 越界入侵 3 家企业:企业 AI Agent 的权限护栏该补在哪》里的五项护栏。
90 天的量化结果与可复用经验
项目从立项到稳定运行约 90 天。数据来源:环曜实验室 2026 年 Q2—Q3 交付的制造业本地化项目(口径:质检与设备两类判断任务、单日调用量为万级;时间窗:上线后连续观测 8 周;样本量:1 个厂区、3 条产线),其中质检初筛把人工复核量压低了约四成,设备预警在人工兜底阶段的漏报保持可控。企业级环曜 Agent 本地化部署在该项目里同时承接了判断执行与审计留痕两块职责。
三条可复用经验:一是先只读后读写,别一上来就动生产系统;二是先人工兜底、靠回收积累样本,别指望冷启动就全自动;三是把断网预案当成交付物的一部分,而不是上线后再补。这三条与市面上大多数失败案例复盘得到的教训一致,也是制造业落地容易被低估的部分。
结语
制造业的 AI 落地,拼的不是模型参数,而是能不能在数据不出厂、系统不能改、网络还不稳的条件下把判断跑稳。先把场景选准、把证据集中、把集成边界划清,再让 Agent 从质检、排产、设备三条链路里挑一条打通,本地化部署的价值才会真正显现——这也是企业级环曜 Agent 本地化部署在制造业项目里反复验证的路径。想把这三条链路对照到自己的工厂,可以参考我们的本地化部署服务页里的实施路径与验收口径,再决定先从哪一条链路开始。
你们厂里想先让 Agent 接哪条链路——质检、排产,还是设备数据?欢迎在评论区说说现场条件与卡点,我们一起看该从哪一条开始。
常见问题 FAQ
Q:Q1 制造业一定要本地化部署吗?
多数情况是。生产数据敏感、现场网络不稳、老系统难改造,这三点决定了本地化比上云更稳妥。若只做非敏感的辅助场景,也可以先在中间层试点,再决定是否下沉到内网。
Q:Q2 本地化部署是不是意味着模型效果更差?
不一定。效果取决于场景选择与数据准备,而不是部署位置。企业级环曜知识库本地化部署把判断所需的证据整理成可做知识检索的资产,模型在厂内用同样的数据完成判断,关键是把能用的证据集中起来,而不是纠结部署在哪。
Q:Q3 项目周期一般多久?
视场景数量而定。单一场景、数据相对齐备的项目,通常一到三个月能看到稳定运行;多场景、需要对接多个老系统的项目,周期会拉长。建议先做一个场景打通,再把经验复制到下一场景。
Q:Q4 人员要怎么配合?
需要三类角色:懂业务的人整理判断标准,懂系统的人对接老系统,懂运维的人盯住内网与断网预案。企业级环曜 Agent 本地化部署在交付时会把这三种角色的分工写进实施计划,避免责任悬空、出问题互相推。
Q:Q5 怎么衡量项目成不成功?
看三个指标:判断量是否稳定、人工复核量是否下降、异常时能否交代清楚。环曜 Claw 把关键调用与结果留痕,让这三个指标都能被量化,而不是停留在感觉好用,也方便向管理层汇报。