夜雨聆风AI CAE 工具实践/第 01 期
MCP 要解决的不是"AI 会不会仿真"，而是"AI 能不能在一个受控接口里调用工程工具"。
过去我们让 AI 帮忙写 Abaqus Python 脚本，通常只能走到这一步：工程师在聊天窗口里描述需求，AI 生成代码，人再复制到 Abaqus 里运行，最后把报错、截图或日志贴回来。
这已经有价值，但它仍然像一个"离线顾问"——AI 知道脚本大概应该怎么写，却碰不到你的 Abaqus 会话；它看不到模型树、材料、Step、Job 状态，也读不到 ODB 结果。
这层缺失的接口，正是 MCP 试图补上的。
●1. 先别急着说 Agent，工程师真正缺的是接口
CAE 工作流里的关键信息，往往不在聊天窗口里，而在模型、脚本、Job、日志、ODB、截图和结果文件中。
如果 AI 只能看见聊天窗口，它最多是解释器、代码草稿生成器、排错建议者。
工程师真正想要的，是另一种工作方式：
工程师描述目标 -> AI 查询当前模型信息 -> AI 生成脚本草稿 -> 工程师确认 -> 工具执行受控动作 -> 日志、截图、结果摘要回传 -> 工程师复核
图 1｜从聊天建议到工具调用闭环。 AI 的角色从“生成建议”进入“受控工具调用”，但工程软件会话和人工复核仍然是闭环里的关键节点。
这中间缺的不是一个更会聊天的模型，而是一套让 AI 应用安全调用外部工具的连接方式。
●2. MCP 到底是什么？
MCP，全称 Model Context Protocol。按照官方介绍，它是连接 AI 应用与外部系统的开放协议。外部系统可以是本地文件、数据库、搜索工具、工程软件、脚本，也可以是一套业务工作流。
换成工程师语言，MCP 不是新的 CAE 软件，不是新的大模型，也不是插件市场。它更像一层标准化接口：AI 应用通过 MCP Server 发现工具、调用工具、读取资源、获得返回结果。
几个概念需要先分清：
| MCP 概念 | 工程类比 | CAE 场景里的理解 |
|---|---|---|
| Host | 工程师正在使用的 AI 应用外壳 | Claude Desktop、Cursor、Codex、ChatGPT 等 |
| Client | Host 内部负责连接某个 Server 的组件 | 管理与某个工具服务的连接 |
| Server | 工具接口层 | Abaqus-MCP、FreeCAD-MCP、自研 CAE MCP Server |
| Tools | 可被调用的动作 | 执行脚本、查询模型、提交 Job、读取日志 |
| Resources | 可读取的上下文资源 | 状态、文件、模型摘要、结果索引 |
| Prompts | 可复用任务模板 | 检查模型、生成报告、排错流程 |
图 2｜Host / Client / Server 的 CAE 类比。 MCP 把 AI 应用、连接组件、工具接口层和 CAE 后端拆成可理解的协作关系。
官方架构文档还涉及 JSON-RPC、生命周期管理、能力协商、传输层等机制，本文暂不展开，只聚焦一点：
MCP 关注的是 AI 应用和外部工具之间如何交换上下文、发现能力、触发动作。它不负责替 AI 做工程判断。
●3. 用 CAE 场景重述 MCP 调用链
把 MCP 放回 CAE 场景，调用链是这样的：
AI 客户端 / Agent -> MCP Client -> CAE MCP Server -> 工程软件 / 脚本 / 求解器 / 后处理工具 -> 日志 / 图片 / 结果摘要 / 文件路径回传
如果后端是 Abaqus，可能是：
Cursor / Claude Desktop / Codex -> Abaqus-MCP Server -> Abaqus/CAE 插件或 Python 执行环境 -> 模型信息、Job 状态、ODB 元数据、视口截图
AI 客户端像工程师助理，负责理解任务、组织步骤、生成建议。MCP Server 像工具接口层，负责把某些动作以可调用工具的形式暴露出来。Abaqus、FreeCAD、OpenFOAM 或工程脚本，才是真正执行任务的后端。
所以，MCP 让 AI 有机会“碰到”工程软件，但它并不会自动让 AI 变成工程责任主体。
●4. MCP 和 API、脚本、插件是什么关系？
很多工程师已经会写 Abaqus Python、OpenFOAM 脚本，或者用 COMSOL、Ansys 的 API 做自动化。MCP 不是替代它们，而是把已有能力包装成 AI 客户端可以发现和调用的工具层。
| 层级 | 解决的问题 | 举例 |
|---|---|---|
| 工程软件 API | 软件能被程序控制什么 | Abaqus Python、COMSOL Java API、PyAnsys |
| 脚本 / 自动化流程 | 如何把工程动作串起来 | 建模脚本、批量提交 Job、后处理脚本 |
| 插件 / GUI 扩展 | 如何嵌入工程软件会话 | Abaqus 插件菜单、FreeCAD Workbench |
| MCP Server | 如何让 AI 客户端调用这些能力 | Abaqus-MCP、FreeCAD MCP、自研 MCP Server |
图 3｜API、脚本、插件与 MCP 的关系。 MCP 不是替代既有自动化能力，而是把 API、脚本和插件组织成 AI 客户端可调用、可追溯的接口层。
真正有价值的 MCP Server，往往不是把所有命令都暴露出去，而是把工程师愿意交给 AI 调用的那部分能力，设计成边界清晰、可审计、可回滚的工具。
●5. CAE 里的 MCP：边界比能力更重要
MCP 很适合做这些事：查询模型摘要、执行受控脚本、调用预定义后处理流程、读取日志和错误信息、返回截图和报告草稿。
但它不能保证 AI 生成的模型物理正确，不能代替工程师选择工况、材料模型、网格策略和安全系数，也不能未经确认自动覆盖已有模型、Job 或结果文件。
尤其在本地工程软件场景里，本地 MCP Server 往往和 AI 客户端运行在同一台机器上，可能接触文件、网络、工程软件会话、脚本执行环境和商业模型数据。官方安全最佳实践也提醒：本地 server 如果缺少沙箱、同意机制和权限限制，会带来任意代码执行、数据泄露、数据丢失等风险。
初学阶段建议先守住几条红线：
| 风险动作 | 初学阶段建议 |
|---|---|
| 任意 Python 执行 | 先只读，后执行；执行前人工确认 |
| 文件写入 / 覆盖 | 限定工作目录，禁止覆盖原始模型 |
| Job 提交 | 小案例优先，提交前确认资源和路径 |
| 结果结论 | AI 只能给初步摘要，工程师必须复核 |
| 商业模型数据 | 脱敏、副本、局部样例，不直接连生产数据 |
| 本地 MCP Server 配置 | 只安装可信来源，确认启动命令和访问目录 |
图 4｜CAE MCP 工具调用风险边界。 脚本执行、文件写入、Job 提交和结果解释都应放在权限边界、日志、副本和人工确认之内。
一句话：MCP 的价值不是“让 AI 什么都能做”，而是“让 AI 在清楚边界内做一小部分可检查的事”。
●6. 一个最小伪案例
下面不是一个真实可调用的工具，而是一个按 MCP Tool 元数据形式写出的伪工具示例。它的作用是说明：CAE 工具不应该让 AI 随便输入命令，而应该通过 inputSchema 把可选案例、参数范围、确认开关和返回结果边界写清楚。
{ "name": "run_simulation_case", "title": "Run controlled simulation case", "description": "Run a predefined CAE simulation case in a controlled workspace.", "inputSchema": { "type": "object", "properties": { "case_name": { "type": "string", "enum": ["cantilever_beam_demo"] }, "mesh_size": { "type": "number", "minimum": 1.0, "maximum": 20.0 }, "load_value": { "type": "number", "minimum": 0 }, "confirm_before_submit": { "type": "boolean", "const": true } }, "required": ["case_name", "mesh_size", "load_value", "confirm_before_submit"] }}
这个例子里，case_name 不是任意字符串，而是限制在 cantilever_beam_demo；mesh_size 有范围；confirm_before_submit 被固定为 true。这代表 Job 提交前必须有确认，不应该让 AI 在没有人类确认的情况下直接消耗计算资源或覆盖结果。同样地，工具返回也不应只有一句"成功"，而应包含状态、日志路径、输出文件路径和待复核摘要，让结果可追溯、可复核。
这里最重要的不是工具多厉害，而是边界清楚：能跑哪个案例、能改哪些参数、是否需要确认、结果如何追溯、哪些结论必须留给工程师复核。
●7. 下一站：Abaqus-MCP
MCP 的真正意义，不是让 AI 突然懂了所有 CAE，也不是让工程师把责任交给模型。它改变的是连接方式：AI 不再只能在聊天窗口里生成建议，而是可以通过标准化接口，在受控边界内调用工具、读取上下文、返回证据。
讲完概念，下一步就不能只停留在协议层了。本系列先从 Abaqus-MCP 开始，原因很直接：Abaqus 是很多结构仿真工程师熟悉的商软，本身有成熟的 Python 脚本生态；Abaqus-MCP 又能自然引出模型信息查询、脚本执行、Job、ODB、截图回传这些 CAE 工程师真正关心的动作。
但也要提前说明：Abaqus-MCP 不应该被理解成"生产级自动工程师"。它更像一个值得拆解和实测的接口层项目。越是能调用真实工程软件，越要把权限、日志、副本、确认点和回滚策略讲清楚。
欢迎工具连接，但拒绝无边界自动化；欢迎 AI 参与流程，但工程责任仍然属于工程师。
下一期，我们拆开 Abaqus-MCP，看看 AI 客户端到底如何进入 Abaqus/CAE，会话内能看到什么、能执行什么，又有哪些动作必须停在人类确认之前。
公众号  | 知识星球  | 扫码关注 科趣范，让科研更简单 |
小红书  | 抖音  |
