Инструменты CAD-агентного проектирования: глубокий практический срез 30.10.2026

Дата проверки: 30 октября 2026, UTC. Продолжение исследования подходов. Предмет — агент, который создаёт и меняет инженерную CAD-модель через API/код, а не чат об инженерии и не генератор красивой сетки.

Граница доказательности: выполнены web_search и чтение первичных web-документов; CAD, платные API и лицензируемые рабочие места здесь не запускались. Ниже разделены документированные возможности и предлагаемые протоколы воспроизведения, которые ещё нужно исполнить в ТГУ. Примеры кода — минимальные заготовки для smoke-test, не протокол успешного испытания. Документация latest/main/master изменяема: дата обращения не является датой выпуска. Номера SDK в URL — проверенная версия источника, не утверждение о последней доступной версии продукта. Оценка зрелости — экспертная, не формальный TRL.

1. Практическое решение для ТГУ

1. Основной учебно-конструкторский стек: КОМПАС-3D + поставляемый КОМПАС-Макро/Python + API5/API7 на выделенном Windows-месте; агент меняет проверенные параметры и вызывает узкий адаптер. Требуемый результат — редактируемые деталь, сборка, чертёж и спецификация в КОМПАС, а не импортированный STEP вместо истории.
2. Открытый исследовательский стек: Python + CadQuery (или build123d как отдельная экспериментальная ветка) для генерации и численных тестов; FreeCAD Python для упражнений с нативным деревом, Sketcher и TechDraw. Не обещать автоматическое превращение CadQuery-кода в дерево PartDesign: это разные маршруты построения. MCP добавлять после работающего детерминированного runner, не вместо него.

T-FLEX — обоснованная замена первого backend при уже имеющейся лицензии, учебной практике и эксперте T-FLEX, но не бесплатный перенос КОМПАС-адаптера. Onshape и Zoo — сравнительные облачные пилоты на несекретных деталях после проверки договора, доступности из РФ, хранения данных и оплаты. Коммерческая доступность для ТГУ в этой работе не установлена.

2. Единый воспроизводимый тест вместо несопоставимых демо

Контракт детали P1

Вход: пластина крепления датчика, мм; L=60, W=30, t=4, pitch=40, d=4; начало координат в центре нижней грани; два сквозных отверстия с осями (−pitch/2,0) и (+pitch/2,0). Материал, нагрузка, посадка и технология отдельно утверждаются преподавателем; отсутствие этих данных запрещает вывод о прочности. Базовый пример намеренно без скруглений: они добавляются отдельным тестом устойчивости ссылок.

Ожидаемые величины: один solid, габариты 60×30×4; объём L*W*t − 2*pi*(d/2)^2*t ≈ 7099.469 мм³. Это проверка геометрии, не массы: масса требует плотности. Допуск сравнения задаётся в протоколе, например 0,01 мм по размерам и 0,1 мм³ по объёму для этого простого аналитического теста; это учебный критерий, не производственный допуск.

Последовательность для каждого backend:

1. Зафиксировать CAD build, SDK, ОС, Python/.NET, зависимости, лицензии и locale. Исходный шаблон только читать; выпускать новую ревизию в отдельной папке/облачной копии.
2. Из JSON-контракта получить план: базовый эскиз → выдавливание → эскиз двух отверстий → вырез. В шаблонном режиме достаточно изменения именованных переменных; агент не должен сочинять произвольный код.
3. Пересчитать; прочитать обратно геометрию, дерево и ошибки. Сохранение файла само по себе не означает успеха solver.
4. Изменить pitch:40→44, t:4→5; перестроить, закрыть, открыть заново; проверить сохранение симметрии, диаметра и сквозности. Отрицательный тест pitch=58,d=4 должен быть отвергнут до моделирования: отверстия выходят за границу.
5. P2: присоединить условный корпус датчика к пластине с заданными интерфейсами. Проверить количество компонентов, реальные сопряжения/DOF, отсутствие недопустимых пересечений. Простое размещение тел координатами не засчитывать как constrained assembly.
6. P3: создать ассоциативные виды и размеры, изменить pitch, проверить обновление размера; оформить обозначение, материал, позиции и спецификацию. PDF/SVG без исходного документа не засчитывать как нативный чертёж.

Сохранять вход, сценарий, нативные документы, STEP, контрольные виды, численные измерения и журнал вмешательств. Для облака дополнительно — document/workspace/version/microversion IDs, но без секретов. Сравнивать шаблон без LLM, агент с адаптером и ручную работу на одинаковых заданиях; учитывать отказы и время исправления, а не только удачное видео.

3. КОМПАС API5/API7/КОМПАС-Макро

Что подтверждено

Официальный курс АСКОН «API КОМПАС-3D. Разработка приложений» прямо требует базовый КОМПАС-3D и Python; КОМПАС-Макро из базового пакета устанавливает Python и необходимые модули. Программа содержит API5/API7, эскизы, тела, сборку, чертежи и спецификацию. Это существенно сильнее рекламного заявления «есть API», но учебные материалы курса требуют отдельного доступа.

Открытая справка SDK 23, ksDocument3D/IDocument3D различает Automation и COM, перечисляет компоненты, спецификацию, экспорт и сопряжения; коллекция сопряжений получаема через ksRequestInfo3D::GetMateConstraintCollection. Следовательно, сборка здесь не обязана ограничиваться набором расставленных solid.

• API5: проверенный в источнике вход KompasObject, Document3D()/ActiveDocument3D(), объекты ks…; удобен для существующих примеров и унаследованной автоматизации.
• API7: другой объектный интерфейс, IApplication, документы и коллекции; нельзя подставлять методы API5 в API7 только из-за похожего названия. Использовать обёртки и типовые библиотеки конкретной установленной версии.
• КОМПАС-Макро: среда запуска/подготовки Python для автоматизации, не LLM-агент и не MCP-сервер. API5 и API7 — не версии языка Python и не разные геометрические ядра.

Сценарий K1: от официального кода к ограниченному агенту

Вход → действия → нативный выход: JSON P1 + утверждённый шаблон → КОМПАС-Макро запускает Python; адаптер открывает копию, меняет именованные размеры/переменные и пересчитывает → деталь .m3d с эскизами/features. Затем шаблон сборки + корпус → вставка компонентов и сопряжения → .a3d; виды/размеры и атрибуты → .cdw, спецификация .spw. Это целевые артефакты пилота; конкретные процедуры выпусков нужно взять из SDK/уроков и проверить на установленном build.

Практическое воспроизведение:

1. На учебной Windows-машине установить базовый пакет и КОМПАС-Макро; выполнить штатный пример Python без LLM. Зафиксировать разрядность и регистрацию COM; не устанавливать случайные Python-модули в поставляемую среду без копии окружения.
2. Получить рабочие образцы из разделов создания 3D API5, API7, параметрического эскиза, сборки и выпуска документов. Создать руками золотой P1 с именованными параметрами и сохранить копию.
3. Сначала реализовать inspect/read_parameters/set_parameters/rebuild/save_copy; только после теста — create_sketch/extrude/cut/add_component/add_mate. Имена здесь предлагаемый контракт адаптера, а не названия методов АСКОН.
4. Выполнить P1 и perturbation-тест. Получить список операций и сопряжений обратно, проверить native reopen; затем P2/P3. Программно заданные координаты прямоугольника не считать автоматически полностью определённым параметрическим эскизом.
5. Включить LLM только как источник JSON-параметров/плана; runner валидирует диапазоны и управляет CAD в одном сеансе. Новые типы features допускаются после review инженером.

Публичный форум официальной СДО содержит pythoncom, win32com.client, gencache.EnsureModule и Dispatch("Kompas.Application.5") / Dispatch("Kompas.Application.7"). Но это сообщение учащегося с ошибками, не эталон SDK: там обсуждаются LineSegment/LineSegments, есть Stule. Не копировать весь блок как гарантированно рабочий пример. Полезность источника — подтверждение COM-механизма и демонстрация реального риска несовпадения интерфейсов.

Constraints/дерево: сохраняются только при явном создании соответствующих нативных объектов; координатный рисунок и импорт STEP не эквивалентны constraints/features. Сборки/чертежи: документированы, но автоматическое соблюдение ЕСКД и полнота простановки размеров не следуют из наличия методов.

ОС/лицензия/развёртывание: проверяемый путь — Windows COM и локально установленный коммерческий КОМПАС; агентный frontend может работать на Linux и отправлять задания Windows-runner. Не утверждается, что этот COM-код переносим в Linux-редакцию. Учебная лицензия и базовый пакет не означают право неограниченного серверного/параллельного использования: согласовать число мест, удалённую автоматизацию и дополнения с АСКОН.

Зрелость: нативная автоматизация зрелая; ограниченный агент поверх утверждённых шаблонов — реалистичный пилот; автономная генерация произвольной сборки/документации не доказана. Основные ограничения: состояние активного документа, модальные окна, COM lifecycle, версия typelib, устойчивость ссылок на геометрию, разрешения на файл, лицензии и тестирование восстановимости после сбоя.

4. T-FLEX CAD Open API

Документированный минимум и инженерное расширение — отдельно

Официальный пример StarsPlugin для v17: C#-исходники поставляются в API/StarsPlugin, решение собирается Visual Studio с workload .NET desktop; DLL подключается через штатный механизм приложений. Пример уже скомпилирован в поставке. .tfa позволяет добавлять приложение из произвольной папки: для пилота лучше этот путь, чем замена DLL в системной Program с правами администратора.

Полностью описанный в открытой справке сценарий T0: число лучей, центр, два радиуса, угол, цвет → запуск StarsPlugin → команда создания звезды на чертеже/активной рабочей плоскости → редактируемый пользовательский объект в нативном документе T-FLEX .grb. Пошаговая инструкция задаёт 1–10 лучей, редактирование координат и вызов параметров уже созданной звезды. Это воспроизводимое доказательство подключения и параметрического пользовательского объекта, не доказательство автоматического выпуска 3D-сборки.

Предлагаемый сценарий T1 для P1: JSON → C#-адаптер Open API открывает копию заранее подготовленной .grb, изменяет внешние переменные L,W,t,pitch,d, пересчитывает, проверяет и сохраняет → нативный .grb с исходными зависимостями. Возможность написать внешний редактор переменных через Open API и автоматический пересчёт прямо подтверждены справкой внешних переменных v17. Точные методы чтения/сохранения/пересчёта следует брать из поставляемой Open API help, на которую отсылает изготовитель; здесь не выдумываются компилируемые C#-сигнатуры.

1. Повторить T0 без изменений; пересобрать копию StarsPlugin и подключить её из пользовательской папки.
2. Создать эталон P1 в T-FLEX, выставить внешние переменные и проверить ручное редактирование с пересчётом.
3. Написать узкую команду изменения переменных по JSON, используя installed Open API help; выполнить P1 и повторное открытие.
4. Отдельно расширить до P2/P3: шаблон сборки, связи компонентов, проекции и размеры. Входы/выходы остаются .grb-документами; состав и ассоциативность нужно проверять внутри документа, а не по расширению.

Constraints/дерево/сборки/чертежи: T-FLEX как CAD имеет параметрический контур, но прочитанные web-страницы подтверждают именно приложение/объекты и внешние переменные. Полнота конкретных Open API операций для произвольных 3D-features, сборочных связей, BOM и чертежей в этой проверке не установлена. Для шаблона можно сохранить созданные инженером зависимости; не выдавать это за агентное построение их с нуля.

ОС/лицензия/локальность: документированная среда — Windows, Visual Studio/.NET, локальный коммерческий T-FLEX; условия SDK, образовательной лицензии, дополнительных модулей и серверного исполнения уточняются у поставщика. Не переносить на другие ОС только потому, что C# кроссплатформенный.

Зрелость: штатный механизм расширения зрелый; агентный адаптер — собственная разработка. Для ТГУ наиболее низкорисковый старт — конфигуратор проверенного семейства через внешние переменные, затем операции. Не называть StarsPlugin ИИ-конструктором.

5. FreeCAD Python и community MCP

Официальное руководство Python подтверждает консоль, макросы, внешние скрипты, создание/редактирование объектов, doc.recompute() и разделение App/Gui; геометрия может работать без GUI, визуальные свойства — нет. Встроенный Assembly Workbench отмечен с v1.0, использует Ondsel solver, содержит joints и примеры; не путать его с дополнительными Assembly3/Assembly4/A2plus. Наличие современного встроенного solver не гарантирует стабильность всех Python-вызовов между версиями.

F1: нативная эскизная модель

Вход → действия → выход: JSON P1 → Python создаёт PartDesign::Body, Sketcher::SketchObject, геометрические и размерные ограничения; Pad; эскиз отверстий и Pocket; recompute и измерения → .FCStd с деревом Body/Sketch/Pad/HoleSketch/Pocket, плюс исходный Python. Для P2 — встроенная Assembly с links/joints; для P3 — TechDraw page/views/dimensions внутри .FCStd, PDF как производная копия.

Следующий минимальный F0 smoke-test проверяет API, редактируемые примитивы и сохранение. Он намеренно не претендует на полную реализацию F1: дерево boolean-операций есть, Sketcher-constraints нет.

# Выполнять в Python-консоли FreeCAD либо через его Macro.
# out — существующая отдельная каталог-папка результатов; не исходный проект.
import FreeCAD as App
import Part
from pathlib import Path
out = Path.home() / "cad-pilot-output"
out.mkdir(exist_ok=True)
doc = App.newDocument("P1")
base = doc.addObject("Part::Box", "Plate")
base.Length, base.Width, base.Height = 60, 30, 4
base.Placement.Base = App.Vector(-30, -15, 0)
last = base
for i, x in enumerate((-20, 20)):
    hole = doc.addObject("Part::Cylinder", "Hole" + str(i))
    hole.Radius, hole.Height = 2, 4
    hole.Placement.Base = App.Vector(x, 0, 0)
    cut = doc.addObject("Part::Cut", "Cut" + str(i))
    cut.Base, cut.Tool = last, hole
    last = cut
doc.recompute()
assert last.Shape.isValid() and len(last.Shape.Solids) == 1
assert abs(last.Shape.Volume - 7099.469035) < 0.1
doc.saveAs(str(out / "P1.FCStd"))
Part.export([last], str(out / "P1.step"))

F0 полезен как baseline против «агент только загрузил готовую Shape»: изменение свойства примитива и recompute меняет результат, но расстояние между отверстиями здесь задаётся Python, не именованным параметром с constraint solver. В F1 добавить явные размерные constraints/expressions, проверить DOF и серию изменений, затем сохранить и открыть документ заново.

Чертежи: TechDraw API показывает TechDraw::DrawPage, SVG template, DrawViewPart, DXF/SVG; сама страница предупреждает о неполноте/устаревании с ноября 2018 и направляет к автодокументации и unit tests. Поэтому изготовление корректного ЕСКД-комплекта нельзя объявить подтверждённым одним этим примером. Зафиксировать шаблоны и текущие тесты установленной версии; сравнить с образцом преподавателя.

F2: MCP — транспорт к FreeCAD, не официальный продукт FreeCAD

Проверен сторонний community-проект neka-nat/freecad-mcp, README автора. Это первичный источник именно данного connector, не документация официального MCP-продукта FreeCAD. README описывает две части: addon внутри FreeCAD и MCP server у клиента, создание/редактирование моделей и выполнение Python.

Протокол повторения: закрепить commit и проверить код; скопировать addon/FreeCADMCP в пользовательский addon directory; перезапустить FreeCAD; выбрать MCP Addon и Start RPC Server; в MCP-клиенте command: uvx, args: [freecad-mcp]; оставить FreeCAD/RPC запущенным. По умолчанию localhost. Для реального повторения следует закрепить и addon commit, и пакет сервера, а не оставить плавающий uvx без версии. Перед включением LLM выполнить F0/F1 через проверенные команды коннектора и сравнить геометрию.

Вход P1 → MCP-клиент → community server → addon/RPC → штатный Python FreeCAD → тот же .FCStd. MCP сам не добавляет constraints, историю или способность проектировать: если выполнен Part::Feature с готовым B-rep, результат не становится автоматически PartDesign. Arbitrary Python/RPC — широкие полномочия: привязка loopback, запрет внешнего доступа и allowlist операций обязательны. Значки security assessment и demo не заменяют аудит.

ОС/лицензия: FreeCAD локально на Windows/Linux/macOS; основной код под LGPL 2.1, лицензии зависимостей/addons проверять отдельно. Облако для геометрии не обязательно; внешняя LLM может передавать данные наружу. Зрелость: Python и моделирование — практичны, встроенная сборка моложе базового Part/Sketcher; agent+MCP — экспериментальный слой, требующий сопровождения и version pinning. Не заявлять официальную поддержку FreeCAD для выбранного community-server.

6. CadQuery и build123d: лучший короткий путь к проверяемому коду, но не к чужому feature tree

C1: CadQuery

Официальный QuickStart демонстрирует параметрический блок с отверстиями, fluent API и экспорт; сборочная документация — Assembly, constrain, Point/Axis/Plane и solve. CadQuery не следует описывать как библиотеку без сборок. Вместе с тем assembly solve не равен полноценной системе динамического моделирования и документации изделия.

Вход → действия → нативный выход: JSON/утверждённый Python → Workplane/operations/OpenCascade → исходный .py + параметры как инженерный оригинал; STEP/BREP как геометрический результат. «Нативный» здесь — код, не .m3d/.FCStd с восстановленным деревом. Историю действий можно воспроизвести исполнением кода; STEP её не переносит.

import cadquery as cq
from math import pi
L, W, t, pitch, d = 60.0, 30.0, 4.0, 40.0, 4.0
assert 0 < d < W and 0 < pitch < L - d and t > 0
part = (cq.Workplane("XY").box(L, W, t, centered=(True, True, False))
        .faces(">Z").workplane()
        .pushPoints([(-pitch/2, 0), (pitch/2, 0)]).hole(d))
s = part.val()
assert s.isValid() and len(part.solids().vals()) == 1
assert abs(s.Volume() - (L*W*t - 2*pi*(d/2)**2*t)) < 0.1
cq.exporters.export(part, "P1.step")

Повторение: отдельное Python-окружение с закреплёнными CadQuery/OCP; запустить сценарий из отдельной output-папки, затем заменить pitch,t, запустить заново, импортировать STEP обратно и сравнить solid/габариты/объём. Для assembly добавить именованные компоненты и constraints, вызвать solve и проверить фактические положения. Теги/семантические selectors предпочтительнее случайных индексов граней; после усложнения модели даже selector >Z может перестать выбирать задуманную поверхность.

Constraints/дерево: параметры и зависимости — код; Sketch/Assembly имеют свои средства ограничений, но Workplane-цепочка сама по себе не GUI-дерево с fully constrained sketch. Чертежи: 2D-экспорт/проекции не эквивалентны готовому ассоциативному ЕСКД-чертежу с размерами и основной надписью; выпуск документов — отдельный backend/шаблон.

B1: build123d

Документация v0.10.0 подтверждает B-rep, builder/algebra API, enums и Python filters; сборки v0.10.0 — Compound(children=...), дерево компонентов и экспорт, связь с joints tutorial. Создание Compound не означает, что solver решил произвольную систему сопряжений. Для агента полезны явные Python-объекты, типы и фильтрация; это не независимое доказательство превосходства над CadQuery.

Минимальный P1 без хрупкого выбора граней:

from build123d import *
from math import pi
L, W, t, pitch, d = 60, 30, 4, 40, 4
with BuildPart() as p:
    Box(L, W, t, align=(Align.CENTER, Align.CENTER, Align.MIN))
    with Locations((-pitch/2, 0, 0), (pitch/2, 0, 0)):
        Cylinder(d/2, t, align=(Align.CENTER, Align.CENTER, Align.MIN),
                 mode=Mode.SUBTRACT)
assert abs(p.part.volume - (L*W*t - 2*pi*(d/2)**2*t)) < 0.1
export_step(p.part, "P1.step")

Вход → Python builder/algebra operations → .py/параметры + STEP; сборочное дерево — Compound/именованные Shapes в коде. Геометрическая валидность и число solid дополнительно проверяются средствами закреплённой версии и обратным импортом. Повторение и perturbation-тест те же, что C1. Не смешивать API/примеры dev-документации с зафиксированной версией.

ОС/лицензия/локальность обоих: Python-библиотеки для Windows/Linux/macOS при наличии совместимых wheels OCP; локально, headless, без обязательной подписки CAD. CadQuery Apache-2.0, build123d Apache-2.0; зависимости/контейнеры имеют собственные лицензии. Разница отсутствия лицензии CAD и стоимости внешнего LLM API принципиальна.

Зрелость: детерминированные script-first детали/семейства — практично; agent-generated code — контролируемый пилот; большие сборки, документирование и нестабильные boolean/fillet требуют ручной инженерии. Свободный Python исполнять в отдельном контейнере/процессе с лимитами CPU/RAM/времени, без сети и доступа к исходным данным по умолчанию.

7. Onshape FeatureScript + REST API

Здесь есть два разных механизма: FeatureScript задаёт параметрическую геометрию/пользовательские features в CAD-контексте, REST читает и изменяет документы, features, сборки и чертежи. Onshape — не локальное Python-ядро.

O1: редактируемый облачный документ

Вход P1 + document/workspace/Part Studio IDs → авторизованный клиент получает getPartStudioFeatures, создаёт/обновляет эскиз и extrude/cut через addPartStudioFeature/updatePartStudioFeature либо вставляет проверенный custom FeatureScript feature → нативный Onshape document с Feature List. Затем createAssembly/createInstance и mate features → вкладка Assembly; drawing API → вкладка Drawing. Нативный результат — не локальное расширение файла: сохранять IDs и неизменяемую version/microversion, плюс резервный STEP/PDF.

Официальный Features guide даёт конкретный воспроизводимый маршрут:

1. В UI создать sketch, extrude и fillet; получить JSON feature list, состояния features и library version. Это рекомендуемый самим Onshape способ изучения реальной схемы, а не угадывание JSON LLM.
2. В копии документа повторить официальный пример cube: POST .../partstudios/d/{did}/w/{wid}/e/{eid}/features с featureType:"cube", quantity parameterId:"sideLength", expression:"60 mm"; сохранить featureId и ответ solver. Затем update того же feature на "64 mm".
3. Перейти к P1: круг/прямоугольник + ограничения; extrude/cut; получать plane IDs запросом, а не жёстко кодировать ID из чужого документа. В примере круга constraints:[]: его успешное создание не доказывает полной определённости.
4. Проверить featureStates, измерения и variation P1. Схема btType, параметры и версии API могут меняться; закрепить клиент/тестовый fixture и читать API Explorer.
5. Для P2 повторить официальный Assembly guide: createAssembly → createInstance → mate connectors → BTMMate-64 (например FASTENED). Матрицы occurrence — absolute object-to-world, переносы в примерах в метрах; не применять рекурсивно родительские transforms как в произвольном scene graph.
6. Для P3 использовать Drawing guide: create drawing из source element/part/template → modifyDrawing → modification status → inspect. Важно: HTTP 200 может означать частичный успех batch; проверять статус каждого изменения и dangling annotations, не только код HTTP.

Критическая ловушка: evalFeatureScript принимает lambda expressions; это не endpoint для произвольного полного Feature Studio-кода и не гарантированный способ сохранения feature в документе. Мутации дерева выполнять через документированные feature APIs/custom feature; вычисления геометрии — через eval. Обычный bounding box может быть приблизительным; для проверки размеров использовать tight evBox3d, как в официальном примере.

Constraints/дерево/сборки/чертежи: документированы нативно, включая mates и аннотации/допуски/BOM в drawing API; ЕСКД, оформительские шаблоны и корректность размерных баз по-прежнему отдельная проверка. API не превращает произвольный text prompt в качественный замысел.

ОС/лицензия/облако: браузерный клиент, REST с любой поддерживаемой ОС; коммерческая облачная платформа, образовательные/бесплатные планы имеют отдельные условия. План, приватность документов, API credentials/limits и допустимость обучения для ТГУ нужно проверить до загрузки. Нельзя обещать локальный/offline solver или доступность из РФ. Зрелость: CAD/API зрелые; свой агент требует управления auth, rate limits, конфликтами microversion и повторными запросами без дублирования features.

8. Коммерческий text-to-CAD: что удалось подтвердить первичными источниками

Zoo / Zookeeper / KCL — конкретный проверенный вариант

Прочитаны официальные Agent API, Zoo MCP и CLI KCL export. Agent API прямо описан как CAD-focused LLM agent, вычисления выполняются на remote machines. Фразы «агент eventually приходит к правильному решению», «fully editable» — заявления изготовителя, не независимый benchmark.

Z1: вход → действия → нативный выход: конкретное ТЗ P1 → MCP-совместимый клиент + официальный Zoo MCP; ассистент создаёт/редактирует KCL, сохраняет проект разрешёнными файловыми инструментами клиента, выполняет его через Zoo с kcl_path, проверяет геометрию → сохранённый KCL-проект (main.kcl и необходимые project files), открываемый в Zoo Design Studio; STEP — дополнительный экспорт. Это отличается от обещания «STEP переносит дерево в КОМПАС».

Документированный порядок воспроизведения:

1. Получить Zoo API token, передать через environment ZOO_API_TOKEN; команда MCP — uvx zoo-mcp. Токен не включать в журнал/репозиторий.
2. Дать ограниченное ТЗ: пластина 60×30×4 мм, два отверстия Ø4 с pitch 40 мм; потребовать именованные параметры и сохранение KCL, не только preview/mesh.
3. Сохранить KCL через authorized file-editing tools клиента в отдельной папке; затем исполнить сохранённый проект через kcl_path. Не считать текст в чате сохранённым инженерным оригиналом.
4. Открыть проект в Design Studio; изменить pitch/t и проверить заново. Экспорт: zoo kcl export --output-format=step main.kcl output_dir. Не использовать --allow-errors для выпуска; фиксировать версии CLI/KCL и предупреждения. Флаг --deterministic нормализует временные поля экспорта, но не доказывает детерминизм LLM.
5. Импортировать STEP в независимый локальный backend, проверить P1 численно и подтвердить редактирование исходного KCL. Отдельно измерить стоимость/время и неуспешные попытки.

Constraints/дерево/сборки/чертежи: первичные страницы подтверждают путь к редактируемому параметрическому KCL и геометрическим утилитам; в этой проверке не установлен уровень fully constrained sketches, полноценной native assembly с mates, ассоциативного комплекта чертежей/спецификации по ЕСКД. Эти пункты нельзя заполнить словом «да» из общего обещания editable CAD. Нет основания утверждать перенос нативной истории в КОМПАС, T-FLEX или Onshape.

ОС/лицензия/локальность: MCP/CLI запускается у клиента с совместимым runtime; ядро/Agent API — облачные сервисы по договорным условиям. Локальная оболочка и локальный KCL не означают полностью локальные вычисления. Zoo MCP не имеет отдельной платы, но hosted tools считаются API usage вне Design Studio; общую стоимость считать вместе с LLM-клиентом/API. Поддерживаемые ОС конкретного desktop build, региональный доступ, приватность и условия образовательного использования отдельно проверяются; закупочная рекомендация для РФ не даётся.

Зрелость: продукт/API и официальный MCP подтверждены; инженерная надёжность на P1–P3 независимо не измерена. Роль в ТГУ — ограниченный внешний comparator, не обязательный учебный backend и не основание передавать чувствительную конструкторскую информацию.

Другие коммерческие названия — только с оговоркой о неполной проверке

Первичная страница Backflip Export Reconstructed CAD as a STEP File открылась HTTP 200, но fetch вернул только оболочку Notion. Поэтому из неё здесь не выводятся наличие text-to-CAD, параметрического дерева, поддержка сборок, лицензирование и зрелость; reverse engineering mesh→CAD не следует смешивать с text→constrained CAD. Вторичные новости не используются, чтобы заполнить пробел. Backflip и другие не прошедшие полнотекстовую первичную проверку коммерческие решения не ранжируются как подтверждённые альтернативы. Это ограничение исследования, не утверждение об отсутствии у них возможностей.

Дополнительная ловушка актуальности: найденная поиском старая команда Zoo zoo_ml_text-to-cad после перехода на основной домен дала 404. Воспроизводимый маршрут выше основан на прочитанной актуальной документации Agent API/MCP, а не на устаревшем поисковом сниппете.

9. Практическая сравнительная матрица

Обозначения: Д — прямо документировано в прочитанных первичных источниках; Ш — предлагается сохранять через заранее проверенный нативный шаблон; О — ограниченная/иная семантика; НП — не подтверждено данной проверкой. Отсутствие подтверждения — не доказательство отсутствия функции.

Выбор по критерию: нативный КОМПАС/ЕСКД → КОМПАС; локальная открытая история эскизов → FreeCAD; headless массовые параметрические варианты/CI → CadQuery, затем сравнение build123d; облачное feature/mate/drawing API → Onshape при разрешённом доступе; готовый коммерческий CAD-focused agent → Zoo как проверяемый кандидат, не промышленная гарантия. Если кафедра уже работает в T-FLEX, экономия на навыках и шаблонах может перевесить более открытую web-документацию конкурента.

10. Два рекомендуемых стека: состав и критерии приёмки

Стек A — «Нативный учебный выпуск ТГУ»

• Выделенное лицензированное Windows-место: КОМПАС-3D установленного build + SDK той же версии + КОМПАС-Макро/Python. API7 — основной путь нового адаптера там, где покрытие проверено; API5 — для нужных штатных примеров/операций, без лозунга «API5 запрещён».
• Небольшой Python orchestrator + JSON Schema/Pydantic-контракт; один writer на документ, read-only инспектор и очередь заданий. Локальная/разрешённая модель LLM сменяема, без обязательного multi-agent framework.
• Утверждённые P1/P2/P3-шаблоны, allowlist действий, checkpoint перед каждым блоком, bounded retries и human gate перед выпуском. Секреты/права CAD не передавать модели как произвольный shell.
• Результат: нативный комплект + STEP/PDF + журнал требований/измерений. Необходимость КОМПАС для учебных результатов обоснована в базовом исследовании.

Предлагаемая приёмка пилота: сначала 100% повторение 5 детерминированных заданий без LLM; затем не менее 20 вариантов P1 и несколько P2/P3 с фиксацией отказов. Числа — план испытаний, не доказанные пороги надёжности. Критерии: корректное повторное открытие, сохранённые параметры/сопряжения, обновляемые чертежи, все обязательные размеры/атрибуты, время исправления преподавателем. Если выпуск чертежа не проходит, ограничить пилот деталью, а не скрывать ручную доработку.

Стек B — «Локальная открытая CAD-лаборатория»

• Linux/Windows с закреплённым Python окружением, CadQuery/OCP и изолированным runner; build123d — отдельное окружение для A/B-сравнения, не смешение зависимостей в одном образе.
• FreeCAD установленного build: отдельный F1-адаптер, создающий Sketcher/PartDesign/Assembly/TechDraw; просмотр STEP из CadQuery — дополнительный interoperability-тест, не способ восстановить исходное дерево.
• Agent → валидированный план/код → изолированный execution → numerical geometry tests → review. Хранить код, JSON, lockfiles, версии ядра, .FCStd, STEP и отчёты. Команды сохранения не должны перезаписывать оригинал; сетевой доступ сгенерированного кода выключен по умолчанию.
• MCP необязателен: сначала прямой Python runner; если нужен универсальный client, собственный узкий MCP adapter или audited/pinned community connector с честной маркировкой. Zoo официальный MCP не делает официальный статус переносимым на FreeCAD-коннектор.

Приёмка: одинаковые входы C1/B1/F1, аналитические геометрические тесты P1 и perturbation; отдельно оценивать качество нативного дерева FreeCAD. Дополнительная оценка — поведение при неверном constraint, сбое ядра, изменении версии и повторном запуске. Этот стек развивает проверяемое программное конструирование и изучение ограничений LLM, не заменяет обязательный учебный комплект КОМПАС.

11. Реестр проверки и оставшиеся пробелы

Все приведённые содержательные URL открывались 30.10.2026. Использованы первичные сайты производителей/проекта; репозиторий автора community connector первичен для коннектора, но не для официального статуса FreeCAD. Ссылка на СДО-форум не превращает пользовательский ошибочный код в эталон изготовителя.

Итог: самые воспроизводимые основания для агентного CAD сейчас — зрелые детерминированные API/скрипты, native output и измеримые проверки. «Есть MCP», «экспортирует STEP» и «fully editable» — три разных свойства; ни одно не заменяет проверки constraints, замысла, сборки, документации и инженерной безопасности.