★ FEATURED ARTICLE 1. 从侧边栏困局说起工业智能体到底该长什么样CAD 和 CAE 这两个词干过制造业的人都不陌生。CAD 负责画图建模CAE 负责仿真验证一个管“长什么样”一个管“扛不扛得住”。过去三十年这两类软件的核心交互方式几乎没变过——人坐在电脑前打开软件点菜单敲命令一步步把脑子里的东西搬到屏幕上。软件是工具人是操作者边界清晰得很。但这两年 AI 大模型一进来事情开始起变化。最早的一批尝试几乎清一色是把 AI 塞进软件的侧边栏做成一个聊天框。你问它“这个倒角怎么画”它给你一段操作说明你让它“帮我写个宏”它吐出一段脚本。用起来不能说没用但总感觉隔了一层——AI 在软件旁边不在软件里面。它看得见你但摸不着你的模型更动不了你的参数。行云创新马洪喜提的那个观点戳的就是这个痛点CAD/CAE 工业智能体不会只停留在软件侧边栏。这句话背后其实藏着一个判断——真正的工业智能体得能钻进软件的骨架里能读得懂几何拓扑能调得动求解器能替人做决策而不是在边上当个“问答客服”。我自己的理解是工业智能体和通用聊天机器人的根本区别在于它必须对“物理世界”负责。你问 ChatGPT“这个零件强度够不够”它只能给你讲一堆材料力学原理但工业智能体应该能直接读你的网格模型跑一遍静力学分析然后告诉你“第三阶模态下这个筋板会共振建议加厚 2mm”。前者是知识问答后者是工程决策。这两者之间的鸿沟就是侧边栏和智能体的距离。这篇文章我想把这件事拆开聊透。从 CAD/CAE 智能体的核心能力拆解到它为什么不能只做侧边栏再到实际落地时该怎么设计架构、怎么选技术路线、怎么避开那些我踩过的坑。不管你是做工业软件开发的还是制造业里搞数字化转型的或者只是对 AI 落地工业场景感兴趣应该都能从里面找到能直接抄作业的东西。2. 工业智能体的核心能力拆解它到底该会什么2.1 从“能聊”到“能算”工业智能体的能力分层通用大模型的能力边界很清楚它能理解自然语言能生成文本能做一些逻辑推理。但工业场景要的东西完全不一样。我把它拆成四层从下往上说。最底层是语义理解层。这一层跟通用大模型重叠度最高就是把工程师的自然语言指令翻译成机器能懂的结构化意图。比如“把这个法兰的螺栓孔从 8 个改成 12 个”智能体得能识别出“法兰”“螺栓孔”“8 个”“12 个”这些实体还得知道“改成”是一个修改操作。这一层现在做得相对成熟但工业术语的歧义性是个大坑——“倒角”在不同行业里可能指完全不同的工艺没有领域微调根本搞不定。往上一层是几何认知层。这是工业智能体区别于通用 AI 的核心。它得能读懂 CAD 模型里的几何信息这个面是平面还是曲面这条边是直线还是样条曲线这个特征跟那个特征之间是什么拓扑关系。传统 CAD 的 API 能提供这些信息但问题是 API 是给人用的参数一大堆调用逻辑复杂。智能体要做的是把这些底层 API 封装成更高层的“几何操作原语”比如“识别所有圆角半径小于 1mm 的特征”“找出所有壁厚小于 2mm 的区域”。再往上是物理推理层。这一层对应 CAE 的能力。智能体得知道材料属性、边界条件、载荷工况这些物理概念还得能判断“这个结构在 200N 的力下会不会屈服”“这个流道在 5m/s 的流速下压降是多少”。这一层不能靠大模型瞎猜必须跟真实的求解器打通。我的做法是让智能体负责“设置问题”求解器负责“计算结果”中间用一套标准化的参数接口连接。最顶层是决策执行层。智能体得能根据分析结果做判断然后直接操作软件执行修改。比如“检测到应力集中系数超过 3自动在圆角处增加过渡曲面”这个动作要能闭环完成不需要人再点一遍菜单。这四层能力侧边栏聊天框只能碰到第一层后面三层它根本够不着。这就是为什么我说侧边栏模式注定是过渡形态。2.2 为什么侧边栏模式走不远三个硬伤侧边栏模式的问题不是技术不够好而是架构上就有天花板。我总结了三个绕不过去的硬伤。第一个硬伤是上下文断裂。侧边栏里的 AI 只能看到你粘贴给它的文字看不到你当前打开的模型不知道你选中的是哪个面更不知道你上一步做了什么操作。这就好比一个工程师站在你旁边但你得把所有信息口述给他他才能给建议。效率低不说还容易出错。真正的智能体应该像坐在你工位上一样屏幕上的东西它全看得见。第二个硬伤是操作断层。侧边栏 AI 能告诉你“应该把圆角改成 R5”但它改不了。你还得自己找到那个圆角双击输入 5回车。这个过程中间只要有一个环节你理解错了结果就偏了。智能体应该能直接执行或者至少生成一个可回滚的操作序列让你确认。第三个硬伤是数据孤岛。侧边栏 AI 通常是一个独立的服务跟 CAD/CAE 软件之间只有很窄的接口。它拿不到完整的模型数据也拿不到求解器的中间结果。这就导致它只能做“表面文章”没法做深度分析。比如你想让它优化一个零件的拓扑结构它需要反复调用求解器、读取应力场、修改几何这个循环在侧边栏架构下根本跑不起来。我见过不少团队一开始都从侧边栏切入觉得门槛低、见效快。但做到后面都会遇到同一个问题用户用了几次就不用了因为“它说的我都知道它做的我做不了”。这个反馈很致命。2.3 真正的工业智能体该长在哪三个嵌入层级那智能体应该长在哪我的判断是三个层级由浅入深。第一层是命令级嵌入。智能体以插件形式挂在软件里能调用软件的 API能读写模型数据但交互还是通过对话框。用户说“帮我检查一下这个装配体有没有干涉”智能体调用干涉检查 API把结果用自然语言返回。这一层比侧边栏深因为它能真正操作软件了。第二层是工作流级嵌入。智能体不再是一个独立的对话框而是渗透到软件的各个操作环节里。你画一条线它实时提示“这条线与基准面夹角 87 度是否要调整为 90 度”你设置一个载荷它自动推荐“根据历史案例类似结构通常用 500N”。这一层的特点是主动服务不需要你每次都去问它。第三层是内核级嵌入。这是最彻底的形态。智能体直接跑在软件的几何内核和求解器内核之上能实时读取内存中的模型数据能在求解迭代过程中动态调整参数。比如在拓扑优化时智能体根据每一步的应力分布实时调整材料分布策略而不是等整个优化跑完再看结果。这一层对软件架构的要求最高但效果也最颠覆。马洪喜说的“不会只停留在侧边栏”我理解就是指要往第二层和第三层走。侧边栏是入口但不是终点。3. 技术架构怎么搭从 API 封装到内核级集成3.1 整体架构设计四层解耦真要动手做架构上我建议分四层层与层之间用标准接口解耦。这样后面换大模型、换求解器、换 CAD 平台都不用推倒重来。最底层是软件适配层。这一层负责跟具体的 CAD/CAE 软件打交道。不同软件的 API 差异巨大有的用 COM有的用 Python有的用 C 插件。适配层的作用是把这些差异屏蔽掉对上提供统一的“几何操作接口”“求解调用接口”“数据读写接口”。我一般会定义一套抽象基类每个软件写一个适配器实现。第二层是能力封装层。这一层把底层的原子操作封装成更高层的“能力”。比如“识别特征”这个能力底层可能调用了十几个 API但上层只需要传一个模型 ID 和一个特征类型就能拿到结果。这一层的设计原则是面向工程语义而不是面向 API。第三层是智能体编排层。这是核心。它负责接收用户指令拆解成任务序列调用能力封装层的接口处理中间结果最后生成响应。这一层通常用 LangChain 或者类似的框架来做但工业场景下需要做大量定制。比如任务拆解不能只靠大模型得有一套领域规则来约束否则它可能给你拆出一个物理上不可能执行的任务序列。第四层是交互层。这一层决定用户怎么跟智能体交互。可以是对话框可以是右键菜单可以是实时提示也可以是自动化脚本。交互层要灵活因为不同场景下用户想要的交互方式完全不同。3.2 大模型选型通用还是垂直大模型选型是绕不过去的问题。我的经验是通用大模型打底垂直微调补差。通用大模型比如 GPT-4、Claude 3.5 这个级别在语义理解和任务规划上已经够用了。你不需要自己从头训一个成本太高效果还不一定好。但通用模型在工业术语和几何推理上会犯低级错误。比如它可能分不清“拔模角”和“倒角”可能把“过盈配合”理解成“间隙配合”。解决办法是用领域数据做微调。微调数据从哪来三个来源一是软件的操作日志把用户的操作序列和对应的自然语言描述配对二是工程手册和标准把材料参数、工艺规范这些结构化知识喂进去三是历史项目数据把“问题-分析-方案-结果”这个链条整理成训练样本。微调的方式我推荐 LoRA成本低效果好而且可以针对不同模块训不同的 LoRA 适配器。比如一个适配器专门管几何特征识别一个专门管求解参数设置一个专门管工艺决策。推理时根据任务类型动态加载对应的适配器。有个坑要注意微调数据里的几何信息不能只用文字描述得把几何特征向量化。比如一个圆角不能只说“R5 圆角”得把它的曲率、位置、相邻面信息都编码进去。否则模型学不到几何之间的空间关系。3.3 几何内核的对接方式三种路线对比智能体要操作几何必须跟几何内核对接。目前有三条路线各有优劣。对接方式实现难度能力上限适用场景我的推荐度API 调用低中快速验证、轻量级操作入门首选插件嵌入中高深度集成、实时交互主力方案内核级集成高极高拓扑优化、实时仿真长期方向API 调用是最简单的直接用软件提供的 Python 或 COM 接口。优点是开发快不用碰 C。缺点是能力受限很多底层操作 API 不暴露而且性能有损耗。适合做原型验证。插件嵌入是主流方案。写一个软件插件在插件进程里跑智能体逻辑。这样能拿到更完整的数据性能也更好。缺点是每个软件都得单独开发插件工作量不小。内核级集成是最彻底的直接把智能体逻辑编译进几何内核。这需要拿到内核源码一般只有软件原厂或者深度合作伙伴才能做。但效果最颠覆能做到真正的实时交互。我的建议是先用 API 调用跑通流程验证价值然后针对核心软件做插件嵌入提升体验最后如果有条件跟原厂合作做内核级集成。3.4 求解器调用怎么让 AI 等得起CAE 求解动辄几分钟到几小时智能体如果傻等用户体验会很差。我的做法是异步调用 进度回调 中间结果利用。异步调用就是智能体发起求解任务后不阻塞继续处理其他事情等求解完成再回调。进度回调是让求解器定期上报进度智能体可以据此给用户反馈“已完成 60%预计还需 3 分钟”。中间结果利用是更高级的玩法——不等求解完全收敛智能体就根据当前的残差和场变量做初步判断如果明显不对就提前终止节省时间。还有一个技巧是代理模型。对于频繁调用的分析类型可以训一个神经网络代理模型输入几何参数和边界条件直接输出应力、变形这些结果。代理模型精度不如真实求解器但速度快几个数量级。智能体可以先用代理模型做快速筛选只对候选方案跑真实求解。4. 实操落地从零搭一个 CAD 智能体原型4.1 环境准备与工具链选型假设你要从零搭一个 CAD 智能体原型我把我用过的工具链列一下。CAD 平台选 FreeCAD 或者 Onshape。FreeCAD 开源免费Python API 完善适合练手。Onshape 是云原生API 设计得很干净适合做产品化。商业软件里 SolidWorks 的 API 最成熟但需要正版授权。大模型用 OpenAI 的 API 或者本地部署 Qwen2.5-72B。前者效果好但贵后者便宜但需要显卡。原型阶段建议用 API快速验证。编排框架用 LangChain 或者 LlamaIndex。LangChain 生态更全但抽象层太厚调试麻烦。LlamaIndex 更轻量适合工业场景。我最近在用 LangGraph做多步骤任务编排很顺手。几何处理用 OpenCASCADE 或者 trimesh。OpenCASCADE 功能全但学习曲线陡trimesh 轻量但只能处理网格。如果要做精确几何操作还是得上 OpenCASCADE。开发环境用 Python 3.10配 PyCharm 或者 VS Code。AI 插件我试过 Fitten Code补全速度不错对 Python 支持很好。4.2 第一个智能体自动识别并修改圆角拿一个具体任务练手用户说“把所有小于 R2 的圆角改成 R3”智能体自动完成。第一步解析指令。用大模型把自然语言拆成结构化任务task { action: modify_fillet, condition: {radius: {operator: , value: 2}}, target: {radius: 3} }这一步的关键是给大模型一个清晰的 schema让它按格式输出。我一般用 function calling 或者 JSON mode比纯 prompt 稳定得多。第二步识别目标特征。调用 CAD 的 API 遍历所有圆角特征import FreeCAD import Part def find_small_fillets(doc, threshold): small_fillets [] for obj in doc.Objects: if obj.TypeId Part::Fillet: for edge in obj.Shape.Edges: if edge.Curve.TypeId Part::GeomCircle: radius edge.Curve.Radius if radius threshold: small_fillets.append((obj.Name, edge.Index, radius)) return small_fillets这段代码遍历文档里所有 Fillet 对象检查每条边的曲率半径。实际工程中圆角可能不是标准圆弧得用曲率分析来识别但原型阶段这样够用了。第三步执行修改。对每个识别出的圆角修改其半径参数def modify_fillet_radius(doc, obj_name, edge_index, new_radius): obj doc.getObject(obj_name) # FreeCAD 的 Fillet 修改需要重建特征 # 实际实现会更复杂这里简化示意 obj.Radius new_radius doc.recompute()第四步验证结果。修改后重新检查确认所有目标圆角都改到位了。如果有没有改成功的记录下来反馈给用户。这个流程跑通你就有了一个能真正操作 CAD 的智能体雏形。虽然简单但架构是完整的。4.3 多智能体协作让专业的人干专业的事单一智能体处理复杂任务会力不从心。比如“优化这个支架的结构减重 20% 同时保证强度”这涉及几何修改、仿真分析、结果评估多个环节。我的做法是拆成多个专业智能体用编排器协调。几何智能体负责读模型、改特征、生成变体。仿真智能体负责设边界条件、调求解器、读结果。评估智能体负责判断方案是否满足要求、给出下一步建议。编排智能体负责拆解任务、分配工作、汇总结果。智能体之间通过消息队列通信每个智能体有自己的工具集和知识库。编排智能体用状态机来管理流程比如“几何修改 → 仿真验证 → 评估 → 如果不满足则回到几何修改”。这种架构的好处是每个智能体可以独立优化而且可以并行执行。比如几何智能体生成 10 个变体的同时仿真智能体可以开始分析已经生成的变体。多智能体协作的坑在于通信开销和状态同步。我建议初期用简单的共享内存或者 Redis 做状态存储别一上来就搞复杂的消息中间件。等规模上来了再考虑分布式。4.4 参数计算实例怎么让 AI 算得准工业场景里很多决策需要精确计算不能靠大模型拍脑袋。举个例子用户说“这个悬臂梁在 500N 载荷下变形不能超过 2mm帮我选个合适的截面尺寸”。智能体得先算。悬臂梁端部挠度公式是$$\delta \frac{FL^3}{3EI}$$其中 F 是载荷L 是长度E 是弹性模量I 是截面惯性矩。假设材料是钢E200GPaL300mmF500N要求 δ≤2mm。代入得$$I \geq \frac{FL^3}{3E\delta} \frac{500 \times 300^3}{3 \times 200000 \times 2} 11250 \text{ mm}^4$$如果是矩形截面宽度 b高度 hI bh³/12。假设 b20mm则$$h \geq \sqrt[3]{\frac{12 \times 11250}{20}} \sqrt[3]{6750} \approx 18.9 \text{ mm}$$所以选 20×20 的方钢就够了。智能体把这个计算过程跑一遍然后自动在 CAD 里把截面改成 20×20再调求解器验证。这个闭环跑通用户就真的省事了。关键是公式和参数不能靠大模型记得放在知识库里智能体调用计算工具来算。大模型只负责理解问题、选择公式、解释结果。5. 常见问题与排查技巧实录5.1 智能体“听不懂”工业术语怎么办这是最高频的问题。用户说“把这个件的拔模角加大一点”智能体回“拔模角是什么”。原因是大模型的训练语料里工业术语占比太低。解决办法分三步。第一步建术语表。把行业里的标准术语、企业内部的习惯叫法、甚至老师傅的口头禅都整理出来每个术语对应标准定义和同义词。第二步做实体链接。用户输入里出现术语时先用术语表做匹配和消歧把自然语言映射到标准术语。第三步微调模型。用术语表构造训练样本让模型学会在工业语境下理解这些词。我实测下来术语表加实体链接能解决 80% 的“听不懂”问题剩下的 20% 靠微调补。5.2 几何操作失败怎么排查智能体调用 CAD API 时经常失败原因五花八门。我整理了一个排查表现象可能原因排查方法解决思路API 返回空对象名不对打印文档所有对象名用遍历代替硬编码操作被拒绝特征被锁定检查特征状态先解锁再操作结果不符合预期坐标系不对检查全局/局部坐标统一坐标系性能极慢频繁 recompute加日志计时批量操作后统一 recompute模型损坏操作顺序错误回滚到上一步按依赖顺序操作最常见的坑是坐标系。CAD 里全局坐标系和局部坐标系混用是常态智能体如果搞混了改出来的东西位置全错。我的做法是在适配层统一转成全局坐标上层只用全局坐标。另一个坑是特征依赖。你改了一个基础特征后面依赖它的特征可能全部失效。智能体得能识别依赖关系按正确顺序操作。这个用拓扑排序就能解决但前提是得先把依赖图建出来。5.3 求解器不收敛怎么让 AI 处理CAE 求解不收敛是家常便饭。传统做法是工程师凭经验调参数智能体要做的就是把这种经验固化下来。我总结的排查顺序是先看网格再看边界条件最后看材料参数。网格质量差是最常见的原因智能体可以自动检查雅可比比、长宽比这些指标超标就自动加密。边界条件冲突是第二常见比如过约束导致刚体位移被锁死智能体可以检查约束方程的数量和秩。材料参数不合理是第三常见比如泊松比设成 0.5 导致体积不可压智能体可以检查参数范围。如果自动排查搞不定智能体应该把诊断信息整理好推给人工而不是瞎试。我见过有的智能体不收敛就疯狂调参数跑了几十次还是失败浪费时间。5.4 怎么评估智能体的效果不能只看“能不能跑通”得有一套量化指标。我用的是四个维度任务完成率用户下达的任务有多少比例被正确完成。这个最重要低于 80% 就没法用。平均交互轮次完成一个任务平均需要几轮对话。越少越好理想是 1-2 轮。操作准确率智能体执行的操作有多少是正确的。这个要跟人工操作对比。用户采纳率智能体给出的建议有多少被用户接受。这个反映信任度。我一般会建一个测试集包含 100-200 个典型任务定期跑一遍看指标变化。新版本上线前必须跑通测试集否则很容易引入回归。有个经验别追求 100% 准确率。工业场景里有些任务就是模糊的智能体做到 85% 准确、剩下 15% 能给出有用的中间结果让用户接手比追求 100% 但经常卡死要好得多。6. 工业智能体的边界与我的实操体会做了一段时间下来我对工业智能体的能力边界有了更清楚的认识。它能做的是有明确规则的重复性工作和有历史数据支撑的决策做不了的是需要创造性突破的设计和没有先例的异常处理。比如参数化建模、标准件选型、常规仿真设置这些智能体做得比人快得多。但全新的结构方案、颠覆性的工艺路线还是得靠人。智能体的价值不是替代工程师而是把工程师从重复劳动里解放出来让他们专注在真正需要创造力的地方。我在实际项目里踩过最大的坑是过度承诺。一开始跟用户说“什么都能干”结果用户拿一堆模糊需求来试智能体频频翻车信任度直接归零。后来学乖了明确告诉用户“这几类任务我能干那几类我干不了”反而口碑更好。还有一个体会是数据比模型重要。同样的模型架构喂了高质量领域数据的版本效果比通用版本好一个数量级。所以别急着换更大的模型先把数据整理好。最后分享一个小技巧让智能体学会说“我不确定”。工业场景里一个错误的确定答案比一个正确的“我不确定”危害大得多。我在智能体的输出里加了一个置信度字段低于阈值就自动转人工。这个机制上线后用户投诉率降了一半。这个方向后续还能往实时协同走——多个工程师和多个智能体在同一个模型上协作智能体之间互相协商工程师随时介入。这个场景的技术挑战还很大但我觉得是工业软件的下一个形态。
阅读完成 · 觉得有帮助？
模型详解与Python实现)
