企业官网建设流程全解析

新能源工厂要想真正吃下AI红利，光有大模型远远不够，关键在于怎么让一线工程师、工艺员、班组长也能快速用上AI能力。我在今年参与的几个项目中感受特别明显：低代码平台和智能体（Agent）这两个东西叠加在一起，正在把智能制造的门槛从“会写代码”拉低到“会描述问题”。尤其在前段时间跟进的一家新能源电池工厂里，我们用低代码+智能体的方式，把设备告警分析、工艺参数寻优、排产辅助决策几个场景在几周内就做上了线，这个速度放在以前用传统软件交付方式根本不敢想。这篇内容不聊宏大的数字化转型概念，就把我们实际怎么选型、怎么设计智能体、怎么让它在车间里真正跑起来的过程拆开讲，给同样在搞智能制造落地的朋友一个参照。

1. 为什么这个时间点，新能源工厂需要智能体

1.1 车间里不缺数据，缺的是把数据变成决策的人

新能源工厂和其他制造工厂最大的区别在哪里？我用一句话概括：数据密度极高，但决策链条极长。

产线上的传感器、PLC、MES、ERP、QMS系统每天都在产生海量数据。拿我们做的这家电池厂举例，仅一个电芯车间，单日产生的工艺数据就有几千万条。但真正让人头疼的不是数据量，而是当设备报警或者工艺指标出现波动时，工程师要花大量时间去查数据、翻历史记录、找相关性。一个资深工艺工程师每天至少有三分之一的时间耗在“数据拉取-人工比对-经验判断”这件事上，而且这种判断极度依赖个人经验。

为什么说智能体在这个时间点迎来拐点？因为大模型加上低代码平台，第一次让“把老师傅的经验变成可复用、可交互的数字助理”成为可能。以前我们做一个专家系统，要把工艺知识写成规则库，费时费力还不好维护；现在通过智能体，可以直接把老师傅的分析思路用自然语言描述出来，让大模型去调用工具、查询数据、执行分析，这本质上是一种知识表达方式的革命。

1.2 传统软件和纯AI方案各自的死穴

过去几年，制造企业在智能化上其实走过两条路，但都卡住了。

一条路是传统软件路线。无论是MES升级还是上APS系统，实施周期动辄半年起步，定制开发成本极高。尤其在新能源这样工艺迭代极快的行业，今天刚上线的一个报表模块，明天工艺一变又得改。牵一发动全身，IT部门和业务部门互相拉扯。

另一条路是纯AI路线。找算法团队做数据建模，让AI工程师天天泡在车间里研究业务。结果发现业务问题千变万化——今天看设备振动，明天看涂布厚度，后天又看化成分容的容量一致性——算法团队疲于奔命，每个场景都要重新做数据标注、特征工程、模型训练，单场景落地成本高到离谱。

智能体+低代码为什么能破局？核心在于这两者组合后，把“AI应用”从项目制变成了搭积木。算法能力被封装成工具，业务流程被编排成工作流，知识沉淀成知识库，交互界面通过低代码拖拽生成。一线人员不需要理解Transformer或者梯度下降，只需要知道“我要问什么问题、给智能体配什么工具”。

2. 智能体平台选型与整体架构设计

2.1 低代码智能体平台怎么选：从Dify、Coze到企业级方案

聊到智能体开发，目前行业内主流的路径无非三种：基于开源框架（比如LangChain、Spring AI）自行开发、使用商业低代码智能体平台（比如Dify、扣子Coze）、或者使用头部云厂商的企业级AI平台。

我们这次在新能源工厂的项目里，最终选择了Dify作为核心平台，主要基于三点考量。

第一是私有化部署的友好度。新能源电池厂对数据安全要求极高，工艺参数、配方数据绝对不能出车间。Dify社区版支持Docker Compose一键部署，对GPU资源要求相对可控，一套CPU机器加上一块消费级显卡就能跑起来，这在车间IT环境里非常现实。

第二是工作流编排能力。我们的智能体不只是纯对话，很多场景需要调用外部API查询MES数据、调用Python脚本做计算、甚至触发PLC的指令下发（这是后话，目前仅做了只读类操作）。Dify的工作流节点支持HTTP请求、代码执行、条件分支，可以直接把一个复杂的业务逻辑可视化编排出来。

第三是知识库管理和检索增强（RAG）的功能成熟度。我们把设备手册、工艺规范、历史异常处理记录灌进知识库，Dify在文件解析、分段、向量化和检索这一套流程上做得比较顺手，后续维护成本低。

诚然，像Coze这类云端平台在对话体验和插件生态上也很强，但在工控网环境里的私有化部署会受限，所以最终没进入我们的候选名单。如果你所在的场景对数据外传没有限制，Coze上手更简单；但制造业尤其是新能源这种敏感领域，私有化几乎是硬门槛。

2.2 智能体与现有系统的接口怎么打通

智能体要在车间里产生真实价值，必须能拿到实时数据。我们接的是MES数据库和部分设备采集网关的数据接口。

这个环节有几个经验值得单独拿出来讲。

首先，不要一上来就想着直接写数据库。车间系统的数据表结构往往复杂且权限敏感，智能体直接连库既危险又容易把系统拖垮。更稳妥的方式是对接MES已有的API服务，让IT团队封装一层统一的数据服务接口，智能体只通过这个标准化的HTTP接口去取数。

其次，要设计好权限边界。我给智能体配置的数据库账号只开放只读权限，并且只能访问白名单内的表。涉及下发指令、修改参数等高危操作，一律没有开放权限。在项目演示时对方工程师也问过“为什么不直接让智能体调PLC”，我的建议是：先让智能体把分析和建议做扎实，控制动作留给人来确认。智能体给的不是“最终指令”，而是“建议方案”，这个边界在工业场景里必须守住。

第三，接口响应速度要有兜底。大模型调用链路的时延通常在几秒级别，如果数据服务接口本身响应超过2秒，用户体感会非常差。我们专门做了一个轻量级的数据缓存层，高频查询的热点数据提前同步到Redis，确保智能体取数为毫秒级返回。

2.3 整体架构：模型层、平台层、工具层、应用层

把整个系统的架构理清楚，后续扩展才能不乱。

从底层往上看，模型层用的是私有化部署的Qwen系列（千问）和本地Embedding模型。为什么没用更大的模型？因为车间服务器的显卡资源有限，用了量化版本部署，推理速度大概在每秒十几token，单轮对话2-5秒返回，处于可接受范围。选型时也测过ChatGPT类的云端API，效果确实好，但数据出域这一关过不了，只能放弃。

平台层就是前面说的Dify，负责工作流编排、知识库管理、Agent设计。这一层是整个体系的大脑，所有智能体的生命周期管理都在这里完成。

工具层是我们自定义的几个API工具：MES数据查询工具、工艺参数统计工具、报警记录检索工具、设备档案查询工具。每个工具本质上是一个带参数的HTTP接口，智能体根据用户的意图去决定调用哪个工具、传什么参数。

应用层面向最终用户：工艺工程师用的参数分析助手、设备维护人员用的故障排查助手、生产管理人员用的排产决策助手。这三类智能体在Dify里以独立应用的形式配置，挂在企业微信和Web门户上，用户直接对话就能用。

这套架构的好处是每一层都解耦：模型不好用随时换，平台升级不影响工具层，工具增删不需要改智能体逻辑。后续想加一个新场景，只需要在工具层加一个API，然后在平台层配置一个新的智能体应用，一周内就能上线一个全新的AI助理。

3. 三个典型制造场景的智能体落地拆解

3.1 设备故障排查智能体：从“翻手册”到“问一句”

新能源工厂的设备种类繁杂，从搅拌机、涂布机到卷绕机、化成分容柜，每台设备的故障代码动辄几百个。以前维修工遇到一个不常见的报警，要翻纸质手册或者问老师傅，经常一等就是半小时。

我们的设备故障排查智能体是怎么做的呢？

知识库层面，把所有设备的操作手册、故障代码表、历史维修工单灌了进去。RAG检索让智能体能在几秒内找到相关章节。工具层面，接入了设备历史报警接口，智能体可以根据当前报警代码，自动查询最近7天同类型报警的发生频率和处理记录。

实际的交互效果大概是这样的：车间维修工在手机端发一句“2号涂布机报E102，怎么处理”，智能体先调用报警检索工具查出E102在最近一个月的出现次数和常见处理方案，再结合知识库里的维修手册生成操作步骤。当环境数据不足时，它会主动追问：“当前涂布速度是多少？浆料粘度有没有波动？”从而引导工人补充关键参数。

这个场景落地的最大难点在于知识库的质量。一开始我们只是把手册PDF灌进去，效果很一般，回答经常张冠李戴。后来把历史维修工单整理成“故障现象+处理步骤+注意事项”的结构化文档再导入，效果立刻好了很多。

3.2 工艺参数寻优智能体：给老师傅配了个AI参谋

电池生产过程中，涂布厚度、辊压压力、化成分容温度这些参数直接影响产品质量。以前工艺工程师调参数主要靠经验加DOE试验，周期长、成本高。

我们设计的工艺参数寻优智能体，本质上是一个数据分析和知识检索的组合体。工程师描述问题：“最近一周NCM811体系的涂布面密度波动变大了”，智能体会自动调用工艺参数统计工具，抓取对应产线、对应时间段的面密度数据，计算均值、极差、标准差和CPK指标，然后把统计结果和异常点位返回给工程师。

这里面有个很关键的细节——Prompt设计。我们给智能体的系统指令中明确要求：所有分析必须基于工具返回的实时数据，不能凭空推断；给出的建议必须区分“数据事实”和“经验参考”两个层次。为什么？因为大模型有幻觉风险，如果直接让它“分析原因并给出建议”，它可能一本正经地编一个看起来合理的结论。但限定它先摆数据、再根据知识库中沉淀的工艺规范给出参考建议，就能最大程度降低误导风险。

这个场景跑通之后，工艺团队从“靠记性、靠翻聊天记录”变成了“随时有一个懂工艺数据的参谋”。新入职的工艺员上手速度也明显加快，以前要跟老师傅学半年的经验常识，现在可以先问智能体，再找老师傅确认关键判断。

3.3 生产排产辅助智能体：交期承诺不再拍脑袋

新能源行业订单波动大、插单频繁，生产计划员排产时最头疼的问题就是“这个单子到底能不能在交期内做完”。以前要么靠Excel手工估算，要么听老师傅拍脑袋。

我们做的排产辅助智能体，核心是调用一个基于历史工时的产能预估API。计划员输入订单数量、产品型号、交付日期，智能体自动计算标准工时、评估当前产线负荷、给出交期可行性判断，并且引用类似订单的历史实际周期作为佐证。

这个场景有意思的地方在于：它没有做复杂的运筹优化模型，而是先用智能体把信息聚合和初步推理做掉。为什么这么设计？因为真正的排产优化涉及多目标约束——交期、产能、物料齐套、人员班次、换型时间，这些变量之间的关系极其复杂，现阶段数据基础还不够支撑一个完整的优化模型。智能体的价值是先让计划员能快速拿到一个相对靠谱的参考基准，再结合人的经验去微调。

不过在做这个智能体时踩过一个大坑：产能预估API的历史数据颗粒度不够，很多工序的时间记录是班组手工填的，不准。后来我们要求计划员在QA环节对智能体的产出做反馈标注——“偏乐观”“偏保守”“基本准确”，持续用反馈数据去校准API的修正系数。这个闭环机制目前还在运转，随着标注数据积累，预估准确率会逐步提高。

4. 真实落地过程中的关键避坑指南

4.1 别一上来就做“超级智能体”

我们在项目启动时犯过一个典型错误——想做一个能回答工厂所有问题的“超级智能体”。结果发现需求范围收不住，知识库庞大且混乱，对话经常答非所问，维护成本极高。

后来调整为“一个场景一个智能体”的策略。设备相关的归设备智能体，工艺相关的归工艺智能体，排产相关的归排产智能体。每个智能体的知识库边界清晰、工具集合收敛、Prompt针对性强。用户知道自己面对的是什么工具，提问引导也做得更容易。等到每个场景都稳定跑通了，再考虑在应用层做一个统一入口做语义路由，这是后话。

这个教训我想重点说：智能体的边界感，比智能感更重要。一个什么都能聊的AI助手听起来很酷，但在工业场景里，边界清晰、能力可预期才是用户信任的前提。

4.2 Prompt调优和知识库维护是持续活

很多团队把智能体上线当成项目的终点，这完全错了。智能体的效果从来不是一次配置出来的，而是持续调出来的。

我们维护频率最高的是两块：Prompt模板和知识库内容。

Prompt模板的调整通常来自两类情况。第一类是新发现的badcase，比如用户用了一个方言词或者简称，模型理解偏差，我们就在系统指令里补充术语表。第二类是业务变化，比如工艺部门修订了控制计划，我们会同步调整智能体在某个场景下的分析口径。

知识库的维护同样重要。设备手册会更新、工艺规范会换版，历史的维修工单每天都在新增。我们定了一个机制：每周拉取一次新增的维修工单，清洗后增量导入知识库。如果没有这个机制，智能体就只能靠静态的旧知识回答问题，价值会随时间快速衰减。

如果你没有专职的Prompt工程师，我的建议是让懂业务的人来主导Prompt维护而不是让程序员来做。业务人员更清楚什么样的问题表述是高频的、什么样的回复是有用的。平台方负责把调整流程做成自助式，让业务人员可以直接在后台编辑Prompt并发布。

4.3 模型幻觉在工业场景里的危害必须正视

前面提过幻觉问题，这里再展开讲一下我们的应对方案。

工业场景和聊天机器人最大的区别在于：错误信息的代价是真实的——误导一次维修操作可能导致停机时间延长，误导一次工艺调整可能造成整批产品报废。

我们的三道防线是这样的。第一道防线：系统指令约束。明确要求智能体在数据不足时必须说“信息不足，建议补充XX数据”，而不是强行给结论。第二道防线：工具结果优先。智能体所有的量化结论必须来自工具返回的真实数据，知识库只作为解释和建议的参考。第三道防线：标注“置信度”。生成回答时将“数据依据”和“经验参考”分开展示，经验建议部分明确提示“此为参考经验，请根据现场情况判断”。

这三道防线并不能100%消除幻觉，但能极大降低错误决策的概率。我们在给管理层汇报时也反复强调：智能体是副驾驶，不是自动驾驶。这在理念上必须先对齐，否则后续推广一定出问题。

4.4 低代码平台的权限管理和审计日志

最后这部分属于合规和技术债的范畴，但重要性不低。

车间环境里使用AI应用，必须有完整的权限管理和审计机制。我们通过Dify的API扩展能力，将用户体系对接了企业的统一身份认证，不同岗位看到的智能体和数据范围不一样。工艺工程师能查工艺参数，维修工能查故障知识库，生产经理能看排产分析，互不越权。

所有对话记录都做了全量日志存储。为什么要存日志？一方面是安全问题，出事后可以追溯；另一方面是数据资产问题，用户在对话中暴露出的高频问题、分析思路，都是未来优化智能体和沉淀业务知识的金矿。

权限和审计必须在第一天就建好，哪怕当时觉得“有点重”，也不能等系统规模大了再补。智能体一旦被一线员工主动用起来，数据流转量是巨大的，事后补审计就像亡羊补牢，代价远大于一开始就规划好。

5. 现在的效果和下一步想做的事

5.1 现实收益：效率提升和组织知识固化

目前这套系统在那边工厂已经稳定运行了三个多月，接入用户一百多人。最直接的反馈是设备故障排查的平均用时从原来的二三十分钟缩短到几分钟，工艺人员查历史参数分析原因的时间至少节省了六成以上。

但我个人认为，比效率数字更重要的是组织知识固化的价值。老师傅的经验以前都在脑子里，人走了知识就没了。现在通过知识库和智能体的交互记录，这些经验正在被系统性沉淀下来。哪怕未来有老员工退休，新员工也能在AI助手的帮助下快速补位。

另一个隐性收益是对IT团队能力的提升。以前他们觉得AI很远，现在通过低代码平台亲手搭建了几个智能体之后，对“AI能做什么、不能做什么”有了非常具体的认知。这种组织能力的转变，比一个两个场景的落地更有长期价值。

5.2 扩展方向：多目标调度优化与更多产线复制

下一步我们正在探索的方向是智能制造中的多目标调度优化。前面说过，最初的排产智能体做的是信息聚合和辅助判断，真正的优化计算还没有深入进去。

多目标调度优化的核心挑战在于生产环境中有多个互相冲突的目标：交期满足率、设备利用率、能耗成本、人员负荷均衡。传统做法是建数学模型，用遗传算法、粒子群或强化学习去求Pareto最优解。但这类方案落地难在两点：动态扰动太多（插单、设备故障、物料延迟），以及车间调度员对算法给出的结果信任度不足。

我们的思路是用智能体作为“调度员与算法之间的翻译官”。算法负责生成多组候选排产方案，智能体负责将每组方案的权衡关系、对关键指标的影响，用自然语言解释给调度员听，辅助人来做最终决策。人的经验负责处理算法考虑不到的业务约束，算法负责给出全局视角的优化空间，智能体负责把双向信息翻译到位。

这个方向如果走通，会是把运筹优化和智能体结合的一个有代表性的案例。

同时，这套平台架构也在往这个工厂的电极段、组装段、PACK段复制。我们的目标不是“为每一个车间各做一套新系统”，而是通过低代码平台沉淀出一套可复用的智能体模板和工具链，让新车间上线时只需要做参数微调即可快速落地。

6. 如果你也想在工厂里做智能体

6.1 给刚起步的团队四个建议

第一，从高价值低风险的场景切入。设备故障知识问答、工艺数据查询这类场景既能快速见效、又没有权责风险，非常适合做第一个试点。不要一上来就挑战生产优化控制这类高风险场景，那会让你在证明价值之前就被质疑淹没。

第二，业务人员全程参与。智能体不是IT部门自嗨的工具，业务侧必须有人在项目组里。我们的经验是设立一个“AI应用BP”角色，由懂业务又愿意尝鲜的员工担任，负责梳理场景需求、参与Prompt设计、组织一线测试反馈。这个角色往往决定了一个智能体能不能从“能用”走向“好用”。

第三，指标定义要前置。上线前就说清楚这个场景要解决什么问题、用什么指标衡量成功。设备排查看平均故障处理时间，参数分析看单次分析耗时，排产辅助看交期预估准确率。有指标才能向管理层证明价值，才能争取到后续的资源投入。

第四，不必一次性配齐高端硬件。初期用4090级别的消费级显卡跑量化模型，足够支撑一个几十个人的车间试用。先把业务逻辑跑通、让用户习惯用起来，再根据并发需求去扩容算力。算力成本不该是智能体落地的第一瓶颈，流量和用户活跃才是真正决定项目生死的指标。

6.2 关于长期主义的一点体会

项目做久了，我对“AI落地制造”的看法也从最初的技术崇拜，逐渐变成了对组织、流程和人性的重新审视。

技术层面，低代码和智能体确实把AI应用的门槛压到了一个非常低的位置，这个趋势是不可逆的。但真正决定一个工厂能不能吃到这波红利的，不是它用了多强的模型、部署了多有排面的平台，而是它有没有一套机制，让一线员工愿意每天打开这个AI工具、把自己的经验通过对话贡献出来、并不断反馈修正系统的判断。

这套机制很难靠一个技术项目的交付来建立，它更像是组织管理层面的一次升级。我们在这家新能源工厂里能走到今天，很大程度上是因为有一两个关键的车间负责人在最早期的试用阶段愿意忍受那些不完美的回答，愿意反复给出修改建议。这种来自业务侧的耐心和包容，在AI落地的过程中，比任何参数调优都珍贵。

如果你正准备在自己所在的工厂推动智能体落地，我的建议是：别急着追求技术上的“大而全”，先找到那个愿意跟你一起打磨的业务伙伴，从一个小而真、业务愿意用的场景开始，跑通以后再快速复制。踩过的坑我写在上面了，照着做能帮你少走很多弯路。