claude mcp add solidcraft -- solidcraft-cli mcp
前段时间刷到一条消息：一个叫 SELENE 的科学漫游车，整个建模过程走 SolidCraft 的 MCP 服务器做出来，作者 @0xlillith，时间线 3323 个可编辑步骤，重建无报错。
看到这种数字我第一反应是找茬。但"可编辑"三个字让我停了一下——不是因为 3323 大，是因为它不是一份烤干的网格，是一条能往回改的时间线。这两件事的难度差着量级。
于是我干了一件挺笨的事：没去复现它，把 SolidCraft 露给 agent 的工具列表整个摊开，一条条对着看。
list_commands execute batch inspect_design measure
body_topology set_parameter screenshot export undo
redo new_design open save
十四把。真正值钱的不在前两个。
让 agent 写代码，它错了你能读 diff。让 agent 建模，它错了你只能看画面——而画面是最会骗人的东西。一个壁厚差了 0.4 毫米的壳，在视口里和在图纸上，看起来都是对的。
所以要让 agent 自己干活，第一步不是给它手，是给它眼睛。inspect_design、measure、body_topology、screenshot，这四个就是眼睛：能量出体积、面积、质心和面/边/顶点数，能问出实体的拓扑关系，能把当前视口拍一张下来。
这四个在不在，直接决定 agent 是"能自己发现错了去修"，还是"每走一步都要停下来问人"。前者可以放权，后者只能当自动补全用。
接着是 undo 和 redo。
这两个太不起眼，可我翻完那圈之后认为它们分量最重。写代码的 agent，兜底靠 git——最坏情况 reset 一下，世界回到原点。建模场景谁来给这个兜底？没有的话，agent 学到的第一条教训就是"别乱动"，第二条是"问人"。
一个能撤销的 agent 会去试；一个不能撤销的 agent 会保守。这跟性格没关系，是它能承担多少试错成本的问题。
画外音：现在一堆 MCP server 连 undo 都没有，把后端接口机械地包成工具名就算完事，agent 一次调用失败就得整段重来，然后你还会奇怪它为什么越来越怂。
batch 解决的是另一个方向的账——上下文。
一步一步调，每调一次，工具返回的东西都要塞回 context window。建模这种活的量级吓人，一条草图十几个图元、七八个约束，全拆成单次调用，几步下来 context 就见底了，然后 agent 开始一本正经地胡说。把十几步压成一次，省下的不是时间，是它保持清醒的长度。
然后是路径限制那条，这个我最想聊。
solidcraft-cli mcp --allow-path DIR
工具的文件访问被卡死在几个地方：当前设计所在的那个文件夹（还得位于用户主目录里，不能是主目录本身，也不能是隐藏目录）、SolidCraft 自己的恢复文件夹、以及用 --allow-path 显式放开的目录。
头一遍读我把它归类成"防呆"——厂家的安全措施，防 agent 到处乱写。
后来我把这个判断推翻了。更准的说法是：这是授权书的反面。边界焊死之后，agent 不需要在动手之前先问一句"我能写这儿吗"——它知道答案，因为边界是确定的。敢放权的前提从来不是"我信得过你"，是"不该去的那部分已经被划掉了"。
权限这种东西我吃过几次亏，都是先给满、出了事再往回缩，来回好几轮才想明白边界应该一开始就立好。所以现在看到那种"给 agent 完整文件系统权限"的配置教程，我都是直接划走。不是为了安全，是那种配置下的 agent 干不了几件事就开始犹豫——它不是在思考，是在试探你。
跟带实习生一个道理。你给他多大授权，取决于他搞砸之后能不能自己发现并回退，跟简历漂不漂亮无关。
扯远了，回到正题……在拉回来之前，还有个跟工具面不太搭、但我憋不住的东西。
约束求解。
草图的约束求解在 CAD 里是最不性感的活，也是最难写对的。我在文档里翻到它怎么做的：相对已知几何被固定的点，用构造法精确放置；剩下的交给 Levenberg–Marquardt 迭代；解完拿雅可比矩阵的秩去算还剩几个自由度。
这段我盯着看了挺久。大多数同类项目在这一步会选择绕——接一个现成的求解器，或者只支持最基本的几种约束，够演示就行。自己写、还肯先用构造法把能精确算的算掉、只把算不准的部分交给迭代，说明写的人知道 LM 在退化情形下有多难看。
这里我又推翻了自己一个预设。我原本以为"纯 Rust 从零写参数化 CAD"多半是渲染做得漂亮、一碰约束就散的玩具。约束这块一出来，这个判断就站不住了。
而且反馈做得直白：过约束的编辑直接拒绝，完全约束的几何显示成黑色。这两个信号人和 agent 都不会误判。拖动时每帧求解，松手才重建一次——我一开始还想它为什么不边拖边重建，后来意识到模型一复杂，每帧重建就是自杀。
再说个数字。76 个公开参考零件里，75 个的体积、表面积、质心和包围盒跟解析解或 FreeCAD 算出来的一致，剩下 1 个是已经登记的问题。
75/76 本身不稀奇。稀奇的是紧跟在后面那句声明：这些校验不能说明它在几何或工作流上已经跟对照工具等价。
一个项目肯把 75/76 摆出来，又自己把台下的话说清楚，这比数字本身值钱。我见过太多 README 挂一个漂亮数字，然后什么上下文都不给。
不过我也不是全买账。同一批文档里写着"规划并求值 78 个参考实体约 65 毫秒，比上一代网格器快 50–65 倍"——上一代是谁、什么机器、什么场景，一个字没提。这种数字我存疑，等它把对照条件写明白再信。
还有一个自己的观察：体积、面积、质心、包围盒这四个量，说白了是静态快照级别的校验。建模里真正爱翻车的地方——重建顺序、特征依赖、约束的退化情形——这四个数对不出来。官方说"不能证明等价"我信，但"不等价"具体藏在哪些角落，这份 benchmark 也给不出答案。
顺手提一句成熟度。项目自己标的是早期，够做简单零件。下载文件没签名，Windows 上大概率弹 SmartScreen，macOS 第一次打开得右键选打开。
别拿它现在去接正经的生产活，这是我的建议。但这跟"值不值得花时间看"是两件事。上面翻的那些工具定义、那条路径限制、那个约束求解器，能学到的东西跟这个项目成不成熟没关系。
回到开头那个问题。3323 步的 SELENE，到底是模型牛还是工具牛？
我的答案是工具。而且这个答案我觉得能推广——以后看到任何"agent 自主跑完了一个复杂流程"的案例，先别急着归功于模型，把它的工具列表摊开看一遍。测量有没有、撤销有没有、批量有没有、权限边界清不清晰，这四个问题的答案，比模型叫什么都更能解释结果。
反过来也成立。你要是正在给自己的工具接 MCP，与其在工具描述的措辞上磨半天，不如先回答一件事：agent 出错之后，靠什么自己爬回来。
我现在给自己立的规矩是：碰一个新的 MCP server，第一条先看它有没有 undo。没有，就别聊什么全自动。
那个我到现在也没想明白的问题先搁这儿——如果工具面做到足够好，是不是小模型也够用了？不知道。哪天有空拿同一个任务换个便宜模型跑一遍，说不定能看出点什么。