工业智能体开发实战：大模型赋能制造现场的新范式

很多做制造业信息化的朋友这两年应该都有一个共同感受大模型相关的概念铺天盖地但真正能在车间、工段、日常巡检和工艺分析里用起来的东西反而不多。我一开始也觉得“智能体”离工业现场太远毕竟一张报表、一条工单、一个报警都要严谨哪敢让一个会“脑补”的模型乱来。后来跟着团队做了几个实际项目才慢慢想明白关键不在于模型多聪明而在于给它划好边界、接通工具、喂对数据。这篇文章不聊空洞趋势直接把“大模型赋能工业”语境下的智能体开发新范式拆开讲清楚包括它是什么、怎么起步、怎么搭、怎么避坑。无论你是设备工程师、工艺员还是刚开始接触代码的IT同学都可以照着思路自己动手试一把。1. 先搞清楚工业智能体到底是个什么东西1.1 一个直观的定义我习惯用一个比方来解释什么叫智能体传统自动化像一条固定轨道的传送带每一步动作都提前写死换个场景就得重新铺轨道大模型本身像一个聪明但没下过车间的实习生懂很多知识却容易慌张容易自说自话。智能体做的事情就是给这个“实习生”配上一本操作规程、一套趁手工具和几条不可逾越的铁律让它接到一个自然语言指令之后自己去查资料、调接口、算数据最后给出结论或者执行动作。所以工业智能体不是一个新的算法也不是单纯的聊天机器人而是一套“模型 工具 数据 控制规则”组合出来的系统。它的核心价值在于把过去需要人翻手册、查工单、问老师傅才能完成的经验判断变成一种可以7×24小时响应的数字服务。1.2 和普通聊天机器人、自动化脚本有什么不一样很多人会把智能体和聊天机器人搞混我刚开始也会。两者的差别其实很明显聊天机器人主要做“对话”你说一句它回一句上下文可能都记不住更别说帮你办成一件事智能体则强调“闭环”它要在一个任务里进行拆解、调用API、读取结果、判断是否完成必要时还要向人求助。工业领域原本也有大量自动化脚本比如定时抓取设备数据、生成报表、发告警。但这些脚本的缺点是规则刚性、不支持自然语言交互业务人员想临时查一个“上周三夜班3号产线有哪些异常”得等开发改代码。智能体补上的正是这一层把自然语言理解能力和已有的系统能力拼在一起。为了更直观我画过一张对比表平时讲给新人听实现方式交互方式能否跨系统办事现场落地难点对话机器人一问一答弱通常只查知识库容易出现答非所问难以追溯依据固定脚本表单/按钮强但写死流程改动成本高业务人员用不起来大模型对话助手自然语言中能生成SQL/文案结果不稳定需要人工复核工业智能体自然语言工具调用强可查询可写入需要做好数据、权限、评估三件事1.3 为什么“新范式”这个词现在才成立我在一些人面前提智能体对方第一反应是这不就是以前做过的专家系统吗确实逻辑上有点像但有一个根本变化过去专家系统要靠人来总结规则每条规则都要写成if-else覆盖几百条规则已经非常痛苦现在大模型可以把大量文档、手册、历史工单压缩成一种概率化的“常识”再通过工具调用把实时数据引进来让系统既懂经验又有现场依据。另一个原因是工业软件本身的成熟。过去很多工厂的设备、物料、工艺参数都只存在于Excel表甚至老师傅脑子里系统接口匮乏。这几年设备联网、数据中台、API网关逐渐普及等于给智能体铺好了插座。智能体这个概念热起来不是因为模型突然万能而是因为“数据可访问、接口可调用、算力成本可接受”这三件事同时发生了。2. 小白上手的完整路径从选型到跑通第一个Demo2.1 先定场景再谈技术我见过不少团队一上来就讨论用什么模型、上不上私有化结果聊了一个月还停留在PPT。后来我们总结出一条经验先用一周时间选场景场景选对了后面的事情全是水到渠成。适合智能体落地的工业场景通常满足四个条件频次高每天都有大量重复性问题比如设备报修、工单查询、质量异常初判。单点价值清晰一次帮忙能省几分钟到几十分钟乘以频次就是可量化的收益。结果可复核模型给出的答案能被人快速验证错了不会造成太大损失。风险边界可控不直接接触会造成设备损坏或人身伤害的动作。拿设备巡检场景来说一线运维人员经常要回答“某型号泵的润滑油规格是多少”“这个故障码之前出现过吗”“备件库存还有多少”。这种问题既依赖文档也依赖实时数据非常适合智能体。反过来如果一上来就让智能体直接调整温度曲线、修改PID参数风险就太大了不建议新手尝试。2.2 选型三件套模型、编排方式、数据存储选型永远是为了服务场景不是为了追新。模型获取方式上我建议新手按这个顺序考虑先用云端模型接口跑通业务逻辑确定这个场景真的有价值之后再评估是否要私有化部署。很多工厂担心数据安全这确实重要但更稳妥的做法是先做数据脱敏和权限隔离让敏感数据不出内网文档类知识先用通用接口验证效果。等到验证完毕再花预算采购GPU服务器或者一体化设备避免一上来就盲目买卡。编排层是智能体的骨架。如果你完全不会写代码可以选低代码/无代码平台通过拖拽节点把“意图识别、知识库检索、API调用、规则判断”串起来先跑通闭环。如果你有代码基础用开源编排框架或直接自己写一套任务调度也行。我的建议是不要让编排依赖某一个特定品牌的模型接口最好做成可替换因为模型迭代速度太快绑定太死反而难受。数据存储也需要提前想清楚。工业领域最常见的组合是向量数据库放非结构化知识关系型数据库放实时数据和业务记录再加一个对象存储放原始文档。前期不需要搞复杂架构一台普通服务器甚至一台开发机就能同时跑起这些服务。2.3 构建最小可用数据闭环工业智能体的效果一半靠模型一半靠数据。很多Demo失败的原因不是模型不行而是数据没有组织好。第一步是盘资产。把工厂里已有的操作规程、维修手册、历史工单、质检报表、备件清单全部列出来标记格式、更新频率、存在哪个系统。这一步很土但决定了后续能接多少知识。第二步是清洗。原始PDF经常是扫描件表格会错位图片里的文字提取不出来。我们常用的办法是通过OCR识别扫描页再人工抽检关键页对于表格优先转成结构化数据而不是硬读成纯文本对于长文档保留章节层级防止切碎后丢失上下文。第三步是切片和向量化。切片不是简单地按字数切而是尽量按照章节、段落、表格边界来切。切片之后要给每段补一个摘要字段方便后续召回。向量化之后一定要做召回测试拿20条真实问题去检看前5名召回结果是否包含正确答案不包含就调整切片策略或改成混合检索。第四步是建立反馈通道。智能体上线后每次回答让用户点“有帮助/没帮助”把错误样本收集回来定期重跑评测。这个闭环越早做系统进化越快。2.4 快速跑通第一个Demo的节奏给新手一个可复制的四步走节奏单次周期控制在三天以内第一天接一个大模型接口把3到5份核心文档切片、向量化做一个“只读知识问答”雏形。目的不是追求准而是打通链路。第二天接一个业务API比如设备主数据查询或备件库存查询让智能体在回答中带上实时数据。这一步会体会到什么叫“工具调用”。第三天加上边界处理比如“信息不足时明确说不知道”“越权操作被拒绝”并准备10条测试用例做回归。我印象很深刻的一次是我们用一台普通的办公电脑两天半就做出了一个备件查询助手。虽然界面很粗糙但老师傅试用的时候说“这个比查Excel快多了”。那一刻你就会明白跑通Demo的意义不在于展示而在于让使用的人看到可能。3. 一个能落地的工业智能体解剖模拟质检助手3.1 场景与目标为了把抽象概念讲得更具体这里用一个模拟项目做解剖某工厂想在质量科部署一个“质检异常初判助手”。一线质检员每天要面对几十条产线报上来的检测数据一条数据超差就得翻工艺卡、查历史批次、找工程师确认。流程熟练的老员工也需要五分钟新员工往往无从下手。这个智能体的目标很朴素质检员在系统里输入异常描述或检测参数。智能体自动关联工艺标准、历史同款异常处理记录。给出“可能原因排序”和“建议检查步骤”。如果查不到足够依据必须明确说“信息不足”而不是瞎猜。我们不要求它直接下结论“该批次报废”因为那涉及质量判定责任超出了它的安全边界。它只做初判和推荐最终决定仍然由人来拍板。3.2 系统架构与关键模块这个项目的架构大致可以分成四层我列出来供大家参考层级承担职责典型组件接入层接收用户输入展示结果质检工作台、企业IM大脑层理解意图、拆解任务、生成回复大模型接口/本地模型服务知识层存储工艺卡、历史记录、质量标准向量库、关系库工具层查询实时数据、写入工单质量系统API、设备主数据API在这些层级外面还套了一个控制层专门负责权限判断、敏感操作拦截和审计日志。即使是最简单的Demo我也建议大家保留这个控制层的概念哪怕前期用配置文件硬编码权限白名单也好过后面补安全漏洞。3.3 核心提示词与工具调用示例下面是一段我常用的系统提示词模板你可以直接改成自己业务的版本你是一名质检异常初判助手你的使用对象是工厂质检员。 你的职责 1. 理解用户输入的异常现象或检测参数 2. 先从工艺标准库中查找对应标准范围 3. 再从历史异常记录库中查找相似案例 4. 输出内容包括可能原因列表、建议检查步骤、参考依据来源 5. 如果知识库中没有足够信息直接回复“当前信息不足”并建议人工找工艺工程师确认。 安全铁律 1. 不得给出判定成品合格或不合格的最终结论 2. 不得尝试修改任何检测设备参数 3. 不得编造不存在的案例编号或标准条款。工具调用的设计也很重要。模型本身不直接连接数据库而是通过一套带描述的函数列表来决定要不要调用工具。下面是一个简化后的主循环示意代码# 伪代码演示一个智能体的核心循环 def run_agent(user_input: str) - str: # 1. 构造对话记录 messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input} ] # 2. 调用模型让它决定是直接回答还是调用工具 response call_model(messages, toolsTOOL_LIST) # 3. 如果模型请求调用某个工具 while response.get(tool_calls): for call in response[tool_calls]: tool_name call[name] tool_args call[arguments] # 权限校验不在白名单内直接拒绝 if not is_allowed(tool_name): messages.append({ role: tool, content: 无权限调用该工具请向用户说明。, tool_call_id: call[id] }) continue # 执行工具查询 result execute_tool(tool_name, tool_args) messages.append({ role: tool, content: result, tool_call_id: call[id] }) # 4. 把工具结果交回模型生成最终回答 response call_model(messages, toolsTOOL_LIST) return extract_final_answer(response)工具列表的写法也有讲究。每个工具要写清楚名称、用途和参数结构让模型自己能做选择。示例[ { name: query_standard_by_product, description: 根据产品编码查询该产品的工艺标准和检测限, parameters: { product_code: string, parameter_name: string } } ]这块没有太多黑魔法核心就是不厌其烦地把工具描述写清楚。模型对模糊工具名的判断能力有限不要指望它猜出“query_inventory2”是什么意思。3.4 如何评估不是“看起来聪明”就行我见过不少团队看智能体演示觉得惊艳一到生产环境就翻车根源就是没有定义“什么是好的答案”。工业场景必须把评估指标前置。我们用的评估方式是从历史工单里抽取50条真实异常记录人工标注出标准答案然后让智能体在离线环境跑一遍。统计几个维度召回率标准答案中的关键信息是否出现在模型回答里。准确率模型给出的建议是否和人工判定一致。拒答率信息不足时是否老实承认而不是编造。超时率回答是否在5秒内返回超过10秒基本不可用。不要只看准确率拒答率同样重要。有时候模型为了迎合用户明明没有资料也要硬答这在工业现场是最大的风险。我们当时定了一个原则宁可不答不可错答。评估通过之后再做小范围灰度让5名质检员试用一周收集意见后再推全场。4. 工业智能体落地中躲不掉的坑与对策4.1 数据坑文档切碎不等于知识可用工业文档看起来很多真正能直接喂给模型的却没多少。最常见的三个数据坑分别是扫描件与照片图纸、手写记录、老旧工艺卡全是图片必须走OCR但OCR对公式、表格、手写体的识别准确率不稳定。建议先做小范围抽检识别准确率高于95%再批量处理。版本混乱同一份工艺标准可能同时存在V2、V3、V4如果切片时不处理好版本模型可能把旧版标准当成现行标准回答。需要加“当前有效”标记检索时优先返回有效版本。专业缩写工业里到处是行话同一个缩写在不同车间含义不同。模型回答时如果不带上下文很容易产生歧义。这一步需要让懂业务的人提前做术语表并且把术语表也放到知识库中让模型先查术语再回答。我们还有个比较深的体会不要迷信“文档全部向量化”。很多表格和结构化数据更适合先解析成JSON存进关系库需要时让模型通过工具查询而不是把整个表格塞进向量库。混合检索要比单一向量检索稳定得多。4.2 幻觉与置信度让模型学会说“我不知道”大模型会一本正经地胡说八道这是所有工业项目绕不开的挑战。我的对策有三招第一招强制引用。在系统提示词里规定回答中涉及标准、案例、条款的地方必须标注来源编号没有来源的信息不允许写。这样虽然不能完全消除幻觉但至少能让用户追溯答案从哪里来错了也容易定位。第二招置信度兜底。如果向量检索返回的相似度分数不高就不要让模型强行作答。可以在编排层加一个判断最高分低于阈值时直接返回“未找到相关资料”。这个阈值需要拿真实历史数据去调不是拍脑袋定的。第三招冲突检测。当知识库里出现前后矛盾的内容时比如两个版本的工艺卡对同一个参数规定不同可以让模型把矛盾明确指出来而不是自行选择一边。工业场景里把矛盾暴露出来恰恰是对现场最有价值的帮助。4.3 权限与安全模型只能“建议”不能乱动工业智能体不能像通用助手那样用户说什么就做什么。我们接入工具层时固定执行“最小权限”原则。系统把所有操作分成三个等级只读操作查设备信息、查工单、查库存允许自动执行。非破坏性写操作创建草稿记录、生成报表可以在用户确认后执行。破坏性写操作修改设备参数、删除记录、发起审批流程必须走人工审批钩子。即使模型在对话里表现得很自信工具层也要独立校验权限不能只靠提示词约束。代码里的逻辑应该写死未在白名单中的API一律拒绝调用。所有工具调用都会生成审计日志记录谁在什么时间发起了什么查询方便事后复盘。4.4 性能与成本别让Token烧穿预算工业现场对响应时间有硬性要求一味堆长提示词和大量资料检索会让成本失控。模型的每次调用都是钱尤其是频繁把几百页资料塞进上下文费用会指数级上升。我们的经验是分级处理先把用户问题做一次意图分类简单查询走轻量模型复杂分析才走大模型。用缓存机制保存高频问题的答案相同问题不重复计算。检索结果限制数量一般取前5段即可不是越多越好。对长文档做摘要入库检索时先看摘要需要细节再取原文。这几点看起来简单实际节省的成本非常可观。印象很深刻的一次是我们只加了缓存和高频问题静态化月度调用费用就下降了约40%响应时间也从平均6秒降到2秒以内。5. 我给新手的几条实操建议和习惯5.1 从“记录型智能体”开始别一上来就上控制型我强烈建议没有任何经验的新手把第一个实验项目定位成“记录型”或“查询型”而不是“控制型”。查询型智能体做的是把信息找出来、整理好、交给用户模型答错了最多也就是信息不准确不会碰坏设备。先在这种低风险场景里积累经验再逐渐扩展到“建议型”最后再考虑半自动化操作。有些人会觉得这样不过瘾但我要说一句实话工业用户最看重的不是智能体“能干什么”而是“能不能稳定地干好同一件事”。一个只做备件查询、但做到99%可靠的小助手比一个什么都敢碰、三天两头出错的全能助手更受欢迎。5.2 提示词也要版本管理很多团队写提示词像在记事本里随手记改来改去最后自己都不知道哪版有效。提示词就是程序的一部分应该像代码一样管理。我自己的习惯是每个版本记录改动日期、改动人、测试结论。每次修改提示词都先在离线测试集上跑一遍回归确认各项指标没有明显回退再上线。真到了生产环境遇到“之前好好的、现在突然变傻了”的问题回头排查版本就能快速定位而不是一头雾水地猜模型又抽风了。5.3 灰度发布与现场应急回退智能体上线不用搞“惊险一跃”先影子模式跑一周再小范围灰度最后才全面开放。影子模式的意思是系统在后台模拟运行所有回答都记录但不直接呈现给用户让开发团队拿着结果和人工答案比对看准确率到底有多少。第二步是辅助模式只给少部分人试用回答前面加一句“AI辅助结果请人工复核”。最后再成为正式工具。同时必须设计应急回退按钮。一旦现场反馈变差可以一键关闭智能体的自动回复切回原来的工单处理流程。这个按钮看起来简单但没有它你很难说服车间管理者放心尝试新东西。最后再分享一点个人体会做了几个工业智能体项目之后我最大的感受是这个领域真正难的不是模型而是愿意花多少心思去理解现场的一线工作。最成功的几个场景往往是一线老师傅提需求、IT团队做实现、业务领导给支持的结果。智能体本质上像一个试用期员工你给它讲清楚流程、边界和工具它就能帮上忙你不教就让它自由发挥它就一定给你闯祸。所以下一次再听到“大模型赋能工业”的时候不用慌也不必过度迷信。找一个小场景用上今天说的这套方法把一个只能查备件的智能体跑通你离掌握这个新范式也就不远了。