企业官网建设流程全解析

中年龙虾养成记这个系列，本意是记录我从传统矿山信息化往AI方向折腾的过程。上一篇聊了转型路上的心态变化和一些试错体会，这篇直接上硬货——AI智能体在矿山行业的落地应用。不是概念验证，不是咨询报告，是我带着团队在某座金属矿山里从0到1真跑出来的系统。如果你正打算把AI智能体往传统工业场景里搬，或者正在为“大模型到底能帮传统行业干什么”发愁，这篇内容应该能给你一些能直接抄作业的思路。

先说一个反直觉的结论：AI智能体在矿山落地的最大难点，从来不是模型能力不够，而是矿山的数据、流程、人和组织习惯都还没准备好。模型反而是整个链条里最成熟的一环。

1. 为什么矿山要的是“智能体”而不是“大模型接口”

1.1 矿山行业的老问题：不是缺模型，是缺闭环

矿山行业这几年不好干。设备数量逐年增加，皮带、破碎机、提升机、通风机、水泵，随便一条产线就是几百上千个测点。环境高粉尘、高湿度，井下信号时有时无，设备台账混乱，备件管理靠老师傅脑子记。但最扎心的还不是设备，是人——经验丰富的老师傅陆续退休，年轻人不愿意下井，一批批操作规程和故障判断经验正在跟着老师傅一起流失。行业里到处在讲“技能断层”，落到我们项目组头上就是活生生的现实：设备一响，能判断出“这是轴承早期磨损还是正常噪声”的人，全矿一只手数得过来。

这类问题，传统信息化手段解决不了。做BI看板？看板能告诉你设备温度高了，但不会告诉你怎么处理。上专家系统？规则写死了，现场情况千变万化，上线的成本比请十个老师傅还高。正因为这样，当大模型热潮起来的时候，矿里很多同行第一反应是“这玩意儿能帮我分析设备数据吗”，结果试用下来发现，大模型像个什么都懂一点的军师，你问它“皮带跑偏了怎么办”，它能把规程给你背得头头是道，但它没法自己去现场看一眼，也没法帮你提单、通知检修工、跟踪整改结果。军师再好，不落地就是白搭。

1.2 大模型的边界：会答、不会做、还会瞎编

真正把大模型用到生产环境，我总结了三道坎，每一道都卡得死死的。

第一道坎叫“会答不会做”。模型本质是个语言系统，输入输出都是文字。矿山要的是动作：报警要分发给责任人、工单要进系统、设备参数异常要触发巡检任务、整改结果要有人复核。这些靠对话解决不了，必须有程序在背后根据模型的判断去调用系统、发消息、建工单。这就是“智能体”跟“模型接口”的第一个区别——智能体有工具调用能力，能动手。

第二道坎叫“幻觉”。这是大模型天生的毛病，它在生成内容，不是在查数据库。矿山是高度依赖精确数据的行业，设备型号、压力范围、操作规程，错一个字可能出大事。我见过最离谱的一次测试，系统把“主通风机”写成了“局部通风机”，这俩在操作规程里根本不是一个级别的东西，主通风机是整条矿井的命脉，真按这个执行，整个作业面都得停。所以模型不能直接面对生产，必须有一层机制拦住胡说八道。

第三道坎是“没学过你家的规矩”。通用大模型训练的是全网数据，它不知道你们矿的提升机是哪个厂家的，不知道你们的历史故障规律，不知道你们安全规程第几条怎么规定。要让它懂这些，得把企业的私有知识喂进去，这个环节现在主流做法是RAG，检索增强生成，本质上是给模型外挂一个企业知识库，它回答之前先去库里检索相关条文。但这只是第一步，知识库怎么建、怎么管、怎么保证版本正确，才是真正费功夫的地方。

1.3 智能体补上的那一环：感知-思考-行动闭环

那“智能体”到底比“大模型接口”多了什么？用大白话说，大模型是脑子，智能体是“脑子加眼睛加手”。

智能体的标准结构，就是把三件事串起来：感知——从摄像头、传感器、数据库、人工录入拿到现场信息；思考——调用大模型推理，结合规则和知识库做判断；行动——调用工具去发告警、建工单、更新看板、通知责任人，然后等结果反馈回来，判断动作有没有效、要不要升级处理。业界管这种循环叫ReAct模式，Reasoning and Acting，思考一步、行动一步、再思考一步，不是让模型一次性憋个大招，而是像人干活一样，走一步看一步。

我在项目里跟团队打过一个比方：大模型是军师，智能体是连长。军师负责出主意，连长负责做决策、调动资源、看执行结果，出了岔子还得临场应变。矿山要的不是一个军师，是一批能自己去干活的连长。

想清楚这一层，后面的架构设计就顺了：先别急着买算力、别急着训练模型，先想清楚哪些环节需要感知、哪些环节需要思考、哪些环节需要行动，然后去找工具把它们串起来。这就是AI智能体在矿山行业落地应用的第一性原则。

2. 从0到1的架构设计：三个场景、一套底座、一次选型踩坑记录

2.1 先划边界：不碰“透明矿山”那种大命题

接到任务的时候，领导的意思是“把AI用起来，建设智慧矿山”。这个概念太大，自动驾驶矿卡、井下机器人、数字孪生、无人值守，什么都能往里装。我跟团队花了很多力气做了一件事：把场景收敛成三个——安全巡检、设备预测性维护、生产调度辅助。

为什么是这三个？第一，它们都是高频、高价值、强规则的场景，AI介入之后效果看得见摸得着。第二，它们的数据基础相对好，起码有摄像头、有传感器、有工单系统。第三，它们不涉及直接控制生产设备——所在矿对“系统自动操作提升机”这种事极其保守，不是说技术上做不到，是出了事故责任界定太麻烦。所以智能体先做“辅助人”的事，不做“取代人”的事。

选场景的时候有一个原则可以分享：优先选“老师傅凭经验能做好、但新人做不好”的事，而不是“连老师傅也头疼”的事。前者说明里面有可提取的知识，AI有得学；后者往往连规则都说不清，AI进去也是抓瞎。

2.2 平台选型：从自建到扣子工作流，再到生产级组合

2026年再看国内AI智能体市场，工具已经多到眼花。主流的路线有三条：一是通用智能体平台，比如扣子这类产品，适合快速搭工作流做原型验证；二是开源Agent框架，适合技术团队深度定制；三是各家云厂商的智能体服务，优点是跟自家云生态绑定，开箱即用。

我在这项目里走了不少弯路。最开始技术团队兴致勃勃用开源框架从零自建，底层接DeepSeek的模型API，做了几轮对话和工具调用，跑通是跑通了，但进度非常慢——权限管理要自己写、知识库要自己管、前端要自己搭，光是把一个巡检告警流程跑通就花了两周。后来换了个思路：用扣子这样的工作流平台做原型验证——拖拽节点、配置提示词、接数据源，一天就能出一个版本给业务方看。原型阶段用平台工具，效率差距确实是数量级的。

但原型跑通不代表生产能用。生产环境有几个硬要求：所有操作要留痕、告警要分级、知识库要能溯源、系统出问题要能快速定位。通用平台在这些方面确实方便，但也存在厂商绑定问题。最终架构是组合拳：底层模型用DeepSeek（中文能力强、推理靠谱、支持私有化部署），工作流编排保留扣子验证过的逻辑，生产环境切到私有化部署的Agent框架，接上矿里自有的统一身份认证和工单系统。一句话总结：平台负责“跑得快”，代码负责“跑得稳”。

2.3 工作流搭建的本质：把老师傅的脑子翻译成流程图

很多朋友问：智能体工作流到底怎么搭？我给过一个很朴素的答案：你别把它想成写代码，你想成“采访老师傅”。

比如说皮带跑偏该怎么处理。我先去找干了十五年的设备班长，问他：皮带跑偏了，你第一步干什么？他说先看跑偏量，一点五厘米以内调整托辊，超过三厘米要停机检查。我再问：你怎么知道跑偏量？看摄像头或者现场传感器。又问：调整完怎么确认？跑偏传感器恢复、运行半小时后再巡检确认。这些问题全问完，一个工作流就出来了：感知层（取图像和传感器数据）到判断层（跑偏量阈值加图像判断）到决策层（查SOP知识库匹配处置方案）到行动层（生成工单、通知检修班、跟踪闭环）。每个节点一条规则，每条规则背后对应一段老师傅的经验。

这个过程里最耗时间的不是拖拽节点，是把模糊经验变成确定逻辑。老师傅说“差不多就调一下”，你得追问“差不多是多差？调一下是调多少”。有些东西老师傅自己也说不清，那就让他现场演示两遍，把动作拆成步骤再做成规则。AI落地的价值七分在流程梳理，三分在模型算法，这句话我们项目组一直挂在嘴边。

2.4 数据接入与知识库：藏在设备里的“脏数据”没那么好治

工作流画得再漂亮，没有数据就是空中楼阁。矿山的数据情况，用四个字概括：脏、乱、缺、孤。

脏——传感器漂移、灰尘遮挡、电磁干扰，数据里各种异常值。乱——PLC时间、摄像头时间、数据库服务器时间各走各的，同一个事件三方时间戳能差出好几分钟。缺——井下网络不稳，数据断传、乱序、重复传输是家常便饭。孤——自动化系统、MES、设备管理系统各管一摊，根本没有统一的设备编码，同一个提升机在三个系统里叫三个名字。

这块没有捷径，老老实实建三样东西：统一时钟（一台内网NTP服务器，强制所有采集设备对时）、统一设备树（从设备台账反推一套全局编码，要求所有系统对接时映射到这套编码上）、边缘缓存（采集终端本地缓存，网络恢复后按序补传）。做数据治理那两周是整个项目最枯燥但最值的部分，后面智能体每次调用数据不再打架，全靠当时的底子。

知识库又是另一摊事。我们把操作规程、设备手册、历史故障案例、检修记录做了一次结构化清洗，按“设备-部件-症状-处置”四要素打标入库。这一步做到位，后面设备维护智能体每次给的处置建议都有据可循，领导审查时能一条条追溯到原文。

3. 三个落地场景的实战拆解：从安全巡检到多智能体调度

3.1 场景一：安全生产巡检智能体——把“人盯人”变成“系统盯人”

矿山安全巡检是个苦活。重点区域要求每两小时巡检一次，一趟走下来四十分钟，半夜那一班最容易走马观花。以前的做法靠安全员抽查加监控回放，发现问题再回去翻录像，等找到责任人，黄花菜都凉了。

我们的设计思路是：摄像头加边缘计算盒子在井下做实时画面分析，识别未戴安全帽、闯入危险区域、违规操作等行为，把结果以结构化事件推送上来；上层的安全巡检智能体拿到这些事件后，第一件事不是直接报警，而是去查这个区域、这个班组、这个时间段的上下文——是不是检维修时段？是不是有临时作业审批？如果确认异常，就按规则等级分发：一般违章推给值班安全员，严重违章直接推给矿长办公室并生成整改工单，同时把现场图片和事件链截图一起带上。

这个场景最出彩的是“告警联动”而不是“告警本身”。识别出违章只是第一步，智能体还能自动检索对应的安全规程条文，把“违反了哪一条、该怎么整改”一并推给负责人；整改完成后，责任人拍照回传，智能体再做一次复核确认，形成一个完整闭环。现场安全检查从“人盯人”变成了“系统盯人加AI盯整改”。

实测效果简单说说：违章识别响应从以前的按小时计变成按秒计，单区域巡检人力下降三成左右，更重要的是夜间和偏远区域的遗漏明显减少。但前提是——你得先把识别的误报率压下去，这个坑后面专门讲。

3.2 场景二：设备预测性维护智能体——用一次提前预警“收服”老师傅

设备维护是矿山最期待的环节。提升机、主通风机、破碎机，随便一台非计划停机，链条上的生产全部停摆，一天的损失顶得上好几个工程师的工资。以前维护靠两种手段：周期性保养加故障后维修，全是被动应对。

预测性维护智能体的架构分两层。底层是时序分析：在关键设备上加装振动和温度传感器，用时序模型学习正常运行数据的分布，当新数据偏离分布超过阈值时给出“异常分数”。但光有异常分数不够——矿上老师傅看一眼波形就知道是轴承坏了还是齿轮磨损，机器只有分数，不知道怎么处置。第二层就是智能体的工作：拿到异常分数后，去知识库里检索这台设备的历史故障记录和厂家手册，把可能原因、检修方案、所需备件、停机时间预估整理成一份“处置建议单”，推给设备主管。

这里有个细节值得讲：为什么非要叠加智能体而不是直接告警？因为维修是有代价的，乱停机比不停机更伤生产。智能体不是一检测到异常就喊“赶紧停机”，而是综合判断严重等级、备件库存、当前生产负荷，给出一二三级建议：一级继续观察、二级安排计划检修、三级才建议立即停机。判断依据全部取自知识库，有据可查。

这个场景真正立住，靠一次真实的“收服”时刻。系统投运一个多月，老师傅们大多将信将疑。有天凌晨，系统对主通风机给出二级预警，建议白班安排计划检修。值班工程师将信将疑地带着测振仪去测——果然轴承早期磨损，拆开检查发现保持架已经出现裂纹。老师傅的反应是：“这玩意儿真能提前看出来？”从那天起，老师傅不再说我们搞花架子了，反而开始主动往知识库里补充经验。这个故事我逢人就讲：AI在传统行业落地，一次实实在在的提前预警，比一百页可行性报告都管用。

3.3 场景三：生产调度辅助智能体——多Agent协作的初次尝试

前两个场景都是单智能体，调度场景我们做了一次多智能体协作的尝试，这在矿山行业里相对少见。

采矿调度的复杂性在于交叉约束特别多：生产计划要完成掘进量，车辆要把矿石运到碎矿站，安全员要控制井下车速，维修班要占用某个时段检修设备。以前调度员每天早上抱着对讲机喊，一场突发变化，比如某台铲车故障，整天的计划全乱，调度室一上午都在打电话。

我们的方案是让四个智能体各管一段，然后通过共享任务板协作：生产调度Agent负责分解当日计划；车辆管理Agent负责派车和路径规划；维修Agent负责设备状态变化；安全Agent负责规则约束，比如弯道限速、错峰交接。任何一个Agent发现变化，把事件写到共享任务板，其他Agent读取后重新评估自己的方案，有冲突就按优先级协商——比如安全约束永远优先于效率目标。这套机制受益非常明显：突发异常时的排程响应从半小时压缩到五分钟以内，调度员从“到处打电话”变成“看板确认”，工作量肉眼可见地降下来了。

做多Agent协作的时候我认真琢磨了两个原则。第一，不要让一个大模型去扮演所有角色，那样协作出不来，反而容易人格分裂；每个Agent用不同的系统提示词和知识库，各管一摊，比一个全能Agent更牢靠。第二，Agent之间的交互用消息和结构化数据，不要用自然语言对话——自然语言在机器之间传递效率太低，还容易产生歧义。这两条原则到今天都在沿用。

4. 踩坑实录：从实验室Demo到井下真跑，我们迭代了三版方案

4.1 幻觉问题：压不住就不许上线

前面说过把“主通风机”识别成“局部通风机”的事，那是压力测试阶段最惊险的一次。后来复盘定位了整个链路：先在日志里发现模型的回答里设备型号字段可疑，再回溯到提示词，发现知识库检索时关键词匹配把两款设备的维保手册都召回了，模型综合信息时张冠李戴。问题根源不是模型变傻了，是检索给了它让人混淆的信息。

最后用了三重防幻觉机制，这是从demo到生产的关键一跃。第一层是知识库限定检索：所有面向设备维护的查询，先走设备树字典，把查询绑定到具体设备编码上，检索只返回该编码对应设备的知识，不给模型跨型号发挥的空间。第二层是输出校验：模型的输出必须包含设备编码、知识库来源编号、置信度三个字段，程序自动用知识库原文比对关键实体——比对不过就拒绝输出，转人工。第三层是分级人工复核：一级建议自动放行，二级和三级建议必须由设备主管在系统里点确认才会派发工单。这套机制上线后，设备维护场景的幻觉相关投诉几乎清零。

我特别想跟同行分享的排查思路是：遇到幻觉不要拍脑袋改提示词。正确路径是——先把出问题的对话日志和检索记录完整导出来，看模型到底“看到了什么”，再决定是提示词的问题、知识库的问题还是检索逻辑的问题。我们那次就发现根本不是提示词写得不好，是知识库检索召回了不相关的设备手册，改提示词一点用没有。

4.2 数据之脏：时间戳错位导致“半夜报警”的诡异乌龙

系统联调期间出过一个特别磨人的问题：每天凌晨两三点，设备振动数据偶尔会触发一次异常告警，白天什么事都没有，晚上就“闹鬼”。排查了整整两天，一度怀疑是不是真有“幽灵振动”——数据曲线看过去，波形确实异常，像是被拉伸过。

完整排查链路是这样的：第一步，把异常时段的数据抽出来画曲线，发现频谱确实不对；第二步，怀疑传感器本身故障，但同一时间段的原始数据人工回放，波形又是正常的；第三步，对比PLC时间戳和数据库入库时间戳，发现整整差了三分半——原来是边缘网关在断网恢复后按自己的时钟补传数据，乱序的包按接收时间而不是采样时间入库，导致波形被重组，出现瞬时“伪异常”。最后统一了采集端NTP时钟，补传逻辑改成按采样时间戳排序入库，“幽灵振动”不治而愈。

这个坑教会我一件事：矿山做AI，前提是数据的“时间秩序”必须干净。算法再强也架不住时间戳错位，看着是AI的锅，根子上是数据治理的锅。项目启动时宁可多花两周把时钟、编码、补传逻辑理顺，也别急着往模型上堆功能。

4.3 井下算力与网络：边缘听哨、云端思考

矿山井下环境比机房恶劣太多：高温、高湿、高粉尘，光纤平时还算稳定，但一遇到检修、爆破作业，通信中断也是常事。我们的架构原则后来总结成八个字：边缘听哨、云端思考。

实时性要求高的环节，比如安全帽识别、皮带跑偏检测，必须在边缘侧完成，因为网络往返经不起一秒钟的中断。做法是在井下配电硐室部署边缘计算盒，跑轻量化的目标检测模型，只上传结构化事件。需要大模型深度推理的环节，比如设备故障原因分析、检修方案生成，才调用井上云端的大模型接口。网络抖动怎么办？定了一条红线：断网期间智能体只做“提示”不做“动作”，把告警积压到本地，恢复联网后补发；严禁在通信不稳定时自动执行任何控制类操作。矿山这种场景，宁可漏报也不乱动，安全永远排在效率前面。

4.4 组织阻力：老师傅的信任比模型参数难搞

最后一个坑，不是技术问题，但比技术问题更致命。系统刚上线那阵，老师傅们处于一种“不反对也不使用”的状态，问起来都说“行行行，挺好的”，回头该咋干咋干。在矿上待久了才琢磨明白，他们不是抵触AI，是怕自己被AI替代，更怕AI乱指挥出事故算谁的。

破局的办法说穿了也简单：让老师傅变成系统的“知识贡献者”和“验收者”。请了矿上最有威望的机电副总工当知识库顾问，系统里每一条处置建议都标注“知识来源：张工，2025年某月提供”，培训时直接让张工讲“这条规则为什么这么定”。把老师傅的经验变成系统的一部分，再把荣誉还给他们。这一招非常管用，后面老师傅们开始主动提需求，甚至开始维护自己负责的那部分知识库。AI落地矿山，技术占一半，人心占一半，这话一点都不虚。

5. 效果数据与成本账：老板问“到底省了多少钱”

5.1 指标怎么定：别拿对话评测那套用在工业一线

智能体上线后，老板第一个问题永远是“效果怎么样”。但矿山场景的效果，不能拿“答对了几道题”来算，得按业务指标来。

我们最终定了三套指标。安全巡检场景看“有效违章识别率”和“告警闭环率”：模型识别出来的违章事件里，经安全员复核确实违规的比例，从最初不到六成，通过数据清洗和规则收敛，爬到了88%左右；告警闭环率（从发现违章到整改确认完成）从以前的一到两天缩短到平均4小时。设备维护场景看“预警提前量”和“误报率”：提前量指报警比故障实际发生早多少时间，目标是不小于24小时；误报率控制在15%以内，太高老师傅会麻痹。调度场景看“异常响应时长”：突发变化后完成新排程的时间，从30分钟压到5分钟以内。

这里多说一句，行业里做AI应用评测，可以参考头部产品的指标口径。比如华为云那个码道检视修复智能体，对外宣传召回率做到91.3%，这个数字背后有完整评测集支撑，含金量不低。我们的场景跟他们不一样——他们是代码检视，我们是设备告警，没有可比性，但至少说明一个道理：认真建评测集、用硬指标说话，才是AI智能体获得信任的正道。靠几页PPT是过不了老师傅那关的。

5.2 算一笔账：投入产出比到底怎么样

钱这块说点实在的。项目总投入粗略分四块：边缘计算硬件占四成，传感器改造两成，算力租用和模型调用两成，实施和开发人力两成。一次性投入加上半年试运行，是一笔不小但也不算吓人的数字。

产出端算的是三笔账。第一笔，非计划停机损失减少——投运后预测性维护成功预警了三次潜在故障，避免了至少两次非计划停机，单台核心设备一天停机的损失，就能覆盖项目不少成本了。第二笔，巡检人力优化——安全巡检智能体上线后，人员不再需要保持高频全覆盖巡查，人力释放约三成，这些人转去做更精细的点检和保养，老板看着也开心。第三笔，安全与合规价值——违章事件从发现到闭环的时间大幅缩短，这种事没法直接算钱，但矿山行业的人都懂，一旦出了事故，损失绝不是钱能衡量的。

汇报的时候，建议把第一笔和第二笔算成真金白银，第三笔讲清楚价值逻辑就行。别把AI吹成万能钥匙——如果老板问“能不能不用人了”，标准答案是“不能，但能让同样的人干更多更有价值的事”。

5.3 一套可以复用的“向上汇报”方法论

最后分享一个经验。去跟矿领导汇报，别堆技术名词，讲三件事：原来什么样——事故率、停机损失、人力投入；现在什么样——用前面那几个硬指标讲；为什么稳定——知识库可溯源、三重防幻觉、人工复核兜底。把这三件事讲透，领导心里的疑虑基本就消了。同行想在其他行业复制这套打法，逻辑是一样的：先立样本，再用数字说话，最后把信任体系搭起来。

6. 中年龙虾的下一步：从单点智能体走向矿区智能体网络

6.1 智能体之间的协作还会继续深化

现在的三套智能体各管一摊，中间靠共享任务板协作，其实还是初级阶段。下一步的设想，是把安全、设备、生产、调度、能源五个领域的智能体全部接入统一事件总线，任何异常事件进来，相关智能体自动触发联动预案。举个例子：设备维护智能体检测到某台破碎机需要计划检修，自动通知生产调度Agent调整供矿计划，同时通知安全Agent评估检修作业风险，并把检修工单派给维修班——整个链路不再需要人来回传话。这件事技术上不难，难点在组织流程的重新梳理，走得慢点没关系，方向是确定的。

6.2 知识资产化：把老师傅的“脑子”变成矿上的数字资产

我越来越觉得，这套系统最大的价值不是几个智能体，而是知识库——它把分散在老师傅脑子里的经验，逐步变成了矿上可查询、可追溯、可持续更新的资产。老师傅总有退休的一天，但他们的经验可以以知识条目的形式留在系统里，新来的年轻人遇到问题，智能体会把老前辈的处置思路原原本本推给他。这次项目做下来，对“知识管理”四个字有了完全不一样的理解：以前KM系统为什么失败？因为知识录进去就死掉了。现在知识被智能体每天调用、每天验证、每天更新，它是活的。

6.3 给同路人的六条建议清单

最后把这次落地最值钱的六条经验汇总一下，给想往这个方向走的同行一个参考。

1. 场景选择：先做“老师傅能做、新人做不好”的辅助类场景，别上来碰无人化。
2. 平台选择：原型阶段用扣子这类工作流平台快速验证，生产阶段再谈私有化和自建。
3. 数据优先：先花两周治理时钟、编码、补传逻辑，比优化模型参数值钱得多。
4. 防幻觉机制：知识库限定检索、输出校验、人工复核，三层缺一不可。
5. 信任先行：让老师傅当知识贡献者，把他们的名字写进知识来源。
6. 指标说话：建好评测集，用召回率这类硬指标汇报，不用形容词汇报。

做这个系列，起因其实很简单——一个四十多岁的中年人，在矿山信息化这行干了小二十年，眼看着大模型和智能体把整个行业搅了个底朝天，想把自己踩过的坑、试对的路子记下来。如果这些经验能让某个同行少走两步弯路，那就值了。

下一步的“中年龙虾养成记（三）”，大概率会聊智能体知识库的深度运营，或者边缘算力在矿山的更细用法，还没完全想好。要是你也在折腾传统行业加AI，欢迎在评论区聊聊你的现场情况，咱们互相取取经。