NX / Designcenter 的开源类 AI 工具：实现路径、现有项目与能力范围

Siemens 官方对 NX（现称 Designcenter）的 AI 布局，本站前文已有梳理。本文换一个角度：目前外部 AI 智能体如何通过模型上下文协议（Model Context Protocol，MCP）和 NXOpen 接口操作 NX，已有哪些工具，它们各自能做什么。资料来自 GitHub 仓库的说明文档、厂商页面和第三方服务商页面，检索与核对截至 2026 年 10 月 26 日；本文没有安装或运行任何一个工具，文中的工具数、版本和验证情况均为项目自述，星标数只是关注度指标。

1. 背景：官方尚无建模类 MCP，现有工具来自社区与服务商

Siemens 官方 What's New 页将 Designcenter MCP 列入 2026 年 12 月版本，截至核对日尚未发布 [14]，详见本站前文 西门子 NX 的 AI。服务商 inteliScience 与 innfactory 的页面也都称，据其所知不存在面向 NX 建模操作的官方 MCP 服务器 [11][13]。因此，本文涉及的工具都不是 Siemens 的官方产品，而是开源社区项目和第三方服务。

这些项目出现得很晚。本文核对的 NX 操作类开源项目创建于 2026 年 4 月至 10 月之间，最早的是 4 月的 NX_MCP，其余集中在 7 月之后 [1][2][3][4][5][6][7]；Teamcenter 方向的 MCP 项目则早到 3 月 [9]。

2. 实现路径

2.1 通用结构

所有操作类项目的结构大体一致：AI 客户端通过标准输入输出与 MCP 服务端通信；MCP 服务端把工具调用转为对本机 NX 的请求；NX 内部有一个桥接程序，在 NX 进程中调用 NXOpen 完成建模，再把结果返回。

图 1：本文依据 NX_MCP、nx-auto-mcp 与 CAD-Agent-Hub 的说明文档归纳的通用结构，具体通信方式因项目而异。图由 CADFrontier 绘制。

各项目在三个环节上有差别：MCP 服务端用什么语言（Python 或 Node.js）；服务端与 NX 之间用什么本机通道；NX 里的桥接程序是什么形态。

2.2 四种桥接方式

方式	做法	代表项目	特点
常驻的 C# 插件	编译成 NX 托管插件，NX 启动时加载，在 NX 进程内监听本机端口或管道	nx-auto-mcp（TCP）[3]；NX_MCP 的 C# 界面桥（环回 JSON-RPC）[1]；CAD-Agent-Hub（.NET Remoting）[4]；nx-codex（命名管道）[5]	响应快，可在已打开的 NX 窗口内操作；需自行编译和签名
常驻的 Python 外挂	在 NX 中用日志（Journal）启动一个 Python 外挂，随 NX 常驻并提供面板	skyf0l/siemens-nx-mcp [2]	说明中的安装步骤是 pip 安装并在 NX 中播放日志，未要求编译；外挂面板显示智能体动作
批处理日志	每次调用或每个会话由 run_journal 启动 NX 进程，通常无界面	NX_MCP 的 Python 批处理桥 [1]；nx12-cli-mcp [8]	简单；启动有固定开销，不接管用户当前窗口
知识检索	不操作 NX，而是为写 NXOpen 代码的智能体提供准确的 API 文档	nxopen-mcp [7]	降低代码编写时的 API 幻觉，需要本机已安装的 NX 文档

nx-auto-mcp 的说明给出了前两类的差别：常驻插件的往返时间通常为 10–50 毫秒，而每次日志运行都要新启动 NX 进程，至少有 1.5 秒的固定开销 [3]（项目自述）。同一文档也建议，修改已有零件或查询状态用工具，大批量从零建模仍以日志更合适 [3]。

2.3 共同的设计取舍

几个项目的文档反复出现同样的设计问题：

• 类型化工具还是通用代码执行。 NX_MCP 默认只公开有类型的工具 [1]，nx-codex 的桥接程序不暴露原始 NXOpen 会话对象 [5]；CAD-Agent-Hub 提供 run_python，但默认需显式启用 [4]；nx-auto-mcp 的日志通道只接受 C# 文件 [3]。
• 读写分层与撤销。 NX_MCP 的对象编号只是会话内引用，撤销或重开后需要重新查询；执行状态未知的变更不得自动重放 [1]。
• 谁拥有哪个零件。 skyf0l 的外挂只在用户勾选“允许智能体修改该零件”后才改动或保存；并可选“先询问我”模式，使每一步等待确认 [2]。nx-sketch-mcp 要求用户明确授权后才接管指定零件 [6]。
• 只在本机。 NX_MCP 的桥接程序只绑定 127.0.0.1，并用会话令牌验证请求 [1]。

2.4 使用前提

这些项目共同的前提是：Windows、本机安装并有许可的 NX、对应版本的 NXOpen。多数需要自行搭建环境：nx-auto-mcp 的仓库不含预编译 DLL，因为 NX 要求托管插件由本机的 SignDotNet 签名 [3]；NX_MCP 的说明也提到加载未签名 DLL 需要 NX Open .NET 作者许可 [1]。

3. 现有工具

下表按能力范围由宽到窄排列。星标和更新时间为 2026 年 10 月 26 日的读数，会变化。

项目	形态与路径	工具数（自述）	声明验证的 NX 版本	许可、星标、创建日期
skyf0l/siemens-nx-mcp [2]	Python MCP 服务端 + NX 内常驻外挂	说明称 269（工具文档列出约 270 个）	2406 已测；2412–2606 预期可用	MIT，4 星，2026-10-09
cyw2527/nx-auto-mcp [3]	Node.js 适配层 + TCP + C# 插件	覆盖表 115；契约快照 123；说明首段称 130+	针对 2412 开发	MIT，8 星，2026-09-20
Cai-aa/CAD-Agent-Hub 中的 MCP/UG [4]	Python MCP + .NET Remoting 桥	说明文档列出的工具名约 70 个	2412	MIT，117 星（整个仓库），2026-07-28
DreamEnding/NX_MCP [1]	Python 服务端 + C# 界面桥或 Python 批处理桥	默认 16；另有 34 个隐藏的旧工具	批处理 2506；界面桥 2206（均为开发版验证）	MIT，145 星，2026-04-17
hcjrcsol123/nx-sketch-mcp [6]	标准库 Python + .NET 桥	20	2506	未见许可，0 星，2026-10-11
jiaotashidi-bi/nx-codex [5]	Codex 插件 + 命名管道 + C# 桥	受限的类型化集合	仅 NXOpen 12.0.2.9	未见许可，1 星，2026-08-08
Voss0919/nx12-cli-mcp [8]	NX 12 日志 + CLI/MCP	3 个公开工具	NX 12	未见许可，1 星，2026-09-29
mingfeng6684/nxopen-mcp [7]	文档检索，不驱动 NX	检索类	取决于本机 NX 文档	MIT，17 星，2026-07-15

图 2：各项目自述的工具数量。统计口径不同，数量不代表能力或成熟度；NX_MCP 为默认工具数。图由 CADFrontier 绘制。

两点需要注意。其一，工具数的口径不一致：NX_MCP 的 GitHub 简介仍写“47+ 工具”，其说明文档则写默认暴露 16 个工具，另有 34 个旧工具默认隐藏且未验证 [1]；nx-auto-mcp 的说明首段称 130+ 个工具，同一文档的覆盖表合计为 115 个，仓库内的契约快照列出 123 个 [3]。其二，星标最多的 NX_MCP 并不是工具最多的项目，也仍标注为开发预览 [1]。

此外还有两类相邻项目：Teamcenter 的 MCP 服务器通过 REST 接口访问部件、BOM、数据集和变更流程，不需要打开 NX [9]；cam-agent-showcase 是一个脱敏的 CAM 智能体复现，用语言模型提出加工意图，再由确定性校验器和计划生成器处理，NX 执行器只是接口占位 [10]。服务商方面，inteliScience 提供在 NX 会话中调用类型化工具的服务，主张先上线只读工具，每次写入前预览并确认 [11][12]。

4. 具体能做什么

4.1 按能力域归纳

下表依据各项目说明文档中列出的工具或范围整理，✓ 表示文档列出该类工具，空白表示文档未列出，不表示做不到。

能力域	skyf0l [2]	nx-auto-mcp [3]	CAD-Agent-Hub [4]	NX_MCP [1]	nx-sketch-mcp [6]
零件与文件、导出 STEP	✓	✓	✓	✓	保存副本
草图（线、圆、矩形等）	✓	✓	✓	线、矩形	线、矩形、圆
拉伸	✓	✓	✓	✓	限单圆或矩形轮廓
旋转、扫掠、放样	✓	✓	✓
孔、倒角、圆角、阵列、抽壳	✓	✓	✓		螺纹
同步建模、曲面	✓	✓	曲面 ✓
装配与约束	✓	✓	✓
钣金	✓	✓	✓（含展开 DXF）
测量与检查	✓	✓	✓	列表类	✓
工程图	✓		✓
CAM			✓

skyf0l 的工具文档还列出运动、拓扑优化、知识融合（Knowledge Fusion）规则、螺纹、渲染材质等 [2]；这些是项目自述，本文没有核实其实际效果。

4.2 典型调用

NX_MCP 的文档给出一个最小例子：创建一个 20 × 10 × 12.5 mm 的块，依次调用状态检查、新建零件、新建草图、画矩形、结束草图、拉伸、列出实体与特征、保存、导出 STEP，共 9 步 [1]。skyf0l 的示例提示是：创建一块 100 × 60 × 10 mm 的板，四个 6.6 mm 孔距边 10 mm，并给出图片 [2]。

4.3 CAM 方面的现状

CAD-Agent-Hub 是公开资料中 CAM 工具最多的一个：可创建加工装配、坐标系与工件、刀具和工序，设置几何与进给，生成刀轨并导出 CLSF；0.20 版增加了机床仿真就绪检查和带碰撞停止的受保护仿真 [4]。其后处理工具默认禁用，需设置环境变量并提供确认才可使用，且输出明确标注为未经认证，仍需独立的机床仿真、试运行和操作员批准 [4]。

需要区分两类东西：这类工具把 NX CAM 的对象和操作暴露给智能体，是“可编程的基础”；它们不等于“一键自动编程”。cam-agent-showcase 的做法是让模型只提出加工意图，由确定性规则校验并生成工序计划，模型不生成也不执行 NXOpen 代码 [10]。NX 自带的基于特征的加工则是另一条路线，依靠企业预先配置的规则，不属于 MCP 工具。

5. 限制与风险

• 成熟度。 这些项目大多创建不足半年，其中 skyf0l 创建于 10 月 9 日 [2]；NX_MCP 仍标为 0.2.0.dev0，默认工作流在 NX 2506 批处理下验证，同一候选版在两种环境下的验收尚未完成 [1]；nx-codex 的 RC1 只正式支持 NXOpen 12.0.2.9，其他版本不受支持并拒绝写操作 [5]。
• 版本覆盖。 声明验证的版本分散在 2206、2406、2412、2506 和 12.0.2.9 之间，没有一个项目声明覆盖当前的 2606 [1][2][3][5][6]；skyf0l 对 2606 只写“预期可用”[2]。
• 验证口径。 NX_MCP 明确区分“默认可用”“自动化测试”和“真实 NX 验收”三种说法 [1]；CAD-Agent-Hub 提醒，成功调用接口并不证明模型、图纸或仿真结果正确，需要检查 NX 内的实际状态 [4]。
• 代码执行权限。 这些服务在本机以用户权限操作 NX，凡提供 run_python 或日志通道的项目都把它们默认关闭或要求显式启用 [1][3][4]；安全文档的共同提醒是只打开可信来源的文件和脚本。
• 工具数不等于能力。 同一项目的简介与说明文档就可能给出不同的工具数 [1][3]，且大多没有第三方评测。

6. 讨论与结论

从公开资料看，NX 上的 AI 工具目前处于社区探索阶段：官方尚无建模类 MCP，几个项目在数周内从十几个工具扩展到上百个甚至两百多个，能力域覆盖了建模、装配、钣金、工程图和部分 CAM。实现路径已经趋同，即“MCP 服务端 + 本机桥接 + NXOpen”，分歧主要在桥接形态、是否允许任意代码执行，以及人如何确认和撤销。

本文认为，这些项目的价值是证明了这条路径可行，并给出了可供企业参考的设计取舍，但在成熟度、版本覆盖和验证证据上都不足以直接用于生产设计：它们多为个人项目，需要自行编译和签名，版本与当前 2606 之间存在距离，且缺少第三方评测。对需要在企业内使用的团队，本文认为更稳妥的做法是先用只读类工具检查零件，再逐步开放写操作，并保留预览确认和撤销。