从 CollectEntities() 开始，Python 脚本第一次真正连接到了 ANSA模型数据库。

但在实际工程工作中，还有一个更进一步的问题：

如果把 AI 加入这个过程，它能够帮助我们完成什么？

例如，我们可以向 AI 提问：

CollectEntities 有哪些参数？

对于这类问题，AI 可以根据已有知识给出解释。

但是，如果问题变成：

我当前使用的 ANSA 版本中，这个函数到底如何定义？

或者：

帮我统计当前模型中有多少壳单元。

事情就不一样了。

因为普通对话中的 AI，默认无法访问：

• 当前使用的软件版本；
• 本地 API 文档；
• 正在运行的工程软件；
• 当前打开的模型数据。

它缺少的并不是"再想一会儿"，而是一条：

连接 AI 与外部工具、数据和软件环境的通道。

这正是 MCP 想解决的问题。

01 MCP 不只是一个插件

MCP 的全称是：

Model Context Protocol

简单来说，它是一套让 AI 应用连接外部系统的开放协议。

这里的外部系统可以包括：

• 本地文件和技术文档；
• 数据库；
• Web API；
• 命令行程序；
• 工程软件及其二次开发接口。

因此，MCP 本身不是一个新的 AI 模型，也不是某个 CAE 软件专用接口。

它更像：

一套标准化的连接方式。

可以简单理解为：

工程师 ↓AI 应用 ↓MCP ↓文档、数据库、脚本或工程软件

MCP 中的三个角色

Host：承载 AI 的应用

Host 是用户直接使用的 AI 应用。

Client：负责连接管理

Client 位于 Host 内部，负责与 MCP Server 建立连接。

Server：向 AI 提供外部能力

MCP Server 可以向 AI 提供：

• Resources：文档、文件、数据库记录；
• Tools：查询、计算、调用 API；
• Prompts：可复用提示模板。

一个 MCP Server 并不是让 AI 自动拥有所有能力，而是向 AI 暴露一组：

边界明确、可以被发现和调用的外部能力。

02 从 CAE 场景看，MCP 可以分为两类

MCP 官方并没有按照 CAE 场景划分类别，下面两类是为了方便理解工程应用。

第一类：知识检索型 MCP

这类 MCP 解决的问题是：

AI 如何获得更加准确、符合当前版本的工程知识？

例如 ANSA Python API 文档。

通过知识检索型 MCP，可以让 AI 查询指定版本 API 文档，再组织答案。

它解决的是：

"这个 API 应该怎样使用？"

第二类：软件调用型 MCP

这类 MCP 不只提供知识，还提供可以执行的工具。

例如：

查询当前模型信息统计指定类型实体执行模型检查导出模型摘要

它解决的是：

"当前工程环境中实际发生了什么？"

03 用 ANSA 场景理解两者区别

问题一：CollectEntities 到底怎么用？

知识检索型 MCP：

查询 ANSA API 文档 ↓找到 CollectEntities 定义 ↓整理参数说明 ↓返回示例代码

解决：

这个 API 应该怎样使用？

问题二：当前模型中有多少壳单元？

软件调用型 MCP：

AI 调用工具 ↓MCP Server 接收参数 ↓调用 ANSA Python API ↓读取当前模型 ↓返回结果

解决：

当前工程环境中实际发生了什么？

两者最大的区别在于：

知识检索型 MCP 解决"如何使用工具"，软件调用型 MCP解决"如何获取真实环境中的结果"。

04 MCP 可以先帮助 CAE 工程师解决什么？

相比"自动完成一次完整仿真"，MCP 更适合先解决：

边界清楚、容易验证、风险较低的问题。

1. API 文档查询

帮助工程师快速查询指定版本 API。

2. 模型只读检查

例如：

• 当前模型有多少节点和单元；
• 使用了多少材料；
• 是否存在缺少属性的实体。

这些操作：

只读取数据，不修改模型，因此更加适合作为软件调用的第一步。

3. 受控脚本执行

将已有脚本包装成参数明确的工具，让 AI 调用。

4. 批量流程衔接

例如：

读取模型 ↓执行检查 ↓导出结果 ↓生成摘要

AI 的价值往往首先体现在：

减少重复操作，而不是替代求解器。

05 真正困难的不是让 AI 调用一个函数

写出一个 MCP Server 只是开始。

真正工程化落地时，还需要考虑：

软件版本一致性

不同版本 API、字段和行为可能变化。

软件环境

包括软件安装、Python 环境和模块依赖。

会话和 license

MCP Server 启动成功，不代表工程软件已经正常连接。

权限控制

读取模型和修改模型不是同一级别操作。

结果可信度

AI 调用成功，也需要工程师确认结果是否合理。

06 更稳妥的落地路线

如果在 CAE 场景尝试 MCP，可以按照：

第一步：连接文档

让 AI 查询指定版本 API 文档。

第二步：增加只读工具

从实体统计、模型摘要等低风险任务开始。

第三步：测试受控写入

使用测试模型，明确作用范围。

第四步：连接完整流程

查询 ↓检查 ↓修改 ↓导出 ↓生成报告

对于工程软件来说：

稳定和可追溯，比快速实现复杂功能更加重要。

最后

MCP 给 CAE 工程师带来的，并不是一个：

"自动完成所有仿真"的按钮。

它真正提供的是一种连接方式：

让 AI 查询工程知识让 AI 调用边界明确的工具让 AI 获得真实软件返回的数据再由工程师完成判断和验证

可以简单理解：

MCP负责连接能力CAE API负责执行能力工程师负责定义规则和验收结果

MCP 解决的是 AI如何接触工程工具，而不是替工程师判断模型是否合理、结果是否可信。

对于 CAE 场景来说，更现实的发展方向不是一开始追求"全自动仿真"，而是先让AI 帮助我们：

• 查得更快；
• 做得更稳；
• 记录得更清楚。