BOM Voyage

На конференции 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/

Large language models for high-level computer-aided process planning in a distributed manufacturing paradigm Прямо-таки научная статья посвященная применению языковых моделей к высокоуровневому автоматизированному проектированию технологических процессов. Речь не о режимах резания или выборе инструмента, а о построении общей последовательности операций: например, получение заготовки, точение, сверление и шлифование. Это особенно важно для распределённого производства, где одну деталь можно выпускать на разных предприятиях с различным оборудованием. Поэтому система должна формировать несколько допустимых маршрутов, которые затем можно сравнивать по стоимости, срокам, загрузке и доступным ресурсам. Авторы не используют большую универсальную языковую модель. Они обучают с нуля небольшую модель (SLM а не LLM) на основе архитектуры GPT на специальном «языке производства». Геометрия детали, её особенности, требования к точности и параметры заказа представляются последовательностью условных обозначений, как и технологические операции. Проектирование маршрута сводится к предсказанию следующей операции. Для обучения создан синтетический набор из 7840 деталей и допустимых маршрутов на основе экспертных правил. При этом модель содержит всего около 200 тысяч параметров и не требует значительных вычислительных ресурсов. Экспериментально показывается, что для хорошо формализованной задачи такая компактная модель способна точно строить технологические маршруты даже при сравнительно небольшом объёме данных. Главный вывод работы в том, что универсальную модель необязательно заставлять напрямую «понимать производство». Инженерную задачу можно сначала перевести в компактное формальное представление, а затем обучить модель закономерностям технологических последовательностей. Проверку ограничений, стоимость и выбор предприятия при этом выполняют другие компоненты. В перспективе такой модуль может стать частью агентной производственной системы, где одни компоненты извлекают данные из CAD и заказа, другие строят маршруты, а третьи оценивают их по производственным ограничениям. Ещё одно — Adaptive task planning and coordination in multi-agent manufacturing systems using large language models Там уже про LLM-управляемую многоагентную производственную систему, агент в ней интерпретирует ранее неизвестные требования к изделию, динамически получает знания о доступных производственных возможностях, подбирает ресурсы и преобразует требования в исполняемые операции. В испытательном стенде система смогла обрабатывать требования, которые заранее не были заложены в модели агентов. То есть интересный следующий уровень после простой автоматической генерации BOP: технологический план становится не статическим результатом проектирования, а адаптируемым планом, который может перестраиваться с учетом фактических возможностей оборудования. И наконец, не про ИИ, но интересно A STEP-NC-based post-process simulation system for closed-loop machining — про замыкание CAPP/CAM в обратную связь с производством. На основе STEP-NC связали каждый workingstep с фактическими сигналами выполнения, которые дополняют технологическую модель реальными результатами обработки и затем используют байесовскую оптимизацию для изменения параметров следующего цикла. В экспериментах оптимизация улучшила результат для всех 12 исследованных операций; среднее превышение лучшего исходного результата составило 24,33%. Это не то, чтобы ИИ (однако очень просится в эту схему), но архитектурно направление очень важное: цифровой двойник перестает только отображать производство и начинает возвращать опыт реального выполнения непосредственно в технологический процесс. ————— Кстати, «СПРУТ-Технология» недавно как раз показали своего ИИ-помощника технолога СКАТ в СПРУТ-ТП-Нормирование. Он умеет генерировать технологический процесс по текстовому заданию, восстанавливать ТП из сканированных документов, строить его по чертежу и переносить результат непосредственно в структуру технологического процесса. https://rutube.ru/video/5e90995f470180dfbde0f403d94662f5 В РФ это вроде бы первый такой пример. На западе это есть например как Manufacturing Planning Agent в Teamcenter Manufacturing Easy Plan 2606 https://blogs.sw.siemens.com/teamcenter-manufacturing/2026/07/28/whats-new-in-teamcenter-manufacturing-easy-plan-2606/ или CAM Assist для GibbsCAM https://www.cloudnc.com/news-room/cam-assist-the-first-ai-plug-in-for-cam-is-now-available-for-gibbscam

По мере того как ИИ-агенты будут брать на себя всё бОльшие фрагменты инженерной работы, главным ограничением станет контроль результата, трассируемость, прозрачность происходящего. Агенты смогут определять затрагиваемые инженерные объекты, сопоставлять контекст из CAD, PLM и ERP, даже CRM, проверить структуру изделия, оценить последствия изменений, причём не только сугубо инженерные. Инженеру и менеджеру нужно видеть, какие версии объектов использовались, какие ограничения учтены, что и почему находится в контексте изменения, к чему оно приведёт. Поэтому согласование должно относиться к конкретному состоянию данных и отменяться при его существенном изменении. Работа инженера постепенно смещается от выполнения операций к проверке решений агентов. Как и в программировании, роль инженера будет стремится к слиянию с ролью менеджера. Для CAD/CAE/CAPP/PLM это особенно важно: изменение редко остаётся внутри одной системы. Геометрия может затронуть EBOM и MBOM, технологию, материалы, расчёты, закупки и документацию. Поэтому предложение агента должно быть проверяемым решением: что меняется, на каких данных оно основано и чем подтверждены выводы. Для CAE важен не только итог расчёта, но и версия геометрии, сетка, граничные условия, материалы и настройки решателя. Инженер должен согласовывать воспроизводимое обоснование, а не текстовый ответ. Между агентами и корпоративными системами потребуется слой контроля, который собирает контекст из разных источников и оставляет человеку только то, где требуется инженерное суждение. Ревизии, состояния объектов, связи, ограничения и численные пороги лучше проверять автоматически. По мере накопления доверия типовые изменения смогут всё чаще выполняться без участия человека, а инженер будет разбирать главным образом исключения и рискованные случаи. Однако сначала доверие надо будет накопить, это не будет происходить автоматически, стартовать будет с позиций явного скептицизма и открытого сопротивления. Особую ценность из-за этого получает история решений, их трассируемость, прозрачность. Важно сохранять не только факт утверждения, но и исходные данные, доказательства, альтернативы, причины выбора и иной контекст. Формировать человевекочитабельную сводку и развёрнутое представление. Скорее всего PLM придут к хранению не только то, что изменилось, но и причин изменения, контекста в том состоянии в каком изменение производилось. При этом CAD, PLM, ERP, MES, QMS и другие системы могут оставаться владельцами своих данных: необязательно собирать всё в одной базе, важнее уметь сформировать доверенный и версионированный контекст решения. В итоге основным интерфейсом инженерной работы с ИИ может стать не редактор BOM, процесс согласования или чатбот, а среда проверки решений, связывающая предложения агентов, инженерные доказательства и выполнение изменений. Она может быть распределена между CAD, CAE и PLM, сохраняя единый объект решения. Если PLM останется системой форм, BOM и жёстких процессов, этот слой возникнет над ним. Следующее поколение PLM, вероятно, будет управлять не столько данными изделия, сколько проверяемыми изменениями, которые совместно выполняют люди и агенты. Класс таких систем можно назвать Engineering Decision Control — EDC Engineering Decision Assurance — EDA или «Система управления инженерными решениями», «Система контроля инженерных решений», «Платформа инженерных решений», «Инженерный контур доверия» в русскоязычном варианте.