AI-агент становится полезен Blue Team не тогда, когда модель один раз дала удачный ответ. Рабочая система должна помнить задачу, обращаться к нужным источникам, повторять заданный процесс и останавливаться там, где требуется решение специалиста.
На открытом воркшопе по сборке AI-агента для Blue Team эксперт покажет эту архитектуру на примере анализа уязвимости.
А здесь разберём, какую роль играет каждый компонент и почему один из них не заменяет остальные.
Начинать нужно с задачи, а не с модели
Перед выбором инструментов стоит описать рабочий результат. Для анализа CVE это может быть единообразная выжимка, в которой указаны затронутый продукт, условия атаки, критичность, сведения об эксплойте и рекомендации.
Такой результат сразу задаёт рамку архитектуры. Агенту нужно не просто написать текст по номеру уязвимости. Он должен пройти последовательность действий, сохранить ограничения, собрать данные, привести их к одной структуре и показать, какие пункты требуют проверки.
Полезно сформулировать четыре вопроса до сборки:
- что агент получает на входе;
- какой результат должен вернуть;
- к каким источникам и инструментам может обращаться;
- где он обязан остановиться и передать решение человеку.
Если ответов нет, дополнительные компоненты лишь усложнят систему. Память начнёт хранить случайные сведения, MCP подключит источники без понятного порядка работы, а субагенты разделят плохо определённую задачу на такие же плохо определённые части.
Контекст удерживает цель и ограничения
Контекст отвечает за условия, которые нельзя потерять по ходу работы. В нём живут цель анализа, требования к результату, ограничения и терминология. Благодаря этому агент сверяет каждый следующий шаг с исходной задачей, а не только с последним сообщением.
Для Blue Team это особенно важно в длинных сценариях. Агент может найти новые сведения и перестроить промежуточный план, но обязательные поля результата должны сохраниться. Если контекст не закреплён, к концу работы можно получить подробный рассказ об эксплуатации и не увидеть чёткого ответа о затронутом продукте или условиях атаки.
Хороший контекст не обязан быть длинным. Он должен однозначно отвечать на вопросы: что исследуем, что считаем готовым результатом и какие действия недопустимы.
Память избавляет от повторных объяснений
Контекст удерживает правила текущей задачи, а память переносит полезные факты и настройки между запусками. Она нужна там, где специалист не хочет каждый раз заново объяснять формат выжимки или постоянные требования к работе.
При этом память не должна превращаться в архив всех прошлых ответов. Для повторного использования подходят устойчивые правила и проверенные факты. Промежуточные гипотезы конкретного анализа лучше оставлять внутри текущего процесса. Иначе старые данные могут начать влиять на новую задачу.
Практический критерий прост: в память стоит помещать то, что должно оставаться верным при следующем запуске с другой CVE.
Скилл превращает инструкцию в повторяемый маршрут
Скилл задаёт порядок действий. Он определяет, что собирать, в какой последовательности, когда вызывать инструменты и как проверять итог. Именно скилл превращает разовый диалог с моделью в процесс, который можно снова запустить по номеру уязвимости.
В сценарии анализа CVE скилл может вести агента по маршруту:
- определить продукт и затронутые версии;
- выяснить условия атаки;
- собрать сведения о критичности;
- проверить наличие данных об эксплуатации;
- подготовить рекомендации;
- собрать единообразную выжимку;
- отметить пункты, которые должен подтвердить специалист.
На воркшопе одну задачу сначала передадут базовому агенту, а затем повторят через собранный скилл. Сравнение покажет, каких сведений не хватает в первом ответе и что приходится уточнять вручную.
MCP подключает данные и инструменты
Скилл описывает маршрут, но сам по себе не даёт агенту доступ к рабочим источникам. Эту связь обеспечивает MCP. Через него данные и инструменты подключаются к процессу, поэтому специалисту не приходится вручную переносить сведения в каждый запрос.
Важно разделять доступ и логику. MCP отвечает на вопрос, чем агент может воспользоваться. Скилл отвечает, когда это нужно сделать и какой результат получить. Подключение источника без правил работы с ним не делает анализ надёжнее.
Перед добавлением очередного инструмента полезно проверить три вещи:
- какое конкретное действие он закрывает;
- что агент должен извлечь из результата;
- как система поступит, если данных нет или они противоречат друг другу.
Так архитектура остаётся связанной с задачей, а не превращается в коллекцию интеграций.
Субагенты изолируют тяжёлые части работы
Субагенты нужны, когда отдельную часть исследования можно вынести в самостоятельный процесс. Один может собрать сведения о продукте, другой проверить данные об эксплуатации, а основной агент сохранит общую линию и соберёт результат.
Разделение полезно, если для каждой части заранее определён выходной формат. Основному агенту нужны не несколько свободных пересказов, а сопоставимые результаты, которые можно встроить в итоговую структуру.
Поэтому добавлять субагентов стоит после того, как описаны общий результат и маршрут. Иначе вместо ускорения команда получит больше промежуточных ответов, которые придётся сводить вручную.
Границы оставляют решение специалисту
Последний компонент архитектуры не связан с новой функцией модели. Это явная граница между тем, что можно передать агенту, и тем, что остаётся за человеком.
Агенту можно поручить сбор сведений, первичный анализ и подготовку структурированной выжимки. Специалист проверяет выводы, оценивает применимость рекомендаций и принимает решение о дальнейших действиях.
Эту границу лучше отражать в самом результате. Факты, выводы агента и пункты для ручной проверки должны различаться. Тогда автоматизация сокращает рутину, но не маскирует неопределённость уверенным текстом.
Как проверить собранную архитектуру
Рабочий агент оценивают не по числу подключённых компонентов. Важно, как они вместе решают исходную задачу.
Перед использованием проверьте:
- сохраняются ли цель и ограничения до конца процесса;
- переносит ли память только устойчивые правила;
- повторяет ли скилл один и тот же маршрут;
- подключает ли MCP только нужные источники и инструменты;
- возвращают ли субагенты результаты в заданном формате;
- видит ли специалист, где требуется его проверка;
- получается ли единообразная выжимка при разных входных данных.
Если убрать название конкретной модели, схема всё равно должна оставаться понятной. У неё есть вход, маршрут, доступные инструменты, состояние, формат результата и контрольные точки человека.
14 октября в 19:00 МСК Владислав Бурцев соберёт такую архитектуру и применит её к разбору одной уязвимости. На открытом воркшопе можно увидеть, как контекст, память, скиллы, MCP, субагенты и границы складываются в единый процесс для Blue Team.
