Что такое мультиагентная система?

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

Мультиагентная система не является универсально правильной архитектурой. Для простых, четко ограниченных задач один агент быстрее и дешевле. Система становится правильным выбором, когда задача слишком велика для одного контекстного окна, включает по-настоящему разные области знаний или выигрывает от параллельного выполнения.

Ключевое различие — в том, как эти два подхода работают с масштабом задачи и специализацией.

Одноагентная система использует один экземпляр LLM для восприятия, рассуждения и действия в рамках всей задачи целиком. Это работает хорошо, когда задача ограничена по объему. По мере роста масштаба у одного агента накапливаются конкурирующие приоритеты — проверка безопасности, стиль кода, покрытие тестами и архитектурные решения — все в рамках одной и той же сессии. Контекст из более ранних этапов начинает влиять на последующие решения, а способность агента глубоко проработать любую отдельную проблему снижается. Это ИИ-эквивалент проблемы "God object" в проектировании программного обеспечения.

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

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

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

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

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

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

Наиболее распространенный паттерн в продуктивных системах — на основе оркестратора:

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

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

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

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

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

Практический путь к мультиагентным системам редко начинается с осознанного архитектурного решения. Он начинается со скриптов, кодирующих поведенческие политики — как должны создаваться фичи, как должны распределяться изменения, как должны готовиться описания пул реквестов. Переход к мультиагентной архитектуре происходит по мере роста масштаба задач: универсальный агент начинает демонстрировать те же паттерны отказа, что и "God object" в проектировании ПО, и разделение зон ответственности становится естественным решением.

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

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

Код, сгенерированный ИИ, порождает уязвимости, которые возникают из-за постепенного дрейфа между коммитами и компонентами — невидимого при просмотре любого отдельного diff-а. Функция, которая отключает фильтрацию контроля доступа, путь запроса, который обходит границы проекта, логика аутентификации, которая дает сбой при враждебном вводе — ни одно из этого не выглядит как явный дефект в отдельном файле. Такие проблемы накапливаются постепенно.

Enji Fleet — это система непрерывного сканирования, построенная именно для решения этой проблемы. Она распределяет работу между специализированными агентами (Claude, Codex, Gemini, Kimi), каждый из которых выполняет задачи по выделенному ранбуку, кодирующему специфичный для проекта инвариант, а не общее правило. Каждая задача выполняется в изолированном контейнере воркера, отдельно от продуктивной инфраструктуры.

Ранбуки и Fleet покрывают:

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

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

Для команд, приближающихся к раунду привлечения инвестиций, риски, накопленные в кодовых базах, сгенерированных ИИ, обычно проявляются в самый неподходящий момент. Понимание того, что находит техническая комплексная проверка в проектах, написанных в стиле вайб кодинга, и как выглядит слой непрерывной санации кода, необходимо еще до прохождения раунда Series A.