ИИ‑агент внутри КОМПАС-3D: пишет код, строит деталь и проверяет результат

Я сделал ИИ‑агента для КОМПАС-3D: он живёт прямо в окне программы, принимает запрос текстом или фотографией и строит параметрическую деталь — не мёртвую геометрию в step, а дерево построения с переменными, которое пригодно для редактирования.
Агент пишет код и сам смотрит на то, что построил, — анализирует рендеры «глазами» через VLM.
В статье: как хорошо агент справляется с моделированием по тексту и чертежам уже сейчас, почему один блок кода лучше десяти tool’ов и почему агенту мало просто «видеть» результат.

Введение

За последние несколько лет ИИ‑агенты научились на высоком уровне писать код, собирать отчёты в Word, Excel и других офисных программах — там, где результат работы легко описать текстом и командами. Работа с CAD‑программами, вроде КОМПАС-3D, устроена принципиально иначе. Из инструментов для работы через код есть только COM API, с которым и человеку не всегда легко, что уж говорить про ИИ.
В добавок, пространственное мышление до сих пор остаётся слабым местом VLM/LLM моделей — и это критично для проектирования.

Отдельно стоит отметить статьи ИИ управляет КОМПАС-3D… и Запрещаем AI выдумывать методы КОМПАС-3D…: там рассмотрено подключение через КОМПАС через MCP, а проблему угадывания методов COM API решили дообучением небольшой модели для семантического поиска по документации.

В этой статье покажу свой подход: агент, встроенный прямо в КОМПАС, с глубокой интеграцией в программу — свой Python поверх голого COM API и визуальный фидбек, который замыкает цикл «построил → посмотрел → поправил», компенсируя слабое пространственное мышление модели.
Дальше — демо как это работает, разбор архитектуры, метрики на реальных задачах и выводы по ним.

Как это выглядит в работе

Агент открывается боковой панелью прямо в окне КОМПАСа — не отдельным приложением. Он работает с тем документом, который у вас сейчас открыт: видит дерево построения, переменные и текущее состояние модели. На вход принимает текст и изображения — можно скинуть фотографию эскиза с листа или скан чертежа.

Кейс 1. Зубчатое колесо по текстовому описанию

Всё, что получил агент:

Построй зубчатое колесо: модуль 5, 50 зубьев, ширина венца 60, вал диаметр 50 со шпонкой

В запросе заданы четыре числа, а у детали параметров сильно больше. Всё остальное — ступицу, обод, диск, шпоночный паз — агент достроил сам, по стандартным соотношениям, не переспрашивая. И на выходе получилась не импортированная мёртвая геометрия из STEP, а обычная деталь КОМПАСа с деревом построения, которое можно открыть и править руками.

И главное — агент сам завёл переменные с человеческими именами и комментариями. Чтобы поменять посадочное отверстие с ⌀50 на ⌀80, не нужен ни агент, ни перестроение в эскизах: правится одна ячейка, модель пересобирается успешно.

▶ ссылка видео демонстрация, без монтажа

Кейс 2. Деталь по скану чертежа

Здесь агент получил только картинку с чертежом и просьбу построить по ней деталь — без подсказок по размерам и без описания.

Интереснее самой геометрии две другие вещи, которые показывает этот кейс:

Агент сам проверил себя. Он не остановился на «код выполнился без ошибок», а посмотрел на деталь с разных ракурсов и сверил с чертежом параметры. Это тот самый визуальный контроль, которому дальше посвящён отдельный раздел.

Заполнил не только геометрию. Деталь — это ещё и свойства. Агент прочитал основную надпись, проставил наименование, обозначение и материал, а заодно сам проанализировал расхождение по массе:

Теперь задам свойства детали — материал, обозначение, наименование и плотность картона (по ГОСТ 9347–74 картон А-2,00 имеет плотность около 0.65–0.7 г/см³; текущая масса модели в стали 122 г далека от заявленных 0,01 кг = 10 г для картона — но это ожидаемо, так как плотность стали завышает массу; проставлю реальную плотность картона).

▶ ссылка Видео демонстрация, без монтажа

Как это устроено: свой агент, код вместо кнопок и визуальный контроль

ИИ агент

Внутри ИИ агент, основанный на ReAct цикле, где LLM/VLM модель на каждом шаге принимает решение о вызове инструмента и получает обратную связь
Модель обязательно VLM — она должна принимать изображения на вход. Без этого не работает визуальная обратная связь, а на ней в этой системе держится качество: цифры будут ниже.
В этой системе реализован свой ИИ агент, а не просто обвязка для готовых кодинг агентов типа claude code, codex или opencode.
преимущества такого подхода:

• независимость от поставщика моделей, можно использовать и локальные

• возможность перекроить сам граф работы агента под конкретный сценарий — а иногда это единственный способ получить рабочую версию. Дальше по замерам будет видно, что восстановление модели по чертежу как раз такой случай: универсальный цикл там не справляется, и нужен отдельный пайплайн

• глубокая интеграция с компас 3д, например подстановка состояния дерева прямо в промпт

Как агент общается с КОМПАСом

Есть ряд устоявшихся практик по подключению программ к ИИ агентам, но в случае с КОМПАСом оба варианта оказались проигрышными — я объединил их сильные стороны в одном решении

Первая попытка: свой tool на каждое действие — extrude, hole и так далее, модель выбирает нужный из списка. Проблема простая: каждый вызов — это как нажать одну кнопку в КОМПАСе руками. Ни переменных, ни циклов, ни функций — только атомарные команды одна за другой, и это очень медленно. Моделирование — это работа с объектами, а не просто последовательность команд.

Попытка вторая: пустить модель прямо в COM API. Раз проблема в том, что не хватает кода — дадим модели писать код. КОМПАС имеет COM‑интерфейс, пусть модель его и использует напрямую.

Здесь выяснилось, что COM API писался для программистов, а не для языковых моделей. Одна осмысленная операция разворачивается в десяток служебных шагов (фрагмент‑пример ниже), половина параметров передаётся числовыми константами, которые надо помнить или искать в документации, и на каждом шаге модель имеет шанс перепутать интерфейс.
Вдобавок это просто небезопасно: неудачный вызов роняет не скрипт, а сам КОМПАС вместе с несохранённой работой пользователя.

import pythoncom
import win32com.client
from win32com.client import gencache

kc3d = gencache.EnsureModule("{2CAF168C-7961-4B90-9DA2-701419BEEFE3}",
                             0, 1, 0).constants

pythoncom.CoInitialize()
app = win32com.client.GetActiveObject("Kompas.Application.7")
app.Visible = True

doc = app.Documents.Add(4, True)                      # 4 = ksDocumentPart
doc3d = win32com.client.CastTo(app.ActiveDocument, "IKompasDocument3D")
part = doc3d.TopPart
part.Name = "Втулка"
part.Update()

container = win32com.client.CastTo(part, "IModelContainer")

# --- эскиз Ø60 ---
sketch1 = win32com.client.CastTo(container.Sketchs.Add(), "ISketch")
sketch1.Plane = part.DefaultObject(kc3d.o3d_planeXOY)
sketch1.Update()
# рисование идёт ВНУТРИ эскиза: пока открыт BeginEdit, активным документом
# КОМПАСа считается его фрагмент, а не деталь. EndEdit обязателен
fragment1 = sketch1.BeginEdit()
view1 = fragment1.ViewsAndLayersManager.Views.View(0)
drawing1 = win32com.client.CastTo(view1, "IDrawingContainer")
circle1 = win32com.client.CastTo(drawing1.Circles.Add(), "ICircle")
circle1.Xc, circle1.Yc = 0.0, 0.0
circle1.Radius = 30.0
circle1.Style = 1                    # основная линия; иначе контур не сработает
circle1.Update()
sketch1.EndEdit()
sketch1.Update()

# --- выдавить на 80 ---
boss = win32com.client.CastTo(
    container.Extrusions.Add(kc3d.o3d_bossExtrusion), "IExtrusion")
boss.Sketch = sketch1
boss.Direction = kc3d.dtNormal
boss.SetSideParameters(True, kc3d.etBlind, 80.0, 0.0, False, None)
if not boss.Update():                # Update возвращает False молча
    raise RuntimeError("выдавливание не построилось")

# --- эскиз Ø30 ---
sketch2 = win32com.client.CastTo(container.Sketchs.Add(), "ISketch")
sketch2.Plane = part.DefaultObject(kc3d.o3d_planeXOY)
sketch2.Update()
fragment2 = sketch2.BeginEdit()
view2 = fragment2.ViewsAndLayersManager.Views.View(0)
drawing2 = win32com.client.CastTo(view2, "IDrawingContainer")
circle2 = win32com.client.CastTo(drawing2.Circles.Add(), "ICircle")
circle2.Xc, circle2.Yc = 0.0, 0.0
circle2.Radius = 15.0
circle2.Style = 1
circle2.Update()
sketch2.EndEdit()
sketch2.Update()

# --- вырезать насквозь ---
cut = win32com.client.CastTo(
    container.Extrusions.Add(kc3d.o3d_cutExtrusion), "IExtrusion")
cut.Sketch = sketch2
cut.Direction = kc3d.dtBoth          # эскиз на торце — режем в обе стороны
cut.SetSideParameters(True, kc3d.etThroughAll, 0.0, 0.0, False, None)
cut.SetSideParameters(False, kc3d.etThroughAll, 0.0, 0.0, False, None)
if not cut.Update():
    raise RuntimeError("вырез не построился")

Что заработало: библиотека‑обёртка. Я написал поверх COM API собственный слой, в терминах которого модель пишет код:

from kompas_core import new_part

part = new_part("Втулка")
part.extrude(part.sketch("xy").circle((0, 0), 30), 80)
part.cut(part.sketch("xy").circle((0, 0), 15))

Это сочетание сильных сторон обоих подходов: краткий, безопасный и семантически понятный интерфейс, как у tools, — но при этом обычный Python с переменными, циклами и функциями, как в COM API. part — живой объект со своим состоянием, у которого просто дёргают методы, ничего не нужно протаскивать по идентификаторам. Вся грязная работа с COM и проверка аргументов остаётся внутри библиотеки: кривой вызов возвращает понятную ошибку, а не роняет программу.
И главное у подхода есть понятный путь масштабирования на другие задачи — сборки, чертежи, спецификации добавляются новыми методами библиотеки, без переделки агента.

Визуальная обратная связь

Агент никогда не может быть уверен, что код действительно сделал то, что задумано: эскиз мог построиться не на той плоскости, выдавливание уйти в другую сторону, фаска сесть не на ту грань — и всё это без единой ошибки выполнения.

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

Насколько это важно, видно по статистике прогонов.

Из каждой сотни блоков кода агент идёт смотреть на результат в 65 случаях, и только треть осмотров заканчивается «всё в порядке» — в остальных находит расхождение и правит его.
Итог: примерно 45 блоков из 100 уходят на переделку после того, как агент увидел результат своими глазами.

Первая цифра, 65% — это просто настройка: строкой в промпте или программным вызовом её можно уверенно двигать к 100%.
А вот доля осмотров 31% — это свойство самих моделей с двумя новостями, одной плохой и одной хорошей.

Плохая: LLM и VLM пока плохо держат трёхмерную геометрию в уме по одному коду — модель искренне считает, что построила нужное, и почти в половине случаев ошибается.
Хорошая: увидев рендер модель способна самостоятельно заметить расхождение

Метрики: что агент реально вытягивает, а что нет

Дальше — цифры, и сразу оговорка о том, чем они являются, а чем нет.
Это не бенчмарк и не строгая методика: 90 кейсов, по 10 на ячейку, один прогон на кейс. На такой выборке разница между 0.80 и 0.84 значит не много.

Значимо другое — разрывы. Там, где результат падает с 0.78 до 0.25, никакая статистическая строгость уже не нужна: сигнал видно невооружённым глазом. Ради этих разрывов и проведен замер, чтобы понять ограничения подхода в разных задачах

Задачи. Проверялись три сценария:

• создание модели с нуля по текстовому описанию (text2model);

• внесение правки в готовую модель по текстовому запросу (text2edit);

• восстановление 3D‑модели по скану чертежа в полностью автономном режиме (drawing2model).

Условия. Модель — moonshotai/kimi-k2.7-code, по API через agentplatform.ru. Взял её сознательно: открытая в общем доступе и дешёвая. Оба эти критерия важны при промышленном использовании.

Эталоны. Мои собственные модели студенческого уровня: то, что делается в курсовых и на первой работе. Обычные машиностроительные детали: фланцы, прокладки, зубчатые колеса.

Уровни сложности

Каждая задача разбита на три уровня, логика везде одна:
простая — всё дано напрямую, проверяется, что агент вообще попадает в API;
средняя — появляется вычисление, размер или координату надо вывести, а не списать;
сложная — появляется структура: массивы вместо повторов, работа с деревом построения, связывание нескольких видов в одну форму.

*Для правок уровень определяется самой правкой, а не исходной деталью: снять фаску на сложном корпусе — простая правка.

Метрики

IoU
Насколько объём построенной агентом детали совпадает с эталоном — от 0 (не пересеклись) до 1 (совпали идеально).

expected = difference(was, should) # эталонное изменение 
actual = difference(was, got) # изменение агента 
common = len(np.intersect1d(expected, actual, assume_unique=True)) 
union = len(expected) + len(actual) - common 

Cost — среднее число вызовов инструментов на один кейс. Метрика простая, но показывает то, чего не видно по качеству: насколько задача трудоёмка и не ходит ли агент кругами.

Потолок — 60 вызовов. Если агент за них не пришёл к результату, кейс засчитывается как IoU = 0. На этом месте у него в документе лежит промежуточное построение, и брать его в зачёт было бы нечестно: результата нет — значит нет.

Результат: качество

Моделирование по тексту работает. 0.99 на простых, 1.00 на средних — то есть на деталях, которые составляют основную массу рутины, агент попадает в эталон практически точно. Проседание начинается только на сложных, 0.84, и это уже задачи с массивами, вращением и деревом больше шести операций.

Правки деградируют быстрее моделирования. 1.00 → 0.80 → 0.62. На простой правке разницы с моделированием нет, но дальше расхождение растёт, и причина у него одна и вполне конкретная: селекторы. Чтобы снять фаску, агенту мало понять, что нужна фаска, — надо выбрать правильную грань. Эта проблема связана и с трудностями в пространственном мышлении и отсутствием семантики при работе с селекторами.

А вот с чертежами не спад, а обрыв. 0.78 на простых — и 0.25 на средних. Всё, что сложнее чертежа из демо выше, агент фактически не понимает: когда видов становится несколько, он не связывает их в одну форму. Между средним и сложным уровнем разницы уже нет (0.25 и 0.24) по простой причине — ниже падать некуда.

Результат: цена

Текстовые задачи ожидаемо экономны: 2–4 вызова на простых и средних, рост до 10–15 на сложных, в основном за счёт правок после визуального осмотра.

Чертежи стоят дорого с самого начала — 5.6 вызовов там, где текстовая задача обходится двумя. А на сложных начинается то, ради чего эту метрику и стоило считать: половина кейсов упёрлась в потолок в 60 вызовов Агент не сдаётся и не признаёт поражение — он по десятому разу переделывает построенное, пока не кончится лимит.

Просадка на чертежах объяснима: это не одна задача, а комплекс — прочитать проекции, связать их между собой, восстановить объёмную форму, воспроизвести операциями.
Сквозной агент, который отлично тянет текстовое моделирование, здесь разваливается, хотя по отдельности нейросети такие подзадачи уже решают (распознавание видов, чтение текста на чертеже, классификация элементов).
Именно здесь окупается то, что агент свой: под чертежи можно достроить отдельный граф с нужными этапами — не только для этой задачи, но и для других узких сценариев в будущем.

Итог

ИИ агент способен моделировать по тексту.
Моделирование по описанию даёт IoU около единицы на рутинных деталях — втулках, фланцах, крышках — и оставляет параметрическую деталь, а не мёртвую геометрию. Слабые места конкретны: правки упираются в выбор грани, чертежи сложнее одноракурсных пока не тянутся. Это не ограничение нейросетей — сквозной цикл здесь просто не тот инструмент.

Дальше — не переписывать агента, а достраивать библиотеку:

• сборки, чертежи, спецификации — новые методы обёртки, без переделки ядра;

• чертежи — отдельный пайплайн с чтением проекций;

• правки по грани — отдельная задача на распознавание геометрии, не общий цикл.

Развитие проекта.
Попытки скрестить ИИ и CAD пока чаще вызывают скепсис, чем доверие — и это понятно, обычно за красивым демо стоит то, что не выдержит реальную задачу. Но технологические ограничения, на мой взгляд, преувеличены: при должной проработке ИИ уже можно отдавать реальные операции, и в статье показано, что уже хорошо работает и как это дальше можно расширять под конкретные задачи.

Дальше хочу проверять подход не на демо‑кейсах, а на реальных задачах. Если у вас в компании есть КОМПАС и рутина, которая ест время инженеров, — расскажите, что это за задачи. Часть наверняка закроется тем, что уже есть в статье, часть — повод для отдельного пайплайна под конкретный сценарий.