Агент умел двигать детали, но не умел собирать механизм. Как я доработал FreeCAD MCP
«Нет, ты их повернул, а я просил поменять местами».
Это моё сообщение AI-агенту, которому я поручил собрать двухосевой механизм во FreeCAD. Чуть позже я уже объяснял, какую деталь нужно повернуть, вокруг какой оси, на сколько градусов, а затем по какой единственной координате её сдвинуть. Формально агент выполнял CAD-операции. По факту я управлял сборкой через чат. На это ушёл 1 час 37 минут — и даже тогда основание ещё оставалось несобранным.
На следующий день другой агент самостоятельно собрал механизм за 15 минут 7 секунд. Я не диктовал ему ни углы, ни координаты. Затем я повторил эксперимент с Codex, тем самым агентом, которому накануне пришлось объяснять каждое движение. Он тоже закончил самостоятельно — примерно за 17 минут 29 секунд. Правда, допустил ошибку, которой не заметили его геометрические проверки.
Между этими попытками я доработал FreeCAD MCP. И именно эта ошибка во втором прогоне лучше всего объясняет, чему новые инструменты научили агента, а чему — пока нет.
Мне нужен был не CAD, а механизм
Я делаю большой проект, одна из частей которого — платформа для поворота телефона в двух плоскостях: pan (по горизонтали) и tilt (по вертикали). Для конструкции выбрал два сервопривода MG996R. Я разработчик программного обеспечения, но не умею проектировать механические узлы в CAD и не собирался начинать с длительного изучения FreeCAD.
Установил FreeCAD, подключил MCP и нашёл готовый исходный дизайн Pan and Tilt for Standard Servo от micromet. В архиве были STL-модели, исходники OpenSCAD, изображения и описание. Основной механизм состоял из пяти печатных деталей: основания, поворотного лотка, двух разных боковин и верхней платформы. Дополнительно был шестой STL для ИК-датчика. Но готовой CAD-сборки, где все детали уже поставлены на места и связаны, в архиве не было. Геометрических моделей сервоприводов тоже не было.
Казалось бы, подходящая работа для агента: прочитать исходники, разобраться, как соединяются детали, собрать их в FreeCAD и показать результат. Мне хотелось задать именно такую задачу — на уровне результата, а не отдельных преобразований координат.
Вчера агент мог двигать детали, но не понимал, что собирает
Вечером 26 октября я передал Codex архив с моделью и попросил собрать конструкцию. Довольно быстро выяснилось, что красивого скриншота мало, чтобы понять, правильно ли всё расположено.
Одна деталь оказалась внутри другой. Я попросил поменять местами боковины — агент их повернул. Я спросил, зачем он изменил высоту, если у деталей раньше была одинаковая координата Z. После нескольких исправлений пришлось признать, что в таком режиме быстрее управлять процессом самому.
В журнале остались мои сообщения:
«нет ты их повернул, а я просил поменять местами»
«видимо придется делать самомму (((»
«давай заново. раздожи все детали. я буду тебе по шагам говорить что с чем собрать»
Дальше я делал именно это. Указывал оси и углы поворота, выбирал, какое отверстие с чем совместить, запрещал двигать соседние детали, ограничивал коррекцию одной координатой, просил откатывать неудачные перемещения. Это была не работа с CAD мышью — команды по-прежнему выполнял агент. Но решения о взаимном положении деталей принимал я.
От повторной передачи архива до частичной приёмки прошло 1 час 37 минут. Причём на тот момент я принял всё, кроме основания, а затем работа продолжилась. Это не замер «сколько Codex тратит на полную сборку» и не честная база для вычисления ускорения. Но вполне честная иллюстрация того, сколько человеческого участия потребовал процесс.
Меня особенно раздражало не то, что агент ошибался. Ошибки при сборке ожидаемы. Проблема была в другом: он не мог устойчиво обнаруживать и исправлять их без меня.
Почему я подумал о «глазах» для агента
Это не первый раз, когда я сталкиваюсь с такой проблемой. До FreeCAD я уже занимался двумя другими MCP-проектами.
В Remotion MCP App агент может получать реально отрендеренные кадры видео, а не рассуждать о том, как должен выглядеть написанный им React/Remotion-код. В Android UI Renderer MCP он получает не только скриншот экрана, но и дерево интерфейса, координаты элементов, размеры и состояние текста.
Оба проекта были попыткой решить одну задачу: дать агенту обратную связь, достаточную для самостоятельной итерации.
Во FreeCAD я постоянно уточнял у агента, видит ли он результат. Было ощущение, что он переставляет объекты, не понимая, какой механизм в итоге должен получиться. Это не значит, что исходный MCP вообще не умел показывать изображение: ракурс получить можно было. Но изображение одной проекции не отвечает на вопросы, соосны ли отверстия, какой зазор между плоскостями и не пересекаются ли детали.
Я сам в CAD не специалист, поэтому попросил другого агента оценить инструментарий. Его оценка подтвердила мои опасения. После этого я поручил coding agent доработать MCP. Это было моё инженерное решение, основанное на наблюдениях и экспертной проверке, а не доказанная заранее причина всех неудач.
Моя цель была простой: агент должен иметь возможность итеративно добиваться результата без участия человека.
Что я изменил в FreeCAD MCP
Я взял за основу открытый neka-nat/freecad-mcp. Исходный проект уже умел работать с документами, объектами и Python-кодом внутри FreeCAD. Я не писал альтернативный CAD-инструмент с нуля: по моей задаче агент расширил существующий MCP, сохранив исходные 17 инструментов и добавив 14 новых.
Главное изменение — переход от произвольного «выполни этот Python-скрипт» к специализированным, проверяемым операциям сборки. Например, теперь агент может пройти такую последовательность:
inspect_part → прочитать грани, цилиндры, оси и размеры
↓
define_interface → указать контактную плоскость и крепёжные отверстия
↓
plan_alignment → рассчитать совмещение, не меняя документ
↓
preview_alignment → увидеть предлагаемое положение в нескольких ракурсах
↓
apply_alignment → применить перемещение с замерами и откатом при ошибке
↓
check_assembly → независимо повторить проверку результата
↓
inspect_region → получить несколько стандартных видов сборки
Это предусмотренный инструментом рабочий цикл, а не последовательность, которую каждый агент в моих экспериментах прошёл целиком.
Здесь есть несколько важных деталей. Отверстия задаются в определённом порядке: инструмент не угадывает сам, какая сторона детали должна быть наружной. Совмещение проверяет численные отклонения осей, зазоры и пересечения с перечисленными объектами. Если допуск нарушен, изменение можно откатить. Для долгих операций появились отслеживаемые задания; для предварительно рассчитанных перемещений — защита от применения к уже изменившейся модели.
Проверка при этом не всесильна. Например, результат явно сообщает whole_assembly_checked: false, если проверены лишь указанные объекты, а не вся конструкция.
На исследованной версии проекта 286 тестов проходили. Но тесты MCP и отдельные CAD smoke-сценарии — не доказательство, что любой созданный им механизм можно изготовить или что он будет работать под нагрузкой.
Сегодня: сборка без моих координат
27 октября я попросил Claude собрать механизм из того же архива самостоятельно. Когда агент начал обращаться к предыдущему проекту подставки, я остановил его: «забудь про проект подставки. делай сам не подглядывай». До запрета он уже успел увидеть служебную информацию и заголовки прежних коммитов, поэтому абсолютной изоляцией от предыдущего контекста этот прогон назвать нельзя. Но после запрета я больше не подсказывал, как располагать детали.
Агент изучил STL и исходники OpenSCAD, восстановил пять деталей как геометрию, пригодную для анализа граней и цилиндров, сверил их объёмы с исходными моделями (разница не превышала 0,04%) и габариты в пределах заданного порога. Затем рассчитал положения деталей, добавил две упрощённые модели сервоприводов и качалку, проверил пары тел на пересечения, сделал дискретные проверки поворота, сохранил FCStd и подготовил четыре ракурса.
На всё — 15 минут 7 секунд после команды работать самостоятельно. Я получил сохранённый CAD-документ, а не просто финальное сообщение «готово».
Исторический коллаж Claude, сохранённый без ретуши. Важно: зелёная надпись внутри изображения «Все оси совпали до 1e-6 мм, пересечений между деталями нет» ошибочна. Ниже — реальные ограничения и замеры. Не используйте эту подпись как подтверждение инженерной точности.
При разборе логов обнаружилась существенная деталь: основную компоновку Claude сделал собственными Python-скриптами. Новый API совмещения он применил к двум боковинам после исходной расстановки, чтобы проверить и воспроизвести их положение. Поэтому было бы неверно написать, что «новые MCP-команды собрали весь механизм». Мы наблюдаем самостоятельную работу в доработанном инструментальном окружении, но не изолированный тест вклада каждой новой команды.
После этого я специально повторил задачу в Codex. Хотел исключить слишком простое объяснение: «вчера был Codex, сегодня Claude — всё дело только в смене модели».
Codex тоже собрал и сохранил конструкцию без моих пошаговых указаний — примерно за 17 минут 29 секунд. В этом прогоне он уже использовал новые инструменты define_interface, plan_alignment, preview_alignment, apply_alignment, check_assembly и inspect_region для ряда соединений. Создал две условные модели серво, качалки и также включил шестую деталь архива — крепление ИК-датчика.
Исторический результат Codex в четырёх проекциях. Расположение деталей специально не исправлено: на этой модели я заметил ошибку компоновки.
Именно Codex дал наиболее показательный результат: сборку он теперь сделал сам, но две боковины перепутал местами.
Проставки, которые объясняют границу автоматической проверки
Codex добавил в сборку четыре проставки толщиной 1 мм. В оригинальном архиве их не было. Агент ввёл их, когда пытался устранить пересечения в верхней части механизма.
Когда я посмотрел на модель, понял, что боковины стоят не на своих местах. По моей оценке, проставки понадобились именно из-за этой перестановки: вместо исправления исходного расположения деталей агент стал компенсировать проблему дополнительными элементами. Эта причинная связь — мой разбор результата, а не отдельно проведённый эксперимент с удалением проставок и перестановкой боковин.
Интересно, что проверки Codex при этом сообщали об успехе. Для заданных им сопряжений отклонение отверстий было меньше 5e-14 мм, угловая ошибка — ноль. Отдельный скрипт не нашёл объёмных пересечений среди 91 пары тел в нейтральной позе.
Противоречия нет. Инструмент проверял то, что агент сам объявил правильным: выбранную пару отверстий, допустимый зазор, отсутствие пересечения в проверенном положении. Он не проверял, верно ли агент понял назначение правой и левой боковины.
Другими словами, можно математически безупречно совместить не те детали не той стороной.
И у Claude проверка тоже была не идеальной. В его финальных измерениях оставалось смещение осей 0,5831 мм, по сопоставленным креплениям — до 0,25 мм, одно отверстие не получило соответствия. Было и пересечение условных вала серво и диска качалки — 84,823 мм³. Тем не менее итоговая картинка утверждала, что все оси совпали до 1e-6 мм и пересечений нет.
Более того, одна из собственных проверок Claude сначала ошибочно показывала нулевые отклонения, потому что перед измерением сама восстанавливала эталонные положения деталей. Агент заметил подозрительные нули и исправил скрипт. Хороший пример того, почему проверочный код тоже нельзя автоматически считать истиной.
Я визуально принял основную компоновку Claude. Но это ещё не означает, что реальные MG996R встанут без доработок, что все узлы выдержат нагрузку телефона или что конструкция свободно пройдёт весь диапазон углов. Серво в повторных прогонах были упрощёнными CAD-макетами. Физическую сборку и испытания я пока не предъявляю.
Что на самом деле изменилось
За два дня я прошёл путь от управления каждой CAD-операцией через сообщения к постановке задачи целиком. Это для меня главный результат.
При этом я не могу честно сказать, что новый MCP «ускорил сборку в шесть раз». Прогоны различались не только инструментами: менялись агент, контекст, способ представления геометрии, состав деталей и условных сервоприводов. Первый процесс включал ручную адаптацию под MG996R, а последующие — самостоятельную компоновку с упрощёнными моделями. Полученные 15 и 17 минут описывают именно эти два самостоятельных прогона, не универсальный показатель скорости.
Но практическая разница в моей роли очевидна. В первом случае я объяснял, как повернуть и куда сдвинуть. Во втором — что нужно собрать, а затем проверял результат. Когда Codex ошибся, мне не пришлось обучать его геометрическим преобразованиям заново: я увидел неверное инженерное решение на готовой модели.
Опыт с Remotion, Android UI и теперь FreeCAD укрепил мою мысль: агенту мало возможности действовать. Ему нужно уметь наблюдать последствия действия, проверять их и повторять цикл исправлений. Иногда для этого достаточно кадров видео, иногда — дерева элементов интерфейса, а иногда нужны оси, плоскости, расстояния и объёмы пересечений.
Но обратная связь не заменяет понимание задачи. FreeCAD MCP научился проверять геометрию сопряжения. Следующий предел оказался выше: нужно проверять не только то, насколько точно соединены детали, но и правильно ли агент вообще решил, какие детали соединять.
Пока это по-прежнему моя ответственность.
Код и источники: мой fork FreeCAD MCP · исходный MCP neka-nat · дизайн Pan and Tilt for Standard Servo от micromet. Механические модели и изображения сборок основаны на стороннем дизайне, распространяемом в архиве на условиях Creative Commons Attribution–ShareAlike (версия лицензии в доступном исследовании не установлена); MIT-лицензия MCP к этим моделям не относится.