矿山行业AI智能体实践复盘：从场景选择到成本ROI，传统行业如何避开落地深坑

先说个背景。我是“中年龙虾”，一个在矿山行业干了十几年的信息化老兵。这个系列的第一篇写了些杂事，基本就是记录一个只会改Bug的老头子，怎么被大模型这阵风刮得坐不住，开始吭哧吭哧研究提示词和工作流的过程。当时很多人私信问我，说你这套东西在矿山上到底能不能真落地，还是说就做几个Demo给领导表演一下。这篇文章就是回答这个问题的——AI智能体到底是怎么在矿山行业真正跑起来的，以及为了让它跑起来，我们踩了多少坑。

先把你可能会产生的好奇心摆出来：矿山这种地方，井下几千米深，设备又大又老，网络还经常断，数据乱七八糟，跟互联网公司玩的那套AI智能体完全是两个世界的东西。但我得说，恰恰是这种环境，AI智能体反而能发挥出它最独特的作用——因为这里太缺人了，太缺经验了，太缺能快速响应的人了。这篇文章就围绕我们团队在矿山落地AI智能体的完整过程，从选场景、搭方案、写工作流、处理数据，到应付人、算成本、跑运维，全盘拿出来晒一晒。适合矿业企业的信息中心同行、做工业互联网的集成商，以及所有想在传统行业里搞AI落地的朋友参考。

1. 矿山场景里，AI智能体到底盯上哪些活

1.1 先给矿山工作流“拍个X光片”

很多人一听“矿山行业的AI智能体”，脑子里冒出来的画面是机器人在地底下到处跑，或者是无人驾驶卡车在矿区飞驰。那种东西不是智能体，那是自动化系统，而且投起来没个几千万下不来。我们这次真正落地的，是那种更朴素、更“软”的AI智能体——它能听懂人话、能翻资料、能按流程办事、能帮人做判断的软件系统。

要把AI智能体放到矿山里，第一步不是选模型，而是搞清楚矿山日常运作里，到底哪些活儿是又累又烦又容易出错的。我调研了一圈现场，把一线真实工作流大致拍了个X光片：

• 生产调度：调度员每天接几十通电话，问的都是“三号铲车在哪”“今天夜班安排怎么调的”“破碎站还堵不堵”。这些信息分散在调度日志、微信群、Excel表格和个人脑子里。调度员嘴上说熟悉，但一旦遇到替班、新员工、紧急情况，整个人就开始翻聊天记录，找电子表格，效率极低。
• 设备维修：矿山设备种类多，同一个故障在不同工况下原因完全不一样。老师傅凭经验听声音摸温度能判断个大差不差，但年轻维修工只能对着厚厚的手册一页页翻，翻到天黑也不一定找得准。更麻烦的是，维修知识大量沉淀在工单备注里，厂家的技术手册动辄几百页，谁也记不住。
• 安全监控：这个是矿山最敏感的环节。监测系统每秒钟都在产生大量数据，气体浓度、粉尘、人员定位、车辆运行状态。值班员盯着几十块大屏，说实话人眼根本盯不过来，往往等报警了才知道出事了。报警信息也是一堆乱码式的编号，值班员还得先去查这个编号代表什么，等查明白了，黄金处置时间早就过了。
• 报表与总结：矿上每天、每周、每月都要写大量生产报表、安全总结、检修记录。这些东西七成内容都是格式化的，但就这点活，能让技术员加班到晚上十点。

这些场景摆出来之后你会发现一个共性——大量工作本质上是在“翻信息”和“做判断”，而不是在“操控设备”。这就为AI智能体留出了巨大的空间。矿山智能化喊了这么多年，大家一直把注意力放在设备自动化和远程控制上，反而忽略了管理流程里的知识处理和决策辅助才是最缺人的地方。

1.2 什么活适合智能体干，什么活不适合

我一开始也犯过贪大的毛病，恨不得把全套矿山业务都塞给智能体干，结果差点把自己干废。后来我总结出一个筛选判据，像我老板常说的：先开枪后瞄准是浪费子弹，先找准靶心再开枪才是省时省力。一个场景适不适合上AI智能体，我看四个条件：

• 高频：天天都有人问、天天都有人干，才值得投入。低频场景做出来没人用，没有孔雀开屏的机会。
• 规则相对明确：就算不能完全枚举，但逻辑边界是清楚的，比如故障排查虽然有千百种情况，但大方向是从现象倒推原因，再倒推处理方案。
• 依赖文档和知识积累：这类场景最怕“老师傅走了，知识也带走了”，AI智能体天然适合做知识沉淀和检索。
• 响应要求快：人翻手册要十分钟，AI检索要三秒钟，这个差距越大，使用意愿越强。

反过来，什么场景不适合？比如“让智能体直接控制提升机的启停”，这种涉及人身安全、责任边界极其敏感的操作，短期内压根不碰。智能体可以给建议、给预警、给操作步骤，但最后那个“点击执行”的按钮，必须留给人。这不是技术问题，是责任划分问题，出了事故追责的时候，智能体没法替你坐牢。还有那种数据基础几乎为零的场景也别碰，矿山很多设备压根没有联网数据，临时补数据采集，投入产出太不划算。

2. 方案选型与总体架构：没有弯道超车，只有土路慢跑

2.1 为什么没选自研大模型框架

做方案的时候，团队内部吵过一轮：有人说要用开源模型自己微调，搞一整套完全私有的AI体系；也有人说直接用市面上现成的API，省事。最后我们走了中间路线，但我还是想把当时决策的思考过程写出来，给同行一个参考。

自研大模型框架这事，听着很高级，但矿山行业的信息化团队普遍也就三五个人。我掰着指头算了一下：要微调一个行业模型，得先攒训练数据，矿山的数据不是没有，但散落在几十个系统里，格式乱七八糟，光清洗打标就得三个月；微调完还要做评测，做部署，做运维，做好之后大模型领域又更新换代了。这个周期和人力投入，是矿山信息中心承受不了的。而且说实话，矿山行业的业务知识变化没那么快，没必要让模型去记住所有东西，更需要的是让模型能准确地查到你喂给它的资料。这一点靠检索增强生成（RAG）就能解决大半。

直接调通用API也有顾虑，主要是数据安全模型。矿山的安全生产数据、设备参数、调度信息都属于企业内部敏感数据，直接传到外部模型接口，合规层面很难交代。后来我们选了可以私有化部署的模型底座，再加上一套自建的知识库和工作流平台，相当于把“脑子”和“记忆”都放在自己家里。

2.2 用“平台底座+知识库+工作流”拼出的落地框

最终落地的架构，我从上到下给你拆开看：

• 应用层：就是用户直接面对的东西，可以是调度室大屏上的问答框，也可以是手机上的企业微信机器人。
• 编排层：负责把用户的请求拆解成任务，决定调哪个知识库、跑什么逻辑、要不要转人工。这是AI智能体的“中枢神经”，我用工作流平台实现。
• 知识层：把矿上的规章制度、设备手册、历史工单、应急预案全部清洗、切片、向量化，存到知识库里，供检索调用。
• 数据层：对接矿山已有的调度系统、设备点检系统、安全监测系统。这一层最苦，往往需要写大量接口去抓数据，还要处理老系统数据格式混乱的问题。

这个架构的一个核心思路是：AI智能体像一个刚入职的实习生，脑子灵活但不懂矿山业务。知识库是给他看的培训资料，工作流是给他定的办事流程。模型本身会更新换代，但知识库和工作流是我们真正积累的资产。今天用这个模型，明年有更好的模型，把底座换掉就行，工作流和知识库还能继续复用。这个设计理念让我在后来升级模型底座的时候省了天大的力气。

2.3 安全边界与数据隔离怎么处理

矿山行业的网络安全等级保护要求摆在那里，生产网络和办公网络之间的隔离是原则性的问题。模型服务可以放在办公网侧，但调度数据、监测数据往往在生产内网里，两边不能随便打通。

我们当时的处理方式不复杂但很有效：单向数据同步+脱敏导出。生产内网的关键数据，经过审批流程后，以脱敏或摘要的形态单向同步到知识库和业务数据库里；办公网侧生成的指令和建议，一律只输出文本，不直接反写生产系统。说白了，AI系统只做“读”和“建议”，不做“写”和“控制”。这样做既满足了隔离要求，又让智能体能拿到足够的信息来回答问题。如果哪天真需要从办公网侧发起反写操作，也是生成一个审批工单，由值班员在指定的生产终端上执行。

这套边界规则，我觉得是矿山AI落地的生命线。谁要是图省事把内外网直接打通，出了事连补救的机会都没有，直接出局。

3. 三个真正落地了的智能体，实操复盘

3.1 生产调度问答智能体——从打电话到问一句就有答案

第一个智能体我们选的是生产调度问答，原因是它高频、纯软、不碰控制，试错成本最低。

知识库建设：我们把调度规程、各作业面生产计划、设备状态变更记录、常用应急预案全部整理成结构化文档，按章节切片。关键一步是给切片打标签，比如“采区-掘进-班组排班”“设备-铲运机-故障代码”，这样检索的时候能按标签做初筛，准确率高不少。这个过程花了大半个月，比建模型本身还费劲，但这一遍苦功夫值得下。

工作流设计：用户提问进来之后，先做意图识别，判断是问排班、问设备、还是问制度。然后根据意图去检索对应知识库，检索出来的片段交给大模型组织答案。同时接了一个兜底分支，如果检索置信度低于阈值，就自动转给值班调度员人工回复。这个兜底分支特别重要，它保证了系统不会胡编乱造，宁可说自己不知道，也不能一本正经地误导人。

参数设置：模型温度设的0.2，也就是几乎不做创造性发挥，回答风格尽量贴着知识库原文走。检索返回数量设的5条上下文，记忆长度控制在10轮对话。这些参数都是实测调出来的，并不是越高越好。

Prompt设计。这里我给出一个我们实际在用的核心模板，你可以拿去改：

你是一名矿山生产调度助理，服务于调度室值班人员。 请严格依据以下检索到的资料回答提问。资料不足时，明确回复“当前知识库中未找到相关信息，建议您联系当班调度长确认”。 回答要简洁，优先引用资料中的时间、地点、设备编号和责任人。 不要猜测，不要编造操作规程，不要输出与矿山安全生产相抵触的内容。

这段提示词里我特意加了“不要输出与矿山安全生产相抵触的内容”，看起来像废话，但实测下来它能显著减少模型在边界情况下的胡说八道。因为大模型对安全类表述是有基本的遵从意识的，你把“安全”这个词放在Prompt里，它在生成时会下意识更谨慎。

上线三个月后，调度员日均使用量稳定在80次左右，60%到70%的基础性问询不需要再打电话打扰别人。准确率这块我们没有搞太复杂的评测，就是让当班调度长每天抽10条对话打分，给了一个模糊指标：关键信息正确率95%左右，剩下5%基本是旧数据更新不及时导致的。

3.2 关键设备维修助手——把老师傅脑子里的东西倒出来

第二个智能体选的是设备维修助手，这个场景比调度问答难一个数量级，因为它涉及真正的专业判断。我的思路是：先别指望智能体能像老师傅一样听声辨障，先把它做成一个“能干的技术员”——能快速查到故障代码含义、能给出该型号设备的排查步骤、能调出同类故障的历史处理记录。这就已经很值钱了。

数据来源：历史维修工单、点检标准、厂家操作手册、报废设备档案。最麻烦的是历史工单，写的人五花八门，有的写“电机异响换了个轴承就好了”，有的写“处理了，好使了”，完全不具备结构化。我们让维修班组的老技师对着系统里的工单一条条审核，把有价值的经验抽出来，整理成“故障现象-可能原因-排查步骤-处理结果”四段式条目。这个人工整理的工程量很大，但是整个项目里性价比最高的一笔投入。

为了提升维修助手回答的实用性，我设计了让智能体“按步骤进行多轮追问”的逻辑。例如工人说“铲运机大臂举升无力”，第一轮先按知识库匹配出8种可能原因，然后不是一股脑全部甩出来，而是先问工况信息（冷车还是热车，带不带负载，举升时有没有异响），根据回答逐步缩小范围。这样既避免信息轰炸，也更有实战价值。你可能已经看出来了，这一步其实用到了最基础的决策树式工作流，但语言交互把它包装得特别像一个“老师在带徒弟”。

图片识别部分：我们一开始想让维修助手通过拍张照片自动识别设备故障部位，实测下来发现掉坑里了。井下光线差、角度歪、设备表面油污多，通用视觉模型的表现非常拉胯。后来把这个功能砍成辅助性质：工人可以上传照片，系统只做初步的设备铭牌识别和仪表读数记录，真正的故障判断还是靠文字信息。这里我想说句实在话：AI功能不是越多越好，不能用的功能坚决不硬上。

这套维修助手上线后，在试点矿区的维修工单平均处理时长缩短了约20%，最明显的改善是年轻维修工不再轻易打扰老技师了。老师傅从天天被问烦了，变成只在智能体判断不准的疑难杂症上出山。群众评价还算正面。

3.3 安全报警闭环智能体——让报警信息从“乱码”变成“人话”

第三个智能体选的是安全报警闭环管控，这个场景一开始是最被质疑的，因为涉及安全，大家普遍觉得AI不靠谱。但我们的切入角度很克制：AI不负责决策，只负责把报警信息变成人能快速看懂的东西，并辅助值班员完成闭环处置流程。

对接方式：从矿上的安全监测系统取实时数据流，接报警事件记录。这一层技术难度不高，真正难的是老系统的数据协议五花八门。有一台传感器设备的数据格式还是上世纪风格的十六进制文本，我们专门写了一个解析服务，转成标准JSON结构，再喂给智能体工作流。

事件分级规则：我设计了三类处理逻辑。一级事件（比如瓦斯浓度超限、人员违规闯入采空区）直接推送值班长手机，并生成包含处置步骤摘要的应急卡片。二级事件（比如设备温度异常升高但未超限）先让智能体去检索最近的运行数据和同类事件历史，自动补一段上下文说明再发给值班员，避免值班员还要自己去翻系统。三级事件（比如轻微离线、信号中断）则汇总成每班简报，不实时打扰，减少报警疲劳。

安全智能体的核心提示词又和问答类不一样，它更强调“格式即责任”。我们给每条报警生成的文本都强制带上数据来源、报警时间、处置建议和备注免责声明。值班员能不能看懂、能不能快速转述，是这套系统好不好用最直接的标准。

试运行头一个月，报警响应平均耗时从原来的约8分钟降低到约4分钟，其中很大一部分提升是因为值班员不需要再去查报警编号的含义了。这算是一个真真实实的提效，不是虚的。

4. 落地路上踩过的坑，一个个排

4.1 网络隔离带来的“取数难”

这个问题我从头到尾都在跟它搏斗。刚开始做数据对接时，开发团队按互联网产品的思路，准备直接调数据库接口拉数据，结果到了现场发现生产内网连接口都不让随便通。我们费了很大劲才搞明白边界，最终方案是使用隔离区加单向数据同步工具，每天定时推一次结构化数据到知识库侧，做了完整的审计日志。实时性肯定牺牲了一些，但对于问答和维修辅助这些场景，T+1的时效性完全够用。安全报警场景要求高一些，就用单独的窄带加密协议实时推报警事件，不推原始明细。

这里有个经验：做ToB传统行业项目，先问清楚网络拓扑和数据流向管理规范，再动手设计架构，千万別按互联网的思维去做。不然辛辛苦苦搭完的系统，过不了等保评测也是白搭。

4.2 检索效果差，不是模型笨而是切分太粗暴

测试阶段我一度怀疑大模型是不是太笨了，很多问题就是答不对。后来把检索结果拉出来一看，发现是知识库切片方式有问题。原来我把一份几十页的设备手册当整体向量化，检索的时候匹配到的是一片模糊的大段落，模型从里面提取不到准确信息。

解决方式如下：把文档先按章节结构做一级切分，再把超大段落按每300到500字做二次切分，设置200字的相邻重叠区。同时为每个切片保留标题路径和上下文，检索召回后先给模型看标题，再给正文。这样之后准头立刻上来了。Embedding模型我们也换了一轮，国产中文场景下，选了一个基于中文语料优化的向量模型，效果比通用模型好不少。后来又叠加了一层重排序，用粗排召回50条再用精排模型选前5条。整套操作下来，回答质量和响应速度才达到了能给人用的标准。

4.3 大模型一本正经地胡说八道，矿山最怕这个

矿山场景里胡说八道的后果远比客服机器人答错餐巾纸颜色严重得多。有一次测试安全助手，我故意问“瓦斯超限报警后，应该先处理什么”，模型回答了一条看似合理但完全杜撰的操作顺序。这要是值班员信了，那就是生产安全事故级别的问题。从那天起我立了几个铁规矩：

• 所有安全相关回答必须给出知识库引用来源，点击引用能跳转看到原文段落，如果没有引用，则在显著位置提示“回答未经知识库验证”。
• 置信度低于0.6时直接拒答或转人工，宁可答不上来，也不能蒙。
• 在Prompt里增加“无答案时可以拒绝回答”的授权，让模型觉得“承认不知道”是被允许的。

这三个规矩加上去以后，系统整体回答质量稳定了不少。我还是想跟你强调一下：在矿山这种行业，大模型的聪明远不如可靠重要。你哪怕每句话都答得慢一点、生硬一点，也千万不能让它给你编一个像模像样的错误操作流程。这个东西没有任何后悔药可以吃。

4.4 用人这件事比技术难十倍

项目刚启动的时候，矿上的老师傅们普遍冷眼旁观，觉得你们搞IT的就是给领导表演，回头还不是添麻烦。后来我们换了个策略——让老师傅当“知识库审核官”，凡是整理出来的维修经验，必须过一遍他的手，他说不行就不入库。这一下子老师们有了参与感。加上试点效果确实帮他们减少了重复性咨询，态度很快就转过来了，甚至还主动拉着我们补充了一些手册上没有的“土经验”。

领导那边的问题正好相反，是期望值太高。有的领导看了演示视频，以为AI什么都能干，甚至问能不能直接接个摄像头识别井下违规行为。我每次都得泼冷水，明确说哪些能做、哪些不能做、哪些要多久才能做。后来我发现，管理预期最好的方式不是嘴上汇报，而是拿出阶段性的交付清单：这周上线了什么、数据指标是什么、下周计划是什么。让领导看到明确的进度条，反而比承诺宏大远景更让他放心。

5. 账要算清楚：成本、周期与ROI

5.1 花了多少钱、多少人、多久

我不知道别的团队怎么报价，但我尽量把真实情况罗列出来，好让大家心里有数。

我们在试点矿的总体投入大约在一百万上下，周期约四个月。这个数字在矿山智能化的项目里真的不算大，矿山行业随便一套自动化控制系统就是几百万起步。关键就是你能不能用这个投入换来可量化的收益，而且这个收益必须讲给领导听。

5.2 汇报时怎么讲ROI

我给领导汇报的时候从来不讲技术细节，只算三笔账：

一是省人力工时。调度员每天减少查询和电话沟通的时间，按每人每天省出0.5小时，10个调度员一年省出约1300小时。矿山人力综合成本按每小时100到150元算，一年就省十几万。二是降非计划停机。设备维修助手让平均维修时长降了20%，按关键设备非计划停机每小时损失几万来算，一个月的维修提效就能覆盖掉这部分成本。三是安全效益。报警响应时间缩短4分钟，这个很难直接算钱，但对接安全绩效考核和事故风险规避，说大不大说小不小，领导向来愿意听这个。

这三笔账算下来，投入产出比只要超过1，项目就值得继续。很庆幸，我们这个试点项目周年总结时，数据是好看的。

最后说几句

AI智能体在矿山行业的落地，技术难度其实没有想象中那么大，真正的难点是它怎么融入一个已经运行了几十年的流程系统，怎么让一群习惯了原有工作模式的人愿意每天打开它。我的体会是，切入点一定要小、要窄、要高频。先让智能体在一个低风险、但大家每天都会碰到的场景里跑起来，用实际效果说服人，再逐步扩大它的职责范围。反过来你一开始就搞一个大而全的东西，大概率会死在落地前的最后一公里上。

这篇文章写到这里，第二篇就差不多停笔了。后面应该还有第三篇，我大概率会写写AI智能体怎么跟矿山的班组考核、培训体系结合起来，也可能聊聊更完整的行业知识库建设方法，到时候再说。大家在实际落地过程中如果有什么不一样的经验，欢迎随时交流。