AI-агент для CAD без MCP: зачем нужен контекстный слой, а не только tools

LLM-агент, который пишет код для CAD-системы, сталкивается с проблемой, знакомой всем, кто автоматизировал сложные desktop API: модель уверенно придумывает методы, путает версии интерфейсов, подставляет невалидные аргументы и ссылается на устаревшие стандарты. Чем богаче API, тем выше шанс, что «примерно правильный» ответ окажется неработающим.

В таких задачах недостаточно дать модели tool calling или MCP-сервер. Нужен контекстный слой, который ограничивает пространство ошибок ещё до запуска кода. Особенно если агент работает с инженерными системами, где неверная геометрия, стандарт или параметр могут стоить дорого.

Почему обычный prompt не спасает

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

Типовые ошибки:

вызов несуществующего метода;
путаница между ветками COM API;
неверные enum-значения;
устаревшие ГОСТы и стандарты;
неправильный порядок аргументов;
код, который синтаксически выглядит нормально, но не компилируется.

Для production-помощника нужен механизм, который проверяет ответ модели формально.

Граф API как источник правды

Один из подходов — представить API в виде графа: классы, методы, свойства, связи, допустимые переходы, типы аргументов. Тогда агент не просто вспоминает интерфейс из prompt, а получает структурированную карту доступных действий.

Это даёт несколько плюсов:

меньше галлюцинаций методов;
проще искать релевантные элементы API;
можно валидировать цепочки вызовов;
появляется база для подсказок и автодополнения;
ошибки становятся объяснимыми.

Граф не заменяет документацию, но делает её машинно-пригодной.

Валидаторы аргументов

Даже если метод выбран правильно, аргументы могут быть неверными. Поэтому рядом с моделью нужен валидатор: типы, диапазоны, обязательные поля, допустимые enum, единицы измерения.

Для CAD это особенно важно: миллиметры и метры, углы, координаты, допуски, типы элементов и стандарты. Модель может написать правдоподобный код, но только валидатор скажет, что конкретное значение недопустимо.

Компиляция как фильтр

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

Feedback loop может выглядеть так:

Модель генерирует код.
Валидатор проверяет API и аргументы.
Код компилируется.
Ошибки возвращаются агенту в структурированном виде.
Агент исправляет код.
Результат тестируется на живом окружении или sandbox.

Такой цикл превращает LLM из автора «магического скрипта» в участника инженерного pipeline.

Стандарты и справочники

Для инженерных задач важны не только API, но и предметные правила: ГОСТы, версии стандартов, допустимые параметры, отменённые документы, corporate conventions. Их нельзя оставлять на память модели.

Нужен отдельный справочник с датами, статусами и связями. Агент должен получать актуальный статус стандарта и явно видеть, что документ отменён или заменён.

MCP не всегда центральный элемент

MCP удобен как протокол интеграции tools и контекста, но он не решает саму проблему качества данных. Если tool возвращает неполный или плохо структурированный контекст, модель всё равно ошибётся. Если нет валидаторов и компиляции, агент будет выдавать неработающий код быстрее.

Поэтому архитектура должна начинаться не с выбора протокола, а с вопроса: какие классы ошибок нужно поймать до выполнения?

Итог

AI-агент для CAD и сложных API требует не только LLM и tools, а полноценного контекстного слоя: граф API, валидаторы, справочники стандартов, компиляция и feedback loop. Именно эти элементы снижают риск галлюцинаций и делают результат проверяемым.

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