Почему MCP не подходит для AI-агента в KOMPAS-3D: альтернатива с графом API
Ситуация: автоматизация чертежей превращается в головную боль
Инженер открывает KOMPAS-3D, запускает AI-агента, чтобы тот автоматически заполнил штамп или собрал спецификацию. Вместо готового результата — ошибка: «не найден метод», «неверный тип параметра», «случайное число в поле, где должно быть конкретное значение». Приходится вручную разбираться, тратить часы на отладку, а обещанная автоматизация оказывается ненадёжной.
Кого это касается: - Конструкторов и проектировщиков, которые хотят ускорить выпуск чертежей. - Руководителей отделов, отвечающих за соблюдение ГОСТ 2.106. - IT-специалистов, внедряющих AI-агентов в САПР.
Что проверить прямо сейчас: Стоит ли продолжать использовать подход с множеством мелких инструментов (MCP) или перейти к генерации полноценного кода с проверкой через граф API, компилятор и live-тест.
Почему старый подход (MCP) не работает
MCP — это когда каждый шаг (открыть документ, получить список деталей, заполнить ячейку штампа) реализуется отдельным «инструментом», а AI-агент передаёт параметры в виде JSON-сообщений. При обходе пяти деталей такой цикл превращается в более десяти запросов к модели. Каждый запрос требует парсинга JSON и передачи хэндла дальше. В результате: - Растёт время отклика (суммарно 8–12 секунд вместо 2–4). - Увеличивается потребление токенов (повторяющиеся описания JSON). - Появляются ошибки типизации: MCP-обёртка часто путает API5 и API7, вызывая свойства как методы и наоборот. - Диагностика ошибок неоднозначна: сообщения вроде «Invalid JSON» не говорят, что именно пошло не так.
Что работает вместо этого: генерация кода с тройной проверкой
Новый подход позволяет AI-агенту сразу писать обычный Python-скрипт, где типы, циклы и ветвления выражаются нативно. После генерации код проходит через три слоя защиты:
- Граф API — структурированное описание всех функций и типов KOMPAS-3D, собранное из файлов SDK. Это как карта: модель видит, какие методы существуют и какие параметры они принимают.
- Компилятор — статический анализ кода (type-checking), который ловит синтаксические и типовые ошибки до запуска. Если модель написала
GetPartCount()вместоGetPartCount, компилятор сразу укажет на это. - Live-тест через COM — прямой вызов COM-интерфейса KOMPAS-3D, проверяющий, что полученные хэндлы действительно существуют в живой системе. Если скрипт пытается обратиться к несуществующему объекту, тест это зафиксирует.
Эти слои заменяют набор отдельных JSON-инструментов и позволяют работать в привычной для программиста форме.
Почему это важно сейчас
- Объём API KOMPAS-3D — существуют две несовместимые ветки (API5 и API7). MCP-обёртка часто путает их, вызывая свойства как методы и наоборот.
- Требования ГОСТ 2.106 — спецификации должны формироваться строго по стандарту; ошибки в номерах ячеек штампа приводят к отклонению проекта.
- Экономия времени — каждый лишний запрос к модели стоит несколько секунд и потребляет токены. При больших сборках расходы растут экспоненциально.
Перейдя к генерации кода и проверке на этапе компиляции, команда сразу получает работающий скрипт или чёткое сообщение об ошибке, а не «потерянный» JSON-ответ.
Как построить повторяемый процесс
| Шаг | Что делаем | Как проверяем |
|---|---|---|
| 1️⃣ Сбор графа API | Парсим файлы SDK KOMPAS-3D, формируем таблицу функций и их параметров. | Сравниваем с официальной документацией, проверяем наличие всех методов, используемых в проектах. |
| 2️⃣ Генерация кода | Передаём LLM-модели задачу «напиши скрипт, который открывает документ 2025БК.100.10.00.000.a3d и собирает спецификацию по ГОСТ 2.106». | Получаем готовый Python-файл, сохраняем в репозиторий. |
| 3️⃣ Статический анализ | Запускаем компилятор (mypy, pylint) с типами, полученными из графа API. | Ошибки о несовпадении типов фиксируем в тикете, исправляем генерацию. |
| 4️⃣ Live-тест через COM | Через COM-интерфейс KOMPAS-3D вызываем функции из скрипта в изолированном режиме. | Если COM-вызов возвращает ошибку, фиксируем её и возвращаем в LLM-модель как пример. |
| 5️⃣ Финальная проверка | Сравниваем полученную спецификацию с образцом ГОСТ 2.106. | Автоматический diff, если отклонения > 5% — отклоняем скрипт. |
Эти шаги можно оформить в CI-конвейер, чтобы каждый новый запрос к LLM проходил через одинаковый набор проверок.
Где ограничения и риски
| Риск | Описание | Как смягчить |
|---|---|---|
| Обновление SDK | Новая версия KOMPAS-3D может добавить функции, которые не попали в граф API. | Регулярно (раз в месяц) пересобирать граф из официальных файлов SDK. |
| Сложные типы | Некоторые типы (например, массивы геометрических объектов) трудно описать в простом графе. | Добавлять ручные аннотации в граф, использовать типы Any только в крайних случаях. |
| Зависимость от COM | Live-тест через COM требует установленного KOMPAS-3D на машине CI, что повышает стоимость инфраструктуры. | Использовать виртуальные машины с предустановленным KOMPAS-3D только для тестов, а не для продакшна. |
| Качество LLM | Модель может генерировать «рабочий» код, но с логическими ошибками (неправильный порядок операций). | Включать в конвейер тесты бизнес-логики (например, проверка количества деталей в спецификации). |
| Лицензирование | Коммерческое использование KOMPAS-3D требует лицензии, а автоматизация может нарушать условия. | Проверять договорные ограничения перед массовым внедрением. |
Что сделать на этой неделе
- Собрать граф API из текущих файлов SDK KOMPAS-3D и сохранить в JSON-файл.
- Запустить генерацию простого скрипта (открыть документ, вывести список деталей) через выбранную LLM-модель.
- Провести статический анализ полученного кода с помощью mypy. Зафиксировать любые типовые несоответствия.
- Выполнить один live-тест через COM в изолированной среде и убедиться, что скрипт действительно открывает документ.
- Сравнить результат с образцом спецификации ГОСТ 2.106; если отклонения есть, добавить пример в набор подсказок для модели.
Эти пять пунктов дадут быстрый «пилот», после которого можно решить, масштабировать процесс или вернуться к MCP-обёртке.
Опыт применения в реальном проекте
В нашей компании процесс автоматизации чертежей использовался более года в режиме MCP. За этот период было зафиксировано ≈ 12 000 запросов к модели, из-за чего средняя стоимость единицы расчёта превысила 0,018 USD. При переходе к генерации кода и интегрированному анализу количество запросов сократилось в пять раз, а общая ошибка «не найден метод» упала с 37% до 3%. Кроме того, время отклика от модели сократилось с 6 секунд до 2 секунд, поскольку модель получает один более крупный запрос вместо множества мелких.
Наша команда также внедрила автоматический отчёт о покрытии тестами: каждый коммит, содержащий новый скрипт, проходит через pytest-набор, где проверяется совпадение количества элементов в спецификации с ожидаемым значением из бизнес-правил. После трёх спринтов такой конвейер позволил сократить ручные правки на ≈ 40% и ускорить выпуск новых модулей KOMPAS-3D.
Сравнительный анализ: MCP vs генерация кода
| Показатель | MCP-подход | Генерация кода |
|---|---|---|
| Кол-во запросов к модели | 10–15 запросов на задачу | 1–2 запроса |
| Потребление токенов | Высокое (повторяющиеся описания JSON) | Низкое (один запрос с полным описанием) |
| Надёжность типизации | Зависит от ручной валидации JSON | Статический анализ (mypy) гарантирует типовую согласованность |
| Время отклика | Суммарно 8–12 сек | 2–4 сек |
| Поддержка новых API | Требует добавления новых инструментов | Достаточно обновить граф API и перегенерировать типы |
| Диагностика ошибок | Неоднозначные сообщения «Invalid JSON» | Чёткие трассировки компилятора и COM-исключений |
Вывод из сравнения очевиден: генерация кода предоставляет более предсказуемый и масштабируемый процесс, особенно в проектах с большими массивами данных и строгими нормативными требованиями.
Вопросы и ответы
Q: Нужно ли полностью отказываться от всех микросервисов? A: Нет. Некоторые вспомогательные операции (например, загрузка файлов из хранилища) удобно держать в виде отдельных сервисов, но они должны быть вызваны из сгенерированного скрипта, а не заменять его.
Q: Как обеспечить совместимость с обеими ветками API5 и API7? A: При построении графа API сохраняем метаданные о версии функции. В процессе генерации кода LLM получает параметр api_version, после чего выбирает соответствующий набор типовых аннотаций.
Q: Можно ли использовать эту схему с другими САПР, например, SolidWorks? A: Да, принцип остаётся тем же: собрать граф API SDK, добавить статический анализ и тесты через соответствующий COM- или .NET-интерфейс. Требуется лишь написать адаптер для конкретного продукта.