ИИ-агентное CAD-проектирование: практики и ограничения на 30.10.2026

Дата проверки: 30 октября 2026, UTC. Контекст: интеграция в программу ТГУ БАС. После уточнения предмет исследования — агенты как инструмент CAD-проектирования, а не только программирование агентов. Coding harness рассматривается как средство управления CAD API, геометрическим ядром и проверками.

1. Основной вывод

Практически обоснованный путь — не «текст → готовое безопасное изделие», а спецификация → ограниченный план операций → CAD API → пересчёт ядром → геометрические и инженерные проверки → утверждение человеком. Самая зрелая составляющая — детерминированная CAD-автоматизация; генерация агентом корректной последовательности операций менее зрелая; автономное проектирование произвольных сборок с доказанной технологичностью — исследовательская задача.

Для ТГУ нельзя автоматически заменять КОМПАС-3D на FreeCAD. В РПД инженерной графики:143–156 прямо предусмотрены деталь, сборка, чертежи по ЕСКД, спецификация и изготовление/3D-печать в КОМПАС-3D. Следовательно, основной учебный контур должен сохранять эти результаты и нативную редактируемость; открытый CAD полезен как сравнительный, воспроизводимый исследовательский backend.

Неравенства, которые необходимо преподавать: исполняемый Python ≠ корректный B-rep; корректный B-rep ≠ соответствие ТЗ; совпадение силуэта ≠ сохранение замысла; отсутствие коллизий ≠ собираемость; STEP ≠ переносимая история построения; успешная симуляция ≠ сертифицированная безопасность БАС.

2. Что действительно нового подтверждено источниками

2.1. От генерации последовательности к исполняемому коду

Text2CAD, NeurIPS 2024 генерирует последовательные параметрические CAD-модели по тексту. Первичная публикация сообщает около 170 тыс. моделей и 660 тыс. текстовых аннотаций, полученных автоматизированным конвейером на DeepCAD. Это доказательство исследовательского метода и датасета, а не универсального понимания конструкторского ТЗ. Синтетические аннотации могут наследовать ограничения геометрии и языка операций датасета. Источник: https://proceedings.nips.cc/paper_files/paper/2024/hash/0e5b96f97c1813bb75f6c28532c2ecc7-Abstract-Conference.html .

CAD-Coder, первая версия 26.05.2025, v3 21.10.2025, имеет запись о публикации NeurIPS 2025 в карточке arXiv. Генерирует CadQuery/Python, использует supervised fine-tuning и GRPO с геометрической наградой Chamfer Distance и наградой за формат; авторы сообщают 110 тыс. троек «текст–код–модель». Преимущество — код можно исполнить и проверить геометрию. Ограничение: геометрическая награда не оценивает автоматически допуски, замысел, технологию и корректность чертежа. В открытом примере используется exec: копировать этот способ исполнения вне sandbox нельзя. Первичные источники: https://arxiv.org/abs/2505.19713v3 ; https://raw.githubusercontent.com/gudo7208/CAD-Coder/main/README.md . В этой проверке модель не запускалась, качество независимо не воспроизводилось.

2.2. Агент с обратной связью от solver, а не однократная генерация

Embodied CAD, arXiv v1 от 30.06.2026, описывает итеративный выбор навыков L0–L4, типизированные геометрические операции, CAD-backend и обратную связь solver для исправлений и обучения. Рассматриваются параметрические B-rep-сборки. Это особенно релевантно инженерному обучению: проверка ядром становится частью агентного цикла. Однако карточка прямо характеризует работу как ранее не опубликованный manuscript; результаты относятся к авторскому benchmark. Формулировка об исполнении всех strong-planner workflows не означает решение всех промышленных задач и не переносится на КОМПАС без испытаний. Источник: https://arxiv.org/abs/2606.31252v1 .

DIP-CAD, arXiv v3 от 27.10.2026, первая подача 19.09.2026, — свежий пример harness для сохранения design intent при генерации CAD по изображениям. Использует явные ссылки на грани/рёбра/вершины, локальные координаты эскиза, внутренние и внешние ограничения. Авторы оценивают не только статическую форму, но и изменения модели при правке параметров. Сообщённые улучшения mIoU — результаты конкретных GERD-EVL/DeepCAD-подмножеств, не показатели промышленной готовности. В выдаче поиска работа ещё называлась Vision2CAD; первичная карточка уже содержит DIP-CAD. Следует фиксировать версию, а не доверять поисковому заголовку. Источник: https://arxiv.org/abs/2609.22688v3 . Статус здесь — препринт; независимая репликация и испытания в ТГУ не выполнены.

Сдвиг 2024–2026: от правдоподобной формы и последовательности команд — к исполняемости, solver-grounded feedback, явным ссылкам на геометрию и проверке поведения при редактировании. Именно этот сдвиг важнее числа агентов и рекламной «автономности».

3. Сопоставление подходов

Оценки зрелости ниже — аналитические, не формальный TRL и не гарантии поставщиков.

CAD-backends: что сохранять и что проверять

• КОМПАС-3D: основной кандидат для учебного пилота ТГУ. Официальная СДО АСКОН содержит курс API, сравнение API5/API7, создание параметрических эскизов и 3D-моделей. В обсуждении от 24.11.2023 непосредственно видны Python, pythoncom, win32com.client, COM-объекты Kompas.Application.5 и .7. Это подтверждает путь интеграции, не наличие готового надёжного ИИ-конструктора. Использовать SDK/справку, соответствующие установленной версии; проверить Windows/COM, разрядность, лицензирование, доступ к типовым библиотекам, работу с копиями документов. Источник: https://sdo.ascon.ru/mod/forum/discuss.php?d=183&lang=ru ; курс: https://sdo.ascon.ru/course/view.php?id=184 .
• Уточнение по КОМПАС: официальное описание курса «Разработка приложений» прямо подтверждает Python, API5/API7, установку необходимых модулей через КОМПАС-Макро, создание сборки, чертежей и спецификации. Это более сильная опора, чем отдельный форумный пример: https://sdo.ascon.ru/course/info.php?id=227&lang=ru . Дата публикации страницы не указана; проверена 30.10.2026. Задания курса и API доступны не тождественно открытому агентному решению; условия доступа и конкретную версию следует проверить на месте.
• T-FLEX CAD: второй российский backend, если он используется в соответствующих дисциплинах/лабораториях. Официальная документация версии 17 демонстрирует пользовательское приложение StarsPlugin на C#, T-FLEX CAD Open API, сборку Visual Studio/.NET и подключение DLL. Источник: https://www.tflexcad.ru/help/cad/17/28_apps_example.htm . Это подтверждает механизм расширения, но не наличие готового ИИ-агента, не полноту автоматизации всех сборок и не актуальность версии 17 на дату среза. Для пилота нужен отдельный типизированный adapter и испытания на установленной версии, а не перенос COM-кода КОМПАС как есть.
• CadQuery + OpenCascade/OCP: удобная открытая основа для script-first CAD и headless-проверок. Официальная документация подтверждает Python, параметризацию и STEP; GUI отделён от библиотеки. Это не эквивалент нативной истории КОМПАС/Onshape. Сохранять исходный скрипт и параметры вместе с экспортом. Источник: https://cadquery.readthedocs.io/en/latest/intro.html .
• FreeCAD: кандидат для локального открытого контура с нативным деревом объектов и Python. Не считать совместимым с КОМПАС по истории построения; конкретный набор API, сборочный solver и стабильность ссылок нужно испытать на выбранной версии. В настоящей проверке API FreeCAD непосредственно не воспроизводился; выбор между ним и CadQuery — по учебным результатам, а не по ярлыку «open source».
• Onshape: официально документированы REST API и выполнение FeatureScript; для сложной геометрии документация рекомендует рассматривать FeatureScript. Важная деталь: evalFeatureScript исполняет lambda expressions, а не произвольный сценарий редактирования документа. Есть аутентификация и ограничения API. Документация также предупреждает: обычный bounding box может быть приблизительным, для точного нужен соответствующий геометрический запрос. Источник: https://onshape-public.github.io/docs/api-adv/fs/ . Облачная доступность, экспорт данных и условия для российского вуза требуют отдельной проверки.
• Fusion / SOLIDWORKS: типичные кандидаты для нативных scripts/add-ins/API-автоматизаций, если уже используются организацией. Страница Fusion API была открыта, но вернула только JS-оболочку; подробные возможности и переносимость в этой проверке не подтверждены. Поэтому их нельзя ранжировать как «лучших CAD-агентов» на основании наличия API. URL для последующей проверки: https://help.autodesk.com/view/fusion360/ENU/?guid=GUID-C1545D80-D804-4CF3-886D-9B5C54B2D7A2 . SOLIDWORKS API также не был полнотекстово проверен; его включение здесь — карта вариантов, не рекомендация закупки.

4. Harness и context engineering именно для CAD

Harness — исполняющая оболочка вокруг модели: разрешения, инструменты, состояние CAD, контроль версий, ограничения цикла, журнал и проверки. Context engineering — отбор информации для следующего решения модели, а не загрузка всей документации и всех изображений сразу.

В контексте нужны: утверждённое ТЗ с единицами; система координат; выбранный backend и версия API; допустимые операции; дерево модели; параметры и их зависимости; идентификаторы текущей геометрии; последние ошибки solver; результаты измерений и согласованные изменения. Большие модели и журналы хранить снаружи, извлекая нужные части по ID/URI. При смене контекста сохранять не только текстовое резюме, но и версию CAD-документа, набор параметров, незакрытые требования и отчёт проверок.

Anthropic описывает just-in-time retrieval, compaction, структурированные заметки и изоляцию подзадач. Это практический опыт разработчика, а не универсальное доказательство конкретного ускорения CAD. Источник: https://www.anthropic.com/research/effective-context-engineering-for-ai-agents . Для CAD неверно сжатая информация о допуске или базировании опаснее потери стилистической детали.

Рекомендуемый bounded workflow

1. Разобрать ТЗ: размерность, материал, нагрузки, сопряжения, технология; невыводимые размеры запросить у человека, не угадывать по фотографии.
2. Утвердить спецификацию: параметры, геометрические/сборочные ограничения, допустимые изменения, критерии проверки.
3. Составить план features: базы, эскизы, зависимости, последовательность, точки контроля.
4. Выполнить малый пакет операций через типизированный adapter; пересчитать документ; считать фактическую геометрию обратно.
5. Проверить ядро, размеры, ограничения, редактируемость, сборку и технологические правила; визуальные виды использовать дополнительно.
6. Исправлять ограниченно: например, не более трёх попыток на feature и заданного времени/стоимости на задачу. Это предлагаемая политика пилота, не научно установленный оптимум. При противоречии ТЗ, невозможном constraint или превышении бюджета — остановка/эскалация.
7. Выпустить артефакты только после human gate: нативная модель, исходный сценарий/параметры, чертёж, BOM/спецификация, отчёт проверок, нейтральный экспорт, журнал версий.

Мутации CAD должны быть транзакционными или выполняться на копиях с rollback/checkpoint. Повтор сетевого запроса не должен создавать второе отверстие: нужен operation ID и контроль версии документа. Сгенерированный Python не получает произвольный доступ к файловой системе, сети и COM-объектам вне разрешённого CAD-сеанса.

5. Spec-driven development и MBSE/digital thread

Spec-driven подход для CAD означает проверяемый конструкторский контракт, а не длинный Markdown сам по себе. Пример для крепления датчика: расстояния между осями; интерфейсные поверхности; масса; диапазон параметров; минимальные стенки; материал; разрешённая технология; требования к сборке; связь каждого требования с измерением, расчётом или осмотром.

GitHub Spec Kit документирует процесс Specify → Plan → Tasks → Implement → Converge; открытая страница имеет дату обновления 28.09.2026. Наличие шаблонов и интеграций подтверждает инструментальную практику, но не доказательство улучшения CAD. Переносить следует разделение намерения, плана и evidence, а не весь software-процесс без адаптации. Источник: https://github.github.io/spec-kit/index.html .

MBSE не заменяет CAD. SysML связывает требования, структуру, поведение, анализ и verification cases; точная геометрия остаётся в CAD. Официальная карточка OMG указывает SysML 2.0, formal, September 2025. Источник: https://www.omg.org/spec/SysML/2.0 . Наличие стандарта не делает автоматически рабочей интеграцию с конкретной САПР.

Минимальный digital thread: requirement ID → параметр/feature/компонент → revision модели → процедура проверки → результат → утверждение. Для БАС дополнительно фиксировать связь с массой/центровкой, интерфейсами полезной нагрузки, расчётными случаями, конфигурацией сборки. Согласование обозначений, единиц и версий важнее внедрения графовой БД на первом этапе. Нейтральный STEP-экспорт и нативную историю хранить параллельно: нельзя обещать, что STEP перенесёт замысел и всё дерево features. STL использовать для производства/визуализации в допустимом контуре, но не как единственный инженерный оригинал.

6. Один агент или несколько

По умолчанию — один агент с инструментами и внешними проверками. Он проще по стоимости, трассировке и управлению CAD-состоянием. Роли «планировщик–исполнитель–проверяющий» можно реализовать последовательными фазами без независимых агентов.

Несколько агентов оправданы для независимых концепций, чтения разных нормативных/технических источников, параллельного анализа DFM и требований. Только один контроллер должен изменять одну версию CAD-документа; предложения остальных — структурированные patches/варианты, которые проходят проверки. «Голосование» моделей не заменяет точный размерный контроль: их ошибки могут коррелировать.

Источник базового различения workflows/agents и принципа увеличивать сложность лишь после оценки: https://www.anthropic.com/research/building-effective-agents . Исходный материал относится к декабрю 2024 и сам предупреждает об изменении tooling; актуальный текст страницы может быть обновлён. Это качественная архитектурная рекомендация, не CAD-benchmark. В проверенных CAD-публикациях нет достаточного независимого основания обещать универсальное превосходство multi-agent для ТГУ.

7. MCP/A2A: инфраструктура, не инженерная гарантия

• MCP стандартизует доступ модели/host к инструментам и ресурсам. CAD-server может предоставлять inspect_model, create_sketch, apply_feature, recompute, measure, validate, export, но названия здесь — предлагаемый контракт, не существующий универсальный стандарт CAD. В схеме нужны единицы, revision, явные ссылки на геометрию и структурированные ошибки.
• A2A нужен для межсервисного делегирования задач и обмена артефактами между независимо развёрнутыми агентами. Для одного локального CAD-runner он избыточен; discovery и task lifecycle не заменяют CAD-семантику.
• Проверять протокол по версии, не по статье годичной давности. Официальный MCP changelog для 2026-07-28 описывает существенные изменения относительно 2025-11-25: stateless-подход, изменение handshake, explicit handles, перенос tasks в extension. Сам текст местами упоминает draft: наличие датированного URL не следует автоматически трактовать как подтверждение повсеместной стабильной поддержки SDK. Зафиксировать согласованную и протестированную пару client/server. Источник: https://modelcontextprotocol.io/specification/2026-07-28/changelog.md .
• Открытая спецификация A2A описывает AgentCard, Task, Message, Artifact, аутентификацию и несколько bindings; latest — изменяемый URL, для реализации требуется закрепление release/tag. Источник: https://a2a-protocol.org/latest/specification/ .

Границы безопасности: allowlist инструментов, отдельные права чтения/изменения/экспорта, защита credentials, отключённый доступ к производственному PLM по умолчанию, подтверждение удаления/перезаписи. Текст из модели CAD, внешнего документа или tool output — данные, не полномочия менять политику. MCP и A2A сами по себе не устраняют prompt injection, не доказывают технологичность и не обеспечивают корректность B-rep.

8. Что проверять: за пределами «модель выглядит похоже»

1. Исполнение: сценарий/операции завершились, не оставили скрытых ошибок, воспроизводятся на чистом сеансе с фиксированными версиями.
2. Геометрия: корректность solid/shell, отсутствие недопустимых самопересечений и вырожденных элементов, нужное число тел; размеры и объём сравниваются численно с допусками. Правила зависят от назначения: surface-модель не обязана быть solid.
3. Параметрика: эскиз не переограничен; необходимые степени свободы контролируются; параметры имеют смысл и единицы. Выполнить серию допустимых perturbation-тестов и убедиться, что сохраняются отверстия, соосность, толщина, интерфейсные поверхности. Fully constrained sketch полезен, но сам по себе не доказывает правильный замысел.
4. Топологические ссылки: индексы вроде «Face7» могут стать невалидными после изменения модели. Нужны semantic queries/стабильные references, повторная идентификация и тесты изменений; нельзя обещать полное решение topological naming только выбором САПР.
5. Сборка: сопряжения и степени свободы, коллизии, зазоры, доступность крепежа, последовательность монтажа, масса/центр масс при заданных материалах. Геометрическое отсутствие пересечений не доказывает кинематическую работоспособность.
6. Производство: для конкретного процесса — минимальная стенка, радиусы и доступ инструмента, отверстия, ориентация печати/поддержки, припуски, посадки. Универсальный LLM-review не заменяет process-specific DFM и испытания.
7. Инженерная проверка: нагрузки, граничные условия, свойства материала, сеточная сходимость и допущения расчёта; студент/инженер утверждает их до вывода о прочности. Агент может подготовить CAE-case, но не утверждать его своей же оценкой.
8. Документация: соответствие модели чертежу, размеры, обозначения, спецификация и требования ЕСКД проверяются отдельно. Изображение/VLM удобно для обнаружения очевидного дефекта, но не метрологический инструмент.

Метрики пилота: доля задач с корректным нативным редактируемым результатом; выполнение требований; устойчивость при изменении параметров; время человека на исправления; нарушения DFM; качество чертежей/BOM; стоимость и воспроизводимость. Сравнивать на одинаковых заданиях «ручная работа», «шаблон/макрос», «один агент», затем при необходимости multi-agent; считать не только первые успешные примеры, но и отказы.

9. Минимальный vendor-neutral стек для ТГУ

Vendor-neutral означает сменяемость модели и адаптеров, не отказ от уже принятой САПР.

1. ТЗ и проверочные правила в текстовом/структурированном формате с единицами, ID и версиями; требования ЕСКД сохраняются.
2. Небольшой orchestrator/state machine: фазы, бюджеты, checkpoint, human gates; LLM через сменяемый provider interface. Без обязательного тяжёлого agent framework.
3. Типизированный CAD adapter. Первый backend — КОМПАС API на выделенном Windows-месте, после проверки установленной версии и доступных лицензий. Второй, необязательный — CadQuery/OpenCascade либо FreeCAD для открытых воспроизводимых упражнений.
4. Отдельный executor с изоляцией, таймаутами, ограничением файлов и команд; не произвольный exec внутри основного приложения.
5. Детерминированные geometry/constraint tests, экспорт метрик и orthographic/render views; независимое утверждение инженерных допущений.
6. Хранилище версий спецификаций, сценариев и отчётов плюс нативных CAD-файлов/экспортов; для крупных бинарных артефактов — подходящее файловое/object-хранилище. Git возможен для текстов, но не обязателен и в этом исследовании коммиты не выполнялись.
7. Журнал: модель/версия, входные данные, tool calls, ревизии CAD, ошибки, проверки и подтверждения. MCP — по необходимости унификации tools; A2A и графовая БД — только после доказанной потребности.

Первый учебный кейс: параметрический кронштейн датчика БАС с двумя интерфейсами крепления. Студент формирует ТЗ; агент предлагает план и операции; студент проверяет базы и зависимости; затем меняет межосевое расстояние и толщину, проверяет перестроение, собирает узел, оформляет чертёж/спецификацию, готовит печать. Оценивать не красоту генерации, а инженерную доказательность и возможность исправления. Дальше — простая сборка; не начинать с полной конструкции летательного аппарата.

10. Реестр источников и границы проверки

Все URL открывались 30.10.2026; перечислено именно содержание проверки. Статистику поставщиков, обещания автономности и даты в copyright не использовали как доказательство результата. Не включались материалы с подтверждённой датой после среза; поисковая выдача не считалась достаточной проверкой.

Не использовано как подтверждённая содержательная опора: https://openai.com/index/harness-engineering/ — HTTP 403; Fusion API URL выше — только оболочка; https://www.nist.gov/programs-projects/model-based-enterprise — 404; PDF FAQ АСКОН по https://sd.ascon.ru/otrs/public.pl?Action=PublicFAQPrint;ItemID=1051 не декодирован данным web-инструментом. Непрочитанные страницы не подтверждают claims. Эта работа — кабинетный обзор первичных текстов, документации и карточек публикаций, а не испытание CAD-агентов и не исчерпывающий systematic review.