让 AI Agent 直接操作参数化 CAD：Loböle 的命令层与 MCP 实践
让 AI 生成一个三维模型并不难，难的是模型能否继续编辑、检查尺寸、生成工程图，并在上游参数变化后保持关联。Loböle 的思路不是把 CAD 变成“会聊天的界面”，而是把 GUI、Python 脚本和 Agent 接到同一套命令层：用户可以手动建模，程序也能通过 JSON-RPC 调用同样的能力。
这使它成为一个值得观察的工程实验：Agent 不只负责输出网格或一段建模脚本，而是可以操作参数化文档，并通过检查接口验证结果。项目目前标注为 0.1 版本，功能和平台成熟度仍需谨慎评估；本文更适合把它当作可试验的开源 CAD/Agent 架构，而不是生产环境承诺。
同一命令层连接 GUI、脚本与 Agent
项目 README 将 Loböle 定位为基于 OpenCASCADE 的参数化 CAD，包含约束草图、特征、装配、工程图、有限元分析和 CAM 等能力。对 Agent 集成而言，关键不在功能清单，而在架构边界：应用内运行 JSON-RPC 服务，GUI、Python SDK 和 MCP 服务都围绕这套命令接口工作。
文档明确说明，新的能力应先进入命令层并提供描述信息，再由 GUI 调用。这样的设计减少了“界面能做、Agent 却做不了”的双轨实现；同时，能力也更容易被脚本和自动化测试复用。Agent 可通过 MCP 工具访问命令，再用检查接口读取文档结构或几何信息，而不是单纯相信模型刚才的自然语言总结。
从 Python 脚本开始验证
Loböle 的脚本文档指出，应用可用 --remote 启动本地 JSON-RPC 服务；Python 包提供 client、SDK 与 MCP 模块。一个有用的工作流是先用脚本生成简单零件，再读取文档状态，确认实体、尺寸和输出格式，最后才让 Agent 参与复杂修改。
# 安装 Python 客户端、SDK 与 MCP 服务 pip install lobole # 启动应用并开放本地 JSON-RPC 服务 lobole --remote 0
0 端口允许操作系统分配端口，具体端口会由应用记录并公布。要注意，这段启动示例依赖已安装的 Loböle 应用；仅安装 Python 包并不会自动提供 CAD 引擎或 GUI。官方文档也列出 headless 与 offscreen 模式：前者不渲染，适合无 GPU 的文档处理；后者保留 Vulkan 渲染能力但不需要窗口，适合需要图像的自动化场景。两者的可用操作并不相同，调用前应根据所需截图或 UI 操作选择模式。
示例代码不应凭空猜 SDK 的具体方法名。稳妥做法是从项目的 SDK 文档和 MCP 文档复制已记录的调用，并先用简单只读操作检查连接，再执行会改动文档的命令。涉及文件写入或加工路径时，也要使用隔离目录和可回滚的版本，避免 Agent 把试验性输出覆盖到正式设计文件。
把“执行成功”与“模型正确”分开
CAD 自动化最容易误判的地方，是命令返回成功就认为设计正确。更可靠的流程应拆成三层：先检查 RPC 调用是否成功，再读取模型的参数和拓扑信息，最后导出 STEP、STL 或工程图并由下游工具复核。若任务涉及加工，尤其不能跳过仿真和空运行；项目 README 明确提示 CAM 在有限的硬件环境中验证过，实际切削前必须模拟与 dry-run。
对团队而言，这类架构还提示了一个实用原则：把约束写成机器可检查的条件。例如零件外形尺寸、孔数量、装配间隙和导出文件是否存在，都应该通过独立检查确认，而不是让 Agent 自己评价“看起来没问题”。可将失败结果保留为可读日志，让人能定位是几何建模、约束求解还是导出环节出错。
适合谁尝试
如果你在探索生成式设计、参数化零件自动化，或希望 Agent 在 CAD 文档内进行可验证的修改，Loböle 的统一命令层值得试用。它的价值是把 GUI 功能、脚本操作和 Agent 接口放在同一条可检查的路径上；但 0.1 阶段、Linux 优先的现状意味着部署前要确认系统要求，并以小模型验证工作流。Windows 有构建版本，macOS 尚未测试，不能把跨平台支持理解为成熟度相同。
最好的起点不是让 Agent 一次性设计复杂机构，而是给它一个明确、可回滚的小任务：创建几何体、修改一个参数、读取结果，再由人工检查导出物。先建立“命令可调用、结果可核验、失败可恢复”的闭环，才有条件把 CAD 自动化从演示推进到工程流程。