下一代 PLM 如何以 .NET 类型接口和 CLI 为能力基础，通过 MCP 原生支撑自有和第三方 AI 智能体；

下一代PLM的“AI原生”，不是增加一个聊天窗口，而是让产品数据、业务规则和工程能力，能够被智能体安全地发现、调用、验证与追溯。

下一代PLM的分层智能接口架构：MCP基于.NET能力与CLI任务构建

AI原生，不只是“接入大模型”
     当AI进入工业软件，真正的分水岭并不是系统能不能对话，而是AI能否进入真实的工程业务：理解产品上下文、调用专业能力、遵守企业规则，并对执行结果留下可靠证据。
     基于这一认识，Extech正在探索一种新的PLM能力架构：以Foundation及其上的XBOM、CAD与图纸处理、工艺智能、变更管理为统一业务内核；以.NET类型接口形成稳定的能力契约，以CLI封装可自动执行的工程任务，再由MCP将这些能力组织为智能体可发现、可理解、可治理的资源与工具。
一个内核，三种能力入口

从使用侧看，.NET类型接口、CLI和MCP是同一套PLM能力的三种入口；从实现侧看，它们具有清晰的分层关系：.NET是能力基础，CLI是自动化任务封装，MCP是面向智能体的语义适配与编排层。无论从哪个入口进入，最终都应执行同一套对象模型、权限、版本、流程、事务和审计机制。

.NET类型接口是内部最可靠的能力契约。复杂的BOM、配置、变更、工艺和产品数据，首先通过强类型服务获得清晰边界与稳定质量。未来无论界面和模型怎样变化，真正决定工程结果的，仍是经过测试和治理的专业服务。

CLI命令行让这些能力可以自动化执行。它通常复用.NET业务服务，也可以封装模型转换、图纸解析等本地工程工具，使批量任务能够部署在CAD工作站、计算节点或客户现场，由工程师、测试系统及本地智能体以统一方式调用。

MCP本身不重新实现PLM业务逻辑。在线查询、结构读取和业务分析，可以直接适配.NET类型接口；模型转换、批量解析和本地计算，则可以编排CLI任务。由此，客户自建智能体及第三方AI平台能够在授权范围内发现能力、读取上下文、发起任务并获取结构化结果。
一套统一的PLM能力目录

为了避免三种入口各自发展、逐渐分离，下一代PLM需要建设统一的能力目录。每项能力都具有一致的业务名称、输入输出语义、权限范围、风险等级、验证方式和审计要求，并在.NET服务与受控工程任务的基础上，按需封装为CLI命令和MCP资源或工具。

面向智能体开放的，不应是缺少业务语境的底层数据操作，而应是“生成指定配置的产品结构”“审查工艺方案”“分析工程变更影响”这类完整的工程动作。智能体负责理解意图、组织任务和解释结果；配置求解器、规则引擎、几何算法及PLM服务仍负责专业计算和业务约束。
开放能力，更要守住工程边界

AI原生并不意味着无限开放。系统应区分查询、建议、预演和正式提交。对于BOM发布、版本变更、工艺批准等高风险动作，仍需完成身份验证、权限检查、规则校验和必要的人工确认。所有入口共享同一套治理机制，才能避免AI绕过既有流程，形成新的数据孤岛。

以一次工程变更为例，智能体可以沿数字主线读取相关产品版本、EBOM、PBOM、BOP、图纸和工艺文件，调用专业能力完成影响分析，再向工程师提交建议。确认后系统才执行正式变更，并记录使用的数据版本、规则、工具、分析结果与批准过程。
从数字主线走向产品记忆

这些执行记录进一步构成“产品记忆”：不仅保存产品最终变成了什么，也保存为什么这样变、依据是什么、由谁确认，以及后续结果是否验证了当时的判断。数字主线为智能体提供上下文，统一业务内核提供可靠能力，而产品记忆让每一次人机协同都可以追溯和复用。

一个业务内核、一套能力目录、三种智能入口。 通过.NET能力、CLI任务和MCP服务的分层复用，Extech PLM将逐步演进为可发现、可组合、可验证、可治理的工程能力平台，为自有与第三方AI智能体进入真实研发制造流程奠定基础。