Как мы интегрировали AI агентов с T-FLEX: отказ от абстракций и самопроверка моделей
Попытки связать большие языковые модели с инженерным программным обеспечением обычно разбиваются о суровую реальность.
Системы уровня T-FLEX CAD работают через закрытые DLL-библиотеки, требуют жесткого контроля сессии и точного вызова методов API. В такой среде нейросети часто «галлюцинируют», выдавая код, который выглядит правдоподобно, но на практике приводит к падению процесса или зависанию лицензии. САПР не прощает ошибок в типах данных или абстрактных догадок.
Чтобы автоматизировать реальные конструкторские задачи и получать стабильный результат, нам пришлось отказаться от привычного формата чат-ботов. Мы разработали tflex_harness в котором агент состоит из языковой модели, из контура управления, локального поиска по API-документации, генерации C#-кода, компиляции и контролируемого запуска в T-FLEX CAD.
Разделение зон ответственности
При интеграции с САПР часто возникает соблазн написать удобные обертки на Python (что-то вроде part.add_hole()). На практике это быстро заводит в тупик: при любом сбое нейросеть начинает пытаться исправить ошибки в самих обертках, полностью теряя из виду исходную инженерную задачу.
Мы пошли другим путем и разделили зоны ответственности. Python остался в контуре управления: он принимает задание, ищет сведения в локальной документации API, готовит рабочую папку и собирает результаты. Всё взаимодействие с ядром T-FLEX CAD выполняется через сгенерированный исходный C#-код, который компилируется вместе с вспомогательными классами и ссылками на библиотеки САПР. и жестко разделили логику. Python работает только в контуре управления, а взаимодействие с САПР происходит исключительно на чистом C#.
Python отвечает за маршрутизацию: принимает конфигурационные файлы, ищет информацию в локальной документации API и собирает результаты. А любые обращения к ядру T-FLEX происходят через генерацию открытого C#-кода, который компилируется с привязкой к нативным библиотекам САПР.
Проверка компилятором перед запуском
Языковые модели склонны выдумывать несуществующие методы. Модель может уверенно предложить условный вызов вроде ExportToStep(), даже если в текущей версии API такого метода нет или он называется иначе. Поэтому такой код нельзя сразу отправлять в сессию САПР: сначала его нужно проверить на уровне компиляции.
Поэтому мы добавили промежуточный этап, обязательную предварительную компиляцию.
Сначала система ищет точные названия методов в локальном справочнике API и формирует черновик программы. Затем сгенерированный код передается штатному компилятору csc.exe без запуска T-FLEX CAD. Этот этап отсекает значительную часть ошибок: несуществующие методы, несовпадение типов, неверные пространства имен и неправильные сигнатуры вызовов.
Как мы скормили API-справочник нейросети
Одной из главных проблем при работе с энтерпрайз-САПР является формат документации. Справочник API T-FLEX поставляется в виде классического скомпилированного файла .chm на 17 МБ и набора сырых .xml файлов с метаданными.
Закидывать мегабайты сырого XML в контекст современной языковой модели плохая идея. Модель съест огромное количество токенов, потеряет контекст (lost in the middle) и всё равно начнет выдумывать.
Мы пошли другим путем: написали парсер, который берет TFlexAPI.xml и разбивает его на тысячи атомарных Markdown-файлов (.md). Каждый такой файл описывает строго один класс, интерфейс или метод.
Как это работает в динамике:
Алгоритм осуществляет поиск по локальной базе .md файлов и находит только те классы, которые реально нужны для решения текущей задачи.
В контекст (промпт) нейросети отправляется не весь справочник, а только компактная и релевантная выжимка в понятном для ИИ формате Markdown.
Для реализации этого шага мы рекомендуем использовать deepwiki по нашему репозиторию t-flex_api (ссылка на него есть в конце статьи); Это дает наилучшие результаты при поиске связей между методами. Но в базовом варианте отлично работает и банальный текстовый поиск по .md файлам. Получая контекст в таком виде, модель перестает фантазировать и опирается только на жестко заданную спецификацию.
Открытые инструменты и самопроверка алгоритма
Писать с нуля шаблонный код для подключения к документу или настройки экспорта долго и неэффективно. Мы подготовили базовый набор вспомогательных классов на C#. Главное их отличие в том, что это не скрытые скомпилированные библиотеки. Это обычные текстовые файлы (например, EasySession.cs), которые копируются в рабочую папку и компилируются вместе с кодом, созданным алгоритмом.
Нейросеть видит эти файлы, использует их функции и самостоятельно пишет логику проверки своих же действий. Ниже показан фрагмент кода, который алгоритм создал для построения параметрического кронштейна.
var endSubtract = doc.EndChanges();
EasyDiagnostics.Print("subtract.endChanges", endSubtract);
if (endSubtract.ToString() != "OK") return 30; // Жесткий выход при ошибке построения
var box = EasyDiagnostics.PrintBodyBoxMm("final", finalBracket);
int operations = Document3D.GetOperations(doc).Count;
string outPath = sess.ArtifactPath("symmetric_clevis_bracket.grb");
bool saved = EasyExport.Grb(doc, outPath);
// Проверяем ключевые контрольные размеры модели
if (!box.Valid) return 40;
if (!Near(box.SpanX, 140.0, 0.5) || !Near(box.SpanY, 86.0, 0.5)) return 41;
if (operations < 16) return 42;
if (!saved || !File.Exists(outPath)) return 43;
return 0;
Алгоритм запрашивает у системы габаритный контейнер модели, замеряет размеры по осям, подсчитывает количество операций в дереве построений и только после прохождения этих контрольных проверок программа возвращает успешный код завершения.(проверки можно добавлять или изменять в любом виде)
Фиксация результатов вместо переписки
Для каждой попытки создаётся отдельная директория, где сохраняются исходное задание, сгенерированный код, логи компиляции, консольный вывод, код завершения и готовые артефакты.
/artifacts/runs/20260529_120000_clevis_bracket/
├── request.json # Исходное техническое задание
├── snippet.cs # Сгенерированный алгоритмом код
├── helpers/ # Скопированные вспомогательные классы
├── build.log # Подтверждение успешной компиляции
├── stdout.txt # Консольный вывод и измерения
├── result.json # Код завершения
└── artifacts/
└── symmetric_clevis_bracket.grb # Готовая 3D-модель
Если сгенерированная программа успешно скомпилировалась, выполнилась в T-FLEX CAD и прошла встроенные проверки, её можно сохранить как проверенный «рецепт» переиспользуемый C#-сценарий для задач того же типа.
Автоматизация рутины, а не замена инженера
Проверенные рецепты переводят сценарий из режима эксперимента в режим пакетной обработки. На вход можно подать таблицу Excel или JSON с параметрами, а на выходе получить набор .grb/.step-файлов, сводный CSV-отчет или извлечённые атрибуты моделей.
Мы разработали этот подход для T-FLEX CAD, но сам принцип универсален. Искусственный интеллект пока не способен полностью заменить инженера-конструктора или разработать сложное изделие с нуля. И мы не пытаемся этого обещать.
Однако этот подход отлично работает для точечной автоматизации изолированных, рутинных участков. Массовое перестроение типовых моделей, выгрузка атрибутов и проверка спецификаций - это те процессы, на которые специалисты тратят десятки часов рабочего времени.
Для таких задач стандартные языковые модели в виде чат-ботов не подходят. Здесь требуется глубокая интеграция на уровне программного интерфейса и строгий контроль выполнения, применимый к любой корпоративной системе с открытым API (будь то T-FLEX, Компас-3D, SolidWorks или системы документооборота).
Репозитории:
t-flex harness: https://github.com/dwnmf/tflex_harness *любая обратная связь и PR приветствуются
t-flex api: https://github.com/dwnmf/tflex_api
Если у вас есть повторяемые инженерные или расчётные процессы, которые занимают слишком много ручного времени, напишите нам: vanamasorub@gmail.com.