Claude、Codex、DeepSeek控制ANSYS：从Skill&MCP到仿真论文复现研究
1. 引言：我为什么开发这个 AI 控制 ANSYS 的工具
大家好，我是小郭老师。
最近我在开发一个项目：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 和下一步建议。
2. 技术思路：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_launch
workbench_open_project
workbench_list_systems
workbench_open_geometry_ui
workbench_import_geometry_file
workbench_update_geometry_and_model
workbench_open_mechanical_ui
workbench_start_mechanical_server
mechanical_connect
mechanical_inspect_model
mechanical_run_script
geometry_launch
geometry_export_designAI 不直接操作 ANSYS 内部对象，而是通过这些 MCP tools 一步步调用。
每个工具都会返回结构化结果：
{
"ok": true,
"tool": "tool_name",
"session_id": "wb_001",
"data": {},
"warnings": [],
"errors": [],
"logs": [],
"next_actions": []
}这样 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 journal
Mechanical 操作通过 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 变成可检查规则
把可检查规则变成后续操作的默认纪律3. 核心实现：基于 pyansys-common-mcp 的 ANSYS 控制层
ansys-control-mcp 采用了比较清晰的分层设计：
AI Agent / MCP Client
|
v
ansys-control-mcp server
|
v
tools/ MCP 工具入口
adapters/ PyWorkbench / PyMechanical / PyAnsys Geometry 封装
templates/ Workbench Journal 和 Mechanical Python 模板
core/ session、环境检查、审计、统一返回结构
|
v
ANSYS Workbench / Geometry / Mechanical我没有把所有逻辑塞进一个大函数里，而是拆成几个层次：
•
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，这样单元测试和离线开发也能继续进行。
核心结构可以概括为：
class AnsysControlMCP(PyAnsysBaseMCP):
def __init__(self, *args, **kwargs):
self.control_context = AnsysControlContext()
super().__init__(*args, **kwargs)
def create_context(self):
return self.control_context
def product_startup(self):
pass这里有一个重要设计：server 启动时不自动打开 ANSYS。
因为 Workbench 和 Mechanical 都是重状态软件。启动软件、打开项目、更新模型、保存文件，都可能改变工程状态。所以这些动作都应该由明确的 MCP tool 触发，而不是 server 一启动就自动执行。
3.2 Context：保存 Workbench、Geometry、Mechanical 会话
我在项目中定义了 AnsysControlContext：
@dataclass
class AnsysControlContext(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_launch
geometry_connect
geometry_create_design
geometry_import_file
geometry_inspect_state
geometry_inspect_model
geometry_run_script_file
geometry_export_design
geometry_disconnect这为自动建模、CAD 导入导出、SpaceClaim/Discovery 脚本执行提供了基础。
Mechanical 层使用 PyMechanical。核心能力是连接 Workbench 启动的 Mechanical server，并在同一个 session 中反复执行 Mechanical Python。
关键逻辑类似：
def run_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。
工程自动化工具不能为了接口好看而给用户错误预期。
4. 应用案例：仿真论文一键自动复现
“仿真论文一键自动复现”是我正在研究的一个应用案例。
它不是当前项目已经完全成熟的功能，而是基于 ansys-control-mcp 这个底层控制框架继续向上探索的方向。
这个应用案例可以拆成：
论文输入
-> AI 提取几何、材料、边界条件、求解设置
-> Geometry 自动建模或导入
-> Workbench 接入 Geometry
-> Mechanical 设置材料和边界条件
-> 自动网格与求解
-> 提取结果
-> 与论文结果对比
-> 根据误差继续修正用流程图表示
在这个过程中，MCP 工具链的价值是让 AI 的每一步行动都有边界。AI 不再只是输出一段不可控脚本，而是通过工具逐步推进：
打开项目
检查系统
导入几何
更新模型
检查 Mechanical 树
写入材料
设置边界条件
执行计算
读取结果
继续修正如下图所示，就是一个复现论文的运行结果。可以看到，误差小于5%。
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 的背景下，工程师真正需要掌握的，不只是某个按钮怎么点，也不只是某段脚本怎么写，而是如何把重复性仿真流程抽象成可复用、可追踪、可扩展的自动化系统。
点击阅读原文，立即学习《ANSYS Workbench & Mechanical企业级二次开发程序与Python应用入门进阶》，掌握ANSYS Workbench & Mechanical的脚本自动化开发能力。
ANSYS Workbench & Mechanical企业级二次开发程序与Python应用入门进阶
本课程从基础脚本开发到多工况批量计算的自动化实现，手把手教你用 Python 打通 “仿真流程自动化 - 多工况批量计算” 全链路，让 “重复仿真工作自动化、复杂工况高效计算” 从想法变成日常。
我还为付费用户提供VIP群进行交流、答疑服务、持续加餐内容、提供定制化培训和咨询服务、仿真人才库高薪内推就业、仿真秀还提供奖学金、学完此课程，推荐学习者报名参加工程仿真技术（CAE分析职业能力等级评价证书）。
以下是课程大纲及主要内容：
