Ansys-Control-MCP：我开发MCP+PyAnsys，让AI受控地操作ANSYS
导读：上次跟大家聊了我在仿真秀官网在ANSYS二次开发教程中新增AI驱动Mechanical仿真内容，有同学问：小郭老师，这个东西到底能解决我什么问题？今天不聊概念，先说说我们做ANSYS二次开发的人，天天都在面对的几件事：
改一个参数，半天没了；复现一篇论文，两周起步；带学生做毕设，几十个工况跑下来，人累得够呛还容易出错。这些问题的本质，不是我们不会写脚本，而是脚本写完之后，"调参、复现、批量跑"这些事，依然要靠人盯着。所以我接着往下做了Ansys-Control-MCP 这个项目。今天这篇，就把它的来龙去脉讲清楚。
一、事件缘由
最近我在开发一个项目：Ansys-Control-MCP。它的目标是基于 MCP、pyansys-common-mcp 和 PyAnsys，做一个 AI 可以调用的 ANSYS 控制工具。做这个项目，并不是为了做一个简单的“聊天控制 ANSYS”的演示，而是想解决一个更实际的问题：ANSYS 自动化能力已经很多了，比如 Workbench Journal、Mechanical Script、PyWorkbench、PyMechanical、PyAnsys Geometry，但这些能力大多仍然停留在“工程师写脚本、工程师运行脚本”的阶段。
我希望推进的是另一种工作方式：AI 不只是生成脚本，而是能够在受控的工程软件环境中调用工具、读取状态、处理错误，并继续推进下一步仿真流程。在这个方向下，我正在研究一个应用案例：仿真论文的一键自动复现。
这里要说明，这不是一个已经完全成熟的产品功能，而是我基于 Ansys-Control-MCP 正在探索的应用场景。它的目标是：当我们拿到一篇结构仿真、热分析、流固耦合或其他 CAE 相关论文时，AI 不只是总结论文内容，而是进一步尝试把论文中的建模逻辑、材料参数、边界条件、载荷设置、求解流程和结果验证步骤，转化为可执行的 ANSYS 自动化流程。
这个应用案例可以拆成几个关键动作：
从论文中识别几何结构和建模参数；
自动生成或导入几何模型；
设定材料参数；
读取并转换边界条件；
设置载荷、约束、网格和分析类型；
自动提交计算；
提取结果并与论文中的图表或关键指标进行对比；
形成可复现、可追踪、可修改的仿真流程。
这不是单个脚本可以完整解决的问题。它需要 AI 能够读取论文、理解工程语义、调用 ANSYS 工具、检查模型状态、根据错误反馈调整脚本，并在同一个工程上下文中持续推进。
所以我开发 Ansys-Control-MCP 时，重点不是追求“功能堆满”，而是先把一条可靠的控制链路打通：让 AI 能够通过 MCP 工具调用 Workbench、Geometry 和 Mechanical，并且每一步都有明确返回、错误提示、warning 和下一步建议。
二、技术思路：Skill 负责操作纪律，MCP 负责工具调用
在介绍 ansys-control-mcp 之前，需要先讲清楚两个概念：Skill 和 MCP。
2.1 什么是 Skill
在我的工作流里，Skill 可以理解为给 AI Agent 使用的一套“专业操作规程”。它不是一个直接执行 ANSYS 的工具，而是一组本地规则、知识边界、流程约束和经验沉淀。比如当 AI 要操作 ANSYS 时，Skill 会告诉它：
先确认项目边界
不要乱扫无关目录
不要把真实 ANSYS 项目保存到代码仓库
Workbench 操作优先走 PyWorkbench
Mechanical 操作优先走 PyMechanical
修改模型前先 inspect
失败后不要盲目重试
不要杀 ANSYS license 进程
所以，Skill 更像是“操作纪律层”。它解决的是：AI 应该怎么想、怎么判断、怎么避免低级错误。
2.2 什么是 MCP
MCP 是 Model Context Protocol，可以理解为 AI Agent 调用外部工具的一套协议。如果说 Skill 规定了 AI 的行为习惯，那么 MCP 负责把外部工具暴露成 AI 可以调用的接口。
在Ansys-Control- MCP 中，MCP 工具包括：
workbench_launchworkbench_open_projectworkbench_list_systemsworkbench_open_geometry_uiworkbench_import_geometry_fileworkbench_update_geometry_and_modelworkbench_open_mechanical_uiworkbench_start_mechanical_servermechanical_connectmechanical_inspect_modelmechanical_run_scriptgeometry_launchgeometry_export_design
AI 不直接操作 ANSYS 内部对象，而是通过这些 MCP tools 一步步调用。每个工具都会返回结构化结果：
这样 AI 不需要猜测执行是否成功，而是根据 ok、warnings、errors 和 next_actions 决定下一步。
2.3 Skill、MCP 和 ansys-control-mcp 的关系
这三者的关系可以概括为：
Skill：告诉 AI 如何安全、专业地操作MCP：提供 AI 调用工具的协议ansys-control-mcp：具体实现 ANSYS 控制工具PyAnsys：真正连接 Workbench、Geometry、Mechanical
也就是说，ansys-control-mcp 是工具层，chatANSYS skill 是操作纪律层。
如果某个行为可以做成确定、可复用的工具，就放进 ansys-control-mcp；如果某个行为属于 AI 的判断习惯、安全边界、错误恢复策略，就放进 chatANSYS skill。
2.4 chatANSYS skill 的自进化能力
我在开发 ANSYS MCP 工具时，非常重视 chatANSYS skill。
因为 ANSYS 不是普通命令行工具。Workbench、Mechanical、SpaceClaim 都是重状态工程软件。一次错误保存、一次错误更新、一次错误覆盖边界条件，都可能影响真实工程项目。
所以 chatANSYS skill 的作用，是给 AI 设定操作边界。
例如：
优先复用已有受控 Workbench session可见 UI 启动时要验证窗口和端口Workbench 操作通过 PyWorkbench journalMechanical 操作通过 PyMechanical打开 Mechanical 前走 Model container/component Edit修改 Mechanical 前先 inspect_model操作后必须 fresh readback不要杀 ansyslmd.exe 或 lmgrd.exe
更重要的是，chatANSYS skill 不是一份静态说明，而是有受控的自进化机制。
它的基本循环是：
发现一次 ANSYS 操作事故记录 incident归类问题边界生成候选改进规则必要时增加 eval case人工审查后更新 Skill 或参考文件运行回归检查
这里的自进化，不是让 AI 自动改写自己的规则文件，而是把实际操作中的错误沉淀成新的 guardrail。例如，如果 AI 在某次操作中犯了低级错误，比如：
把打开 UI 当成已经连接成功在没有 inspect 的情况下修改 Mechanical 模型错误地把 ANSYS 项目保存进代码仓库遇到 Workbench 启动失败后盲目重复启动
这些问题就可以被记录成 incident。后续如果同类问题重复出现，或者问题涉及项目数据、许可证、隐藏 UI 状态、错误物理设置，就可以提升为新的硬规则。
这对 ANSYS 自动化非常重要。因为很多错误不是语法错误，而是工程流程错误。传统脚本出错，通常靠工程师记住教训；而 AI Agent 如果没有经验沉淀机制，下次可能还会犯同样错误。
chatANSYS skill 的价值就在于：
把一次错误变成一条 guardrail把一条 guardrail 变成可检查规则把可检查规则变成后续操作的默认纪律
三、核心实现：基于 pyansys-common-mcp 的 ANSYS 控制层
ansys-control-mcp 采用了比较清晰的分层设计：
我没有把所有逻辑塞进一个大函数里，而是拆成几个层次：
tools：负责 MCP 参数、返回值和错误封装；adapters：负责调用 PyAnsys 相关客户端；templates：负责生成 Workbench Journal 和 Mechanical Python；core：负责 session registry、audit、runtime path 和统一结果结构。
3.1 Server 入口
项目入口在 server.py。我优先使用 ansys.common.mcp 中的 PyAnsysBaseMCP。如果当前环境没有安装 ansys-common-mcp，则回退到 FastMCP，这样单元测试和离线开发也能继续进行。
核心结构可以概括为：
这里有一个重要设计：server 启动时不自动打开 ANSYS。
因为 Workbench 和 Mechanical 都是重状态软件。启动软件、打开项目、更新模型、保存文件，都可能改变工程状态。所以这些动作都应该由明确的 MCP tool 触发，而不是 server 一启动就自动执行。
3.2 Context：保存 Workbench、Geometry、Mechanical 会话
我在项目中定义了 AnsysControlContext：
@dataclassclassAnsysControlContext(PyAnsysBaseAppContext):sessions: SessionRegistry = field(default_factory=SessionRegistry)jobs: JobRegistry = field(default_factory=JobRegistry)audit: AuditRegistry = field(default_factory=AuditRegistry)workbench_adapter: WorkbenchAdapter = field(default_factory=WorkbenchAdapter)mechanical_adapter: MechanicalAdapter = field(default_factory=MechanicalAdapter)geometry_adapter: GeometryAdapter = field(default_factory=GeometryAdapter)
当 AI 调用 workbench_launch 后，会得到类似 wb_001 的 session。调用 mechanical_connect 后，会得到类似 mech_001 的 session。调用 geometry_launch 后，会得到类似 geom_001 的 session。
后续工具都通过 session_id 找回对应客户端。
这对 AI 控制工程软件非常关键。因为真正的仿真流程不是一次性命令，而是一连串状态相关的操作：
打开项目读取系统导入几何更新模型打开 Mechanical检查模型树设置边界条件求解导出结果保存工程
如果每一步都重新启动软件，流程会非常脆弱。
3.3 Workbench、Geometry、Mechanical 三条控制线
Workbench 层使用 PyWorkbench，主要负责：
启动 Workbench连接已有 Workbench server打开或创建 .wbpj 项目列出 Workbench systems打开 Geometry UI导入 Geometry 文件更新 Geometry 和 Model打开 Mechanical UI启动 Mechanical server保存和断开 Workbench
例如几何文件导入，底层 Workbench Journal 使用：
geometry = system.GetContainer(ComponentName="Geometry")geometry.SetFile(FilePath=r"D:\case\part.step")
如果需要打开 Workbench 原生 Geometry 编辑器，则使用：
geometry.Edit(IsSpaceClaimGeometry=True)Geometry 层使用 PyAnsys Geometry，当前能力包括：
geometry_launchgeometry_connectgeometry_create_designgeometry_import_filegeometry_inspect_stategeometry_inspect_modelgeometry_run_script_filegeometry_export_designgeometry_disconnect
这为自动建模、CAD 导入导出、SpaceClaim/Discovery 脚本执行提供了基础。
Mechanical 层使用 PyMechanical。核心能力是连接 Workbench 启动的 Mechanical server，并在同一个 session 中反复执行 Mechanical Python。
关键逻辑类似：
defrun_script(self, client, script, timeout=60, purpose=None):if timeout != 60:raise ValueError("timeout is not supported by PyMechanical run_python_script in this version.")result = client.run_python_script(script)return { "script_index": self._script_counts[client_key],"result": result,}
这里我没有假装自定义 timeout 一定生效。当前 PyMechanical API 没有可靠暴露可强制执行的脚本超时机制，所以工具会拒绝非默认 timeout。
工程自动化工具不能为了接口好看而给用户错误预期。
四、应用案例：仿真论文一键自动复现
“仿真论文一键自动复现”是我正在研究的一个应用案例。
它不是当前项目已经完全成熟的功能，而是基于 ansys-control-mcp 这个底层控制框架继续向上探索的方向。
这个应用案例可以拆成：
论文输入
AI 提取几何、材料、边界条件、求解设置Geometry 自动建模或导入Workbench 接入 GeometryMechanical 设置材料和边界条件自动网格与求解提取结果与论文结果对比根据误差继续修正
用流程图表示
在这个过程中，MCP 工具链的价值是让 AI 的每一步行动都有边界。AI 不再只是输出一段不可控脚本，而是通过工具逐步推进：
打开项目检查系统导入几何更新模型检查 Mechanical 树写入材料设置边界条件执行计算读取结果继续修正
如下图所示，就是一个复现论文的运行结果。可以看到，误差小于5%。
五、总结：从脚本自动化到 Agent 工程控制
开发的这个 ansys-control-mcp，本质上是在探索一个方向：未来 ANSYS 二次开发不会只停留在“写一个脚本自动点几步”，而会逐渐走向“把工程操作封装成 AI 可调用的工具体系”。
它当前最核心的价值是：
明确的工具边界可复用的 session可读的模型状态可追踪的脚本执行记录可恢复的错误处理流程Workbench、Geometry、Mechanical 分层扩展chatANSYS skill 提供操作纪律和自进化能力
MCP 让 AI 可以调用工具，PyAnsys 让 Python 可以进入 ANSYS 产品体系，ansys-control-mcp 把这些能力组织成工程控制层，而 chatANSYS skill 则在操作层面不断沉淀经验和边界。
过去我们做 ANSYS 自动化，常见方式是：
写脚本运行脚本成功或失败人工排查
而现在开发的方向更接近：
定义工具注册工具AI 调用工具工具返回状态AI 根据状态继续执行错误进入经验沉淀Skill 形成新的操作边界
这不是单纯的代码封装，而是工程工作流的重构。
在 AI + CAE 的背景下，工程师真正需要掌握的，不只是某个按钮怎么点，也不只是某段脚本怎么写，而是如何把重复性仿真流程抽象成可复用、可追踪、可扩展的自动化系统。
六、AI 驱动 Ansys Mechanical仿真
以下是课程大纲及主要内容：
