Решение о внедрении: от обзора к проверяемому учебному контуру

Срез: 30.10.2026. Углубление исследования выполнялось тремя параллельными ветками: инструменты, инфраструктура, фактический почасовой баланс ОП. Это кабинетный проект, без запуска CAD-адаптеров и без измеренного образовательного эффекта.

1. Выбор подхода по задаче

Задача	Первый технический выбор	Почему не более сложный вариант
Научить читать эскиз/чертеж и понимать ограничения	Обычный CAD и дозированные подсказки, без делегирования построения оцениваемой основы	Агент, выполняющий все операции, может скрыть отсутствие навыка
Семейство простых деталей	Проверенный параметрический шаблон/макрос	Это сильный baseline; LLM не нужна для каждой вариации числа
Изменить модель по текстовому требованию	Один агент + типизированный адаптер нативной CAD + внешние тесты	Нативная история и согласование параметров важнее координации многих агентов
Сравнить варианты и их соответствие брифу	Несколько независимых предложений; один CAD-writer	Параллельное редактирование одного документа создает конфликт состояния
Восстановить форму по изображениям	Image-to-CAD как гипотеза формы; размеры/полости уточняет человек	Не выводить неизвестные инженерные свойства из силуэта
Оптимизировать массу/прочность	Отдельно верифицированный CAE/оптимизационный процесс	LLM-цикл сам по себе не задает верные нагрузки, материалы и допуски

2. Минимальный контракт инструмента

Предлагаемая схема вызовов — не существующий универсальный CAD-стандарт:

inspect_document(document_id, revision) → дерево объектов, параметры/единицы, ошибки перестроения;
propose_changes(requirement_ids, operations) → план, без мутации;
apply_operations(document_id, expected_revision, operation_id, operations) → новая ревизия либо структурированный отказ;
recompute(revision) → состояние ядра, failed features/constraints;
measure(revision, query) → фактические размеры/объемы/расстояния с единицами и точностью;
validate(revision, test_suite_version) → результаты диагностических проверок;
export(revision, allowlisted_format) → файл и SHA-256;
rollback(checkpoint) → проверяемое восстановление в выделенной задаче.

Сначала реализовать 6–10 разрешенных операций для одного кейса, не открывать весь Python/COM произвольному агенту. operation_id защищает от дублирующей мутации при повторной доставке; expected_revision — от правок устаревшей версии. Реальные исключения SDK и диалоги документировать, не превращать их в «успешно».

3. Предлагаемые ворота готовности

G0 / учебный смысл: преподаватель согласовал результат, самостоятельный контроль и часы; письменный экзамен/ЕСКД не удалены неявно.
G1 / ручной эталон: деталь, чертеж и изменение строятся без LLM; диапазон параметров проверен.
G2 / технический стенд: версии/лицензии/изоляция подтверждены, логирование и восстановление испытаны.
G3 / надежность агента: набор обычных и дефектных моделей; все неудачи учтены; внешние тесты не редактируются агентом.
G4 / образовательный пилот: студент сдает проект и выполняет новое изменение без ИИ; измерены нагрузка и расходы.
G5 / масштабирование: принимается только после анализа качества/самостоятельности, а не по эффектному демо. Изготовление требует отдельного допуска.

Численные пороги успешности/времени следует согласовать до замера, исходя из цены ошибки и календаря. Не объявлять предложенные здесь ворота сертификацией или правилами ТГУ.

4. Новые первичные проверки

Zoo MCP, проверено 30.10.2026: официальный uvx zoo-mcp, ZOO_API_TOKEN, сохраненный main.kcl и выполнение через kcl_path. Клиент сохраняет файл своими разрешенными инструментами; не все файловые действия выполняет MCP. Отдельной платы за MCP не указано, hosted tools считаются API usage.
Zoo Agent API, проверено 30.10.2026: производитель описывает CAD-focused agent, Zookeeper, визуальные инструменты и удаленные вычисления. FEA и «правильное решение в итоге» — заявления поставщика о возможностях, не независимая гарантия инженерного результата. Доступность/договор/обработка данных для ТГУ не установлены.

Подробное сравнение — инструменты, инфраструктура, почасовая интеграция. Предыдущий 24-часовой концептуальный пилот теперь читается как ранний вариант: при выборе реализации использовать уточненный баланс из почасового плана, не суммировать оба документа как разные нагрузки.