摘要：MCP正在把AI从旁观者变成操作者。Autodesk官方下场、FreeCAD/Onshape社区桥接、Abaqus/Ansys/COMSOL仿真自动化、KiCad EDA自动化、ThingWorx/Rescale平台层扩散,工业软件MCP生态已经出现清晰分层。
如果把 2023 年的工业 AI 看成“问答助手”,2024 年看成"脚本助手",那么 2025 到 2026 年最值得关注的变化,就是 MCP 正在把 AI 从旁观者变成操作者。
MCP,即 Model Context Protocol,是 Anthropic 提出的开放协议,用来让 AI 系统以标准方式连接外部工具、数据源和业务系统。它解决的不是"模型会不会说",而是"模型能不能安全、规范、可审计地调用真实软件"。Anthropic 对 MCP 的定义很直接:开发者可以把数据和工具暴露成 MCP Server,AI 应用则作为 MCP Client 去连接这些能力。
放到工业软件里,这件事的意义非常大。因为 CAD、CAE、EDA、BIM、PLM、HPC 平台本来就高度依赖脚本、API、插件、参数化模型和工程数据。MCP 等于在这些传统接口之上,加了一层 AI 可理解、可发现、可调用的"工具协议"。未来工程师不一定要先打开软件、找菜单、写脚本,而可能直接说:帮我建立一个带四个螺栓孔的支架,做三组壁厚对比,检查最大应力,导出报告。后面的建模、求解、后处理、数据读取,都由 AI 通过 MCP 调用软件完成。
生态分层已经出现
目前工业软件 MCP 生态还处在早期,但已经出现了非常清晰的分层。
第一层:官方厂商下场
最重要的信号来自 Autodesk。Autodesk 已经推出 MCP Servers,定位不是简单插件,而是让 AI 能够连接 Autodesk 工具、数据和工作流,并在权限、安全、执行边界内直接采取行动。官方页面明确提到 Product Help MCP、Fusion MCP、Fusion Data MCP、Revit MCP 等方向,其中 Fusion MCP 可以让 AI 直接与本地 Fusion 会话交互,进行设计自动化;Product Help MCP 则让 AI 访问 110 多个 Autodesk 产品的实时帮助文档。
这说明大厂已经意识到:工业软件的 AI 化,不只是加一个聊天框,而是要把软件能力拆成可被 Agent 调用的工具。谁能把 CAD、CAM、CAE、BIM 的核心操作变成"受控工具集",谁就有机会定义下一代工程入口。
第二层:开源和社区生态最活跃
FreeCAD 是典型代表。FreeCAD MCP Addon 已经可以在 FreeCAD 内启动 RPC Server,并通过 Claude Desktop 等 MCP Client 连接,让 AI 执行建模相关操作。它的价值不在于功能已经超过商业软件,而在于它验证了一个模式:只要软件有 Python API、脚本接口或插件机制,就可以被 MCP 化。
Onshape 也是一个很适合 MCP 的对象,因为它本身是云端 CAD,REST API 相对清晰。社区中的 Onshape MCP Server 将 Onshape 的 API 包装成可编程 CAD 建模工具,使 AI 能够进行文档、特征、模型等层面的操作。CATIA V5 方向也已经出现社区 MCP Server,通过 Windows COM Automation 暴露 50 多个工具,覆盖零件、草图、装配、测量、STEP/IGES/STL 导出等能力。
第三层:CAE 和仿真软件开始被 MCP 接管工作流
这类生态比 CAD 更有想象力,因为仿真天然就是"参数-求解-结果-判断-再迭代"的闭环。Abaqus MCP Server 已经能够连接正在运行的 Abaqus/CAE GUI,通过 MCP 执行 Python 脚本并读取消息日志,本质上是把 Abaqus 的脚本能力暴露给 AI Agent。
Ansys 方向也有社区 MCP Server,目标是连接 Fluent、MAPDL、Mechanical、Geometry 等产品,提供会话管理、文件读取、命令执行、安装状态检查和工作目录管理等能力。Ansys/AGI STK 也出现了 STK-MCP,用于让 LLM 或 MCP Client 控制数字任务工程软件,支持 STK Desktop 和 STK Engine。COMSOL 方向则有 MCP Server 项目,覆盖模型管理、几何构建、物理场配置、网格、求解、结果可视化和知识集成。
这说明 CAE 的 MCP 化很可能比 CAD 更早产生生产力。因为 CAD 需要很强的几何意图理解,而 CAE 很多工作本来就可以模板化、参数化、批处理化。AI 不一定马上能替代资深仿真工程师,但可以先接管大量重复性工作:改参数、提交作业、读取 ODB/RST 结果、整理云图、生成对比表、发现异常工况。
第四层:EDA、BIM、HPC 和工业平台层的扩散
KiCad MCP Server 已经可以让 AI 助手与 KiCad 交互,完成 PCB 设计自动化,包括放置器件、创建符号和封装、布线、检查和导出生产文件。Revit 方向也有社区 MCP Server,提供 100 多个 Revit API 工具,覆盖几何、视图、图纸、族、MEP、结构等能力。
更值得注意的是平台层。PTC ThingWorx 已经把 MCP 作为 Beta/Preview 能力引入,强调通过把 ThingWorx Services 暴露成标准化工具、提示和资源,让 LLM 能够基于上下文调用平台能力。PTC 文档还明确指出,MCP 的价值在于把过去 M 个 AI 应用对 N 个数据源的 M×N 集成,压缩为标准化连接模式。Rescale 也推出 MCP Server,把本地 AI 客户端连接到 Rescale 平台,让自然语言命令可以转化为经过认证的 Rescale API 操作,用于提交仿真作业、查看状态和管理云端计算资源。
雏形已现，但尚未成熟
所以，工业软件 MCP 生态目前已经不是零星实验,而是出现了一个雏形:Autodesk 代表官方产品化,FreeCAD/Onshape/CATIA/Revit 代表 CAD/BIM 社区桥接,Abaqus/Ansys/COMSOL/STK 代表仿真工作流自动化,KiCad 代表 EDA 自动化,ThingWorx/Rescale 代表工业平台与云仿真层。
但也要看到,它还没有真正成熟。现在很多工业 MCP Server 仍然依赖本地 GUI 自动化、COM 接口、Python 脚本、HTTP Bridge 或 API 封装。它们能证明"AI 可以操作软件",但距离企业级工程落地还有距离。真正难的不是让 AI 点按钮,而是权限边界、版本管理、参数校验、单位一致性、仿真可信度、工程审签、日志审计和知识产权保护。MCP 官方规范也提醒,协议会带来任意数据访问和代码执行路径,因此安全、信任和用户授权是必须严肃处理的问题。
未来工业软件形态的三个变化
未来工业软件形态会因此发生三个变化。
第一,工业软件会从"GUI 中心"转向"Agent 中心"。GUI 不会消失,但会从主要操作入口变成审查、可视化和人工确认界面。真正的工作流入口,会逐渐变成自然语言任务、工程模板和 AI Agent。
第二,工业软件会从"单软件能力"转向"跨软件编排"。过去 CAD、CAE、PLM、MES、HPC 是分开的系统,工程师在人肉搬运文件。MCP 之后,AI 可以把这些系统串成任务链:从需求生成几何,从几何生成网格,从网格提交求解,从结果写回 PLM,从异常反馈给设计。
第三,工业软件竞争会从"功能多不多"转向"上下文深不深"。未来不是谁有聊天框谁先进,而是谁能把材料库、工艺库、历史仿真、实验数据、产品结构、制造约束和质量问题变成 AI 可调用的工程上下文。MCP 只是接口,真正的护城河是工程知识和可信执行体系。
国产工业软件的机会
对国产工业软件来说,这反而是一次机会。过去追赶国际 CAD/CAE 巨头,很容易陷入"重写一个巨型软件"的困境。但 MCP 时代可以换一种打法:先把已有求解器、几何内核、脚本接口、行业模板、数据资产和工程知识 MCP 化,变成 AI Agent 可调用的工具网络。谁能率先把工业软件从"人找功能"改造成"AI 调度能力",谁就可能在下一轮工业软件形态变化中占据入口。
工业软件的 MCP 生态,本质上不是插件生态,而是下一代工程智能生态的底座。它把工业软件从封闭工具,推向可组合、可调用、可编排的智能基础设施。CAD/CAE 的未来,也许不是一个更复杂的菜单,而是一组被工程规则约束、被 AI 调度、被人类审查的可信工具链。