在工业互联网平台这一行待了快十年我越来越觉得传统工业软件像一台功能齐全却不会主动说话的机床。AI Agent最近频繁出现在各种技术讨论里它最有可能改变的不是某个按钮而是工业软件与工业互联网平台生态里“人找系统”的底层关系。这篇文章会把我们团队从0到1落地工业AI Agent的完整过程连同踩过的坑、调过的参、拆过的需求一起写出来希望能给正在做同类事情的人一点参考。不管你是工业软件厂商、工业互联网平台的产品经理还是准备在企业内部做智能化改造的研发负责人这篇文章都值得看完。我会把它讲成一次真实的项目复盘为什么工业软件需要被重新定义AI Agent、LLM和AI模型到底有什么区别我们怎么选场景、选技术栈、做工具层又怎么处理权限、审计、幻觉和多智能体协作。内容偏实战不绕弯子。1. 为什么工业软件需要一次“角色重定义”1.1 封闭工具数据在系统里智慧在脑子里传统工业软件并不缺功能。CAD管设计MES管制造ERP管资源SCADA管监控每一套系统在自己的边界里都做得相当深。问题在于它们太“封闭”了一个设备维修工早上可能要同时打开MES填工单、SCADA看报警、文档系统查手册三个系统交互逻辑完全不同操作路径动辄十几个按钮。我见过一条产线的班组长宁可在微信群里发语音报异常也不愿意打开MES因为打开那个系统本身就是一个负担。数据其实都在系统里但智慧始终在老师傅的脑子里。工业互联网平台这些年做的事本质上是把设备、产线、工艺、质量数据连上来形成数据湖、数字孪生、指标看板。但平台本身还是“看板”它能告诉你设备振动曲线异常却不能告诉你下一步该干什么。老师傅看一眼波形能判断是轴承早期磨损还是对中不良平台只能画出一条越来越陡的趋势线。这个落差就是AI Agent真正要补上的位置把平台的数据能力、工业软件的业务能力和人的经验知识连接成一个可以对话、可以行动的整体。1.2 智能伙伴从“人指挥机器”到“人机共同决策”AI Agent不是又一个聊天机器人而是一个“目标驱动的数字员工”。给它一个目标它会自己拆解计划、调用工具、检查结果、修正动作最后交付成果。传统软件是“工具等命令”你点哪里它执行哪里AI Agent是“伙伴给方案”你说“帮我看下今天哪条线异常最多”它会自己去查SCADA报警、关联MES工单、分析故障模式然后把结果连同建议一起给你。我认为这种改变会作用在三个层面。交互层用户可以用自然语言下达任务不再需要记住菜单和按钮能力层Agent可以把多个工业软件的API编排成一条链路自己完成数据收集和动作执行协作层多个Agent可以分工处理报警、质量、排产等不同主题人负责审批和例外处理。这不是概念上的炫酷而是切切实实在解决高频且重复的痛点。比如每天早会前的生产报表、设备报警的初步诊断、工艺参数变更前的风险检查都是适合Agent去做的标准化活人从“执行者”变成了“审批者”和“例外处理者”。2. AI Agent、LLM与AI模型到底是什么关系2.1 三者区别一句话和一张表很多刚开始接触的人都会把AI Agent、LLM和AI模型混在一起。其实区分起来不难。AI模型是一个很大的集合包含各种机器学习和深度学习模型有做分类的、做回归的、做生成的LLM是其中擅长理解和生成自然语言的一类模型比如GPT系列、DeepSeek、QwenAI Agent则是一个完整的系统它内部可能使用LLM作为“大脑”但还包含规划、工具调用、记忆和反馈循环。打个比方AI模型是发动机LLM是一台更聪明的发动机AI Agent是整车。没有发动机不行但只有发动机也跑不到目的地。概念核心能力典型例子类比AI模型从数据中学习模式并完成特定任务图像识别模型、预测模型、生成式模型发动机LLM大规模文本理解与生成具备通用推理能力DeepSeek、GPT、Qwen、Llama高级发动机AI Agent接收目标、规划步骤、调用工具、记忆状态、交付结果工业运维助手、代码辅助Agent整车2.2 DeepSeek属于哪一层工业选型怎么理解最近很多人问“DeepSeek是属于AI模型还是AI Agent”。答案很清楚DeepSeek属于LLM这一层是一个生成式AI模型也是目前大家常说的“大模型”的一种。它可以被当作AI Agent的“大脑”负责理解你的问题、生成中间推理、决定下一步调用哪个工具但模型本身不会直接读取数据库也不会操作工单系统。它只知道“怎么说话”不知道“数据在哪里、接口怎么调”。工业场景选模型我从来不看“谁是排行榜第一”而是看四件事能不能私有化部署、上下文窗口够不够用、单次调用成本和延迟是否可以接受、模型厂商的更新节奏是否稳定。我们团队把DeepSeek和Qwen这类开源模型部署在内网让设备数据、工艺参数、维修记录都留在企业围墙内。这样做不是保守而是很多制造企业的硬性合规要求。模型负责“思考”工具层负责“动手”这样组合起来才有意义。2.3 Agent组成结构大脑之外还需要什么一套完整的AI Agent组成结构在工业场景里通常包括六个部分。感知层负责接收用户输入、工具返回结果和外部事件规划层负责把大目标拆成小步骤决定先做什么后做什么记忆层分短期和长期短期保存当前会话的上下文长期用向量库存设备手册、维修案例、工艺文档执行层负责调用API、生成SQL、创建工单这些实际动作反馈层负责检查执行结果、判断是否需要重试或修正约束层是工业场景特有的一层包含权限、白名单、审计和人工审批规则。我经常用一个比喻合格的工业数字化员工不仅要聪明还必须有业务常识、知道用什么系统、懂得什么动作必须逐级请示。只有LLM等于招了一个聪明但完全不懂公司流程的新人加上工具、记忆和约束他才能真正上岗。所以如果你在PPT里只展示“我们接入了大模型”那还远不够要把Agent当成一个完整的“员工体系”来设计。3. 从0到1搭建工业AI Agent选型与设计3.1 先做窄场景别急着做“万能助手”我做过一次很失败的尝试一开始想做一个“工业智能助手”让用户什么都能问。结果用户一句“今天产量为什么低”Agent完全无从下手因为“产量”背后涉及MES工单、设备状态、工艺参数、班次人员至少四个系统。用户觉得它傻我们也觉得无从优化。后来我们把目标收回只做“高频、小闭环”场景立刻顺了很多。选场景我有四个判断标准。第一输入要明确最好是一个可以通过工具查询的设备编码、产品批次或时间范围第二动作要可回滚比如生成报告、创建草稿工单这种动作错了也不致命第三数据要拿得到平台里已有接口不需要临时打点第四业务方愿意配合最好有一个班组愿意陪着你迭代。我们最终选的第一个场景是“车间异常工单分析与处置建议”SCADA出现报警后Agent自动关联设备档案和历史维修案例生成异常分析、建议措施并在MES里创建一个待确认工单。这个场景的收益非常直观原来班组长填一张工单要十几分钟现在确认和补充信息只要两分钟。3.2 技术栈选择Spring AI还是LangChain技术选型不能只看热闹。我们团队主力是Java工业互联网平台的现有服务也都在Spring Cloud体系里所以最后选了Spring AI。LangChain当然非常成熟但引入Python技术栈意味着要单独维护一套服务、监控、权限和部署链路对于企业级平台来说成本不低。Spring AI的好处是能直接长在Spring Boot 3.x的体系里用注解定义工具、用配置类管理模型、复用现有的日志和鉴权组件团队上手很快。如果你是做快速原型、团队又是Python背景LangChain会更高效如果你要做一个运营五年以上的企业级Java AI Agent应用平台我更建议跟随现有技术栈。我们实际架构里还用Spring Cloud Gateway做了模型网关把在线大模型和私有化模型统一路由支持限流、降级和灰度。这样上层业务不需要关心模型部署在哪里底层换模型也不会影响业务。3.3 核心架构工具注册中心、模型网关、记忆库企业级Agent平台不能只写几个Agent类就上线核心要先把三块基础设施想清楚。第一是模型网关它统一管理多个模型包括在线API和私有化部署支持按场景路由、按租户限流、按模型切换灰度第二是工具注册中心每个工具都有唯一的名称、描述、输入输出Schema、权限标签和所属场景Agent只能调用它当前有权限的工具第三是记忆库短期记忆放在Redis里保存会话上下文长期记忆放到向量数据库里存设备手册、维修案例、工序规范。这三块里工具注册中心最容易被人忽视但它恰恰决定了Agent的上限。你可以把每个工具理解成Agent的“工作手册”描述写得越清楚模型越知道什么时候该用。工具注册中心还要定期清理下线接口不删除、描述写得太含糊都会导致Agent在错误的地方反复尝试。运行时的流程我建议固定下来接收任务 → 意图识别 → 选择工具 → 执行 → 校验结果 → 生成回答。每一步都写日志后面排查问题才有据可查。4. 实操过程核心环节实现与关键细节4.1 让Agent“碰得到”工业软件工具层实现工具层是Agent和工业软件之间的桥梁。工业软件提供的API通常是面向界面或集成的格式复杂、权限模型不一致。我们的做法是封装一层“Agent工具”把一个API变成一个带清晰描述的函数。下面是一段典型的Spring AI工具定义Component public class DeviceDataTools { private final DeviceStatusService deviceStatusService; private final MesClient mesClient; public DeviceDataTools(DeviceStatusService deviceStatusService, MesClient mesClient) { this.deviceStatusService deviceStatusService; this.mesClient mesClient; } Tool(name queryDeviceStatus, description 查询指定设备的实时运行状态、主轴转速、温度和当前报警信息。设备编码为设备铭牌上的ID例如DEV-1001。当用户询问设备当前状态或是否报警时使用。) public String queryDeviceStatus(String deviceId) { return deviceStatusService.getLatestStatus(deviceId).toJson(); } Tool(name createWorkOrder, description 在MES系统中创建异常工单需要传入设备编码、异常描述、建议措施。创建成功后返回工单号。该操作会写入系统必须经过用户确认后再调用。) public String createWorkOrder(String deviceId, String description, String suggestion) { return mesClient.createAbnormalOrder(deviceId, description, suggestion); } }这段代码里有几个细节很重要。第一工具返回值尽量序列化成JSON字符串别返回对象模型解析文本比解析二进制可靠得多第二描述里必须写清楚“什么时候用、参数怎么传、有什么副作用”模型的工具调度极度依赖这段描述第三涉及写操作的工具要在描述里注明“必须经过用户确认”然后在编排层做拦截。我们一开始把工具描述写得非常简略结果模型频繁把“查询设备状态”和“查询产线产量”搞混后来把每个工具的触发条件写清楚准确率立刻上来了。4.2 与PLC编程协作的安全姿势很多人对“AI Agent与PLC编程”感兴趣这确实是工业场景里很吸引人的方向但也是最容易出事故的方向。我的观点是Agent可以辅助PLC编程但绝不能直接自动改PLC。我们团队做过一个“PLC程序助手”它能根据一段工艺描述生成结构化文本或ST语句骨架也能解释报警代码含义、检查变量命名规范、给现有程序加注释。这些功能在实际使用中很有价值工程师原本需要翻手册、查变量表、反复核对逻辑现在用对话就能拿到初稿。但整个流程有一条铁律AI生成代码 → 工程师逐行审查修改 → 离线仿真验证 → 人工确认后再下载到PLC。这个“人机回环”一步都不能省。技术上实现全自动下发并不难但工业现场有太多异常场景和连带责任设备正在运行、安全互锁、断电恢复任何一个环节考虑不到都可能造成事故。所以我们在工具层就不开放“直接写PLC”的工具只提供“生成程序文件”“生成检查清单”“对比现有程序差异”这类辅助能力。想清楚这一点才不会把智能伙伴变成定时炸弹。4.3 多智能体协作报警工单自动闭环多智能体不是为了让技术看起来更酷而是为了解决单一Agent做不了的长链路任务。我们实现过一个“报警工单自动闭环”流程监控Agent从SCADA订阅报警事件判断报警级别诊断Agent在收到需要处理的报警后调用设备历史数据查询工具看趋势和关联参数知识Agent检索设备手册和以往的维修案例给出可能原因值班Agent汇总所有信息生成一份异常工单草稿和建议措施最后推送给班组长确认。整个流程中用户只在一头一尾出现订阅规则由人定最终工单由人审批。需要特别强调的是工业场景的多智能体协作不能搞成“自由聊天”。两个Agent你一句我一句看起来智能实际失控风险极高也不好审计。我们采用“编排器固定流程”的模式由编排器按预设流程调度不同Agent每个Agent只负责一个子任务输入输出必须有明确的Schema。多智能体越多越要有规范统一的任务协议、明确的工具边界、失败兜底逻辑。类似多智能体辅助代码开发的规范也是这个思路协作越多越需要把接口、职责和回滚机制定义清楚。4.4 企业级Java AI Agent平台权限、审计与可观测企业级Java AI Agent应用平台绝不是“加一个聊天框”那么简单。我们的经验是四个关键词权限、审计、可观测、灰度。权限方面Agent能调用的工具权限必须继承当前登录用户的RBAC权限不能因为接入了大模型就绕过原来的权限模型审计方面所有模型输入输出、工具调用、人工确认过程都要落库一旦出现误操作可以追溯可观测方面要记录每一步的耗时、token数、工具调用成功率、Agent规划轨迹没有这些数据就谈不上优化和排障。灰度发布也很关键。Prompt和工具描述经常需要调优我们不会直接全量上线而是先让10%的流量走新Prompt对比工具调用成功率和用户反馈再逐步放量。模型升级也一样先在测试场景跑离线评测再切小流量。集成Jenkins这类CI/CD工具时可以让Agent自动拉取构建失败日志分析是代码变更、环境变化还是依赖问题再把分析结果附加到流水线通知里。这些能力都要统一收敛到平台里而不是每次单独写脚本。5. 常见问题与排查技巧实录5.1 工具调用错乱和意图误判“用户问设备现在怎么样Agent去查了历史趋势”“用户说帮我查一下1号产线OEEAgent却调了工单列表”这类问题在我们上线初期频繁发生。排查时先看Agent轨迹日志确认它在哪一步产生了错误决策。大多数原因都出在工具描述上描述没有写触发条件或者场景相近的工具太多。解决方法是把工具描述改成“当用户询问XX时使用当用户询问YY时不要使用”并且把无关工具从当前Agent的工具列表里移除。意图模棱两可时不要指望模型猜让Agent先反问一句“您指的是设备状态还是当天产量”准确率会高很多。5.2 数据幻觉怎么治LLM最大的问题是一本正经地编数据。工业场景最忌讳这个因为一个错误的温度、一个编造的报警代码都可能误导决策。我们的做法有三层第一层是在系统Prompt里强制“先查后答”明确要求所有数值必须来自工具返回值没有查到就说不知道不得自行推测第二层是对Agent的最终回答做后置校验如果回答里出现了关键数值而这个数值没有出现在工具返回内容中就直接拦截输出第三层是给知识库回答加引用来源回答末尾展示来源文档编号用户点进去能看到出处。加了这三层之后数据幻觉基本被压到了可接受范围。还有一个小技巧工具返回数据时带上“数据时间戳”并在Prompt里要求Agent引用“某个时间点的数据”这样就不会出现拿昨天的数据回答“当前状态”的乌龙。5.3 上下文失控与任务中断处理复杂任务跑时间长了Agent会出现“上下文膨胀”对话太长早期信息被冲淡后续决策开始漂移。我们遇到过Agent在半小时后忘记了自己已经拿到报警原因开始重复查询同样的接口。解决办法是任务分解和记忆压缩一个长任务拆成多个短任务每个短任务只做一件可验证的事每个阶段结束后让Agent生成一段结构化摘要保存下来上下文里只保留摘要和当前步骤。任务状态要持久化到数据库服务重启后可以恢复不能只放在内存里。工具调用要设置超时和重试机制避免Agent卡在一个不返回的接口上反复等待。排查这类问题我建议大家不要只盯最终答案一定要看完整轨迹。日志里如果出现Agent反复尝试一个已经不存在的接口多半是工具注册中心没有及时清理而不是模型问题。把已下线工具清掉问题立刻缓解。5.4 从练手到生产一条可复制的路径如果你刚开始学AI Agent别直接上工业大场景先做几个练手小项目会更稳妥。比如个人知识库问答把几十篇技术文档切片进向量库练检索增强定时抓取行业新闻生成摘要练工具调用和定时任务做一个企业微信或钉钉机器人用来查运维值班表、自动生成交接班记录练交互和权限再进阶一些可以让Agent分析Jenkins构建失败日志练短链路自动化。这些项目都能练到工具调用、记忆、编排三个核心能力。从练手到生产我们的路径是离线问答 → 加工具调用 → 加人工审批 → 小流量自动执行 → 全量自动执行。每一步都验证稳定后再往前走。市面上的AI Agent产品形态越来越多通用Copilot、代码辅助Agent、工业垂直助手都有代表性产品。工业领域里西门子、微软等厂商也在做类似探索核心逻辑都是“模型工业数据工具链安全护栏”区别只是在场景深度和部署方式上。方向已经很明确剩下的就是脚踏实地把一个点打透。6. 写在最后最容易被低估的三件事6.1 别让Agent直接碰执行层我见过最危险的思路是把Agent接到设备启停、PLC下载、参数写入这类动作上理由是“全自动更高效”。但工业现场最贵的是安全和责任。Agent可以分析、建议、生成方案最终下发必须经过人工确认并且走原有工控系统的安全链路。这个原则帮我们避开了好几次可能造成现场事故的隐患。把Agent定位成“伙伴”而不是“替身”要求它在关键动作前说“需要您确认”用户反而更信任它。6.2 可解释性比模型参数重要工业用户不会因为你用了最先进的模型就信任你他们需要知道Agent为什么这么判断、数据来源是哪里、上次是谁确认了这个工单。我们在每个Agent回答下面都加了“推理摘要”和“数据来源”两个字段产品经理一开始觉得太技术但车间主管和老师傅反馈说这才是他们敢用的原因。可解释性在工业场景里不是加分项而是基本条件。6.3 先从一个班组、一个车间跑通再谈平台化我踩过最深的坑就是想一步到位建设“企业级AI Agent平台”结果花了半年时间业务方却不知道拿它干什么。正确的节奏是先找一条具体产线、一类高频异常、一个愿意陪你迭代的班组把最小闭环跑通用真实收益说服其他人再沉淀平台能力。平台是在场景跑通之后自然长出来的不是先画一张大图再到处找场景。对大多数团队来说让AI Agent先成为一个车间里愿意天天打开的“伙伴”比任何宏大的平台规划都重要。