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