"工业智能体"这个词，我第一次听到时以为是概念包装，直到自己动手做了一套面向CAD/CAE工作流的AI操作系统，才发现这个说法其实挺精准。它不是让你换掉手里的三维建模软件，也不是给仿真软件加一个AI助手插件，而是把从结构设计、几何处理、网格划分、求解计算到结果分析、方案寻优的整条链路，交给一个能理解任务、能调度工具、能沉淀经验的智能体去统一打理。

我在某个产品开发团队里见过太多这样的场景：工程师改一个参数，模型要重建、网格要重划、求解要重跑，结果出来之后还要手动对比三四个版本的数据。一轮下来，真正的设计思考时间可能只有两三个小时。我们做这套系统的目标很简单，把这两三小时之外的流程尽量压缩，让AI代替人去做那些重复、机械、依赖经验的环节。这篇文章就把整个系统的设计思路、关键实现和踩过的坑讲清楚，给想做类似事情的人一个参考。

1. 背景与定位：CAD/CAE工作流到底卡在哪里

1.1 传统工作流被切成了一地碎片

一个典型的结构设计任务，流程是固定的：三维建模、导出中性格式、几何清理、网格划分、施加材料载荷约束、求解、查看应力位移、根据结果改参数再来一轮。这个流程听起来标准，但真实环境远比教科书复杂得多。

第一道坎是格式转换。不同软件之间导一次STEP或IGES格式，经常丢面、破壳、小圆角变成锐边，拿回来就得修几何。第二道坎是几何清理依赖人工，简化圆角、去除小特征、抽取中面，老师傅一两个小时的活，新人上手快不起来。第三道坎是网格参数靠经验，同样的模型，网格尺寸、加密区域、单元阶次不同，结果可能差出20%以上。第四道坎是边界条件设置没有标准校验，载荷方向反了、约束漏掉一个自由度，求解能跑完，但结果彻底错了。

这些坎叠在一起，直接后果就是迭代周期被拉得很长。一个中等复杂度的支架，改一轮设计、出一次仿真结论，平均要两到三天。真正花在"怎么改设计"上的时间，可能不到半天，剩下的时间全耗在等流程、修数据、调参数上。

1.2 单点自动化为什么一直解决不了问题

很多团队其实已经尝试过自动化：写脚本批量出网格、用模板批量生成求解卡片、用Python批量采集结果。我自己也写过这类脚本，效果有一点，但很快会碰到天花板。

单点脚本只管自己那一段，前端模型一变，后端脚本可能就崩了。各个环节的数据格式不统一，脚本之间传参数全靠手工对齐字段。异常处理散落在每个脚本里，没有统一的重试和回滚机制。更麻烦的是历史经验没有沉淀，同样的网格事故、同样的参数错误，换个项目又踩一遍。

这恰恰是"AI操作系统"的定位价值所在。它不是一个单点工具，而是一个能编排全流程、能记住业务经验、能做决策兜底的中台。像手机操作系统管理各种App一样，它管理的对象是几何处理模块、网格工具、求解器、后处理脚本，以及它们之间的数据流转。哪个模块空闲就调度哪个，哪个环节失败就自动重试，哪组参数在历史项目中表现好就优先推荐，这种全局视角是单点脚本给不了的。

2. 整体架构：AI操作系统怎么设计

2.1 四层架构：感知、决策、执行、记忆

我最终落地的架构分四层，每一层的职责边界非常清楚。

感知层负责把所有外部输入标准化。不同格式的三维模型、参数表、材料库、工况描述、历史仿真报告，这些乱七八糟的输入进来，先统一成一个系统能理解的内部数据模型。这一层最花功夫的其实是格式解析和几何修复，因为输入永远比预期脏。

决策层是大脑，由大模型和规则引擎混合构成。大模型负责理解用户意图、把任务拆解成子任务、分析仿真结果并给出修改建议；规则引擎负责把关键业务规则硬编码，比如材料许用应力不得高于某个阈值、网格最小尺寸不得小于1mm、所有载荷必须明确方向向量。规则引擎不能省，因为大模型再聪明也可能在参数上产生幻觉，工业仿真参数一旦错了，算出来的结果就没有工程意义。

执行层负责真正调用CAD/CAE工具链。几何内核、网格器、求解器、后处理模块，每个模块都以适配器方式接入，执行层统一处理进程拉起、许可证队列、超时重试和结果回收。

记忆层负责把每一次仿真的设计参数、网格配置、结果摘要、修改决策记录下来，形成结构化知识库。这层最容易被忽视，但恰恰是"操作系统"区别于一堆脚本的关键。系统用得越久，越知道什么参数组合在自己团队的业务场景下靠谱。

2.2 底层工具选型：为什么我优先选开源内核

做底层选型时，我认真对比过商业闭源方案和开源方案。商业软件API稳定、功能全，但有两个绕不开的问题：一个是在集群环境批量部署时的许可成本，另一个是深度集成时的黑盒问题。商业软件的很多中间数据不开放，批量修改参数、重放历史操作这类事情很难做透。

所以我的底层优先选开源技术栈。几何处理用开源CAD内核，三维参数化建模用基于该内核的开源CAD平台的Python接口，网格划分用开源网格工具，求解端搭配开源的有限元求解框架。它们的共同优势是：所有中间结果都能拿到，出问题可以一路追到底层几何拓扑；可以完全脱离交互界面做批量建模、批量改参；可以自行封装统一API给上层调度。

缺点是曲面质量、破面修复、大装配性能相比商业软件有差距，所以要在感知层做兜底策略：模型导入后先做几何自动检测和修复，跑不过修复的模型直接拦截下来交给人工处理，绝不让坏几何流到网格环节。这个取舍让整体流程的失败率大幅下降。

2.3 AI大模型在架构里的角色边界

大模型在整套系统中的位置，我用一句话概括：负责语言和判断，不对参数直接负责。

大模型具体做四件事。第一是意图理解，把"以最大应力降到限值以下为目标，尝试两种板厚方案"这种自然语言翻译成结构化任务清单。第二是任务拆解，把一个大目标拆成建模、网格、求解、解读四个子任务，并指定执行顺序和依赖关系。第三是结果解读与建议，把求解器的数值结果转成工程师能读懂的结论，并给出下一轮参数调整建议。第四是知识问答，基于记忆层的历史数据回答"上次做类似结构用的什么材料"这类问题。

参数最终是否合法，要过规则校验层；执行是否成功，由执行层兜底。这样即使大模型输出有偏差，整个系统也不会失控。工程上这叫把不可控因素关在笼子里，业务规则永远优先于模型猜测。

3. 关键环节的实现细节

3.1 几何接入与参数抽取

第一步是把外部模型统一接入系统。导入时，我会把模型转成内部统一表示，这一步最常踩的坑是破面和丢特征。导入后要跑三段检查：拓扑检查，看壳面是否闭合、边是否连续；几何检查，看有没有微小线段、退化面；特征检查，看关键尺寸是否和参数表一致。

参数抽取是重点。对参数化设计，可以直接从模型的特征树里抓尺寸变量；对非参数化模型，只能做特征识别，例如通过识别圆柱面判断轴孔直径，识别平面和拉伸方向提取板厚。特征识别不能全自动就信任它，正确率到不了100%。我会把抽取出的尺寸导出成一个参数清单，由系统自动比对设计表中的名义值，偏差超过5%就触发人工审核。

这里有一个经验：识别出来的特征，一定要在三维视图里用不同颜色高亮显示。倒不是因为界面美观，而是工程师在审核时能一眼看出AI哪里认错了。有次系统把散热筋板误识别成变厚度区域，如果不做可视化审核，这个错误会一路带进网格和求解，最后整个应力分布都失真。

3.2 网格划分自动化与质量校验

网格划分是CAE环节里最容易出问题的一步。自动化替代人工的关键，是建立一套自适应加密加质量检查的策略。

我的做法分四步。第一步，根据模型尺寸自动计算基准网格尺寸，取包络盒对角线长度的1/50到1/20作为初始尺寸。第二步，曲率半径小的区域自动加密，最小网格尺寸设为基准值的1/10。第三步，薄壁结构单独识别，至少保证厚度方向有2到3层单元。第四步，所有网格生成后跑质量检查，检查内容包括负Jacobian单元数、最小单元角度、最大翘曲度。不合格区域自动局部重划，重划两次仍不合格就标记出来，交给人工判断。

还有一个工程上的选择值得展开：优先用一阶单元还是二阶单元。二阶单元计算更准，但网格量大了求解时间涨得很快；一阶单元适合初步寻优，我们会在批量寻优阶段用一阶，最终验证阶段再切到二阶。这个策略让整个迭代效率提升了不少，代价是维护两套求解配置，对调度层要求更高，需要在任务卡片里明确标注单元阶次。

3.3 求解任务编排与结果解读

求解编排的关键，是把一次仿真任务变成一张可重复执行的卡片。卡片内容包括求解器类型、单元类型、材料卡片、边界条件、载荷、控制字设置、输出请求。我用JSON来描述卡片，这样AI层和规则层可以很轻松地生成和校验。所有人工输入的边界条件，都会在求解前被规则层逐条核对一遍，比如所有节点是否都有约束、是否出现未定义材料属性的单元。

结果解读方面，我一般分三步走。数值提取，解析结果文件取出最大应力、最大位移、应变能等关键指标。位置定位，定位最大应力所在单元和节点，换算成三维坐标，回填到CAD模型上高亮显示。工程判断，把数值与允许值比较，给出"低于限值、接近限值、超限"的分级，并计算剩余安全裕度。

步骤看起来简单，但实际过程中有两个坑。一个是最大应力经常出现在应力奇异的局部，比如尖角、刚性约束点附近，这些位置的数值对网格密度极其敏感，不能直接作为判断依据。我的做法是加一个排除区规则，把约束点周围一圈单元排除在最大应力统计范围之外。另一个是位移结果和应力结果可能对应不同的危险位置，决策层必须同时看两个指标，不能只盯应力。

3.4 多轮迭代闭环的设计

做自动寻优时，核心是一个闭环：第n轮结果交给决策层，决策层根据超限程度调整设计参数，生成第n+1轮的建模参数，再触发下一轮流程。这个环节最怕AI为了收敛而乱改参数，所以我强加两个约束：单轮只改不超过两个关键参数；参数步长限制在初始值的5%到15%之间。

每次迭代必须保留完整的数据快照，包括模型文件、网格文件、求解输入、结果摘要、参数修改记录。不能只存最终版本，因为工程师经常需要回溯到中间某一轮去查"到底哪次改的圆角导致应力下降了"。如果快照不完整，回溯成本会高得让人放弃溯源，那前面的自动化就白做了。

4. 实操记录：一个支架设计仿真全流程跑通

4.1 环境准备与工具链清单

我落地的最小可行技术栈是这样一套组合：Python 3.10作为编排语言；几何内核用开源CAD内核库；三维建模脚本基于开源CAD平台的Python接口；网格划分用开源网格工具；求解端用开源的有限元求解框架；AI推理用本地部署的量化模型，避免把设计数据传到外部服务。

工作目录按以下结构组织：

workspace/ models/ # 中间模型文件 mesh/ # 网格文件 cases/ # 每次仿真的任务卡片和输入 results/ # 结果文件和解读报告 knowledge/ # 结构化历史知识库

这里有个经常被忽略的点：环境一致性。CAD/CAE这类工具链对版本极其敏感，依赖库的版本一变，结果可能就不可复现了。所以强烈建议把所有工具装在容器镜像里，连求解器的编译环境都锁定，每次跑实验用一个全新容器。我们早期因为贪方便直接复用宿主机环境，结果有一次网格结果莫名其妙和上周不一致，查了两天才发现是底层库被自动升级了，从那以后所有实验都改成容器化执行。

4.2 Agent编排的代码骨架

整套流程我用Agent方式编排，每个环节一个Agent，它们之间通过消息传递任务。这里是简化后的同步编排逻辑，方便看思路：

def run_iteration(design_params, history): # 1. 建模Agent：用参数生成CAD模型，导出中性格式 model_file = cad_agent.build(design_params) if not cad_agent.quality_check(model_file): return "failed", "模型质量检查未通过" # 2. 几何Agent：清理几何、抽取特征参数、回写参数表 clean_model = geometry_agent.prepare(model_file) extracted = geometry_agent.extract_params(clean_model) verify_result = rule_engine.verify_params(extracted, design_params) if not verify_result["is_ok"]: return "failed", f"参数校验失败: {verify_result['reason']}" # 3. 网格Agent：自适应划网 + 质量校验 mesh_file = mesh_agent.generate(clean_model, strategy="adaptive") mesh_report = mesh_agent.quality_check(mesh_file) if mesh_report["min_quality"] < 0.3: return "failed", "网格质量不达标" # 4. 求解Agent：生成任务卡片、排队、求解 case_id = solver_agent.submit(mesh_file, design_params["boundary"]) results = solver_agent.wait_finish(case_id) # 5. 解读Agent：提取指标、定位危险区、给出判断 summary = post_agent.analyze(results, design_params["limits"]) history.append(summary) # 6. 决策Agent：判断是否收敛，决定下一轮参数 if summary["status"] in ("converged", "need_review"): return summary, design_params next_params = decision_agent.suggest(design_params, summary, history) return "iterating", next_params

实际生产里每个Agent都是独立进程，通过消息队列通信，一轮失败可以单独重试。同步版本虽然少了并发，但胜在逻辑清晰，适合把流程跑通后再做并行化。Agent之间传递的都是结构化JSON，字段名有约定，比如"model_file"、"mesh_file"、"boundary"、"limits"，这样每个Agent的内聚度很高，替换底层工具时只需要改适配器。

4.3 一个实际跑通的迭代案例

用一个圆孔支架做例子。初始设计参数：板宽80mm、高60mm、厚度6mm，圆孔直径10mm，受向下30kN的拉力。第一轮，AI生成的网格在厚度方向只有一层单元，结果最大应力280MPa，超过材料许用应力240MPa，被判定为超限。

决策层分析后给出修改建议：厚度提高到9mm，圆角从1mm改成3mm。第二轮重新建模、划网、求解，最大应力降到198MPa，低于限值。第三轮系统看还有优化空间，把厚度微调到8.5mm再验算，应力201MPa仍然满足，于是自动选择8.5mm版本作为推荐方案。整个过程跑了三个多小时，大头在网格和求解，人工只做了一个审核动作。

这个案例让我意识到，AI操作系统最值钱的能力不是单次仿真跑得多快，而是它能在一晚上把工程师两天的工作量做掉，并且每一轮的改动依据都留在知识库里，随时可以回溯。对团队来说，这才是真正的效率提升。

5. 工程化踩坑：常见问题与排查实录

5.1 问题速查表

我把实际运作中容易遇到的问题整理成一个速查表，按优先级排序：

5.2 几个值得展开的排查思路

第一个是几何内核崩溃。这个问题在长时间批量跑任务时几乎必然出现。单独一个进程崩了不可怕，可怕的是整个编排被拖死。我的做法是每个CAD/CAE调用都包一层进程隔离，崩了自动拉起，同时把崩溃时的模型特征ID写进日志。连续三次在同一个特征上崩溃，就判定该模型有问题，转到人工处理队列。

第二个是求解器许可证排队。求解器并发额度有限，任务一多就容易卡死。排查时不能只看任务状态，要看许可证占用时长和任务实际计算时长。解决方案是给等待任务设置递增超时，超过三个等待周期就释放许可证给更高优先级的任务，避免一个算不完的大模型把整个队列堵住。

第三个是大模型的参数幻觉。早期我把大模型直接输出参数值，结果出现过密度写成负数的离谱错误。后来所有参数输出先过一个JSON Schema校验，再进规则引擎做物理范围检查。规则引擎兜底的数据，只要不在合法区间，一律用默认值替换并标记"由规则层修正"，同时记录到系统日志。这个改动让参数类错误降到了几乎为零。

5.3 关于数据历史积累的几点建议

记忆层是这套系统能不能越用越值钱的关键。强烈建议从第一天就把每一轮实验的记录结构化。最少要记录这六个字段：设计参数、模型文件路径、网格文件路径、求解器版本、结果摘要、修改决策。其中求解器版本容易被忽略，但没有版本信息，历史数据根本无法对比。

知识库的组织方式，我建议按产品族分类，不要只按时间序。同一个产品族的零件结构相似，参数经验可以互相复用。比如A零件上验证过的网格密度策略，大概率可以直接应用到B零件上。如果知识库只按时间堆，检索时很难找到有价值的参考。

这套系统和别的系统不太一样，它是越跑越聪明的。但前提是你得长期维护知识库的质量，垃圾进垃圾出。我们会定期做一次知识清理，把过时参数、错误建议打上标记，保证决策层不会从历史数据里学到错误经验。

6. 几点个人体会

做这套AI操作系统的过程里，我最大的体会是：难点不在AI模型选得多强，而在你愿不愿意把业务经验变成规则、把历史数据变成资产。很多人觉得用上大模型就万事大吉，实际落地时真正让系统稳定运行的，是规则引擎里那几十条朴素的经验规则，以及知识库里几万条干净的历史记录。

如果你也想做类似的事情，我的建议是别一开始就铺大平台。先挑一个你最熟悉、迭代最耗时的零件类型，把单点流程跑通，再逐步扩展。先用脚本把自动化做了，再让AI介入决策，最后才谈系统编排。走稳这一步，比一开始就追求"AI全能"要靠谱得多。

最后分享一个实用习惯：每次跑批任务之前，花五分钟检查一遍工作目录里有没有上次任务留下的临时文件。看似不起眼，但有一次我们就是被一个残留的旧数据库影响了参数匹配，排查了一整个下午。干净的文件组织习惯，在这个领域真的能省下大把时间。