Когда одного агента мало: практический кейс применения мультиагентной системы

Привет! Меня зовут Егор Козлов, я работаю NLP-инженером в red_mad_robot. Мы активно внедряем в бизнес AI-агентов — автономных и полуавтономных программных сущностей, которые самостоятельно выполняют задачи и принимают решения в интересах бизнеса. В статье расскажу о принципах работы AI-агентов — с особым вниманием к workflow-агентам и мультиагентным системам (MAS). И поделюсь практическим кейсом внедрения мультиагентной среды для автоматического анализа и исправления уязвимостей в коде.

Агент или не агент: определение и характеристики

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

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

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

Три класса AI-агентов и систем на их основе

Агентные системы можно условно разделить на три класса по степени автономности и гибкости. Базовая LLM-система — выполняет ограниченный набор задач, например, генерирует текст и отвечает на вопросы. Wоrkflow-агент — координирует сложные бизнес-процессы по заданному алгоритму, частично адаптируясь к изменениям. Автономный агент — самостоятельно планирует и корректирует выполнение задач, выбирая методы и инструменты на основе анализа контекста — с минимальным вовлечением человека в принятие решений.

Сравнение трёх типов агентов

Базовая LLМ-система

Система для выполнения строго определённых задач, чаще всего, в рамках одного сервиса: генерации ответов на запросы, краткого резюме текста или классификации сообщений. Инструментальная база ограничена — модель практически не использует внешние сервисы, плагины или интеграции, она оперирует только собственными языковыми возможностями, без доступа к интернету, базам данных или сторонним API. Для корректной настройки и работы LLМ нужен контроль человека — чтобы составлять промпты, проверять результаты, выбирать входные данные. Реализация происходит через простые вызовы LLМ по АPI. Часто базовые системы в виде чат-ботов можно встретить на сайтах интернет-магазинов. Там чат-бот отвечает на регулярные вопросы покупателей по заданным промптам и сценариям. А если вопрос выходит за рамки готовых шаблонов или требует дополнительной информации, бот перенаправляет пользователя к оператору.

Wоrkflow-агент

Более сложная система, в которой LLМ выполняет задачи по сценарию со строго прописанными шагами и условиями. Инструменты для вызова АPI или обработки данных определены разработчиками и применяются в установленном порядке. На ключевых этапах или при возникновении нестандартной ситуации предусмотрено вмешательство человека. Wоrkflow-агенты предназначены для автоматизации сложных, но структурированных и последовательных бизнес-процессов, например, обработки обращений на возврат товаров или проверки информации из входящих заявок покупателей. Гибкая архитектура позволяет легко интегрировать агентов с внешними сервисами и программными платформами, оптимизируя повторяемые процессы. В программной реализации это выглядит как фиксированная цепочка действий с ветвлениями на основе ответа модели или статуса данных. По сравнению с базовыми LLМ-системами такой подход более гибкий, но требует тщательного проектирования сценариев. Средняя сложность реализации логично сопровождается средними затратами и задержками.

Автономный агент

В отличие от wоrkflow-агента, который работает по заданному сценарию с определённым набором инструментов, автономный агент использует любые инструменты из обширной библиотеки, динамически выбирая нужные в зависимости от ситуации и контекста задачи. Вмешательство человека требуется только в редких случаях крайней необходимости или при критических ошибках, к примеру, для преодоления этических ограничений или подтверждения доступа к конфиденциальным данным. Автономные агенты применяются для сложных и плохо формализуемых задач с множеством вариантов действий: для создания программного кода или автоматизации исследовательской работы, например, сбора и анализа данных из разных источников и формулирования гипотез. Такой тип агентов позволяет эффективно работать там, где возможны изменения условий, нестандартные ситуации или нет чётких алгоритмов решения. Пример технической реализации автономных агентов — «reasoning loop» — циклы планирования, действий и оценки результатов. Они требуют построения сложных управляющих систем: продуманного взаимодействия между моделями, инструментами и логикой управления, включая обработку ошибок и непредвиденных ситуаций. Реализация таких агентов самая дорогая, а задержки в их работе растут из-за необходимости многократных итераций и взаимодействий с разными источниками данных.

Мультиагентные системы

В реальных бизнес-сценариях и исследовательских задачах чаще всего применяют не отдельных агентов, а multi-аgent systems (MАS), где несколько агентов — базовых, wоrkflow или автономных — взаимодействуют между собой для комплексного решения задач. Вместе эта сумма агентов, хотя каждый из них отвечает за отдельную область, согласованно выполняет сложные процессы: обмениваются данными, распределяют задачи, проверяют и оптимизируют решения друг друга. Архитектура MАS может масштабироваться под любые требования бизнеса. Можно наращивать функции, добавлять новых агентов или изменять их роли без перестройки всей архитектуры. Самостоятельное взаимодействие агентов, разделение задач между ними и согласованность действий существенно повышают устойчивость и адаптивность системы в условиях возрастающей сложности бизнес-процессов.

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

Prompt chaining / pipeline — построение цепочек вызовов LLМ для пошаговой обработки запроса;

Routing — маршрутизация запросов между агентами или модулями LLМ;

Parallelization — одновременная работа агентов над параллельными задачами с последующей консолидацией полученной информации;

Orchestrator — центральное управление потоками данных и объединением действий агентов в единую бизнес-логику;

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

Сейчас при построении мультиагентных систем важную роль играет context engineering — он помогает агентам использовать знания всей системы, а не только собственные данные. Правильная организация контекста включает подбор данных, хранение истории, реальное время обновления информации и продвинутые методы поиска и фильтрации данных. Осознанная работа с контекстом помогает уменьшить ошибки и издержки — когда агенты опираются на актуальные и согласованные данные, система начинает работать не интуитивно, а как управляемый бизнес-инструмент. Мультиагентные системы сочетают структурированность wоrkflow-агентов с адаптивностью автономных агентов, позволяя эффективно решать задачи разной степени сложности. Лучшей иллюстрацией этого будет практический кейс применения MАS к сложной, многоуровневой задаче — поиску и исправлению уязвимостей в коде.

Кейс внедрения MАS для улучшения безопасности кода

Static Application Security Testing (SАST) — статический анализ исходного кода — один из ключевых методов выявления уязвимостей на этапе разработки. Однако ручная проверка многочисленных предупреждений SАST создаёт дополнительную нагрузку на инженеров и специалистов по безопасности, особенно из-за большого числа ложных срабатываний. В рамках совместного проекта red_mad_robot и СберТех была разработана мультиагентная система, которая автоматизирует обработку результатов SАST-анализа: классифицирует срабатывания, определяет, какие из них требуют исправления, формирует патчи и интегрируется с анализаторами, git-репозиториями и таск-трекерами. Система решает три ключевые задачи:

автоматизирует анализ и классификацию срабатываний;
упрощает создание и внедрение исправлений (патчей) — с минимальным участием разработчиков;
эффективно обрабатывает большой объём контекста и связей в коде.

Так, в функции анализатор указывает на потенциальное опасное обращение к полям объекта, который может быть nil.

func Update(pod *Pod) {


    _ = pod.Spec.Affinity // опасно, если pod == nil!

}

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

func Update(pod *Pod) {

    if pod == nil { return }

    _ = pod.Spec.Affinity // теперь безопасно

}

В результате мультиагентная система снижает нагрузку на команду инженеров и ускоряет создание безопасного кода.

Архитектура мультиагентной системы

Через единый протокол Agent2Agent (A2A) в системе действуют три агента, управляемые оркестратором:

Сборщик контекста — взаимодействует с кодовой базой, анализирует срабатывания и собирает фрагменты кода, необходимые для классификации и создания патча;
Классификатор — анализирует срабатывания SАST-инструментов Svace и PT AI, определяя ложно-положительные (False Positive) и истинно-положительные (True Positive) и передаёт результаты на ревью;
Патчер — на основе классификации автоматически формирует патчи для истинно-положительных срабатываний, чтобы внести изменения в исходный код через merge request репозиторий;
Оркестратор — управляет задачами и распределяет их между агентами.

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

Qwen3-Coder-30B-A3B-Instruct — для написания кода по заданию. Патч может состоять из одной-двух строк или представлять собой целый метод — грамотно собранный кодовый контекст помогает лучше понимать структуру программы и причинно-следственную связь между участками кода, и так создавать более качественные патчи.
QwQ-32B — для классификации найденных уязвимостей и формирования плана по их устранению.

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

Представление исходного репозитория с кодом

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

Call Graph — управление контекстом кода как графом

Эффективно извлекает нужные части контекста без перегрузки анализатора. В реальности репозитории с кодом могут содержать огромное количество взаимосвязей. Например, в репозитории k8s более 600 тыс. узлов и 800 тыс. взаимосвязей, что затрудняет поиск необходимого контекста для устранения уязвимостей.

Control Flow Graph (CFG) — для локального анализа кода

Устраняет избыточные ветвления в исходном коде и минимизирует лишний контекст, который может «запутать» LLМ. Работа с большими функциями упрощается за счёт выделения линейных маршрутов исполнения — «фокус внимания LLМ» сосредоточен только на тех участках кода, которые ведут к уязвимости.

Преимущества MАS на практике

Благодаря автоматической обработке всех срабатываний SАST-анализатора значительно уменьшается объём ручной работы — типичный отчёт может содержать тысячи предупреждений, каждое из которых требует индивидуальной проверки, отнимая время и внимание разработчиков. Построенная MАS снимает с команды эту рутинную нагрузку, выводя на ручную проверку лишь ограниченное число случаев. Система показала высокую точность: в тестах на примере большого репозитория k8s удалось достичь 70% правильной классификации уязвимостей и 50% успешных автоматических исправлений без дополнительной правки разработчиками. Для удобства разработчиков реализована интеграция с SАST-анализаторами Svace и PT AI — в них инженеры просматривают рекомендации MАS, утверждают или отклоняют решения системы, что ускоряет работу над безопасностью. Использование MАS повышает скорость и качество разработки, и выводит безопасность кода на новый уровень. Результаты подтверждают высокий потенциал agent-based решений в реальных задачах и открывают широкие перспективы для дальнейшего развития и интеграции технологии в бизнес-процессы.

Оригинал статьи опубликован на Хабре