BOM Voyage

NuScale Power, американский разработчик малых модульных атомных реакторов, внедряет специализированную ИИ систему для ускорения разработки малых модульных реакторов. Решение объединяет отраслевую платформу AtomAssist компании Nuclearn, инженерные и лицензионные материалы NuScale и опыт NPX по реализации атомных проектов. Система работает с проектной документацией, требованиями, стандартами, лицензионными обоснованиями и накопленными знаниями компании. Она помогает инженерам находить применимые методы и нормативные положения, понимать контекст и возвращаться к исходному контролируемому документу. В предварительном испытании такой подход сократил время поиска нужной информации до 80%. Задача системы — связывать поиск и ответы ИИ с актуальными версиями документов, инженерными решениями и доказательной базой для лицензирования. Особое внимание уделяют прослеживаемость: любой вывод должен быть проверяем и иметь ссылку на утверждённый источник. То есть работают над ускорением работы с техническим контекстом без ослабления процедур качества, безопасности и управления конфигурациями, что особо важно в ядерной промышленности. https://www.nuscalepower.com/press-releases/2026/nuscale-power-deploys-nuclear-specific-ai-from-npx-and-nuclearn-to-speed-development-of-its-advanced-reactor-program

С пылу, с жара arxiv: Design-to-Plan: A Large Language Model-Based Multi-Agent Framework for Manufacturing Process Planning from 3D CAD Models and 2D Engineering Drawings Про многоагентную систему, преобразующую 3D-модель и 2D-чертёж детали в технологический план. Она объединяет распознавание конструктивно-технологических элементов, извлечение размеров и допусков, связывание обозначений с геометрией, поиск производственных правил, построение маршрута и выбор инструмента. Языковые модели не генерируют техпроцесс самостоятельно, а координируют специализированные алгоритмы и базы знаний. Нейросеть распознаёт в STEP-модели отверстия, пазы, карманы и другие элементы, а отдельный модуль извлекает из чертежа размеры, допуски, шероховатость, материалы и примечания. Система связывает каждое требование с конкретным элементом модели. Уверенные соответствия принимаются автоматически, неоднозначные разбирает агент, сомнительные проверяет инженер. Другие агенты находят производственные ограничения, выявляют противоречия, строят и проверяют последовательность операций, подбирают инструмент и рассчитывают режимы обработки. Решения сохраняют связь с исходной геометрией, документацией и правилами. Точность распознавания элементов составила около 97%, а их связывания с чертежом — 86% по F1. Параллельная работа агентов успешно обработала 300 тестов и сократила расход токенов на 60–68%. Пока что эта система не заменяет CAPP и CAM, но показывает практический путь к агентному контуру подготовки производства.

На конференции RedPanda (напомню - делают инфраструктуру под агентов которая выдержит высокую нагрузку + позволяют детерминировано контролировать что агентам делать можно, а что нет, предотвращать утечки данных, осуществлять аудит и т.п.) поставил CTO в тупик вопросом о контроле недопустимой цепочки операций, когда каждое действие в отдельности разрешено. Пока что это не решённая задача ни у кого, кто занимается подобной тематикой - жестко контролировать допустимость действий отдельных агентов уже получается, защита эшелонированная и выглядит надёжной, однако всё происходит для отдельных действий, с цепочкам все пока что только теоретически подползают. Надо делать машину состояний, это расходится с решения которые принимаются на пути к "держим высокую нагрузку". Или интегрировать снятие состояния с принятием решения о допустимости действия непосредственно в запускаемый агентом Tool, однако это делает решение самостоятельным, не частью решения поставщика ИИ инфраструктуры (RedPanda). Зато много узнал где разложены грабли которые будут больно бить по лбу идущих по этой дороге. А я иду. P.S. Нечасто на подобных мероприятиях угощают вином и пивом. Прямо на конференции, а не после.

Просто красиво. Докторская диссертация Ханса Ваутерса посвящена тому, как уменьшить размеры и повысить удельную мощность бортовых зарядных устройств электромобилей за счёт нового подхода к высокочастотным трансформаторам. В работе предложены две основные идеи. Первая — обмотки с балансировкой электромагнитного поля (Field-Balanced Windings). Такая конструкция снижает потери в меди на высоких частотах и позволяет эффективнее использовать проводник. Благодаря этому мощные трансформаторы могут работать на значительно более высокой частоте переключения, а повышение частоты позволяет уменьшать размеры магнитных компонентов. Вторая разработка — матричные трансформаторы со «змеевидной» обмоткой (Snake-Winding Matrix Transformers). Это архитектура для очень плоских трансформаторов, в которой обмотка проходит через распределённую систему магнитных путей. Такая конструкция хорошо масштабируется, уменьшает паразитные эффекты и упрощает отвод тепла, что особенно важно при высокой плотности мощности. Обе идеи не ограничились расчётами: их смоделировали, оптимизировали и проверили на полноразмерных преобразователях постоянного тока. Один из прототипов мощностью 7,4 кВт для бортового зарядного устройства работал на частоте до 800 кГц. Другой, особо плоский преобразователь мощностью 6,2 кВт, достиг удельной мощности 40 кВт на литр. Видео презентации https://youtu.be/y5rKlyQ3TDo Сама работа https://kuleuven.limo.libis.be/discovery/fulldisplay?docid=lirias4432772&context=SearchWebhook&vid=32KUL_KUL:Lirias&search_scope=lirias_profile&adaptor=SearchWebhook&tab=LIRIAS&query=any,contains,LIRIAS4432772&offset=0

Построение расчетной сетки прямо в браузере. К сожалению пока что не open source. Используются CSM (Convergent Surface Mesher) и CVM (Convergent Volume Mesher) от Spatial. Эти технологии происходят из MeshGems, приобретённой Dassault Systèmes. CSM строит поверх CAD-модели управляемую по размеру треугольную поверхностную сетку. Затем CVM использует эту оболочку как границу и заполняет внутренний объём конечными элементами — по умолчанию тетраэдрами. В демонстрации в браузер загружается CAD-сборка, выбирается отдельное тело, для него строится поверхностная сетка и визуализируется с раскраской по идентификаторам областей. Затем строится объёмная сетка. Поверх неё запускается простой демонстрационный решатель теплопередачи, а с помощью секущей плоскости можно разрезать модель и посмотреть структуру объёмной сетки внутри. https://lnkd.in/p/d_BE3n9T

Accelerated Understanding представила универсальную модель для физического ИИ. Стартап Анимы Анандкумар, одного из ключевых авторов нейронных операторов, и Бенедикта Йеника строит модель не вокруг языка, а вокруг прогнозирования физических процессов сразу в пространстве и времени. Архитектура работает непосредственно с 3D-полями, выдаёт временную эволюцию системы целиком, поддерживает произвольное разрешение и обучается сразу на нескольких областях физики. Компания заявляет о тестах с контекстом до 5 трлн физических значений. Только не стоит напрямую, "в лоб", сравнивать с токеновым контекстом LLM, хотя масштаб всё равно необычен. Цель — одна базовая физическая модель вместо отдельного суррогата для каждой CFD/FEA/тепловой задачи; среди первых применений названы проектирование микросхем, энергетика, робототехника и прогнозирование погоды. https://www.reuters.com/business/ai-founders-who-walked-away-bezos-backed-prometheus-model-universe-2026-08-25/

^^ Тут наверное стоит более простым языком с примером. APAP это одна из возможных основ для общего «языка обязательств» между агентами разных предприятий. MCP и A2A позволяют агентам вызвать друг друга или доступную функцию, но сами по себе не определяют, о чём стороны договорились, кто что должен сделать и что считать нарушением. APAP добавляет этот смысловой слой: шаблон соглашения, его структурированные условия, текущее состояние и правила обработки событий. Например, агент завода создаёт заказ на изготовление детали. Через APAP он получает согласованный шаблон, указывает обозначение изделия, версию документации, количество, срок, цену и требования к качеству. Агент поставщика проверяет данные по той же модели и принимает соглашение. В результате оба предприятия работают не с двумя независимо истолкованными письмами или файлами, а с одним типизированным экземпляром обязательства. Дальнейшее взаимодействие строится через события. Агент поставщика сообщает: «заказ принят», «производство завершено», «партия отгружена». Агент заказчика передаёт результаты входного контроля. APAP обновляет состояние соглашения и применяет правила: соблюдён ли срок, соответствует ли поставка нужной версии изделия, требуется ли повторная проверка, возникает ли штраф или согласование отклонения. Каждое действие связано с конкретным соглашением и сохраняется в его истории. При этом предприятия сохраняют собственные системы и данные. PLM заказчика остаётся источником требований и конфигурации изделия, PLM поставщика — источником производственной документации, ERP обеих сторон — источником заказов и платежей. APAP не объединяет эти базы, а создаёт между ними общий объект соглашения с понятными состояниями и обязательствами. Агенты обращаются к нему через REST, MCP или в будущем A2A, открывается возможность автоматизации части взаимодействия. Но это лишь один лишь компонентов, "протокол обязательств" взаимодействия, понятный и людям (юридический текст) и достаточно точный для машин (вычисляемый). Он не устанавливает личность агента, не выдаёт полномочия и не определяет, каким данным доверять. Для этого нужны корпоративная аутентификация, делегирование прав, цифровые подписи и проверяемые источники. Роль APAP уже: зафиксировать, что именно согласовано, представить это в форме, понятной людям и программам, и обеспечить одинаковое исполнение правил всеми участниками.

Разбавим забавным MCP сервер для покупок во ВкусВилле https://mcp.vkusvill.ru/mcp

И про фактически один из вариантов многоагентных систем выходящих за пределы контура одного предприятия, взаимодействие агентов принадлежащих разным площадкам требуют тому надёжный протокол. Accord Project — открытый проект Linux Foundation для вычислимых договоров (разновидность смарт контрактов основанная на юридических текстах), где юридический текст связан со структурированными данными и правилами. Его интерфейс APAP — Agreement Protocol API — управляет шаблонами, соглашениями, их состоянием и событиями. Это по сути один из примеров того, как предоставлять агентам строгие прикладные операции вместо доступа к базе или интерфейсу системы. В рамках Google Summer of Code 2026 APAP переработали для агентов. Раньше обработчики MCP вызывали по HTTP маршруты того же сервера, дублируя преобразования и часть логики. Теперь REST и MCP используют общий прикладной слой. Исправление операции действует во всех интерфейсах, а транспорт лишь преобразует запрос и ответ. GSoC 2026: Rewiring APAP for Agents: MCP, A2A, and a Shared Service Layer Агенты также получили различимые ошибки и типизированный контекст. Теперь они могут отличить отсутствие объекта от неверных данных, конфликта или сбоя базы и выбрать подходящую реакцию. Устойчивые адреса вида apap://agreements/{id} связывают вывод с конкретным источником. APAP перевели на MCP SDK 2.0, добавили постраничную загрузку, PostgreSQL 18, проверку изоляции данных и расширенные тесты. Для A2A пока подготовлена архитектура: REST, MCP и A2A остаются независимыми входами, но используют общую логику. Для PLM/CAx это практический образец: создание изменения, получение состава изделия, проверка атрибутов или запуск согласования могут быть доступны через обычный API, MCP и взаимодействие агентов без дублирования правил. Типизированные результаты, понятные ошибки и ссылки на исходные объекты обеспечивают проверяемость и прослеживаемость действий ИИ.

Okta выпустила Agent SSO — единый вход (аутентификация, авторизация, выдача короткоживущих токенов, регистрация, учёт и централизованное управление входями) для ИИ-агентов. Агент получает собственную учётную запись в корпоративном каталоге, а администратор управляет его правами и видит доступные ему системы. В основе лежит открытый протокол Cross App Access, расширяющий OAuth. Вместо постоянных ключей агент получает краткоживущие разрешения с минимальными правами для приложений, API и MCP-серверов. По сути, Okta переносит привычное управление корпоративными учётными записями на ИИ-агентов. Агент становится не безымянным процессом с чужим ключом, а контролируемым участником с собственной идентичностью и ограниченными полномочиями. Okta brings first-class identity to AI agents with Agent SSO

Autodesk запустила в AutoCAD Web экспериментальную функцию Block Auto-Categorization and Search. ИИ анализирует не имя блока и не его метаданные, а непосредственно геометрию, автоматически относит блоки к смысловым категориям и позволяет искать их по содержанию. Например, можно найти нужный тип объекта даже тогда, когда блок назван бессмысленно или по внутреннему соглашению другой организации. https://www.autodesk.com/blogs/autocad/introducing-block-auto-categorization-and-search-tech-preview/ Функция пока имеет статус Tech Preview, то есть пока что бета.

AWS поддержала открытый слой поиска агентов и инструментов, ARD, опубликовав у себя спецификацию Agentic Resource Discovery которая предлагает общий способ описывать и находить агентов, MCP-серверы, инструменты и навыки между разными облаками, локальной инфраструктурой и SaaS. AWS сравнивает эту модель с DNS: каждый владелец сохраняет свой реестр и контроль доступа, а общий протокол позволяет федеративно находить ресурсы без попарных интеграций; AWS Agent Registry уже предоставляет каталог с согласованием публикаций, IAM/JWT и доступом через MCP. https://aws.amazon.com/blogs/machine-learning/agentic-resource-discovery-ard-an-open-specification-for-agent-discovery/ Этакий стандарт для "DNS для агентов". Реестр, которые сейчас так любят создавать, только федеративный, не централизованный. Судя по всему станет ещё одним общепринятым стандартом масштаба планеты, если ещё Cloudflare поддержит - 100% так и будет.

«Цифровые Инженерные Системы» объявили о создании холдинга из пяти специализированных компаний. В него входят разработки для материаловедения, моделирования сыпучих сред и цифровых двойников, CAE, а также платформа «НЕЙРОИНЖЕНЕР» для генеративного проектирования с собственной LLM, RAG и инженерными базами знаний; заявлена интеграция с российскими CAD/CAE/PLM и охват цепочки до технологической подготовки производства. Пока это скорее организационное объединение существующих компетенций, чем появление одной новой платформы, но направление примечательно попыткой собрать ИИ, расчёты, данные и технологическую подготовку в общий инженерный контур. https://digitaltwin.ru/latest-news/des-announcement/ Плюс в последнем обновлении их системы управления производством ServiceVizor ИИ автоматизирует подготовку производственных инструкций. Он преобразует технологические карты, регламенты, сканы, Excel-файлы, видео и аудио в пошаговые инструкции, выделяя операции и используя материалы из исходных документов. https://digitaltwin.ru/latest-news/servicevizor-mass-update/

^^ Кстати, насчёт трат денег агентами в постсоветском пространстве с его засекреченностью всего, паранойей, неприятием облаков, "ИИ только локальный", проблема "ИИ требует денег и по мере внедрения всё больше" приобретает дополнительный аспект — быстрое устаревание железа. Ну предположим Кошёк даст денег на GPU нужные на данном этапе, но через год окажется что надо ещё 10X, а то что купили, развернули и настроили — уже морально устарело. Облака решают в первую очередь эту проблему - когда скорость роста не позволяет уверено прогнозировать будущие потребности, когда это нерационально закрывать самим в силу "быстро понадобиться совсем другое" - проще работать с облачным сервисом, а оптимизировать схему по цене и архитектуре по мере стабилизации потребностей и накопления экпертизы. У меня (международная логистика) гибрид - в основном свои ЦОД, но пиковые нагрузки, плюс растущие части системы - в облаках. Конечно же, зачастую облака неприемлемы, и с этим ничего не поделаешь, придётся крутиться хоть как-то. И это отразится на ходе трансформации. Если же есть возможность выбирать облако - пока что, на этом этапе, лучше брать облако, иначе через год на руках будет морально устаревшее железо, до срока амортизации которого ещё далеко, а поставки нового железа будут нескоро если вообще будут. Думаю постепенно будут развиваться услуги развёртывания и сопровождения локальных ЦОД подрядными компаниями - у них за счёт масштаба будет и экспертиза, нужная производственная база, отлаженное снабжение и отработанные схемы масштабирования этих локальных ЦОД. —— И ещё один момент, читая новости вида "Microsoft запретила ИИ своим программистам т.к. денег не хватает" знайте, что деньги-то есть, на самом деле проблема стукнулась о процесс бюджетирования больших корпораций - бюджет на ИИ заложили в прошлом году и недооценили темпы роста потребностей. А поменять бюджет в больших корпорациях сами понимаете.

По мотивам забавной статьи Enterprises Will Run 1,600 AI Agents by the End of 2026 Нопомню замерять среднюю температуру по больнице - это всегда заявка на определённую премию. Но если все же этим заниматься, то 1600 агентов к концу 2026 в среднем на предприятие будет вряд ли даже в штатах. Сначала бизнес обнаружит, что автономные агенты слишком хорошо умеют тратить деньги на модели. А если бюджет выдержит — выяснится, и это тема статьи по ссылке, что инфраструктура не была рассчитана на сотрудников, которые работают круглосуточно, запускают десятки задач параллельно и способны увеличить потоки данных и спрос на вычисления на 2 порядка. GitHub уже столкнулся с этим эффектом. Осенью 2025 года компания планировала увеличить ёмкость инфраструктуры примерно в 10 раз, а к февралю 2026-го стала проектировать её уже под 30-кратный масштаб. GitHub связывает рост нагрузки в первую очередь с агентной разработкой: быстро увеличивается число операций с репозиториями, pull request, API и автоматизацией. В августе новый пик трафика стал отправной точкой почти восьмичасового сбоя, когда один из критических компонентов не смог масштабироваться вслед за нагрузкой. Агент создаёт принципиально иную нагрузку, чем человек. Пользователь читает результат, думает и неторопливо делает работу. Агент сразу создаёт десятки подзадач, запускает субагентов, тесты, читает тысячи объектов, обращается к поиску и моделям, меняет данные и запускает следующие процессы. Поэтому узким местом становятся уже не только токены и GPU, но базы, сети, хранилища, очереди и корпоративные API, рассчитанные на человеческую скорость работы. Потому в мире уже рождаются проекты, которые готовятся зарабатывать на решении этой проблемы. Завтра как раз пойду на очную конференцию американской Redpanda, которая начинала с создания высокопроизводительной альтернативы Apache Kafka (системы предназначенной для решения проблемы масштабирования сервисов) — переписали без JVM. Теперь компания взяла курс на перенос этой экспертизы на описанную проблему связанную с ИИ. В их Agentic Data Plane агенты подключаются к данным, моделям и инструментам через общий управляемый слой. Потоковая платформа позволяет буферизовать и распределять работу, отделяя скорость агентов от возможностей обслуживающих их систем, а квоты и обратное давление — ограничивать чрезмерную нагрузку. Сверху добавляются идентификация агентов, управление доступом через MCP, единый шлюз к моделям, контроль расходов и наблюдение за действиями агентов. Так что пока агентов десятки, их можно напрямую подключать к Git, PLM, ERP и базам данных. Но скоро (хоть и не к концу этого года) их станет тысячи, и тогда архитектура начнет напоминать тысячи микросервисов напрямую вызывающих друг друга без очередей, ограничений нагрузки и единого контроля. Если денег на токены всё-таки хватит, придётся сделать так, чтобы от агентного энтузиазма не легла инфраструктура.

Свежие вроде как научно-технические статьи (arxiv) RA-CAD: CAD-агент, который анализирует результат собственной работы — вместо одноразовой генерации CAD-программы предлагается цикл Generate → Execute → Critique → Rewrite: агент строит модель, запускает полученный код в CAD-среде, видит фактический результат, отдельно формулирует критику и исправляет построение. https://arxiv.org/html/2608.05714v1 VFEAgent — мультимодальная агентная система, автоматизирующая цепочку от инженерного чертежа до проверенного результата конечно-элементного моделирования. ИИ выступает исполнителем инженерного процесса, связывающий понимание исходного документа, подготовку модели, запуск расчёта и проверку результата. Вместе с DUCTILE, RA-CAD и CADENA начинает складываться довольно отчётливое направление: агентная автоматизация всей инженерной цепочки вместо добавления отдельных ИИ-функций в CAD/CAE. https://arxiv.org/html/2605.28978v2

Вашингтонский университет исследовал, как с помощью ИИ быстрее подбирать параметры 3D-печати для медного сплава GRCop-42, который используют, например, в ракетных камерах сгорания. Вместо перебора более 100 млн возможных сочетаний исследователи построили замкнутый цикл: ИИ выбирал небольшую серию параметров для проверки, детали печатали и измеряли, после чего результаты возвращались в модель, и она предлагала следующие варианты. При бюджете всего в 40 экспериментов удалось найти шесть рабочих конфигураций на разных мощностях лазера и впервые стабильно печатать этот материал при 500 Вт. https://news.wsu.edu/news/2026/08/24/researchers-use-ai-to-democratize-3d-printing-of-crucial-metal-alloy/ Исходная работа получила Innovative Deployed Application Award на AAAI-26. https://ojs.aaai.org/index.php/AAAI/article/view/41428 Одновременно опубликована работа российского Сколтеха с новым подходом к моделированию механических свойств гетерогенных материалов, который сочетает машинное обучение с активным обучением на локальных химических конфигурациях. Метод сочетает момент-тензорные потенциалы с активным обучением: модель сама обнаруживает локальные атомные конфигурации, где её прогноз ненадёжен, отправляет только эти небольшие фрагменты на дорогой DFT-расчёт и затем дообучается. На композитах WC–Co удалось перейти от систем в сотни атомов, характерных для прямого DFT, к десяткам тысяч атомов, сохраняя близкую к DFT точность. Это интересно для CAE прежде всего как пример перехода от «ИИ после расчёта» к многоуровневому моделированию, где дорогой физический решатель автоматически вызывается лишь там, где машинная модель выходит за область уверенного прогноза. https://ai.cnews.ru/news/line/2026-08-24_metallokeramika_pod_kontrolem ——— Берлинская компания SPREAD AI, которая строит над существующим инженерным ПО единый слой данных, связей и ИИ, описала свой подход к «PLM нового поколения», и по сути он строится вокруг уже знакомой идеи: не заменять существующие PLM, ALM, ERP, MES и CAE, а создать над ними общий интеллектуальный слой. Он связывает требования, функции изделия, версии программного обеспечения, детали, испытания и изменения в единую модель взаимосвязей. Благодаря этому ИИ работает не просто с отдельными документами, а понимает, как инженерные объекты связаны между собой, и каждый его вывод можно проверить по исходным данным. https://www.spread.ai/resources/stories/ai-native-plm По сути тоже самое что я описал вчера https://t.me/BOM_Voyage/347 Чуть дальше пошла Enlil, небольшая частная американская компания из Кремниевой долины, работающая на стыке инженерного ПО и медицинской техники, — они представили архитектуру Governed AI Foundation для разработки медицинских изделий. Это один из наиболее точных найденных аналогов нашей концепции. Платформа связывает PLM, требования, управление рисками, качество, закупки и производство; общий ИИ-слой в первую очередь читает данные и оценивает межсистемные последствия, но не изменяет рабочие системы. Специализированные агенты получают только ограниченные права и действуют через заданные процессы и обязательные точки согласования. Для каждого результата сохраняются происхождение данных, полномочия агента, его действия и решения человека. То есть присутствуют почти все основные элементы: межсистемный контекст, «читать широко — изменять узко», проверяемые основания, ограниченная автономность и история решений. Отличие главным образом в узкой ориентации на регулируемую MedTech-среду. https://www.prnewswire.com/news-releases/enlil-unveils-governed-ai-foundation-to-ready-medical-device-makers-for-ai-assisted-regulatory-review-302853600.html —— В Китае вышел большой обзор развития агентной инфраструктуры за предыдущую неделю и из него вытекает тот же вывод: конкуренция смещается от качества модели к постоянному состоянию агента, собственной идентичности, делегированию полномочий, согласованиям, восстановлению после ошибок, идемпотентности и аудиту. Отдельно отметили от агентов, которыми человек постоянно управляет в чате, к постоянно работающим организационным единицам, где человек вмешивается только в критических точках — утверждает, приостанавливает или перехватывает выполнение. https://wujiaming88.github.io/2026/08/24/global-ai-agent-weekly.html (китайский) Кстати стартапов в публичном поле в Китае маловато, но может я как-то не так смотрю. Такое чувство что там вся энергия (а её у них ух) уходит сугубо в физический ИИ, практически полностью в робототехнику. Ну и на унижение американцев на рынке LLM. Результат у них на лицо, но и риск локального перепроизводства гуманоидных роботов первого поколения ("забавно, продолжайте, сейчас купим только штучно побаловаться") просто запредельный.

У меня закончились токены при работе с Claude, поэтому я решил переключиться на Qwen3.8. Из-за проблем с вызовом инструментов мне не удалось нормально его подключить, поэтому вместо Claude Code я использовал открытого агента для программирования PI (pi.dev), распространяемого по лицензии MIT. Приятным побочным эффектом стало то, что теперь весь комплекс можно запускать полностью локально, что очень хорошо с точки зрения конфиденциальности данных. Настоящий шаг вперёд заключается в том, что связка Qwen3.8 с PI позволяет агенту напрямую работать с моим инструментом расчёта электрических машин: он автономно предлагает параметры геометрии, запускает расчёты, создаёт модель в FreeCAD, а затем передаёт её в расчёт магнитного поля в Elmer и в основанную на Mantaflow модель смачивания маслом в Blender — пока это лишь приближённая модель, а не полноценный тепловой расчёт или моделирование масла. Вся эта система всё ещё находится на экспериментальной стадии. На приложенном изображении слева показан PI, а справа — сгенерированная ИИ конструкция электрической машины. Конструкция пока не совсем корректна; сейчас я дорабатываю управление геометрией. Это по-прежнему любительский проект и отчёт о полученном опыте, а не реальная инженерная работа.

https://lnkd.in/p/dnMeagdR

ИИ‑агент внутри КОМПАС-3D: пишет код, строит деталь и проверяет результат Показан ИИ-агент, встроенный в КОМПАС-3D и способный по тексту или чертежу создавать параметрическую модель с деревом построения, переменными и свойствами. Вместо управления CAD через множество команд модель пишет Python-код для высокоуровневой библиотеки поверх COM API КОМПАС-3D. Такой слой скрывает сложность интерфейса, позволяет использовать обычные конструкции программирования и ограничивает опасные вызовы. Агент фактически не «нажимает кнопки», а пишет программу построения детали. После выполнения кода агент получает изображения модели, выбирает ракурсы и проверяет результат. Это позволяет находить ошибки, которые не выявляются самим CAD: неверную плоскость, направление операции или выбранную грань. В экспериментах агент часто исправлял модель после визуальной проверки. Получается замкнутый цикл «построил — проверил — исправил», частично компенсирующий слабое пространственное мышление современных моделей. На 90 тестовых задачах лучше всего работало построение по текстовому описанию: для простых и средних деталей совпадение с эталоном было близко к полному, для сложных снизилось примерно до 0,84. Редактирование существующих моделей оказалось сложнее из-за выбора геометрических элементов, а восстановление по чертежу — самым трудным сценарием, особенно при нескольких проекциях. Работа показывает практичный путь к агентному CAD: языковая модель выступает управляющим слоем над программируемой CAD-системой и проверяет результат в замкнутом цикле. https://habr.com/ru/articles/1072444/