夜雨聆风AI智能体在制造业的落地实战 - 第2篇/共6篇
工业智能体的技术架构
第1篇定义了"什么是工业智能体"——第2篇回答：它到底长什么样？需要哪些模块才能跑起来？
系列说明：本系列是"AI+装备制造研发落地实战"的续篇。前系列拆解了23个AI场景，新系列从"单点场景"升级到"智能体构建"。第1篇定义了工业智能体——具备自主感知、分析决策、执行闭环三个核心能力的AI系统，区别于传统AI工具。上篇回顾：第1篇用一个"工程师的一天"开篇，对比了没有智能体和有智能体的巨大差距。核心结论：智能体不是"超级AI"，是"会干活的AI"；智能体和AI工具的区别在于"自主性"；大多数企业不需要从零开始，从最小的闭环做起。
- - -
一个常见的误解
"智能体？是不是买个开源大模型部署一下就行了？"
这是我在过去一年中被问到最多的问题之一。问这个问题的人，通常已经知道智能体"能做很多事"，但对智能体"到底是什么"的理解还停留在"一个更聪明的AI"。
这个误解的后果很严重：买了大模型、部署了、调了参，发现跑不起来——不是因为模型不够强，而是因为智能体不是"一个模型"，是一套系统。
就像你不能只买一个发动机就开上车一样——你还需要底盘、轮胎、方向盘、刹车、油箱……每个部件都到位了，车才能跑起来。
工业智能体也是一样。它由四个核心模块组成，缺一不可：
编排层 —— 业务流程的编排与调度（"神经"）▼大模型 —— 理解、推理、规划（"大脑"）▼知识库 —— 企业数据、标准、经验（"记忆"）▼工具链 —— 调用CAD/CAE/PLM/MES等（"手脚"）
这四层从下往上，每一层都为上一层提供能力支撑。编排层在最上层，因为它负责"指挥"下面三层协同工作。但理解这个架构的时候，我们反过来——从最基础的"手脚"开始，往上讲到"大脑"。
因为工业智能体的落地顺序，恰恰是从下往上的：先打通工具链（能做事），再构建知识库（有记忆），再部署大模型（会思考），最后用编排层串起来（能协同）。
下面我们逐层拆解。
- - -
第一层：工具链——智能体的"手脚"
工具链是智能体最基础的模块。没有工具链，智能体就是"有大脑没手脚"——知道该做什么，但做不了。
工具链解决的核心问题是：智能体能不能"动手"？
一个工业智能体需要调用的工具，远比一个聊天机器人复杂：
读取PLM中的BOM表和图纸 → 需要PLM的API接口 打开CAD软件修改模型 → 需要CAD的API或脚本接口 提交仿真计算 → 需要CAE软件的批处理接口 发送通知给相关人员 → 需要企业微信/钉钉/邮件接口 更新工艺文件 → 需要工艺管理系统的接口 查询物料库存 → 需要ERP系统的接口
每一个"动作"背后，都是一个系统集成问题。而工业智能体的执行能力上限，取决于它能够调用的工具数量和质量。
工业软件API的现状
说到工具链，就绕不开一个现实问题：工业软件的API生态远不如互联网软件成熟。
互联网软件（企业微信、钉钉、飞书、各类SaaS）普遍提供RESTful API，文档完善、调用简单。但工业软件（CAD、CAE、PLM）的情况要复杂得多：
主流CAD软件：提供API，但不同品牌的API差异很大，学习成本高。有些API只支持桌面端调用，不支持云端。 CAE软件：批处理接口相对成熟（因为仿真计算本身就是批处理的），但前后处理的自动化接口参差不齐。 PLM系统：API通常比较完善（因为PLM本身就是管理数据的），但不同厂商的API风格差异大。 MES/ERP系统：API成熟度取决于厂商，老系统可能只有数据库层面的接口。
这意味着什么？意味着工具链的构建，不是"买来就能用"的，需要大量的集成开发工作。
现实案例某企业的工具链集成花了6个月某工程机械企业在建设仿真智能体时，花了6个月时间做工具链集成。主要工作包括：打通PLM和仿真软件的接口（实现BOM→仿真模型的自动映射）、建立仿真软件的批处理脚本库（覆盖静强度/疲劳/模态三种分析类型）、对接企业微信通知接口（实现仿真完成后的自动通知）。6个月听起来很长，但一旦打通，后续所有智能体的建设都基于这套工具链——设计变更智能体、工艺智能体、试验智能体，都复用同一套接口。启示：工具链建设是"一次投入、长期受益"的事。前期投入大，但复用率高。
工具链建设的三个原则
原则一：优先打通"高频调用"的工具。不是所有系统都需要一次打通。先分析智能体最常调用的工具是什么——通常是PLM（查数据）、CAE（做分析）、IM（发通知）。先把这三个打通，再逐步扩展。
原则二：API优先，退而求其次用脚本。有API的用API，没有API的用脚本自动化（如通过命令行调用、模拟键盘操作），但脚本方案不稳定，尽量往API迁移。
原则三：为每个工具建立"能力清单"。明确每个工具能做什么、不能做什么。比如"PLM能查BOM但不能改BOM"——这样智能体在决策时才知道"这件事能不能做"。
- - -
第二层：知识库——智能体的"记忆"
工具链让智能体"能动手"，知识库让智能体"有常识"。
智能体需要知道什么？
企业标准：材料标准、公差标准、焊接规范、试验标准…… 产品知识：零件分类、装配关系、功能要求、历史变更…… 经验知识：常见故障模式、典型解决方案、设计经验规则…… 流程知识：变更流程、审批流程、异常处理流程……
这些知识，目前分散在PLM系统、技术文档、工程师的脑子里。智能体要把它们集中起来，变成可检索、可推理的结构化知识。
知识库的三种形态
知识库不是"一个数据库"，而是三种形态的组合：
形态一：结构化知识（规则库）以"if-then"规则形式存在的知识。比如："如果壁厚变更超过2mm，必须重新仿真。""如果焊缝区域的仿真-试验偏差超过15%，属于正常范围。"这类知识最适合用规则引擎管理——确定性强、执行效率高、可解释性强。来源：企业标准、工艺规范、设计手册。
形态二：半结构化知识（文档库+向量数据库）以文档形式存在的知识——仿真报告、试验报告、技术方案、故障案例。这些文档有结构但不完全结构化，最适合用RAG（检索增强生成）方式管理。智能体收到一个问题时，先从文档库中检索相关段落，再让大模型基于检索结果生成回答。这样既利用了文档中的知识，又避免了"幻觉"——因为回答有据可查。来源：历史项目文档、技术报告、案例分析。
形态三：图谱化知识（知识图谱）以"实体-关系"形式存在的知识。比如："挖掘机动臂"——属于——"结构件""结构件"——涉及——"焊接工艺""焊接工艺"——受影响的参数——"焊接电流、焊接速度、预热温度""壁厚减薄"——可能导致——"焊接变形增大"知识图谱的优势在于推理能力——智能体可以通过"关系链"推导出隐含的知识。来源：BOM结构、工艺路线、故障树、经验规则。
知识库建设的"最小可行"原则：第一阶段：先把最常用的规则（结构化知识）整理出来，用规则引擎管理。这个最快，一周就能见效。第二阶段：把历史文档（半结构化知识）做向量化，建立RAG检索。这个需要文档清洗和标注，一个月左右。第三阶段：围绕一个核心场景（如"设计变更影响分析"）建最小知识图谱。跑通后再扩展。记住：知识库不是"建完再用"，而是"边用边建"。先用规则引擎跑起来，再逐步用实际使用中积累的数据丰富知识库。
知识库的质量决定智能体的智商
这是一个容易被低估的事实：智能体的"聪明程度"，80%取决于知识库的质量，20%取决于大模型的能力。
同一个大模型，配上不同的知识库，表现天差地别。知识库质量高（数据准确、覆盖全面、更新及时），智能体就像一个经验丰富的老工程师。知识库质量低（数据混乱、覆盖不全、过期未更新），智能体就像一个刚入职的新人——态度很好，但说的东西不靠谱。
所以，知识库建设不是"一次性的IT项目"，而是需要持续运营的业务工程——要有专人负责知识的采集、清洗、标注、更新、质量监控。
- - -
第三层：大模型——智能体的"大脑"
工具链让智能体"能动手"，知识库让智能体"有常识"，大模型让智能体"会思考"。
但工业场景对大模型的要求，和通用场景完全不同。
工业场景对大模型的特殊要求
要求一：精度优先，不是"创意"优先。通用大模型追求的是"流畅"——回答要自然、有创意、像人说的话。但工业场景追求的是"准确"——仿真结果偏差5%就是5%，不能"大概、可能、差不多"。这意味着工业智能体不能完全依赖大模型的"生成能力"，必须用规则引擎和知识库做双重校验。
要求二：可解释性——"为什么"比"是什么"更重要。工程师不会轻易相信一个"黑箱"给出的建议。智能体说"这个结构需要加强"，工程师会问"为什么？依据是什么？"大模型需要能给出推理过程，引用具体的标准条款或历史案例。
要求三：领域专业性——通用大模型不懂工业。通用大模型知道"挖掘机是用来挖土的"，但不知道"挖掘机动臂的典型失效模式是焊缝疲劳开裂"。要让大模型具备工业领域的专业知识，有两种方式：一是用工业数据做微调（领域大模型），二是通过RAG从知识库中检索（检索增强）。目前实践中，RAG是更主流的方式——成本低、更新快、可控性强。
要求四：安全边界——不能"自由发挥"。通用大模型可以自由发挥——"如果你是一台挖掘机，你会怎么想？"这种问题在工业场景中毫无意义。工业智能体的大模型需要有明确的"行为边界"——什么能说、什么不能说、什么能做、什么不能做。这个边界通过系统提示词（System Prompt）和规则引擎共同定义。
大模型选型：通用 vs 工业垂直
| 知识覆盖 | ||
| 精度 | ||
| 成本 | ||
| 更新频率 | ||
| 适用场景 |
我的建议：大多数企业从通用大模型+RAG开始。先用通用大模型的API，配上企业知识库做RAG，可以覆盖80%的场景。只有当某些场景对精度要求极高（如标准条款的精确解读、故障模式的准确诊断），且通用大模型+RAG无法满足时，才考虑微调或训练工业垂直模型。
原因很简单：大模型技术迭代太快。今天花大价钱微调的模型，半年后可能就被新版本通用模型超越了。而RAG方式，知识库是企业的、模型是通用的——模型升级时，知识库不需要重建。
一个实用的判断标准：如果场景需要的是"基于企业特有知识的推理"（如"根据我们的历史数据，这种故障最可能的原因是什么"）→ 用RAG就够了。如果场景需要的是"在工业领域达到专家级别的理解"（如"这个焊接符号的精确含义是什么"）→ 考虑微调。如果场景需要的是"实时、低延迟的工业控制决策"（如"根据传感器数据实时调整工艺参数"）→ 不要用大模型，用传统控制算法。
- - -
第四层：编排层——智能体的"神经"
前三层（工具链、知识库、大模型）解决了"能力"问题——智能体能做事、有知识、会思考。但如果没有编排层，这些能力是"各自为政"的——工具链不知道什么时候该调用，知识库不知道什么时候该检索，大模型不知道什么时候该介入。
编排层的作用，就是把这三层的能力"串"起来，形成一个完整的自动化流程。
编排层做什么？
用一个设计变更场景来说明：
步骤1：感知——编排层监控PLM系统中的变更事件。当检测到新的设计变更时，触发智能体流程。
步骤2：理解——编排层调用大模型，分析变更内容（"壁厚16mm→14mm"），结合知识库中的产品知识（"这个零件是挖掘机动臂，属于结构件"），生成变更影响分析。
步骤3：决策——编排层根据规则引擎（"壁厚变更超过1mm需要重新仿真"）和知识库（"历史类似变更的处理流程"），决定下一步行动：触发仿真评估、通知工艺部门、更新BOM。
步骤4：执行——编排层调用工具链：通过PLM API更新BOM、通过CAE API提交仿真、通过IM API发送通知。
步骤5：闭环——编排层监控执行结果，确认仿真完成、通知已发送、BOM已更新。如果有异常（如仿真计算失败），触发异常处理流程。
整个过程，编排层就像一个"总指挥"——它知道每个环节该做什么、什么时候做、做完后下一步做什么。
编排层的两种实现方式
方式一：基于规则引擎的编排——适合流程固定、规则明确的场景。用规则引擎实现，稳定可靠，可解释性强。优点：确定性强、执行效率高、容易调试。缺点：灵活性差，流程变化时需要修改规则。
方式二：基于大模型的编排——适合流程灵活、需要动态决策的场景。用大模型做"决策引擎"，根据上下文选择最优路径。优点：灵活，能处理非标准化场景。缺点：不确定性高，可能出现"意外行为"。
实践中：两者结合。标准化流程用规则引擎（快、稳、可控），非标准化场景用大模型（灵活、智能）。编排层本身需要判断"当前场景属于哪一类"，然后选择对应的处理方式。
编排层设计的核心原则：原则一：人机协作的"握手点"要清晰。哪些步骤需要人确认、哪些步骤可以自动执行，必须在编排层中明确。比如"仿真结果自动生成"可以自动执行，但"仿真结论的最终批准"必须由人来完成。原则二：异常处理不是"事后补丁"，是编排的一部分。每个步骤都要考虑"如果失败了怎么办"——超时重试、降级处理、通知人工介入。原则三：可观测性。编排层需要记录每个步骤的执行日志——谁触发的、什么时候执行的、结果是什么、花了多长时间。这些日志不仅用于问题排查，还用于后续的流程优化。
- - -
一个案例：四个模块如何协同工作
理论讲完了，我们用一个完整的案例，把四个模块串起来看一遍。
场景：某挖掘机企业的仿真智能体，接收到一个"挖掘机动臂疲劳仿真"任务。
第一步：编排层触发流程——设计工程师在PLM中提交了"动臂疲劳仿真"的申请。编排层检测到新任务，启动仿真智能体流程。
第二步：大模型理解任务——大模型读取任务描述："对XX型号挖掘机动臂进行疲劳仿真，载荷谱见附件，材料为Q355B。"大模型结合知识库中的产品知识，理解这是"一个结构件的疲劳分析"，需要"建立有限元模型→施加载荷→求解→结果评估"的完整流程。
第三步：知识库提供参考——知识库检索到历史数据：去年做过同型号的静强度仿真，模型文件在XX路径；类似结构的疲劳仿真历史记录显示，焊缝区域的应力集中系数通常在1.3~1.5之间；企业标准规定，挖掘机动臂的疲劳安全系数不低于1.5。
第四步：工具链执行动作——通过PLM API获取三维模型和载荷谱文件；调用几何清理工具清理模型；调用网格划分工具生成有限元网格；提交疲劳求解计算；计算完成后，调用报告生成工具输出疲劳分析报告。
第五步：编排层检查结果并闭环——编排层检查：计算是否收敛？结果是否在合理范围内？报告是否完整？确认无误后，将报告推送给设计工程师审核，同时在知识库中记录本次仿真的关键参数和结论，供后续类似任务参考。
整个过程，工程师只需要做一件事：审核最终报告。从提交申请到拿到报告，全部由智能体自动完成。
关键洞察四个模块的分工编排层：知道"整个流程该怎么走"——先做什么、再做什么、异常了怎么办。大模型：知道"这个任务是什么意思"——理解任务描述、判断任务类型、规划执行步骤。知识库：知道"相关的知识和经验是什么"——提供历史参考、标准规范、经验规则。工具链：知道"具体怎么做"——调用软件、执行计算、生成报告。四个模块各司其职，缺一不可。
- - -
建设的顺序：从下往上，逐步扩展
四个模块都讲完了，但企业不可能一次性全部建好。正确的建设顺序是从下往上：
第一阶段：先建工具链（1~3个月）——让智能体"能动手"。打通最核心的2~3个系统接口（PLM、CAE、IM），建立基础的批处理能力。这个阶段不需要大模型，不需要知识库——先用规则引擎+脚本把最简单的流程自动化跑起来。产出：一个"最小可行智能体"——比如"自动提交仿真+生成报告"。
第二阶段：再建知识库（3~6个月）——让智能体"有常识"。把企业标准、历史文档、经验规则整理成结构化知识。先建规则库（最快），再建文档向量库，最后围绕核心场景建知识图谱。产出：智能体的回答"有据可查"了，不再"胡说八道"。
第三阶段：引入大模型（6~9个月）——让智能体"会思考"。接入通用大模型API，配上知识库做RAG。这个阶段智能体开始具备"理解"和"推理"能力——能处理非标准化场景，能给出有依据的建议。产出：智能体从"自动化工具"升级为"智能助手"。
第四阶段：完善编排层（9~12个月）——让智能体"能协同"。把前三个阶段的能力用编排层串起来，形成完整的自动化闭环。这个阶段智能体开始"自主工作"——不需要人一步步指挥，自己知道该做什么。产出：真正的"工业智能体"。
一个重要的提醒：这个时间线是"理想情况"。实际中，每个阶段都可能因为数据质量问题、系统集成难度、组织阻力而延期。但有一个原则不会变：不要跳过一个阶段去建下一个。没有工具链，智能体"有想法没能力"；没有知识库，智能体"有想法没常识"；没有大模型，智能体"有执行没理解"；没有编排层，智能体"有能力没协同"。每一层都是下一层的基础，跳不过去。
- - -
一个常见的误区：把"部署大模型"当成"建设智能体"
这是目前市场上最常见的误区，值得单独拿出来说。
很多企业花了几十万甚至上百万买了大模型授权、部署了GPU服务器、做了模型微调，然后发现：智能体还是跑不起来。
为什么？因为他们只做了"第三层"（大模型），忽略了第一层（工具链）、第二层（知识库）和第四层（编排层）。
没有工具链，大模型只能"给建议"——它告诉你"需要重新仿真"，但没办法帮你提交计算。 没有知识库，大模型只能"凭常识回答"——它知道"挖掘机是用来挖土的"，但不知道你们企业的焊接规范是什么。 没有编排层，大模型只能"单次对话"——它回答完一个问题就结束了，没办法完成一个多步骤的流程。
结果就是：大模型部署了，但没人用——因为"它除了聊天，什么实际的事都做不了"。
这不是大模型的问题，是建设思路的问题。
智能体的建设，不是"买一个大模型"就完事了。它是一个系统工程——工具链、知识库、大模型、编排层，四层缺一不可。每一层都需要投入时间、资源和耐心。
一句话总结第2篇：工业智能体不是"一个模型"，是一套系统——工具链是手脚，知识库是记忆，大模型是大脑，编排层是神经。四层从下往上建设，逐层打通，才能跑起来。
- - -
本篇小结
第2篇我们拆解了工业智能体的四层架构：
第一层：工具链——智能体的"手脚"。解决"能不能动手"的问题。工业软件API生态不成熟，需要大量的集成工作。从高频调用的工具开始，API优先，逐步扩展。
第二层：知识库——智能体的"记忆"。解决"有没有常识"的问题。三种形态：规则库（结构化）、文档向量库（半结构化）、知识图谱（图谱化）。从规则库开始，边用边建。
第三层：大模型——智能体的"大脑"。解决"会不会思考"的问题。工业场景要求精度、可解释性、领域专业性、安全边界。大多数企业从"通用大模型+RAG"开始，不急于微调。
第四层：编排层——智能体的"神经"。解决"能不能协同"的问题。把前三层的能力串起来，形成完整的自动化闭环。规则引擎处理标准化流程，大模型处理非标准化场景，两者结合。
建设顺序：从下往上，逐层打通。先工具链（1~3个月），再知识库（3~6个月），再大模型（6~9个月），再编排层（9~12个月）。不要跳过一个阶段去建下一个。
核心就三句话：
1. 工业智能体不是"一个模型"，是一套系统——四层缺一不可。
2. 建设顺序从下往上——先让智能体"能动手"，再让它"有常识"，再让它"会思考"，最后让它"能协同"。
3. 不要只买大模型——没有工具链和知识库的大模型，除了聊天什么实际的事都做不了。
下一篇预告：第3篇讲智能体的数据底座——知识图谱、向量数据库、实时数据管道，三件套怎么搭、怎么选、怎么落地。前系列第6篇说了三遍"先有数据再上AI"，但很多企业的真实情况是：数据有，但"散"。智能体面对这种环境，就像一个失忆的人。第3篇我们展开讲怎么给智能体装上"记忆系统"。
- - -
AI智能体在制造业的落地实战 · 第2篇