CrossnoKaye управляет оборудованием на площадках пищевой промышленности, объектах промышленного охлаждения, в карьерах заполнителей и на производственных предприятиях: более 100 объектов, 13 000 управляемых активов, свыше 22 трлн машинных точек данных и более 50 млрд новых показаний в сутки. Для такого масштаба Physical AI означает конкретное требование к ответу: модель называет число и показывает расчёт, которым оно получено.
Архитектура держится на двух компонентах. ATLAS - программно-определяемая платформа автоматизации CrossnoKaye, которая хранит модель объекта, базовое ПО управления, историан и APC-приложения в одном контуре на AWS. AURA - агентная система на Amazon Bedrock AgentCore. ATLAS уже владеет операционным состоянием предприятия целиком, поэтому AURA читает его нативно, внутри одной границы безопасности, без набора самодельных коннекторов и размазанных по сети учётных данных. Детали этой связки описаны в разборе AWS.
Считать AURA умеет кодом. Модель пишет Python, код исполняется в изолированных управляемых microVM-песочницах AgentCore, результат проверяется по схеме pandas.DataFrame, при ошибке агент исправляет себя и повторяет запуск. Дополнительные слои защиты - Amazon Bedrock Guardrails и локальные edge-средства безопасности. По отчётности самой CrossnoKaye, её APC-приложения поднимают пропускную способность на 11-17% и снижают общие энергозатраты объекта в среднем на 21%. Независимой проверки этих цифр в опубликованном материале нет, это данные вендора.
Что такое Physical AI и зачем CrossnoKaye понадобился агент для промышленного оборудования
Physical AI работает с физическим состоянием оборудования: давлениями, расходами, температурами, мощностью, энергобалансами. Ответ в стиле «вероятно, проблема в компрессоре» инженеру ничего не даёт. Ему нужно знать, с какого момента выросла нагрузка, на сколько киловатт, какая уставка изменилась перед этим и кто её менял.
Разрыв между качеством рассуждения и качеством счёта определил всю конструкцию. Языковая модель разбирает инженерный контекст и планирует, что проверить. Арифметику по сырым рядам она не тянет. Отсюда разделение ролей: LLM решает, что исследовать, Python считает, песочница изолирует, инженер проверяет.
Почему обычный LLM не справится с диагностикой сбоев оборудования
LLM хорошо интерпретируют инженерный контекст и планируют исследование, но не могут надёжно вычислять статистику или физические балансы по миллионам показаний датчиков в промпте. Числа в контексте модели не вычисляются, а предсказываются по распределению. На коротком ряду из десяти значений это незаметно, на смене работы компрессора - фатально.
Типичная ошибка выглядит безобидно: модель видит фрагмент тренда, замечает рост температуры и выдаёт правдоподобную гипотезу про засор фильтра. Причина оказывается в другом - в изменённой уставке или в открытом байпасном клапане. Таймстамп без топологии и истории настроек врёт убедительно. В промышленности цена такой ошибки - простой линии, испорченная партия или вмешательство в процесс, которое само создало аварию.
Поэтому AURA не отвечает числом «из головы». Она пишет код, запускает его и возвращает результат, который можно воспроизвести.
Где именно в промышленности болит: разрозненные PLC, DCS, SCADA и историаны
На большинстве предприятий данные и логика управления распределены по системам разных поставщиков. Программируемые логические контроллеры (PLC) и распределённые системы управления (DCS) исполняют логику оборудования. Историаны пишут временные ряды под именами тегов, придуманными на конкретной площадке. SCADA отвечает за экраны операторов. Отдельные инструменты оптимизации и логгеры аварий стоят сбоку и живут своей жизнью.
Логика, которая реально определяет поведение оборудования (последовательности управления, конечные автоматы, предохранительные блокировки), заперта в проприетарном коде контроллеров. Внешний инструмент её не инспектирует: он видит теги и значения, но не видит причин.
Второй слой проблемы организационный. Подключение стороннего агента к нескольким OT-системам означает распределение учётных данных по сети предприятия: отдельные доступы к историану, к SCADA, к контроллерам, к инструментам оптимизации. Каждый такой доступ - ещё одна точка, которую нужно ротировать, аудировать и защищать.
ATLAS снимает обе части: логика и данные оказываются в одной модели, а агент получает доступ к ней, а не к десятку систем по отдельности.
Архитектура ATLAS: почему единая модель объекта важнее самого агента
ATLAS управляет промышленными процессами поверх уже стоящей инфраструктуры PLC и DCS: печи, дробилки, сушильные камеры, духовки, спиральные морозильники, чиллеры, турбины, клапаны, компрессоры. Менять оборудование целиком не требуется, платформа надстраивается над контроллерами, которые уже работают на площадке.
Ключевой тезис CrossnoKaye: ATLAS держит в одной платформе на AWS модель объекта, базовое ПО управления, историан и приложения оптимизации, поэтому AURA получает нативный доступ к полному операционному состоянию предприятия внутри единой границы безопасности. Именно единая модель, а не выбор LLM, определяет, что агент вообще способен понять.
Что входит в единую модель: датчики, топология, логика управления, история настроек
Модель объекта собирается из четырёх слоёв, и каждый нужен агенту по-своему.
- Данные с датчиков. Временные ряды: давления, температуры, токи, расходы, положения клапанов, обороты. Это то, что обычно и называют «данными предприятия», хотя само по себе они почти бесполезны.
- Топология оборудования. Что с чем связано физически и логически: какой компрессор обслуживает какой чиллер, какой насос качает через какой контур, где физически стоит датчик и как его показания соотносятся с соседними.
- Базовая логика управления. Последовательности запуска, конечные автоматы, предохранительные блокировки. Без этого слоя агент не отличает штатный переходный режим от сбоя.
- История настроек. Уставки, режимы, изменения конфигурации с привязкой ко времени. Половина «внезапных» сбоев объясняется правкой параметров за час до этого.
Пример, чтобы показать разницу. Инженер спрашивает, почему компрессор №3 в третьей смене потребляет больше обычного. Агент с одним историаном сравнит средние и скажет «выросло на 8%». Агент с моделью объекта увидит, что параллельный чиллер перевели на ручной режим, из-за чего выросла нагрузка на контур, что уставка по давлению нагнетания менялась в 22:40, а активная последовательность запуска после этого не пересчитывалась. Причина найдена, корреляция превратилась в диагноз.
Почему «прикрутить агента сбоку» не работает
Bolt-on агент, подключённый к нескольким OT-системам, решает задачу доступа и не решает задачу контекста. Он получает таймстампы с именами тегов, которых не понимает, и проприетарную логику контроллеров, которую не может прочитать. Дальше остаётся один путь: угадывать по форме кривой.
Плюс к этому доступы. Внешнему агенту нужны учётные данные к историану, к SCADA, к инструментам оптимизации, и каждое подключение расширяет поверхность атаки. Единая граница безопасности в ATLAS закрывает и это: агент ходит в одну модель, а не в семь систем с разными политиками.
Практический вывод для своего проекта простой: если данные объекта не сведены в модель с топологией и историей, агент останется умным чатом над историаном. Обёртка вокруг LLM тут ничего не компенсирует.
Как AURA считает: проверяемый Python в microVM-песочницах AgentCore
AURA использует возможность code interpreter в Amazon Bedrock AgentCore, чтобы писать и запускать Python-нагрузки во время выполнения в изолированных управляемых AWS microVM-песочницах, рядом с Amazon Bedrock Guardrails и локальными edge-средствами безопасности. Цепочка шагов выглядит так.
- LLM разбирает вопрос инженера и планирует, что именно проверить: какой участок, какое окно времени, какие сигналы.
- Модель генерирует Python-код под этот план.
- Код исполняется в песочнице AgentCore.
- Результат валидируется по ожидаемой схеме, включая типы колонок pandas.DataFrame.
- При ошибке или несовпадении схемы модель получает сообщение об ошибке, правит код и запускает снова.
- Инженер получает численный ответ вместе с математикой, которую можно перепроверить.
Изоляция microVM означает, что исполняемый код не дотягивается до продовых систем за пределами разрешённого. Сгенерированный моделью скрипт остаётся скриптом в песочнице, даже если в нём окажется что-то лишнее.
Валидация схем pandas.DataFrame и автоматическая самокоррекция
Схема результата превращает «доверяй ответу модели» в «проверяй структуру результата». Контракт простой: расчёт обязан вернуть таблицу с заранее известными колонками и типами. Если код упал, вернул одну строку вместо ряда или отдал строку там, где ожидается float, валидатор это поймает и отправит агенту на переписывание.
expected = ["timestamp", "power_kw", "expected_kw"]
missing = [c for c in expected if c not in df.columns]
if missing or not pd.api.types.is_numeric_dtype(df["power_kw"]):
raise SchemaError(missing)
Код выше - иллюстрация принципа, а не фрагмент из репозитория CrossnoKaye. Смысл в том, что проверка живёт в коде, а не в просьбе к модели «будь аккуратнее».
Иллюстративный пример целиком: агенту нужно посчитать энергобаланс чиллера за смену. Он генерирует расчёт, который возвращает колонки timestamp, power_kw, expected_kw. Валидатор проверяет наличие колонок, числовые типы, отсутствие дыр в ожидаемых местах. Схема не сошлась - агент переписывает код. Схема сошлась - инженер видит отклонение факта от ожидания по времени и понимает, где искать причину.
Почему код лучше, чем «посчитать в промпте»
Код даёт воспроизводимость. Тот же вход, тот же скрипт, тот же результат, и математику можно перепроверить вручную или прогнать заново на другом окне данных. Для инженера, который решает, лезть ли в процесс, это принципиально: он проверяет не уверенность модели, а формулу.
Ограничение подхода тоже честное. Данные должны быть доступны песочнице в структурированном виде, а модель должна уметь писать корректный код под конкретную схему. Отсюда валидация и цикл самокоррекции: они не устраняют риск ошибки, а не дают ошибке дойти до инженера в виде гладкого ответа. Общая механика оркестрации, памяти и обработки ошибок в агентах разобрана в материале про самописного агента на Python.
Похожие задачи изоляции и доступа к инструментам решают и в других проектах на AgentCore, например в аналитике наземного обслуживания AvioBook, где изоляция данных построена вокруг ролей и токенов.
Тёплые сессии против чистых песочниц: как AURA разделяет чаты и рутины
Агент обслуживает два разных режима работы. В интерактивном чате инженер ведёт диалог: уточняет, меняет окно времени, просит копнуть глубже. В фоновых задачах и рутинных проверках диалога нет, есть расписание и требование к повторяемости.
Под эти режимы подходит разная модель исполнения. Тёплые сессии держат контекст между запросами: быстрее отклик, не нужно заново поднимать окружение, диалог не теряет нить. Чистые одноразовые песочницы каждый раз стартуют с нуля: медленнее на входе, зато нет накопленного состояния, нет утечки данных между запусками и результат воспроизводится.
Оговорка по источнику. В опубликованном разборе AWS устройство сессий не раскрыто: там названы изолированные песочницы, Guardrails и локальные edge-средства безопасности, но нет описания того, как именно CrossnoKaye разделяет интерактивные и фоновые запуски. Схема «тёплые сессии для чатов, чистые песочницы для задач и рутин» взята из описания кейса; конкретные детали реализации в источнике отсутствуют.
Инженерная логика при этом переносится на любой проект. Тёплая сессия экономит секунды и деньги, но накапливает мусор: старые данные в контексте, полуавторизованные допущения, случайные артефакты предыдущих запусков. Одноразовая среда стоит дороже на старте и ограничивает радиус поражения при ошибке в сгенерированном коде. Для диагностики в диалоге тёплая сессия оправдана, для ночного расчёта энергобаланса по всем объектам - сомнительна.
Доставка Brief-отчётов через Amazon SES
Канал доставки результата в описанной схеме - Amazon SES, то есть обычная почта. Смысл решения в снижении барьера: инженеру не нужно держать открытым отдельный дашборд и помнить про ещё одну вкладку. Отчёт приходит туда, где его прочитают.
Формат, периодичность и содержимое Brief-отчётов в источнике не раскрыты, поэтому не стоит представлять их как некий стандарт. Что известно: канал доставки - электронная почта через SES. Что из этого следует: результат работы агента должен попадать в существующий рабочий поток, а не требовать от пользователя нового интерфейса.
Четырёхуровневая защита: почему AI не может обойти логику управления на edge
Базовый принцип: агент предлагает и диагностирует, физическое действие выполняет детерминированная логика, которая от модели не зависит. Модель не выдаёт команды напрямую приводам и не может отменить предохранительную блокировку.
Границы фактов. В разборе AWS прямо названы изолированные microVM-песочницы AgentCore, Amazon Bedrock Guardrails и локальные edge-средства безопасности. Формулировка «четырёхуровневая защита» и тезис о невозможности обойти edge-логику со стороны AI - рамка этой статьи; детали каждого уровня источник не раскрывает. Ниже четыре слоя в таком прочтении.
- Изоляция исполнения. Сгенерированный Python работает в управляемой microVM-песочнице AgentCore и не дотягивается до продовых систем за пределами разрешённого.
- Guardrails. Amazon Bedrock Guardrails фильтруют входы и выходы модели: грубые ошибки формата, недопустимое содержимое, попытки увести диалог в запрещённую область.
- Локальные edge-средства безопасности. Защита живёт на площадке, рядом с оборудованием, и не зависит от доступности облака и состояния агента.
- Детерминированная логика управления на edge. Последовательности, конечные автоматы и предохранительные блокировки исполняются на контроллерах и не спрашивают разрешения у LLM.
Четвёртый слой объясняет, почему такая архитектура вообще допустима в промышленности. Модель может ошибиться, поддаться инъекции в тексте заявки или просто перепутать единицы. Предохранительный контур на это не реагирует: он срабатывает по своим условиям. Ровно поэтому граница между «посоветовать» и «изменить» проходит по коду, а не по вежливости промпта.
Почему контракты по безопасности нужно закреплять в коде, а не в промптах
Промпт можно переформулировать, обойти или подменить инъекцией. Код и ограничения песочницы - нельзя: они исполняются независимо от того, что модель «решила». Ограничения на исполнение, доступ к данным и проверка результата должны жить в конфигурации среды и в валидаторах, а не в инструкции «не делай опасных вещей».
Валидация схемы pandas.DataFrame - тот же контракт, только по данным. Edge-логика - тот же контракт, только по физике. Промпт остаётся интерфейсом, а не средством контроля. Как это выглядит на практике, когда агент формально без прав всё равно меняет запись через downstream-узел, разобрано в кейсе про runtime-контроль read-only агента.
Уроки команды CrossnoKaye: что перенести в свой проект
Из кейса выжимаются пять переносимых принципов. Они не привязаны к AWS и работают в любом стеке.
- Сначала модель объекта, потом агент. Данные, топология, базовая логика и история настроек дают агенту причинно-следственные связи. Без них любая модель LLM угадывает по кривой.
- Контракты по данным и безопасности живут в коде. Схемы результата, права доступа, границы песочницы и предохранительные блокировки закрепляются в исполняемой среде, а не в промптах.
- Численный ответ должен быть проверяемым. Расчёт кодом в изоляции даёт воспроизводимость, которую невозможно получить вычислением «в голове» модели.
- Интерактивные сессии и рутины разделяются. Диалогу нужен контекст, регламентному расчёту нужна чистая среда без унаследованного состояния.
- Результат доходит удобным каналом. Отчёт по почте через Amazon SES снижает порог входа: инженер читает вывод там, где уже работает, без нового дашборда.
Пятый пункт часто недооценивают. Агент с блестящей диагностикой, до которой надо дойти через три клика в незнакомом интерфейсе, проигрывает агенту попроще, чей вывод приходит в почту. Если нужен внутренний rollout на команду инженеров, полезна программа обучения с Guardrails и AgentCore, разобранная в кейсе AWS AI League для 400 инженеров Atos.
Ограничения подхода и кому он не подходит
Честный список того, что стоит взвесить до копирования архитектуры.
- Предварительная работа огромна. Единая модель объекта не появляется сама: нужно свести теги, описать топологию, вытащить логику и историю настроек. Это месяцы, а не спринт, и основной объём усилий приходится именно сюда.
- Инфраструктура вокруг песочниц стоит денег и внимания. Изоляция, валидация схем, цикл самокоррекции, наблюдаемость за запусками - отдельный инженерный контур.
- Цифры вендора. 11-17% прироста пропускной способности и 21% средней экономии энергии - отчётность самой CrossnoKaye, независимого подтверждения в опубликованном материале нет. Планировать бюджет на этих числах рискованно.
- Малым установкам может быть избыточно. Для площадки с одним-двумя контроллерами и десятком датчиков модель объекта, песочницы и агентная надстройка дороже, чем дадут. Порог входа начинается там, где данных много, а причину сбоя искать долго.
- Деталей много и они закрыты. Источник не раскрывает сроки запуска, версии продуктов, результаты независимых аудитов, устройство тёплых сессий и формат Brief-отчётов.
Что в итоге: Physical AI как инженерная дисциплина, а не магия
CrossnoKaye показывает скучную и полезную вещь: Physical AI в промышленности держится на данных, топологии и контрактах, а выбор модели стоит в самом конце списка. Amazon Bedrock AgentCore даёт исполняемую среду с изоляцией и механикой code interpreter, но ценность создают единая модель объекта в ATLAS и детерминированная логика на edge, которую модель не обходит.
Если строите агента для физического мира, начните с трёх вопросов. Сведены ли данные объекта в модель с топологией и историей настроек? Возвращает ли агент числа вместе с расчётом, который можно перепроверить? Может ли сгенерированный код дотянуться до чего-то, чего ему трогать нельзя? Ответы на них определяют архитектуру куда сильнее, чем название LLM в конфиге.