一条完整的连接链路

要让 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 个工具：

这 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 英寸。如果在这个状态下直接创建几何或设置材料，后续尺寸、弹性模量、密度、载荷和应力都会缺少共同基准。

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

这张表的意义，在于把“连接成功”从一个笼统判断拆解成多个可检查状态。用户不能再笼统地说“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 的实时自动化代理。