ERP.Next: Архитектура автономных ERP на основе мультиагентного ИИ. AI-native ERP.. AI-native ERP. ERP.. AI-native ERP. ERP. ERP-системы.. AI-native ERP. ERP. ERP-системы. IT-инфраструктура.. AI-native ERP. ERP. ERP-системы. IT-инфраструктура. knowledge graph.. AI-native ERP. ERP. ERP-системы. IT-инфраструктура. knowledge graph. Анализ и проектирование систем.. AI-native ERP. ERP. ERP-системы. IT-инфраструктура. knowledge graph. Анализ и проектирование систем. Блог компании ГК «МТ-Интеграция».. AI-native ERP. ERP. ERP-системы. IT-инфраструктура. knowledge graph. Анализ и проектирование систем. Блог компании ГК «МТ-Интеграция». искусственный интеллект.. AI-native ERP. ERP. ERP-системы. IT-инфраструктура. knowledge graph. Анализ и проектирование систем. Блог компании ГК «МТ-Интеграция». искусственный интеллект. корпоративная ИТ-архитектура.. AI-native ERP. ERP. ERP-системы. IT-инфраструктура. knowledge graph. Анализ и проектирование систем. Блог компании ГК «МТ-Интеграция». искусственный интеллект. корпоративная ИТ-архитектура. мультиагентные системы.. AI-native ERP. ERP. ERP-системы. IT-инфраструктура. knowledge graph. Анализ и проектирование систем. Блог компании ГК «МТ-Интеграция». искусственный интеллект. корпоративная ИТ-архитектура. мультиагентные системы. цифровая трансформация.
ERP.Next: Архитектура автономных ERP на основе мультиагентного ИИ - 1

ERP-системы непрерывно развивались с самого начала своего создания. Но их архитектура до сих пор опирается на принципы, сформулированные до эпохи повсеместного распространения данных в реальном времени и развития автономного агентного искусственного интеллекта

Соответственно, можно с утверждением говорить, что текущая архитектура ERP-систем не отвечает современным вызовам. В этой статье разберем, почему ей нужен принципиально иной фундамент. Я предлагаю строить его на трех китах: семантический слой данных (USDL), открытая интеграционная среда и продвинутая мультиагентная платформа (AMAP).

Далее я подробно представлю архитектуру такой ERP-системы, типы AI-агентов и примеры их работы в реальных бизнес-процессах. Ключевая идея — гибкая автономия под контролем человека. В статье я опираюсь на актуальные разработки и аналитику 2025 года, чтобы показать и возможности, и подводные камни мультиагентных систем в корпоративной ИТ-среде.

1. Вместо введения

ERP-системы уже много лет являются центральной нервной системой крупного бизнеса. Они объединяют транзакции, данные и процессы в единый цифровой каркас. Исторически их архитектура заточена под главные задачи эпохи: обеспечить целостность данных, централизованный контроль и стандартизацию. Центральный механизм выполнения рабочих процессов и единая модель данных были главными козырями ERP, которые гарантировали надежную отчетность и соответствие регуляторным требованиям.

Но мир изменился. Сегодня компании работают с постоянными потоками данных и телеметрии с IoT-устройств, в сложных цифровых экосистемах, в условиях рынка, где быстрые решения определяют операционные и финансовые результаты. Старая, монолитная архитектура ERP не успевает за новой реальностью.

Этот разрыв, между старой архитектурой и новыми потребностями предприятий, является ключевой проблемой. Бизнесу нужны системы, которые могут работать в условиях неопределенности, координировать участников и постоянно адаптироваться.

И здесь на сцену выходят мультиагентные системы (МАС) – являющиеся по сути, «коллективами» автономных программных агентов, которые умеют общаться. Это и есть основа для ERP нового поколения. Каждый агент – это эксперт в своей области. Он может выполнять локальную часть процесса, вести свой участок работы, «договариваться» с другими агентами и учиться на результатах.

Если объединить эти «коллективы» с семантическим слоем данных и консолью управления, где у человека есть полная видимость и остается последнее слово, мы получим большее, чем просто исполнение процедур. Мы получим систему для оркестрации бизнес-результатов.

Дальше мы разберемся в архитектурном дизайне такой ERP-системы. Поговорим про роли и свойства разных типов агентов и их взаимодействие.

Кроме того, я сопоставил предлагаемую мной архитектуру с отраслевыми трендами 2024–2025 годов. С одной стороны, они показывают, что за агентами будущее. Но, с другой, предостерегают, что без адекватного плана и управления внедрением, они легко превращаются в дорогую и неуправляемую игрушку.

2. Почему классическую архитектуру ERP необходимо пересмотреть

Классическую архитектуру ERP создавали для двух вещей: чтобы все транзакции были согласованы, а процессы стандартизированы. Продуманная модель данных, полностью аудируемые финансовые потоки, устоявшиеся экосистемы вендоров, соответствующие лучшим отраслевым практикам – ее сильные стороны, которые до сих пор остаются актуальными.

Но этого уже недостаточно. Современный бизнес требует от систем способности к непрерывной адаптации и автономному принятию решений. И тут старая архитектура начинает пробуксовывать.

Первая проблема – жесткость. Рабочие процессы в классической ERP похожи на рельсы, с которых сойти нельзя если случается что-то непредвиденное и нужен динамический компромисс. Предопределенные маршруты согласований и строгие алгоритмы не умеют учитывать форс-мажоры, вероятностные сценарии или вести переговоры между конкурирующими целями. Например, как сбалансировать уровень сервиса для клиента с дополнительными затратами? В старой системе это почти всегда требует ручного вмешательства и остановки процесса.

Вторая проблема – централизация. Монолитный «мозг» и тесно связанные модули создают две сложности:

  1. Сложности с масштабированием.

  2. Хрупкость системы. Поломка в одном узле может парализовать критически важные процессы, расширяя зону отказа.

Кроме того, любое обновление или внедрение новой функции превращается в ювелирную и дорогую операцию по «перепайке» связанных модулей, что тормозит инновации.

Третья проблема — логика на правилах. Она отлично работает в предсказуемом мире с четкими условиями «если-то». Но там, где неопределенность и большое количество переменных, система проявляет свою неработоспособность. 

Детерминированные правила не способны взвешивать компромиссы, когда нужно учесть сразу много критериев. Им недоступно «контекстное мышление», способность обобщать ситуацию и действовать по аналогии. А именно эти навыки критически важны для гибких операций сегодня. 

Рынок в 2025 наглядного демонстрирует системные противоречия. С одной стороны, все только и говорят об «AI-агентах», вендоры выпускают новые платформы, а бизнес запускает пилоты. С другой – аналитики предупреждают о незрелости большинства таких проектов. 

Например, один известный отраслевой отчет в середине 2025 прямо предсказывает: значительная часть этих AI-инициатив провалится, если с самого начала не закладывать в них понятную бизнес-ценность и продуманное управление.

В этом и заключается главный вызов. Огромные возможности соседствуют с огромными рисками. Именно это противоречие и мотивирует на создание принципиально новой архитектуры, которая будет в самой своей основе являться инкрементальной, наблюдаемой и управляемой [1-3].

3. Концептуальные основы: семантическая основа и агентная оркестрация

Наш архитектурный сдвиг опирается на два фундамента. Первый — это единый семантический слой данных (USDL).

Его можно представить как «цифровой двойник» бизнеса, но не просто копию, а интеллектуальную карту. Внутри него граф знаний, который связывает основные сущности (клиентов, товары, поставщиков), истории транзакций, контекстные данные и их отношения, а также хранилище временных рядов.

Это позволяет AI-агентам говорить на одном языке и видеть связь между данными. Также разные модули будут одинаково интерпретировать одни и те же бизнес-явления, например, «срыв поставки» или «лояльный клиент».

Неудивительно, что в 2026 году графы знаний продолжают набирать обороты. Они отлично подходят на роль такого «переводчика»: семантика понятна человеку, а связи – машине, что идеально для обработки сложных запросов и формирования логического вывода [4].

Второй – Продвинутая Мультиагентная AI-Платформа (AMAP). 

Это не просто среда для запуска агентов, а полноценная «операционная система» для них. Здесь каждый агент регистрирует, что он умеет, как его можно использовать и c каким уровнем сервиса. AMAP предоставляет им инфраструктуру для функционирования:

  • Сеть общения – чтобы агенты могли «разговаривать» и договариваться.

  • Планировщик-оркестратор – который ставит сложные, кросс-функциональные задачи, разбивая их на действия разных агентов.

  • Репозиторий моделей – версионное хранилище для «мозгов» агентов.

  • Песочницы — для моделирования и безопасного тестирования сценариев и обучения.

Важно отметить, что AMAP это не «Дикий Запад» автономных модулей. Это управляемая среда, которая обеспечивает соблюдение политик, ведет логирование (аудиторский след) всех действий агентов и их решений. Без этого внедрение в регулируемом бизнесе невозможно.

USDL и AMAP меняют саму парадигму работы ERP. В связке они обеспечивают переход от централизованного, статичного исполнения рабочих процессов к распределенной, адаптивной оркестрации бизнес-результатов.

USDL выступает как единый источник истины. Он поставляет всем агентам согласованные данные в контексте (не просто «заказ просрочен», а «заказ клиента X на продукт Y просрочен из-за срыва поставки от поставщика Z»).

AMAP выступает как поле для игры по правилам. Агенты в этой среде интерпретируют эти данные, договариваются между собой о наилучшем действии и действуют. И все это – отслеживаемо, тестируемо в песочнице и имеет четкие ограничения.

4. Подробное изложение архитектуры

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

  1. Фундамент (USDL): Единый семантический слой данных,  источник истины для всей системы.

  2. Когнитивное ядро (AMAP): Платформа, где живут и работают AI-агенты, «мозг» системы.

  3. Интеграционная прослойка (Open Integration Mesh): Адаптеры и шлюзы для подключения к внешнему миру (старые ERP, IoT, партнерские системы).

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

  5. Управление и объяснимость: Сквозной слой контроля, который обеспечивает безопасность, аудит и прозрачность работы всей системы.

ERP.Next: Архитектура автономных ERP на основе мультиагентного ИИ - 2

USDL — это не хранилище, а «мозг» данных. Его сила в гибридной архитектуре, которая объединяет два типа мышления:

  1. Граф знаний (логика и связи: онтологии, связи сущностей, бизнес-метаданные). Здесь живут сущности (поставщик, продукт, клиент), их взаимосвязи и обогащенные метаданные. Например, он «знает», что поставщик А ненадежен, а продукт Б можно заменить на В или Г. Это основа для смысловых запросов и логических умозаключений.

  2. Хранилище временных рядов (память и тренды). Здесь пишется история: последовательность событий, телеметрия, агрегированные показатели. Это основа для прогнозов и поиска аномалий.

Агенты работают с обеими частями одновременно. 

Пример.

Агент управления запасами может задать USDL сложный вопрос: «Чем можно заменить продукт X, если его основной поставщик задерживает отгрузку?». Граф знаний найдет все семантически подходящие аналоги из «карты замен», а хранилище временных рядов проверит исторические сроки поставки этих аналогов от других вендоров.

Таким образом, агент получает не просто список вариантов, а контекстуально обоснованное решение, основанное и на правилах, и на исторических данных.

Над семантическим слоем (USDL) работает когнитивное ядро – платформа AMAP. Это «фабрика» и «операционная среда» для AI-агентов.

Каждый агент здесь создается (инстанцируются) с четким контрактом, который определяет:

  • Возможности (что он умеет делать)

  • Цели (к чему он стремится)

  • Ограничения (какие правила и ресурсы ему доступны)

  • Интерфейсы (как он общается с другими)

Для коммуникации в AMAP работает асинхронная шина сообщений. Помимо обмена данными она поддерживает полноценные протоколы общения и переговоров между агентами, а также каналы для широковещательных событий (например, «запущен новый заказ»).

Но главное, это планировщик. Его задача – собирать результаты работы отдельных агентов и формировать из них комплексные цели более высокого уровня. Именно это позволяет координировать сквозные процессы, такие как «от заявки до оплаты» или планирование производства, где успех зависит от слаженной работы десятков узкоспециализированных агентов.

Открытая интеграционная сеть (Mesh), это связь с внешним миром. Ее задача  обеспечить бесшовное взаимодействие с любыми внешними системами.

Как это работает? Сеть предоставляет стандартные адаптеры и шлюзы. Эти шлюзы работают как профессиональные переводчики.Они конвертируют «местные диалекты» внешних API (старых ERP, порталов поставщиков, IoT-датчиков) в единый семантический язык USDL, и наоборот.

В чем главная выгода? Изоляция изменений. Представьте, что поставщик внезапно меняет формат своего портала. В этой архитектуре вы просто обновляете правила преобразования в одном конкретном шлюзе. Высокоуровневая логика агента по закупкам, его стратегия и рассуждения остаются неизменными. Он продолжает «думать» на языке бизнес-сущностей USDL, не отвлекаясь на технические детали внешних API.

Уровень взаимодействия с людьми спроектирован по принципу «постепенного доверия». Интерфейсы делаются максимально простыми, но не примитивными. Их главная задача быть полезными там, где без человека не обойтись.

Когда система сталкивается с ситуацией высокого риска или жеесткого регуляторного требования, она не действует сама. Вместо этого уровень поддержки решений предлагает человеку объяснимую рекомендацию с обоснованием и альтернативные сценарии («что, если мы поступим иначе?»).

Для этого используются разные типы интерфейсов:

  • Разговорный. Можно спросить на естественном языке: «Почему ты предложил этого поставщика?». И получить внятный ответ.

  • Визуальный. Интерактивные дашборды и симуляторы, где можно в реальном времени менять параметры и видеть последствия.

  • Процедурный. Упрощенные консоли для согласования, куда система сама подкладывает все необходимые документы и выкладки.

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

Завершает архитектуру сквозной слой Управления и объяснимости. Это не отдельный модуль, а система контроля, которая пронизывает все уровни. Его задача сделать автономную работу агентов безопасной, прозрачной и подотчетной.

Он работает в трех ключевых направлениях:

  1. Политика и контроль. Принудительно следит за соблюдением всех правил – бюджетных лимитов, маршрутов согласования, регуляторных норм. Агент физически не сможет выйти за заданные рамки.

  2. Наблюдение и логирование. Ведет полный, неизменяемый журнал всех действий, решений и коммуникаций агентов. Каждый шаг можно будет позже «отмотать» и проанализировать.

  3. Объяснимость. Формирует для пользователя понятное обоснование: почему агент принял то или иное решение, на каких данных оно основано и какие альтернативы рассматривались.

Этот слой создаеет «операционную систему безопасности». Он не только проверяет соответствие стандартам, но и в реальном времени обнаруживает аномалии в поведении агентов или данных и предоставляет механизмы отката, чтобы в случае сомнительного решения можно было безопасно вернуть систему в предыдущее состояние.

Без этого слоя доверять автономной ERP будет просто невозможно.

5. Таксономия агентов и когнитивные преимущества

Хотя агенты часто описываются универсально, но в ERP-системе это не один тип сущности, а целая экосистема специалистов. Они различаются по тому, как мыслят, в каком временном горизонте работают и какому уровню доверия соответствуют. 

На практике внутри платформы AMAP живут и взаимодействуют пять основных семейств агентов, каждое со своей ролью.

1. Агенты-эксперты – узкие специалисты.
Это «рабочие лошадки» системы, которые инкапсулируют глубокие знания в конкретной операционной области. Их сила в том, что под капотом у них работают предиктивные модели, алгоритмы оптимизации и сложные эвристики.

Например: 

  • Эксперт по запасам не просто следит за остатками. Он анализирует прогноз спроса и статистику поставок, чтобы рассчитать оптимальную точку заказа, которая минимизирует и дефицит, и затраты на хранение.

  • Эксперт по финансовой сверке делает больше, чем просто сравнивает суммы. Он автоматически сопоставляет счета-фактуры с заказами, учитывая такие нюансы, как округления, начисления и частичные поставки.

Ключевая особенность – прозрачность. Эти агенты не выдают ответ как догму. Они раскрывают свои допущения и доверительные интервалы (например, «точка заказа рассчитана с вероятностью 95%»). Это позволяет другим агентам в цепочке или конечному пользователю оценить, насколько рекомендации надежны, и принять взвешенное решение.

2. Агенты-оркестраторы – менеджеры проектов.
Это «мета-агенты», главная задача которых является координация работы других агентов. Когда в системе появляется сложная, комплексная цель (например, срочно выполнить приоритетный заказ при срыве поставок), в дело вступает оркестратор.

Как он работает:

  1. Декомпозирует глобальную цель на цепочку или сеть подзадач.

  2. Назначает выполнение каждой подзадачи соответствующему агенту-эксперту (по закупкам, логистике, производству).

  3. Разрешает конфликты, если разные агенты требуют одни и те же ресурсы (деньги, мощности, материалы).

  4. Управляет последовательностью выполнения, следя за тем, чтобы все части пазла сошлись в итоговый результат.

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

3. Интерфейсные агенты – переводчики и посредники.
Их задача – быть «лицом» системы для человека. Они берут сложные решения и расчеты других агентов и переводят их на человеческий язык. Выдают не сырые данные и вектора, а понятные тезисы, выводы и обоснования.

Что они делают:

  1. Объясняют. «Система предлагает закупить у поставщика Б, потому что его рейтинг надежности 95%, а цена всего на 2% выше минимальной».

  2. Собирают обратную связь. Принимают от пользователя уточнения, корректировки или дополнительные условия.

  3. Управляют workflow. Ведут пользователя по процессу согласования, показывая нужные документы и запрашивая решения в нужный момент.

Но они же и строгие контролеры (гейткиперы). Если в процессе что-то пошло не по плану (эксперт выдал результат с низкой достоверностью, пользователь внес правку), интерфейсный агент:

  • Эскалирует проблему нужному человеку или системе.

  • Фиксирует все ручные вмешательства.

  • Гарантирует, что каждое изменение и его причина будут сохранены в семантическом слое (USDL) как часть неизменяемой доказательной базы. Все учтено и привязано к контексту.

4. Обучающиеся агенты – инженеры по данным и тренеры.
Их задача поддерживать «спортивную форму» всех предиктивных моделей в системе. Но они не просто периодически переобучают модели. Они управляют их полным жизненным циклом.

В их обязанности входит:

  • Тестирование политик в песочнице. Прежде чем новый алгоритм или правило попадет в работу, они «прогоняют» его на исторических данных или в симуляции, чтобы оценить потенциальные риски и результаты.

  • Мониторинг дрейфа концепций. Следят, не устарела ли модель. Например, если после кризиса покупательское поведение изменилось, а модель этого «не заметила», обучающийся агент первым поднимет тревогу.

  • Управление версиями моделей. На основе мониторинга они рекомендуют, нужно ли дообучить текущую модель на свежих данных, заменить ее на новую или вовсе вывести из эксплуатации устаревшую.

Их суперсила – перенос знаний (трансферное обучение). Они умеют находить успешные паттерны в одном контексте (например, в продажах одной линейки товаров или в работе одного региона) и предлагать адаптировать эти стратегии для других, ускоряя обучение системы в целом.

5. Агенты мониторинга и соответствия — внутренняя служба безопасности.
Это «стражи» системы, которые обеспечивают ее законопослушность и устойчивость. Они непрерывно следят за поведением всех остальных агентов и транзакционными журналами, чтобы мгновенно реагировать на любые отклонения.

Их ключевые функции:

  • Принудительное соблюдение правил. Они обеспечивают выполнение жестких, неизменных условий. Например, правило «ни один заказ не может превысить бюджет без утверждения директором» будет выполнено железно – система просто не пропустит такую транзакцию.

  • Детектирование аномалий. Они ищут подозрительные паттерны – нехарактерные всплески активности, подозрительные цепочки действий или данные, выпадающие из нормального распределения.

  • Инициация ответных действий. При нарушении они не просто сигнализируют. Агенты могут автоматически инициировать откат ошибочной операции или эскалировать инцидент на проверку человеку.

В регулируемых условиях эти агенты критически важны. Они автоматически формируют полные журналы аудита и готовят артефакты объяснимости с обоснованием каждого ключевого решения системы. Эти материалы могут использоваться для проверки внутренними аудиторами или внешними регуляторами в любой момент.

В итоге получается система с четким разделением труда.
Именно такая комбинация агентов создает не хаос, а управляемую экосистему. Каждый тип отвечает за свою зону, что делает систему одновременно практичной и прозрачной.

  • Компетенция локализована у экспертов – они лучшие в своеем узком деле.

  • Координация управляется явно оркестраторами – всегда понятно, кто за ��то отвечает в сложном процессе.

  • Обучение и обновления контролируются обучающимися агентами – эволюция системы происходит осознанно и безопасно.

  • Соблюдение границ обеспечивается агентами мониторинга – система работает только в рамках заданных правил.

Вместе они образуют конструкцию, где автономия не означает анархию, а интеллект формирует не «чеерный ящик».

6. Взаимодействие агентов в бизнес-процессах: пошаговая схема

Чтобы увидеть архитектуру в действии, давайте разберем ее на примере классического бизнес-процесса ERP «от заявки до оплаты» (procure-to-pay). Мы проследим, как разные агенты взаимодействуют друг с другом, используя общий семантический слой данных. Фокус будет сделан на логике их работы и обмене смыслами, а не на технических деталях интеграции.

ERP.Next: Архитектура автономных ERP на основе мультиагентного ИИ - 3

Шаг 1: Все начинается с сигнала от события отслеживания спроса. Это может быть всплеск онлайн-продаж, сработавший триггер мониторинга, или новый прогноз от агента планирования. Это событие фиксируется в USDL как семантическое наблюдение: не просто «продажи выросли», а «продажи продукта X в регионе Y превысили прогноз на Z%».

Эту запись «видит» агент-эксперт по управлению запасами. Он обращается к онтологии USDL, чтобы проанализировать ситуацию: какие текущие остатки, какова статистика поставок, какие правила страхового запаса установлены.

Если анализ показывает риск дефицита, эксперт не просто сообщает об этом. Он формирует структурированную заявку на закупку для агента-оркестратора. В заявке четко указаны: что, сколько, как срочно нужно, в какие бюджетные рамки надо уложиться и каковы требования к качеству.

Шаг 2: Оркестрация закупки. Получив задание, агент-оркестратор начинает действовать по двум направлениям одновременно:

  1. Он вызывает агента-эксперта по закупкам (переговорщика) и ставит ему задачу найти лучшее предложение.

  2. Он параллельно запрашивает у агента финансовой сверки актуальный статус бюджета для понимания сколько можно тратить.

Агент-переговорщик, в свою очередь, не лезет на порталы поставщиков сам. Он обращается к специальным шлюзам из интеграционной сети. Каждый такой шлюз-переводчик обращается к API поставщика и преобразует  ответ в структурированные данные на языке USDL: цена, срок, условия доставки.

Предложения приходят асинхронно. Когда они собраны, агент-переговорщик проводит комплексную оценку. Он сравнивает не только цену и срок, но иисторическую надежность поставщика (из графа знаний USDL) и текущие геополитические риски в регионе поставщика. Эти индикаторы система получает через интеграционную сеть из внешних источников.

На выходе получается ранжированный список вариантов, где у каждого есть не только цена, но и оценка достоверности и общего риска. Например: «Поставщик А: цена 9 тыс. руб, срок 14 дней, общая оценка (score) 87/100. Примечание: в регионе действуют штормовые предупреждения, что может повлиять на логистику». 

Шаг 3: Переговоры, проверка и эскалация. На этом этапе система действует как опытный закупщик. Если первичные предложения поставщиков не укладываются в заданные рамки (цена, срок), агент-переговорщик запускает протокол переговоров через коммуникационную среду AMAP делает встречное предложение или запрашивает частичную поставку. Все эти диалоги записываются в USDL как неизменяемый аудиторский след.

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

  1. Авто-утверждение: если сумма в рамках полномочий, он дает автоматическое добро.

  2. Эскалация человеку: если сумма превышает порог, он передает кейс интерфейсному агенту.

Подготовка решения для человека. Интерфейсный агент не просто говорит пользователю «утверди или отклони». Он готовит полное досье для принятия решения, куда входят:

  • Все рассмотренные варианты поставщиков с их оценками.

  • Прогнозы уровня сервиса (когда товар будет у клиента).

  • Сценарии рисков, смоделированные обучающимся агентом в песочнице («Что, если выбранный поставщик сорвет сроки? Какие будут потери?»).

Пользователь получает не вопрос, а информационно насыщенную рекомендацию с обоснованием для принятия решения.

Шаг 4: Исполнение и последующий контроль. Как только решение принято (автоматически или человеком), процесс переходит в фазу исполнения.

Оркестрация исполнения.
Агент-оркестратор отдает команды шлюзовым агентам в интеграционном слое. Те, в свою очередь:

  1. Формируют и отправляют заказ на закупку выбранному поставщику через его API.

  2. Планируют операцию приемки в модуле управления запасами, создавая задачи для склада на определенную дату.

Мониторинг и сверка (пост-операционный контроль).
После отправки заказа в работу вступают агенты мониторинга. Они:

  1. Контролируют статус исполнения, отслеживая подтверждения от поставщика и обновления в транспортных системах.

  2. После физического поступления товара сверяют фактические поставленные количества с заказанными.

  3. На основе данных о приемке автоматически инициируют процесс финансовой сверки, передавая в агента финансовой сверки данные для сопоставления будущего счета-фактуры с заказом.

На этом этапе система перестает быть инициатором и становится гарантом целостности. Она следит, чтобы реальность соответствовала плану, а финансовая отчетность была корректной.

Фоновая работа в части обучения и контроля. 

Параллельно основному процессу в системе непрерывно работают два важнейших механизма, обеспечивающих ее развитие и безопасность.

1. Непрерывное обучение (Обучающиеся агенты).
Пока основной сценарий выполняется, обучающиеся агенты в фоновом режиме:

  • Запускают симуляции в песочнице. Что, если выбранный поставщик сорвет сроки? Какой альтернативный план будет оптимальным? Эти симуляции готовят систему к нештатным ситуациям.

  • Обновляют модели на основе новых исходов. Как только закупка завершается (успешно или нет), ее данные используются для дообучения прогнозных моделей (спроса, сроков поставки). Система становится умнее после каждой операции.

2. Постоянный надзор (Слой Управления).
Над всеми действиями агентов следит слой управления. Он в режиме реального времени:

  • Обеспечивает соблюдение жестких политик. Следит за разделением ответственности (чтобы один человек не мог все утвердить), бюджетными лимитами, ограничениями на долю одного поставщика.

  • Выдает предупреждения при отклонениях. Если какой-либо агент пытается действовать вне установленных рамок, слой управления немедленно сигнализирует об этом, предотвращая потенциальные риски или нарушения.

Таким образом, система не только решает текущую задачу, но и готовится к будущим сбоям и гарантирует свою законопослушность на каждом шагу.

Этот пример наглядно показывает, как предложенная архитектура превращает жесткий, линейный процесс в живую, интеллектуальную систему. Все работает благодаря слаженной комбинации:

  • Семантической согласованности (USDL) – единому языку для всех.

  • Специализированным рассуждениям (Эксперты) – глубоким знаниям в каждой области.

  • Гибкой координации (Оркестраторы) – управлению сложными сценариями.

  • Человеческому контролю (Интерфейсные агенты) – возможности вмешательства там, где это нужно.

  • Постоянной адаптации (Обучающиеся агенты) – способности учиться на каждом действии.

  • Полной аудируемости (Агенты мониторинга) – гарантии прозрачности и соответствия правилам.

В результате мы получаем процесс, который автономен в рутине, подотчетен в критических точках и адаптивен к изменениям. Это и есть суть ERP нового поколения.

7. Внедрение, эксплуатация и поэтапная адаптация

Проектирование такой системы на практике требует как технологических, так и организационных усилий. 

Технический стек и архитектура

  • Микросервисы и контейнеры. Платформа AMAP идеально ложится на микросервисную архитектуру. Отдельные агенты и сервисы живут в контейнерах, что дает изоляцию, масштабируемость и гибкость в выборе технологий.

  • Гибридная модель данных для USDL. Ключевой выбор — графовая база для онтологий и связей плюс высокопроизводительное хранилище временных рядов для телеметрии и транзакций. Нужно искать баланс между выразительностью запросов и операционной скоростью.

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

  1. Фаза 1: Зеркалирование. Оборачиваем существующие системы шлюзами, которые дублируют все транзакции в USDL. Система пока только «наблюдает» и строит семантическую картину.

  2. Фаза 2: Консультирование. Разворачиваем первых агентов-экспертов. Они не принимают решений, а лишь дают рекомендации («Я бы предложил закупить у поставщика Б»). Персонал привыкает к их советам и проверяет их точность.

  3. Фаза 3: Координация низкого риска. Запускаем оркестраторов для простых, некритичных процессов. Они координируют экспертов, но финальное действие все еще за человеком.

  4. Фаза 4: Исполнитель. Только после накопления статистики доверия и формального согласования, мы начинаем повышать уровень автономии агентов, делегируя им право на исполнение рутинных операций.

Этот поэтапный подход соответствует актуальному отраслевому опыту. Хотя агентские системы приносят существенную пользу, в отчетах 2025 аналитики прямо предупреждают: проекты с размытым объемом и слабым управлением проваливаются [1].

Прагматичные меры защиты:

  • Теневое развертывание (Shadow Mode). Агент работает параллельно с человеком, но его решения не применяются, а только логируются и сравниваются.

  • Канареечные развертывания. Постепенное «накатывание» новых возможностей на малой группе процессов или пользователей.

  • Всесторонний мониторинг. Инструменты, которые следят не только за техническими метриками, но и за логикой и последствиями решений агентов.

Организационные изменения
Для успешной реализации требуется создание кросс-функциональных команд:

  • Специалистов предметной области (бизнес-аналитиков) – они знают процессы.

  • Экспертов по данным и ML – они создают «мозг» агентов.

  • Системных инженеров и архитекторов – они строят платформу.

  • Сотрудников по рискам и комплаенсу – они встраивают управление и контроль с самого начала.

Создание онтологии USDL – это акт управления. Этот процесс заставляет бизнес формализовать свою семантику: что такое «надежный поставщик», что входит в «качество продукта». Это сложно, но дает бесценную ясность и основу для повторного использования.

И последний рубеж, стресс-тестирование интеллекта. Прежде чем давать агентам реальные полномочия, их нужно испытать в жестоких симуляциях: сбросами данных, враждебными сценариями, аномальными входными значениями. Система должна доказать свою устойчивость в виртуальной среде, прежде чем выйти в продуктив. 

8. Риски, ограничения и меры их снижения

Агентские ERP – мощный инструмент, но не панацея. Их внедрение сопряжено с реальными рисками, которые важно признавать и смягчать.

Технические риски:

  • Дрейф моделей. Модели агентов «стареют». Их точность падает, когда реальные данные уходят от тех, на которых их обучали.

  • Неизведанные сценарии. Агенты могут дать сбой в ситуациях, кардинально отличных от тех, что были в обучающей выборке.

  • Эмерджентное поведение. Непредсказуемые последствия от взаимодействия множества агентов и политик. Система в целом может вести себя не так, как ожидалось от каждого компонента в отдельности.

Организационные и экономические риски:

  • Слепая вера в «черный ящик». Люди начинают доверять решениям системы, не понимая, как они принимаются.

  • Вендорлок. Привязка к проприетарным платформам, разработчики агентов могут встраивать проприетарные абстракции

  • Сопротивление изменениям. Культурный барьер, когда сотрудники не готовы делегировать рутину ИИ.

Аналитика 2025 года также предупреждает о возможном «агентном отмывании», когда старую автоматизацию просто перемаркируют в «агентную» без реального добавления интеллекта и автономии. Окупаемость инвестиций часто оказывается ниже громких обещаний вендоров.

Решение: Архитектура, построенная на контроле. 

Именно для нейтрализации этих рисков предлагаемая архитектура изначально заточена на четыре ключевых принципа [6]:

  1. Сквозное управление (Governance). Жесткие политики и ограничения, встроенные в саму ткань системы.

  2. Объяснимость (Explainability). Не «агент решил», а «агент решил потому что…» с понятным человеку обоснованием.

  3. Поэтапная автономия (Incremental Autonomy). Никаких резких скачков от совета к действию, только постепенное делегирование полномочий по мере валидации.

  4. Полная аудируемость (Auditability). Неизменяемый журнал всех решений с приложенными контекстом и обоснованием.  

Только такая, изначально защищенная архитектура позволяет получить преимущества агентского подхода, не скатываясь в хаос непредсказуемых рисков.

9. Современный отраслевой контекст (2024–2026)

Практическая значимость подхода ERP-систем, основанных на AMAP, подтверждается живыми трендами 2024–2025 годов:

  • Появились «агентские операционные системы» от крупных вендоров и консалтинговых компаний. Их цель – стать единой средой для агентов от разных поставщиков. Это прямое следствие потребности в интероперабельности. Миру нужны общие стандарты, чтобы разношерстные агенты могли «договариваться».

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

  • Фреймворки и инструментарий для создания агентов на основе больших языковых моделей (LLM) и их интеграции со структурированными данными стал доступен как никогда. Это открыло дорогу для более естественных интерфейсов и систем, способных понимать контекст.

В то же время отчеты аналитиков и авторитетные новостные агентства призывают к осторожности. Многие агентные инициативы не имеют доказанной ценности и требуют строгого контроля. 

Эти современные тенденции свидетельствуют о том, что, хотя архитектуры агентских ERP-систем становятся более осуществимыми и привлекательными, их успешное применение критически зависит от качественного проектирования и дисциплинированного управления [1–2, 4]. Будущее не за теми, кто быстрее внедрит агентов, а за теми, кто внедрит их правильно. 

10. Вместо заключения

Переход к агентной, семантической и управляемой ERP – это не эволюция, а смена парадигмы. Задача не в том,, чтобы сделать процессы быстрее, а о том, чтобы переосмыслить, как бизнес достигает целей.

Фундаментом для этого служат две основы: семантический слой данных (USDL) как единый источник смысла и продвинутая мультиагентная платформа (AMAP) как среда для распределенного интеллекта. Вместе они позволяют создавать системы с проверяемым и аудируемым «логическим мышлением».

Представленная архитектура делает это мышление структурированным и безопасным. Она разделяет ответственность между разными типами агентов – экспертами, оркестраторами, тренерами, интерфейсами и надзирателями. И показывает, как они взаимодействуют в реальных бизнес-процессах.

Начинать можно с рекомендаций, симуляций и низкорисковых сценариев.. Это позволит постепенно накапливать доверие и получать понятную ценность на каждом этапе, а не ждать окупаемости годами. 

Тренды 2025 года дают нам и уверенность, и предостережение. Технологии созрели, но успех будет не у тех, кто внедрит их быстрее, а у тех, кто сделает это осознанно и дисциплинированно. 

При условии строгого управления и технической дисциплины, мультиагентные архитектуры открывают надежный путь к созданию ERP нового поколения — систем, которые не просто «фиксируют» и «считают», а понимают, решают, учатся и заслуживают доверия.

Поделитесь мнением,  на сколько такое развитие  ERP актуально в современных реалиях?


Список литературы (выборочно, с акцентом на 2024–2025 гг.) 

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

Перевод списка литературы:

  1. Reuters. “Over 40% of agentic AI projects will be scrapped by 2027, Gartner says.” Reuters, 25 June 2025.

  2. Business Insider. “PwC launches a new platform to help AI agents work together.” Business Insider, 2025.

  3. Orq.ai blog. “LLM Agents in 2025: Definition, Use Cases, & Tools.” 17 June 2025.

  4. Semantic Arts. “The Year of the Knowledge Graph (2025).” 18 June 2025.

  5. Medium / Timbr.ai. “The Next Evolution of RAG: How Knowledge Graphs Give AI Real Understanding.” 2025.

  6. Adopt.ai blog. “The Top 6 Enterprise-Grade Agent Builder Platforms in 2025.” 2025.

Автор: BorisVolpe

Источник

Rambler's Top100