WorkBuddy 如何接入 PrePoMax 的 MCP 服务器

一条完整的连接链路

要让 WorkBuddy 真正驱动 PrePoMax，必须打通六个环节：服务端开启、令牌生成、客户端配置、配置重新加载、工具枚举，以及当前会话验证。任何一个环节停留表面状态，都可能造成"配置已经保存，但工具无法调用"的假象。

整个链路可以概括为：

启动 PrePoMax
→ 开启自动化服务
→ 生成访问令牌
→ 记录服务地址
→ 修改 WorkBuddy 的 mcp.json
→ 禁用并重新启用服务
→ 信任服务
→ 枚举工具
→ 确认目标会话
→ 检查模型状态
→ 查询真实 API
→ 初始化单位制与项目文件
→ 执行单项操作
→ 验证模型与历史

这不仅是连接步骤，也是一条状态转换链。只完成服务端配置，说明地址和令牌存在；只重新启用服务，说明客户端开始使用新配置；只有枚举到工具，才说明鉴权通过；只有确认活动会话和模型状态，才能开始建模。每一步都有自己的成功标准，不能合并为"服务已连接"。

第一步：在 PrePoMax 中开启自动化服务

打开 PrePoMax v3.0.0 窗口，进入自动化设置。不同版本的菜单路径可能略有差异，通常位于：

Tools → Settings → Automation

进入设置后，建议勾选：

Start with the application

这样后续每次启动 PrePoMax，自动化服务都会随程序打开。如果只进行单次测试，也可以在当前会话手动启动服务；但从长期使用的角度看，手动启动很容易成为下一次连接失败的原因。

进入设置页面后，首先记录服务地址。常见地址为：

http://127.0.0.1:8756/mcp

具体地址必须以当前 PrePoMax 设置页面显示的信息为准。不要凭经验把端口写成 8080、8000 或其他常见端口，也不要因为曾经连接过另一台电脑或另一个版本，就直接套用旧地址。

接着，在访问令牌区域单击右键，选择：

Generate the access token

生成后妥善保存令牌。令牌应只保留在本地 WorkBuddy 配置中，不应复制到群聊、在线文档、代码仓库或共享项目。它控制的不是普通信息查询，而是对当前 PrePoMax 会话的实时操作权限。

PrePoMax 的自动化服务不会允许通过命令行任意启动，也不会以明文形式把令牌直接展示在普通日志中。首次运行新解压版本时，旧令牌可能被清除，此时必须重新生成，并同步更新 WorkBuddy 配置。只更新软件端而不更新客户端，是连接失败的常见原因。

第二步：检查 WorkBuddy 的现有配置

打开 WorkBuddy 的 MCP 配置文件：

~/.workbuddy/mcp.json

检查是否已经存在 prepomax 服务。常见情况有三种：

1. 服务不存在，需要新增配置；
2. 服务已经存在，但地址、请求头或令牌过时；
3. 服务已经存在，配置也完全一致，但客户端尚未重新加载。

其中第三种最容易造成误判。用户可能认为配置已经正确，却忽略 WorkBuddy 仍在调用旧版本配置。因此，不能根据文件内容倒推客户端当前状态，而要通过工具列表确认实际结果。

如果配置文件中存在其他 MCP 服务，修改时应只调整 prepomax 对象，不要破坏现有 JSON 结构。保存前尤其要检查逗号、引号和大括号，避免因为一个语法错误导致整个配置文件失效。

第三步：配置正确的服务地址和鉴权头

在 mcp.json 中添加或修正 PrePoMax 服务配置：

{
  "mcpServers": {
    "prepomax": {
      "type": "http",
      "url": "http://127.0.0.1:8756/mcp",
      "headers": {
        "Authorization": "Bearer kDftOvNdp36s..."
      }
    }
  }
}

最容易出错的字段是鉴权头。错误写法通常表现为直接写入令牌：

"Authorization": "kDftOvNdp36s..."

正确写法必须保留标准前缀：

"Authorization": "Bearer kDftOvNdp36s..."

如果 WorkBuddy 版本要求显式声明传输格式，可以补充接受类型：

{
  "mcpServers": {
    "prepomax": {
      "type": "http",
      "url": "http://127.0.0.1:8756/mcp",
      "headers": {
        "Authorization": "Bearer kDftOvNdp36s...",
        "Accept": "application/json, text/event-stream"
      }
    }
  }
}

这里的令牌只是占位示例，必须替换成 PrePoMax 自动化设置页面中生成的实际值。地址、令牌和请求头前缀需要同时正确，缺一项都可能导致连接失败。

第四步：重新加载并信任服务

保存配置文件后，进入 WorkBuddy 的：

连接器
→ 自定义连接器
→ 配置 MCP

找到 prepomax 服务，按照以下顺序操作：

禁用或关闭服务
→ 保存
→ 重新启用
→ 执行信任操作
→ 检查工具列表

只刷新当前聊天页面通常不能触发重新连接。客户端可能仍然使用旧地址、旧令牌或缺少 Bearer 前缀的请求头。因此，"禁用---启用---信任"不是形式主义，而是让新配置真正进入运行中的客户端。

如果 WorkBuddy 版本没有 type 字段，而是提供图形化连接设置，可以按以下方式填写：

服务名称：prepomax
服务类型：HTTP
服务地址：http://127.0.0.1:8756/mcp
鉴权方式：Bearer Token
访问令牌：kDftOvNdp36s...

无论使用 JSON 还是图形界面，最终都要确认令牌前缀。图形界面如果自动添加 Bearer，就不要再手工重复；如果界面只提供原始请求头，则需要自行填写完整内容。

第五步：枚举工具并识别失败原因

连接完成后，不要立即要求 WorkBuddy 创建几何或划分网格，而应执行三项只读检查：

调用 get_guide
调用 get_status
调用 list_sessions

如果返回操作指南、会话状态和会话列表，说明连接已经建立。随后检查 WorkBuddy 工具面板，确认能够看到 PrePoMax 提供的 15 个工具：

类别	工具
查询与读取	get_guide、list_sessions、get_status、describe_api、read_model、read_topology、get_history、get_job
执行与修改	run_python、eval_expression、run_job、screenshot
长任务管理	get_call、cancel_call
会话控制	exit_session

这 15 个工具构成了一条从查询到执行的完整链路。读取指南可以获得版本对应的操作规范；查询状态可以确认会话是否空闲；读取模型与拓扑可以获得当前几何；查询 API 可以避免调用不存在的对象；执行 Python 可以真正改变模型；查询任务状态可以知道求解是否结束；截图则可以返回当前视图。它不是一个单纯生成代码的接口，而是能够持续观察并控制 PrePoMax 的实时通道。

如果工具面板仍然为空，应按以下顺序排查：

确认 PrePoMax 是否正在运行；
确认自动化服务是否开启；
确认服务地址是否完全一致；
确认令牌是否与当前会话匹配；
确认 Authorization 是否包含 Bearer 前缀；
确认 mcp.json 的 JSON 格式是否有效；
确认 WorkBuddy 是否重新加载了服务；
确认服务是否已信任并启用；
确认本机防火墙或代理没有拦截请求。

其中，服务开启但缺少 Bearer 前缀，会导致地址可以解析、会话却无法通过鉴权。此时 WorkBuddy 表面上存在连接信息，实际却不能枚举工具。鉴权问题与网络中断不同，不能仅凭"无法访问"判断，还要检查服务返回的具体状态。

第六步：确认当前会话

PrePoMax 的自动化服务可以识别当前实例，因此连接成功后必须确认控制目标是否正确。调用 list_sessions 以后，重点检查当前会话是否标记为：

isThisSession: true

同时确认实例版本、进程标识和连接地址。这次会话返回的信息包括：

会话协议：1.0
PrePoMax 版本：3.0.0
实例数量：1
当前会话：isThisSession 为 true
服务地址：http://127.0.0.1:8756/mcp

当只有一个 PrePoMax 实例时，通常不需要切换会话。但如果系统中存在多个实例，就必须确认当前操作究竟作用于哪一个窗口。否则，即使 API 调用成功，用户也可能在错误的模型中寻找结果。

第七步：检查模型是否具备执行条件

连接成功只代表通信链路打通，不代表模型已经可以安全修改。get_status 在这次会话中返回了以下关键状态：

isRunning：true
isIdle：true
isReadOnly：false
当前模型：Model-1
fileName：空
modelSpace：Undefined
unitSystem：Undefined
视图模式：geometry
当前长调用：无

这些字段共同构成连接完成后的第一次事实检查。会话正在运行，说明服务可用；会话空闲，说明当前没有任务占用；模型可写，说明具备修改权限；但单位制与模型空间未定义、文件也未保存，说明模型仍缺少执行工程操作所需的基础条件。

其中最重要的不是错误提示，而是 unitSystem 和 modelSpace 均为 Undefined。自动化 API 中的数字通常不带单位，服务也不会自动判断 10 究竟代表 10 毫米、10 米还是 10 英寸。如果在这个状态下直接创建几何或设置材料，后续尺寸、弹性模量、密度、载荷和应力都会缺少共同基准。

可以通过一张状态表检查完整连接流程。表中每个节点都有自己的验证动作，不能仅凭界面提示替代：

阶段	关键动作	成功标志	常见失败原因
服务准备	开启自动化服务并生成令牌	页面显示服务地址和令牌	服务未开启、旧版本重新解压
客户端配置	修改或新增 prepomax 服务	JSON 格式正确、地址一致	端口错误、令牌错误、缺逗号
鉴权配置	设置 Authorization 请求头	请求头包含 Bearer 前缀	直接写入原始令牌
配置加载	禁用后重新启用服务	客户端读取新配置	只刷新聊天页面
服务信任	在连接器页面信任服务	服务处于启用状态	仍停留在未信任状态
工具连接	调用 get_guide、get_status 和 list_sessions	返回指南、状态和会话列表	鉴权失败、地址不一致
会话确认	检查 isThisSession 和版本信息	确认控制的是正确窗口	存在多个 PrePoMax 实例
状态检查	读取 isIdle、isReadOnly、unitSystem 和 fileName	会话空闲、可写，状态和文件边界明确	单位制未定义、文件未保存
环境查询	调用 describe_api	获得真实 API 结构	调用教程中的旧函数名
模型执行	执行 run_python	命令历史中增加预期操作	参数、单位或对象名称错误
结果验证	调用 read_model、get_history 或 screenshot	模型状态与执行目标一致	只检查代码是否运行
长任务管理	保存 callId 并调用 get_call	回收任务结果	重复提交相同请求
任务中断	调用 cancel_call	停止不再需要的任务	把中断当成常规流程
流程复用	保存连接和验证步骤	下次能够按节点定位问题	只保存零散代码

这张表的意义，在于把"连接成功"从一个笼统判断拆解成多个可检查状态。用户不能再笼统地说"MCP 已经配置好"，而要明确回答：服务是否开启、地址是否正确、令牌是否有效、客户端是否重新加载、工具是否枚举、会话是否匹配、模型是否空闲、单位是否定义、操作是否验证。

完整连接流程还可以表示为以下链路：

开启服务
  ↓
生成并记录令牌
  ↓
确认服务地址
  ↓
配置 mcp.json
  ↓
检查 Authorization 前缀
  ↓
禁用并重新启用服务
  ↓
信任并启用 prepomax
  ↓
枚举 15 个工具
  ↓
调用 get_guide
  ↓
调用 list_sessions
  ↓
确认当前会话
  ↓
调用 get_status
  ↓
检查空闲、只读和单位制
  ↓
调用 describe_api
  ↓
确认真实对象与成员
  ↓
初始化单位和项目文件
  ↓
执行单项操作
  ↓
读取 read_model
  ↓
检查 get_history
  ↓
进入网格、边界条件和求解流程

箭头方向代表依赖关系，而不是推荐速度。上游状态没有被确认时，下游操作的风险会快速累积。反过来，只要状态表中的每个节点都能独立验证，即使某个环节失败，也能快速定位，而不必推翻整个流程。

第八步：查询真实 API 后再执行代码

连接工具并不等于了解 API 结构。最稳健的做法是先调用 describe_api，确认当前版本真正支持的对象和成员：

describe_api：pmx
describe_api：pmx.model
describe_api：pmx.model.steps
describe_api：pmx.selection

这里查询的不只是函数名称，还包括当前会话中可调用对象的结构。外部教程、旧版文档或语言模型记忆中的函数名，可能与当前 PrePoMax 版本不一致。如果先猜 API，再依靠报错反推，错误就会进入命令历史，并增加撤销成本。

通过 describe_api 查询后，再编写候选代码；代码执行后，使用 get_history 检查实际记录；随后通过 read_model 验证模型状态。这样形成的不是一次性脚本，而是一种带反馈的自动化流程：每一次执行都能验证上一次假设。

第九步：先初始化单位制、模型空间与项目文件

在正式建模前，应先明确单位制，例如毫米、吨、秒、摄氏度体系。常见物理量包括：

长度单位：mm
力单位：N
质量单位：ton
应力单位：MPa
温度单位：°C

在材料参数方面，例如普通钢的参考值可能为：

弹性模量：210000 MPa
泊松比：0.3
密度：7.85e-9 t/mm³

但这些数值只能作为候选参数，不能由自动化接口自行假设。真正进入模型前，仍应由用户确认材料牌号、工作温度、单位体系和允许误差。

同时，应把未命名的 Model-1 保存为具体文件，例如：

D:\PrePoMax\work\beam_test.pmx

或者创建一份独立的验证副本。这不仅是备份，也是把当前会话中的修改限定在明确边界内。否则，一旦连续执行多个动作，用户将难以判断模型究竟处于哪个阶段。

第十步：从规则块开始验证完整建模链

建议第一个自动化模型选择规则块，例如：

长度：100 mm
宽度：20 mm
高度：20 mm

规则块不是最简单，而是最容易验证。它具有明确的尺寸、方向、源面和扫掠路径，适合检查单位制、几何创建、面选择、六面体网格、边界条件和结果输出。

执行顺序应当是：

初始化单位制与模型空间
→ 创建或保存项目文件
→ 创建规则块
→ 调用 read_model
→ 调用 read_topology
→ 预览目标面
→ 确认面、边和顶点
→ 创建源面集合
→ 执行拉伸、旋转或扫掠网格
→ 检查网格状态
→ 设置材料
→ 设置边界条件
→ 设置载荷
→ 写出求解文件
→ 启动分析任务
→ 轮询任务状态
→ 截图并检查结果

每一步都应单独验证。不要在一个脚本中同时创建几何、划分网格、设置载荷、提交计算和截图。虽然这样看起来自动化程度更高，却会把多个不确定因素叠加在一起，一旦失败就很难定位原因。

第十一步：正确处理长任务

网格划分、文件导入和复杂计算可能超过单次请求时限。如果返回：

running
callId

说明任务正在后台执行，不应重复提交相同指令。正确做法是记录 callId，再通过 get_call 回收结果：

读取 callId
→ 等待合理时间
→ 调用 get_call
→ 检查执行结果
→ 必要时继续轮询

只有当任务明显卡死、需要立即停止或不再需要结果时，才使用 cancel_call。该操作可能直接中断正在运行的网格划分器，因此属于异常处置，不是常规流程节点。

相比重复点击，长任务状态更值得关注的是幂等性。相同请求提交两次，并不等于进度加快，而可能造成两个任务同时修改模型、争用资源或生成冲突结果。因此，自动化任务必须记录任务标识和状态，不能只依赖用户判断"是否已经完成"。

第十二步：建立连接后的安全边界

完成连接以后，WorkBuddy 已经不只是聊天助手，而是获得了实时控制 PrePoMax 的权限。每次 run_python 调用都会作用于当前活动模型，并进入命令历史。因此，执行前应确认三件事：

目标会话是否正确；
当前模型是否空闲；
待执行操作是否可逆。

涉及几何、网格、材料和载荷的复杂任务，应先保存副本。涉及六面体网格、边界条件和分析任务时，应先执行只读检查，再执行单一修改，最后查询执行结果。

exit_session 也体现了会话权限边界。它能够关闭无窗口的隐藏会话，却会拒绝关闭用户桌面上可见的实例。自动化接口不应悄无声息地关闭用户正在观察的窗口，这不是功能缺陷，而是安全保护。

不同失败状态也应区别处理：

Busy：等待当前任务结束；
Read only：解除只读限制后再修改；
API error：检查对象名称、参数和调用方式；
PromptRefused：重新审视操作范围；
Authentication error：重新检查令牌与 Bearer 前缀；
Network error：确认服务地址与本地网络状态。

把这些状态统一视为"连接失败"，会掩盖真正的错误原因。只有先分类，才能采取正确的恢复动作。

第十三步：从一次成功连接走向可重复流程

一次成功的接入，最终应沉淀为一份可复用流程，而不是一串临时命令。其最小结构包括：

环境检查
服务配置
鉴权配置
客户端重载
工具枚举
会话确认
模型状态检查
API 查询
单项执行
结果验证
错误分类

如果某一步失败，只需定位具体状态，而不必从头猜测。例如，配置能够保存但工具为空，应重点检查服务与鉴权；工具已经枚举但模型无法修改，应检查只读状态；代码能够运行但参数异常，应检查单位制；网格划分无响应，应检查长任务状态；边界条件错误，应回到拓扑选择和预览环节。

这套流程的核心不是追求操作速度，而是确保每一步都具有明确事实和可验证结果。PrePoMax 的 15 个 MCP 工具已经提供了读取、执行、中断和查询能力；WorkBuddy 的价值则在于把这些能力组织成一条稳定的工程工作流。

连接不是终点，模型状态才是执行起点

在这次会话中，最关键的发现并不是工具数量，而是模型状态本身。get_status 显示当前会话正在运行，协议版本为 1.0，PrePoMax 窗口可见，一个 MCP 客户端处于活跃状态，当前模型为 Model-1，会话空闲且非只读。但模型的 unitSystem 与 modelSpace 均为 Undefined，文件名也是空的。这意味着模型虽然可以被修改，却还没有形成完整的坐标、单位和物理量定义。

单位制在 PrePoMax 自动化中不是一个可以在执行时顺便补上的显示参数。API 输入的数字通常不带单位，服务也不会替用户猜测 10 代表 10 毫米、10 米还是 10 英寸。如果模型处于 Undefined 状态，后续创建几何、设置材料、定义载荷和检查网格尺寸都会缺少共同基准。尤其在毫米、吨、秒、摄氏度体系中，钢的弹性模量约为 210000 MPa，泊松比约为 0.3；如果错误地套用纯 SI 国际单位，数值模型就可能从一开始就偏离预期。

因此，正式自动化建模的第一步应当是确认或设置单位制与模型空间，而不是立即创建零件。模型命名并保存到本地文件，也应早于复杂修改。若 fileName 为空，一旦程序异常退出、误操作覆盖或版本保存失败，用户可能失去验证依据。先保存为 beam_test.pmx 之类的明确文件，不只是为了形成备份，也是为了让后续每一步都有可追溯的项目边界。

这一顺序也揭示了人工智能辅助工程软件的基本规则：可执行不等于可以执行。工具能够运行 Python，只代表权限已经打通；只有当单位、模型空间、文件路径和当前状态都清楚时，操作才具备物理意义。

几何选择必须从猜测转向验证

有限元自动化最容易翻车的环节，往往不是求解器，而是几何选择。在图形界面中，工程师可以旋转视图、放大边缘并逐个人工确认面、边和顶点；在脚本中，如果对象编号、选择范围或法向假设错误，程序则可能安静地选中错误区域，并把错误传播到网格、约束和载荷。模型的几何尺寸可能看似正常，但边界条件已经施加在错误的面上。

PrePoMax 的 read_topology 能够返回面、边、顶点及其编号、尺寸、质心和法向，selection.preview() 则可以在正式提交前验证选择范围。两者结合起来，构成了自动化建模中的安全护栏。工程师不应要求人工智能根据自然语言直接选定"左端面"，而应让它先读取拓扑，再通过预览确认候选对象是否符合位置、尺寸或法向条件，最后才把选择结果固化到集合、约束或载荷中。

这种差异本质上是从"描述几何"转向"验证几何"。人工智能并不需要拥有视觉，也能够根据质心、法向、尺寸和邻接关系进行推理。例如，对于一个规则块，一侧面的法向可以提示其大致朝向，面的尺寸可以帮助区分端面与侧面，顶点和边则可以构成局部坐标线索。只要先读取拓扑并预览选择，人工智能就能从"替用户点击屏幕"升级为"根据模型事实作出可验证的判断"。

六面体网格不是一次魔法操作，而是一条条件链

PrePoMax 在新版本中加强了结构化网格能力。对具有 5 个或 6 个面、边界由三边或四边面构成的实体，可以生成超限六面体网格；对能够沿一个方向扫掠的实体，则可以生成扫掠六面体网格。这些能力显著减少了单元数量、提高了应力结果质量，也改善了接触压力分布。但自动化工具并不会自动把任意 CAD 几何变成优质六面体网格。

规则块之所以适合作为第一个验证对象，不是因为它最简单，而是因为它的几何条件最容易满足。100 mm × 20 mm × 20 mm 的长方体具有清晰的源面、目标面、扫掠路径和方向，便于验证尺寸、选择面和网格层数。相比之下，薄壁件、复杂倒角、多连通域、不规则孔洞和缺少分割的实体，可能需要先进行几何分割。如果人工智能在信息不完整时直接承诺"自动生成六面体网格"，那么所谓自动化实际上只是把失败推后到网格器内部。

正确的执行链应当拆分为多个独立步骤。第一步只创建几何并保存模型；第二步读取 read_model 和 read_topology，确认单位制、零件和几何状态；第三步通过 selection.preview() 验证源面；第四步再执行拉伸、旋转或扫掠；第五步检查网格质量并保存结果。每一步都应有独立的成功标准，不能把几何创建、网格划分、边界条件和提交计算合并成一个脚本。这样即使某一步失败，用户也能定位问题，而不会面对一个被连续修改、无法撤销的复杂模型。

长任务还要遵循专门的回收机制。网格划分或文件导入如果超过单次请求时限，服务可能返回 running 与 callId。此时不应重复提交相同指令，而应调用 get_call 获取结果；确实需要中断时，才使用 cancel_call。cancel_call 可能直接中断正在运行的网格划分器，因此它是一项紧急控制能力，而不是常规流程节点。对自动化任务而言，重复提交往往比任务缓慢更危险，因为它会把单一问题放大为多个并行状态冲突。

run_python 必须被视为实时控制，而不是普通代码生成

run_python 与普通代码助手最大的区别在于，它会直接驱动桌面上正在运行的 PrePoMax 活动模型。代码一旦执行，就会进入命令历史，并可能改变零件、网格、材料、载荷和视图状态。因此，用户不能把 WorkBuddy 理解为后台代码生成器，而应把它看作一个获得授权、能够操作图形界面背后模型的代理。

这种代理需要边界。正式建模前，最好保存原始模型，或在副本中验证流程；一次只执行一个独立动作；涉及单位、材料和载荷时，必须确认单位制；对几何选择，应先预览再提交；对计算任务，则通过 run_job 启动，再使用 get_job 轮询状态。run_job 不阻塞会话，重复点击并不会加快求解，只会制造重复任务和状态混乱。

exit_session 也体现出会话权限的边界。它能够关闭无窗口的隐藏会话，却会拒绝关闭用户桌面上可见的 PrePoMax 实例。这不是功能缺陷，而是有意为之的保护机制。远程自动化接口应当能够管理任务，但不应悄无声息地关闭用户正在观察的软件窗口。类似地，只读请求、繁忙状态、只读模式、API 错误和拒绝提示应当分别处理，不能一概视为连接失败。

人工智能更适合充当自动化翻译器，而不是工程决策者

PrePoMax 的自动化指南要求工程师先确认单位制，优先使用 selection.preview() 验证几何，通过 describe_api 查询准确调用，并区分不同种类的错误。这套规则恰好划定了人工智能在有限元自动化中的合适位置。

人工智能擅长连接自然语言需求与工具调用，例如把"创建一根梁并划分六面体网格"拆解为状态检查、单位确认、几何创建、拓扑读取、面选择、网格划分和结果检查；它也擅长解释工具返回信息，把 JSON 中的状态、单位制、会话标识和错误信息转译为执行建议。但它不应当替用户决定材料参数、安全系数、边界条件或求解方案，除非这些依据已经明确提供。

run_python 也改变了代码验证方式。人工智能可以先在本地编写候选代码，通过 describe_api 检查对象结构，再在 PrePoMax 中执行；执行后通过 get_history 回看实际命令，并依据 read_model 验证模型状态。这实际上形成了一种反馈式编程：代码不是一次性交付物，而是根据真实会话不断校正的操作记录。

一个成熟的接入流程应当从事实检查开始

PrePoMax 接入 WorkBuddy 后，推荐的第一次操作并不是创建复杂模型，而是依次调用 get_guide、get_status 和 list_sessions。这三步分别对应系统规则、当前事实和可用会话。get_guide 说明应该如何操作，get_status 说明当前模型处于什么状态，list_sessions 则确认是否存在多个实例以及是否连接到目标会话。

如果 list_sessions 显示多个 PrePoMax 实例，就需要确认当前连接是否指向正确窗口；如果会话繁忙，则应等待或使用相应状态查询，而不能强行提交代码；如果模型处于只读模式，则需要先解除限制；如果 unitSystem 为 Undefined，则必须先明确单位体系。只有当会话空闲、模型可写、单位明确且文件路径已知时，才可以进入几何创建阶段。

随后，一个完整但克制的初始化流程应当是：通过 describe_api 查询真实 API；确认单位制和模型空间；创建或保存模型文件；读取模型与拓扑；必要时预览选择；执行单一修改；检查历史与状态；确认无误后再进入网格划分和分析阶段。这个流程牺牲了一部分表面上的"自动化速度"，却换来了结果可解释、操作可撤销、错误可定位和可重复执行。

结论

WorkBuddy 接入 PrePoMax 的核心，不是找到一个神奇命令，而是完成四件事：把服务地址、协议和 Bearer 鉴权配置正确；通过重新启用服务使配置真正生效；让客户端枚举并信任实际工具；再根据实时状态组织可验证的执行流程。其中任何一步不完整，都可能出现"配置存在但工具不可用"的假象。

更深一层看，PrePoMax 的 15 个 MCP 工具把有限元建模拆成了可观察、可执行、可中断、可查询的闭环。人工智能要发挥价值，就必须先读取事实，再决定行动，而不是根据常识替工程模型补全参数。当前会话中 unitSystem 和 modelSpace 均为 Undefined，正是一次重要提醒：自动化的首要条件不是代码能够运行，而是数字具有明确含义，几何选择具有验证依据，模型文件具有清晰边界。

因此，最合理的下一步不是立即创建复杂几何，而是查询 pmx、pmx.model 和 pmx.model.steps 的真实成员，结合 get_status 与 read_model 的返回结果，先初始化单位制、保存项目文件，再从规则块开始验证几何创建、面选择、六面体网格和分析流程。只有这样，WorkBuddy 才不只是"会聊有限元的助手"，而会成为能够安全控制 PrePoMax 的实时自动化代理。