Привет! Меня зовут Егор Козлов, я работаю NLP-инженером в red_mad_robot. Мы активно внедряем в бизнес AI-агентов — автономных и полуавтономных программных сущностей, которые самостоятельно выполняют задачи и принимают решения в интересах бизнеса.
В статье расскажу о принципах работы AI-агентов — с особым вниманием к workflow-агентам и мультиагентным системам (MAS). И поделюсь практическим кейсом внедрения мультиагентной среды для автоматического анализа и исправления уязвимостей в коде.
AI-агент — это самостоятельная программная система, которая выполняет поставленные ей задачи, взаимодействует с внешней средой, принимает решения, адаптируется к изменениям ситуации — зачастую без постоянного контроля человека. Агенты действуют независимо, хоть и от вашего имени.
Ключевые характеристики:
самостоятельное принятие решений — от ограниченного до полного, в зависимости от уровня автономности;
динамическое управление процессами — адаптация по ходу выполнения задачи;
работа с разными инструментами — интеграция с другими системами и агентами;
сохранение контекста в памяти — для лучшего выполнения последующих задач;
ограничения и безопасность — соблюдение законов и правил;
инициирование действий — взаимодействие с внешней средой в качестве актора.
Многие разработки формально называют себя агентами, хотя они не обладают ключевыми агентными характеристиками. Настоящий AI-агент не просто реагирует на команды и выполняет запрограммированные действия — он способен анализировать, адаптировать, принимать решения и инициировать действия. Если система ограничена лишь пассивным выполнением последовательности инструкций без самостоятельности, гибкости и памяти о предыдущих шагах, она не является полноценным агентом.
Агентные системы можно условно разделить на три класса по степени автономности и гибкости.
Базовая LLM-система — выполняет ограниченный набор задач, например, генерирует текст и отвечает на вопросы.
Workflow-агент — координирует сложные бизнес-процессы по заданному алгоритму, частично адаптируясь к изменениям.
Автономный агент — самостоятельно планирует и корректирует выполнение задач, выбирая методы и инструменты на основе анализа контекста — с минимальным вовлечением человека в принятие решений.
Система для выполнения строго определённых задач, чаще всего, в рамках одного сервиса: генерации ответов на запросы, краткого резюме текста или классификации сообщений. Инструментальная база ограничена: модель практически не использует внешние сервисы, плагины или интеграции — она оперирует только собственными языковыми возможностями, без доступа к интернету, базам данных или сторонним API.
Для корректной настройки и работы LLM нужен контроль человека — чтобы составлять промпты, проверять результаты, выбирать входные данные. Реализация происходит через простые вызовы LLM по API.
Чаще всего базовые системы в виде чат-ботов можно встретить на сайтах интернет-магазинов. Там чат-бот отвечает на регулярные вопросы покупателей, используя заданные промпты и сценарии. А если вопрос выходит за рамки готовых шаблонов или требует дополнительной информации, бот перенаправляет пользователя к оператору.
Более сложная система, в которой LLM выполняет задачи по заранее заданному сценарию с чётко прописанными шагами и условиями. Инструменты для вызова API или обработки данных определены разработчиками и применяются в установленном порядке. На ключевых этапах или при возникновении нестандартной ситуации предусмотрено вмешательство человека.
Workflow-агенты предназначены для автоматизации сложных, но структурированных и последовательных бизнес-процессов, например, обработки обращений на возврат товаров или проверки информации из входящих заявок покупателей. Гибкая архитектура позволяет легко интегрировать агентов с внешними сервисами и программными платформами, оптимизируя повторяемые процессы в бизнесе.
В программной реализации это выглядит как фиксированная цепочка действий с ветвлениями на основе ответа модели или статуса данных. По сравнению с базовыми LLM-системами такой подход более гибкий, но требует тщательного проектирования сценариев. Средняя сложность реализации логично сопровождается средними затратами и задержками.
В отличие от workflow-агента, который работает по заданному сценарию с определённым набором инструментов, автономный агент использует любые инструменты из обширной библиотеки, динамически выбирая нужные в зависимости от ситуации и контекста задачи.
Вмешательство человека требуется только в редких случаях крайней необходимости или при критических ошибках, к примеру, для преодоления этических ограничений или подтверждения доступа к конфиденциальным данным.
Автономные агенты применяются для сложных и плохо формализуемых задач с множеством вариантов действий: создания программного кода, автоматизации исследовательской работы, например, сбора и анализа данных из разных источников и формулирования гипотез. Такой тип агентов позволяет эффективно работать там, где возможны изменения условий, нестандартные ситуации или отсутствие чётких алгоритмов решения.
Пример технической реализации автономных агентов — «reasoning loop» — циклы планирования, действий и оценки результатов. Они требуют построения сложных управляющих систем: продуманного взаимодействия между моделями, инструментами и управляющей логикой, включая обработку ошибок и непредвиденных ситуаций.
Реализация таких агентов значительно дороже по сравнению с базовыми и workflow-решениями, а задержки в работе могут возрастать из-за необходимости многократных итераций и взаимодействия с разными источниками данных.
В реальных бизнес-сценариях и исследовательских задачах чаще всего применяют не отдельных агентов, а multi-agent systems (MAS), где несколько агентов — базовых, workflow или автономных — взаимодействуют между собой для комплексного решения задач. Вместе эта сумма агентов, хотя каждый из них отвечает за отдельную область, согласованно выполняют сложные процессы: обмениваются данными, распределяют задачи, проверяют и оптимизируют решения друг друга.
Архитектура MAS может масштабироваться под любые требования бизнеса. Можно наращивать функции, добавлять новых агентов или изменять их роли без перестройки всей архитектуры. Самостоятельное взаимодействие агентов, разделение задач между ними и согласованность действий существенно повышают устойчивость и адаптивность системы в условиях возрастающей сложности бизнес-процессов.
Пример архитектурных подходов для построения мультиагентной системы из workflow-агентов. Здесь каждый агент выполняет свою роль, а взаимодействие между ними происходит по стандартизированным протоколам обмена сообщениями.
Prompt chaining / pipeline — построение цепочек вызовов LLM для пошаговой обработки запроса;
Routing — маршрутизация запросов между агентами или модулями LLM;
Parallelization — одновременная работа агентов над параллельными задачами с последующей консолидацией полученной информации;
Orchestrator — центральное управление потоками данных и объединением действий агентов в единую бизнес-логику;
Evaluator-optimizer — дополнительный агент, проверяющий и совершенствующий решения других агентов на основе анализа качества и обратной связи.
Сейчас при построении мультиагентных систем важную роль играет context engineering — он помогает агентам использовать знания всей системы, а не только собственные данные. Правильная организация контекста включает подбор данных, хранение истории, реальное время обновления информации и продвинутые методы поиска и фильтрации данных. Осознанная работа с контекстом помогает уменьшить ошибки и издержки — когда агенты опираются на актуальные и согласованные данные, система начинает работать не интуитивно, а как управляемый бизнес-инструмент.
Мультиагентные системы сочетают структурированность workflow-агентов с адаптивностью автономных агентов, позволяя эффективно решать задачи разной степени сложности. Лучшей иллюстрацией этого будет практический кейс применения MAS к сложной, многоуровневой задаче, например, поиску и исправлению уязвимостей в коде.
Static Application Security Testing (SAST) — статический анализ исходного кода — один из ключевых методов выявления уязвимостей на этапе разработки. Однако ручная проверка многочисленных предупреждений SAST создаёт дополнительную нагрузку на инженеров и специалистов по безопасности, особенно из-за большого числа ложных срабатываний.
В рамках совместного проекта red_mad_robot и СберТех была разработана мультиагентная система, которая автоматизирует обработку результатов SAST-анализа: классифицирует срабатывания, определяет, какие из них требуют исправления, формирует патчи и интегрируется с анализаторами, git-репозиториями и таск-трекерами.
Система решает три ключевые задачи:
автоматизирует анализ и классификацию срабатываний;
упрощает создание и внедрение исправлений (патчей) — с минимальным участием разработчиков;
эффективно обрабатывает большой объём контекста и связей в коде.
Например, в функции анализатор указывает на потенциальное опасное обращение к полям объекта, который может быть nil.
func Update(pod *Pod) {
_ = pod.Spec.Affinity // опасно, если pod == nil!
}
Если ранее разработчику приходилось самостоятельно анализировать и исправлять такую уязвимость, теперь система автоматически предлагает корректное решение — например, добавляет ранний выход из функции.
func Update(pod *Pod) {
if pod == nil { return }
_ = pod.Spec.Affinity // теперь безопасно
}
В результате мультиагентная система снижает нагрузку на команду инженеров и ускоряет создание безопасного кода.
Через единый протокол Agent2Agent (A2A) в системе действуют три агента, управляемые оркестратором:
Сборщик контекста — взаимодействует с кодовой базой, анализирует срабатывания и собирает фрагменты кода, необходимые для классификации и создания патча;
Классификатор — анализирует срабатывания SAST-инструментов Svace и PT AI, определяя ложно-положительные (False Positive) и истинно-положительные (True Positive) и передаёт результаты на ревью;
Патчер — на основе классификации автоматически формирует патчи для истинно-положительных срабатываний, чтобы внести изменения в исходный код через merge request репозиторий;
Оркестратор — управляет задачами и распределяет их между агентами.
Внутри каждого агента работают отдельные подагенты: они строят план действий, принимают решения голосованием и формируют комментарии для разработчиков.
Для решения задачи мы использовали две LLM:
Qwen3-Coder-30B-A3B-Instruct — для написания кода по заданию. Патч может состоять из одной-двух строк или представлять собой целый метод — грамотно собранный кодовый контекст помогает лучше понимать структуру программы и причинно-следственную связь между участками кода, и так создавать более качественные патчи.
QwQ-32B — для классификации найденных уязвимостей и формирования плана по их устранению.
Важно отметить, что задача устранения уязвимостей (написания патчей) с точки зрения кибербезопасности — это в первую очередь комплексный анализ исходного кода, поэтому для достижения лучшего качества необходимо использовать reasoning модель.
В нашем решении исходный код анализируется как граф, где учитываются связи и зависимости между элементами программы. Для эффективной генерации исправлений с помощью LLM важно тщательно готовить контекст: модель получает информацию не только о месте уязвимости, но и о связанных участках кода, чтобы предлагать релевантные патчи.
Call Graph — управление контекстом кода как графом
Эффективно извлекает нужные части контекста без перегрузки анализатора. В реальности репозитории с кодом могут содержать огромное количество взаимосвязей. Например, в репозитории k8s более 600 тыс. узлов и 800 тыс. взаимосвязей, что затрудняет поиск необходимого контекста для устранения уязвимостей.
Control Flow Graph (CFG) — для локального анализа кода
Устраняет избыточные ветвления в исходном коде и минимизирует лишний контекст, который может «запутать» LLM. Работа с большими функциями упрощается за счёт выделения линейных маршрутов исполнения — «фокус внимания LLM» сосредоточен только на тех участках кода, которые ведут к уязвимости.
Благодаря автоматической обработке всех срабатываний SAST-анализатора значительно уменьшается объём ручной работы — типичный отчёт может содержать тысячи предупреждений, каждое из которых требует индивидуальной проверки, отнимая время и внимание разработчиков. Построенная MAS снимает с команды эту рутинную нагрузку, выводя на ручную проверку лишь ограниченное число случаев.
Система показала высокую точность: в тестах на примере большого репозитория k8s удалось достичь 70% правильной классификации уязвимостей и 50% успешных автоматических исправлений без дополнительной правки разработчиками. Для удобства разработчиков реализована интеграция с SAST-анализаторами Svace и PT AI — в них инженеры просматривают рекомендации MAS, утверждают или отклоняют её решения, что ускоряет работу над безопасностью.
Использование MAS повышает скорость и качество разработки, и выводит безопасность кода на новый уровень. Результаты подтверждают высокий потенциал agent-based решений в реальных задачах и открывают широкие перспективы для дальнейшего развития и интеграции технологии в бизнес-процессы.
Над материалом работали
Текст — Егор Козлов
Редактура — Игорь Решетников
Иллюстрации — Юля Ефимова
Это блог red_mad_robot. Мы запускаем цифровые бизнесы и помогаем компаниям внедрять AI. Здесь наша команда разработки на собственных кейсах рассказывает о том, что происходит с AI сегодня, а стратегические аналитики подсказывают, что будет завтра. Мы бы подписались.
Наш Telegram-канал (там всё другое, а ещё есть анонсы мероприятий): t.me/redmadnews