Мультиагентная система выглядит привлекательно на демо: несколько ИИ-агентов делят задачу, спорят, согласуют ответ. В продакшене всё ломается не на агентах, а на стыках – там, где агент дёргает учётную систему, ходит в реестр, пишет в очередь или вызывает соседнего агента. Этот стык и есть интеграционный слой. Без него у вас не система, а набор промптов, которые никто не контролирует. Ниже – из чего складывается заказная разработка интеграционного слоя для бизнеса и госсектора.

Слой как контракт, а не как клей

Соблазн велик: дать агенту прямой доступ к API учётной системы и пусть сам разбирается. Так делать нельзя. Агент недетерминирован – он переформулирует вызов, придумает несуществующее поле, повторит транзакцию дважды. Интеграционный слой выступает посредником с жёстким контрактом: фиксированный набор инструментов, строгая схема входа и выхода, валидация на каждом вызове.

Каждый инструмент – это не «обёртка над API», а отдельный продукт со своим SLA, версионированием и владельцем. Здесь напрямую работает подход «данные как продукт»: агент потребляет не сырую таблицу, а проверенный контракт, за который кто-то отвечает. Тогда смена бэкенда не ломает поведение агента, а ошибочный вызов отсекается на границе слоя, а не уходит в боевую базу.

Оркестрация, идемпотентность, откат

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

Три инженерных требования, без которых слой не выпускают в прод:

  • Идемпотентность. Каждый вызывающий запрос несёт ключ, повтор не создаёт второй платёж или второе обращение.
  • Компенсирующие транзакции. Если цепочка из пяти шагов упала на четвёртом, слой откатывает предыдущие – паттерн saga, а не «надеемся, что не упадёт».
  • Бюджеты и предохранители. Лимит на стоимость, длину цепочки и число итераций. Агент, ушедший в рекурсию, останавливается принудительно.

Качество ответов агента зависит и от того, как он получает знания. Выбор между дообучением модели и подключением через поиск мы разбирали в материале про finetuning против RAG; для интеграционного слоя RAG почти всегда удобнее – источник остаётся снаружи, под контролем владельца данных и с актуальной версией.

Безопасность и аудит по умолчанию

Агент действует от чьего-то имени, поэтому каждый вызов несёт контекст идентичности и проверяется на права. Разрешения мы выдаём не агенту вообще, а конкретному инструменту в конкретной задаче – минимальные привилегии, а не «доступ ко всему на всякий случай».

Для госсектора отдельный пласт – прослеживаемость и размещение в защищённом контуре. Каждое решение агента логируется так, чтобы его можно было воспроизвести и объяснить проверяющему: какой промпт, какие данные, какой инструмент, какой результат. Требования к ИИ в государственных системах мы подробно разбирали в статье про ИИ в ГИС и приказ 117 – для мультиагентных систем они применяются в полном объёме, потому что цена ошибки умножается на число агентов.

Вывод

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