Привет, Хабр. Девять лет я живу в мире управления уязвимостями, а не в центре мониторинга. Тревоги по работе не разбираю, плейбуки реагирования не пишу, справедливости ради конечно, я примерно 4 года назад занимался продуктом класса SIEM. И вот осенью я записался на соревнование, где надо было собрать ИИ-агента, который разбирает тревоги вместо аналитика первой линии.

Коллеги-организаторы уже рассказали про соревнование со своей стороны - вот их статья на Хабре. Там про замысел, формат и общие выводы по всем участникам. Я расскажу, как это выглядело изнутри у одного человека, который зашел в тему с нуля: с чего начинал, что пробовал, сколько гипотез проверил, где ошибался и почему одни решения сработали, а другие нет.

Итоги по лидербордам соревнований у меня вышли такие:

Общий открытый этап

Общий закрытый этап

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

Будет много технических деталей: как устроен граф сцены, как агент его обходит, как я выводил формулу оценки из данных и зачем в середине пути построил собственный офлайн-тренажер. Поехали.

Если в двух словах: агент получает тревогу - скажем, “подозрительный процесс на сервере” - и должен расследовать ее через API арены. На входе у него граф сцены. Это не текст лога, а именно граф: узлы (хосты, учетные записи, процессы, файлы, сетевые соединения, записи журналов, объекты Active Directory) и типизированные связи между ними - “процесс породил процесс”, “учетка вошла на узел”, “процесс записал файл”, “процесс подключился к адресу”.

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

В конце агент отправляет ответ:

• вердикт - malicious или benign;

• для вредоносной тревоги - меры реагирования с указанием, к какому объекту они относятся: какой узел изолировать (host_to_isolate), какую учетку сменить (identity_to_rotate), какой адрес заблокировать (network_block), какой файл удалить (file_to_delete), какое закрепление снять (persistence_to_remove), а что просто зафиксировать как наблюдение (process_observed, file_observed и так далее);

• для легитимной тревоги - улики легитимности: на каких объектах и полях держится вывод, что это штатная работа, а не атака.

Вот как выглядит разобранная вредоносная сцена и собранный по ней ответ - я нарисовал это по мотивам типовой задачи:

Граф сцены глазами агента

Красным тут восстановленная причинная цепочка (внешний узел - вход по RDP - служебный процесс - имплант-тревога - связь с управляющим сервером), пунктиром - связи, которые агент раскрыл поисками, а цифры показывают порядок обращений к арене. Внизу - сам ответ: вердикт и меры, каждая привязана к конкретному объекту.

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

Соревнование шло в несколько кругов. Сначала внутренний прогон внутри Positive Technologies - открытый этап (обратная связь видна) и закрытый (оценка скрыта). Потом общий, уже со внешними участниками, снова открытый и закрытый. Плюс отдельный набор задач от Standoff Defend и отдельная скоростная номинация. Для меня это растянулось почти на месяц.

Таймлайн четырех этапов

Первое мое сообщение напарнику-ИИ по этому проекту было буквально таким: “я не понимаю смысл этого, объясни мне”. Я открыл страницу соревнования, увидел “SOC-агент”, “арена”, “ключ доступа” - и честно не понял, что от меня хотят и с какой стороны подойти. Это важная деталь. Я заходил не как SOC-инженер, который точно знает, как разбирается тревога, а как продуктовый человек, которому надо сперва разобраться в правилах игры, а уже потом в самой игре.

Первые часы ушли вообще не на безопасность, а на быт: зарегистрироваться, получить ключ, понять, к какой языковой модели можно подключаться, поймать на сайте 502 от nginx и сообразить, что это не у меня сломалось, а у площадки. Нормальное начало любого соревнования - половину старта воюешь с инфраструктурой, а не с задачей.

Работал я не один. Со мной было два ИИ-напарника - Codex от OpenAI и Claude Code от Anthropic. И тут сразу признаюсь в методологической вещи, которая многих коробит: я относился к ним как к паре толковых инженеров-джунов, которым можно поручить руки, но нельзя доверить решения. Я ставил задачу, спорил, проверял, регулярно ловил их на том, что они уверенно несут чушь. Весь код арены-клиента, скрипты разбора, помощники по семействам - это диалог с ними. Я держал смысл и решения, они держали клавиатуру. Почему двое? У них разные сильные стороны

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

Открытый этап - подарок. Арена сразу отдает оценку: по каждому заданию видно качество, эффективность и отдельно награду за поиск - сколько впервые найденных эталонных объектов ты собрал. Фактически тебе прямо показывают, попал ли ты в эталон. В таких условиях задача из “угадай ответ” превращается в “подгони ответ под обратную связь”, и это ощущается почти как читерство.

Я быстро заметил, что сцены повторяются по семействам. Kerberoasting, сброс учетных данных из памяти, вынос данных через архиватор и выгрузку наружу, фишинг с макросом, поддельная служба обновления, релей NTLM - одни и те же сюжеты с разными именами узлов и учеток. Раз сюжеты повторяются, их можно узнавать и собирать ответ по шаблону. Мы с напарниками собрали конвейер: тревога приходит, скрипт по “отпечатку” сцены определяет семейство, добирает нужные объекты одним пакетом запросов, а я проверяю логику и отправляю.

Дальше началась чистая инженерная оптимизация, и по истории коммитов она читается как сводка забега. Прогон 10 - первые отпечатки семейств. Прогон 11 - 99,48% качества при эффективности 1,0 на всех заданиях. Прогон 12 - планировщик первого пакета, чтобы добор укладывался в бюджет. Прогоны 15-16 - разбор ролей объектов не в восемь обменов с моделью на задание, а в два; время задания упало с 11 минут до 9. И, наконец, прогон 17 - автодобор прямо внутри драйвера: 17 из 17 заданий, качество и эффективность 1,0, все за 4 минуты 50 секунд, медиана на задание около 13 секунд.

Я зафиксировал это релизом на GitHub с подписью “Hima_Hahahai: состояние 17/17”: 166 вызовов инструментов, Q=E=1,0. Всего до первого места ушло 17 прогонов.

Релиз на GitHub: состояние 17 из 17

Но самое интересное на этом этапе было не про скорость. Шаблон работает, пока семейство знакомое. А что делать, когда прилетает сцена, которой в отпечатках нет? Я сделал отдельный контур обучения: драйвер стал сохранять каждую новую задачу, появился режим разбора незнакомого сценария и журнал гипотез - одна гипотеза на сценарий за прогон, чтобы не путать, что именно повлияло на оценку. Этот контур дал приятный результат: на незнакомом легитимном сценарии удалось собрать верный состав улик - 15 из 15 - вообще без готовой карточки семейства, только по логике.

Конвейер разбора задания

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

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

Сразу пара структурных сюрпризов. Заданий стало меньше - не 17, а 13. Появилась составляющая Active Directory и отдельный инструмент справки по объектам каталога, которым я в первом прогоне не воспользовался ни разу, хотя в сценах лежали десятки идентификаторов AD. А главное - зачет устроен хитро: в одну таблицу идут первые три прогона по порядку, а не три лучших, плюс отдельно один прогон, который ты вручную выбираешь “в зачет” в кабинете. То есть первые три попытки нельзя тратить на эксперименты - а я, конечно, именно это и делал, пока не вчитался в правила.

Раз обратной связи нет, я сделал то, что казалось разумным: построил собственную метрику. Скрипт считал “качество” прогона по моим правилам, выведенным на открытом этапе - насколько полно исчерпана сцена, сколько объектов в ответе, уложился ли в бюджет. Карточки сценариев вели маршрут, бюджет брался из карточки. Прогон за прогоном моя шкала показывала рост: 801 балл, потом 891, потом 902 при всего 142 вызовах. Красота же. Я прогнал девять прогонов, каждый раз выбирая по своей шкале “лучший”, и отправил его в зачет.

Когда 21 сентября оценки раскрыли в кабинете, я получил, наверное, самый ценный урок всего соревнования.

Корреляция моей шкалы с реальной оценкой арены оказалась минус 0,873. Не слабая. Обратная. Пять прогонов, которые моя метрика назвала лучшими, оказались пятью худшими. В зачет по моему выбору ушел седьмой из девяти.

Моя метрика врала в обратную сторону

Разбор показал, почему так вышло. Оценка арены положительно коррелировала с числом вызовов (плюс 0,897) и отрицательно - с числом объектов в ответе (минус 0,698). Расшифровываю:

1. Лишние объекты на закрытом этапе штрафовались. Правило “арена платит за найденное, а лишнее не штрафует” я вывел на тренировочном архиве и перенес на зачет без проверки. На зачете оно не работало.

2. Экономия вызовов не улучшала результат, а ухудшала. Сокращая расход, я обеднял сцену, и потеря качества оказывалась больше выигрыша в эффективности.

Ошибка вышла двойной: конвейер и исследовал меньше, и клал в ответ больше лишнего. Каждая моя “оптимизация” уводила от верного состава, а шкала радостно показывала рост - потому что мерила ровно то, что я улучшал (исчерпанность собранной сцены и экономию шагов), а не попадание в эталон.

Обиднее всего, что я сам себя предупреждал. Еще до раскрытия у меня в заметках лежала мысль: правило, выведенное на тренировке, может перевернуться на зачете. Я записал это про одно конкретное правило - и не применил ни к собственной метрике, ни к правилу про лишние объекты. Четвертое место здесь я занял, по сути, вопреки методу.

После раскрытия я перестроил всю работу. Появился “свод правил зачетного этапа” с простым принципом: состав ответа выводится из логики событий (кто сделал, откуда пришел, на каком основании, в каких границах), а оценка нужна только чтобы присвоить правилу статус “подтверждено” или “спорно”. Если логичная улика стабильно идет против балла - я не ломаю логику под балл, а записываю это как особенность эталона. На прогонах с уже раскрытыми оценками это дало лучшие результаты (6,29, потом 6,38) - но, что важнее, дало метод, который переносится на новые сцены. Именно он потом вытащил меня в финале.

Через пару недель начался общий круг - уже с внешними участниками, на отдельной арене под названием False Positive. И как бы странно это не звучало, но я не собирался принимать участие в соревнованиях, уж сильно был завален работой. Акцент тут сместился: много задач, где подозрительное поведение на самом деле легитимно. Снятие дампа памяти группой реагирования. Остановка служб при плановом обновлении сертификатов. Теневые копии, которые делает не шифровальщик, а возврат базы на основную площадку. Название этапа говорит само за себя: цена ложной тревоги такая же, как цена пропущенной атаки.

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

Логика была такая. У меня накопились сотни, а потом и тысячи разобранных заданий, где известны и ответ, и балл. Значит, можно решить обратную задачу: подобрать, сколько стоит верный объект, сколько - верный вид меры, сколько снимают за лишний объект, чтобы формула сошлась на всех этих заданиях сразу. На тысяче с лишним кейсов она сошлась с точностью до третьего знака. Коротко: качество задания равно суммарной награде, деленной на максимум, а максимум пропорционален числу эталонных объектов. Из формулы сразу выпали практичные вещи.

Например, на этой арене лишний объект во вредоносном ответе стоил минус 3, а недобранный эталонный - примерно минус 4. То есть перебор и недобор штрафуются почти симметрично, и копнуть глубже почти всегда выгоднее, чем сэкономить. А в легитимных ответах улики надо класть только те, что реально входят в эталон: лишняя улика - минус 1,5, а не “ну пусть будет”.

Почему выгоднее копать глубже

Дальше был марафон гипотез. Каждый прогон проверял одну переменную. Начал я с 0,730 и дальше полз вверх: улики легитимных только из объектов с наградой, у учетки в улике оставлять только группу, а не имя, одна запись GPP вместо дублей, верные виды мер, правильный выбор представителя в парке узлов. К N прогону среднее качество дошло до 0,935. Вот эта лестница - каждая точка отдельный прогон:

Лестница гипотез общего открытого этапа

Самое красивое открытие я называю “Ключ - HOST”. Оказалось, что одна из самых весомых и неочевидных улик - сам узел тревоги как объект, причем важно не имя и не роль, а конкретное поле: IP-адрес. А если сцена повторяется на нескольких узлах парка, эталонная улика легитимности часто лежит не на том узле, где сработала тревога, а на соседнем - там, где виден штатный источник процедуры. Это ровно тот случай, когда правильный ответ контринтуитивен: без обратной связи его не угадать, а с ней - находишь и закрепляешь. Это улучшение подняло среднее качество с 0,936 примерно до 0,953 и устояло в слепой проверке.

И здесь сыграл двойной состав. Я гонял прогоны под одной моделью (в логах у них префикс op и cl), Codex - под другой. Несколько прорывов пришли именно от переноса чужих находок: один агент нашел, что в ответ надо класть все билеты Kerberos из сцены, другой - что вид меры для одного семейства не тот, что я думал. Мы буквально сверяли составы ответов по каждому семейству и подхватывали лучшее. Рекорд общего открытого этапа - результат этой переклички двух моделей, а не одной.

И вот в середине этого марафона произошел главный сдвиг в голове. Один из напарников прямо спросил меня: ты смотришь на логику событий или просто подгоняешь ответ под балл? Вопрос был по делу. Я к тому времени уже обжегся в сентябре и ответил честно: переходим на логику. Подгонка не переносится на новые сцены - а именно новые сцены ждали в финале. Второе место на этом этапе я считаю куда более “своим”, чем первое на внутреннем: тут я наконец перестал обманывать сам себя.

К финалу я знал одно наверняка: там снова погасят свет. Обратной связи не будет, а значит, нельзя будет ни подогнать ответ, ни даже понять, какой из прогонов лучше. Готовиться к такому на боевой арене - глупо: каждый прогон ограничен, а учиться надо много. Поэтому я сделал то, что в продуктах мы называем “построить стенд”: собрал офлайн-тренажер.

Устроен он из трех частей.

Первое - симуляция закрытого этапа. Я добавил в драйвер режим, который прячет от агента всю обратную связь ровно так, как это делает боевая арена: никакой награды за поиск, нули в результате. На сохраненных задачах это позволяло честно репетировать работу вслепую - и проверять, не разваливается ли мой разбор, когда подсказок нет.

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

Третье, и самое важное для финала, - способ выбирать лучший прогон вслепую. Вопрос звучит абсурдно: как выбрать лучший из нескольких прогонов, если ни у одного не видишь балла? Я нашел наблюдаемый признак, который не требует оценки: сколько мер и улик агент добрал по каждой задаче - это видно прямо в логе. Гипотеза простая: больше добранных мер обычно значит, что помощник поймал больше эталонных объектов, а значит и качество выше. Я проверил эту связь на десятках прошлых прогонов, где оценки уже раскрывали. На 12 прогонах корреляция вышла 0,917. Потом я прогнал проверку жестче - на 23 реально конкурирующих прогонах разных конфигураций - и получил корреляцию 0,997: слепой выбор каждый раз совпадал с реально лучшим прогоном.

Как выбрать лучший прогон, не видя оценок

Отдельно я честно измерил потолок. На знакомых семействах мои помощники упирались в стабильные 28,8 балла из примерно 29 возможных, и все обоснованные гипотезы роста я проверил: одна (про перенос учетки в tiering) внедрилась и дала прибавку, еще четыре арена живьем опровергла. На незнакомых сценариях картина другая: автомат вслепую выдавал около 0,55 качества, ручной разбор по логике - около 0,70, а с доступной наградой было бы 0,84. Этот разрыв между 0,70 и 0,84 - это ровно вклад обратной связи, которой в финале не будет. То есть я заранее знал физический предел: на незнакомых задачах вслепую выше определенного уровня не прыгнуть, как ни старайся.

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

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

День вышел богатым на мелкие драмы.

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

Потом на середине первого прогона арена упала - 502, разрыв соединения, рантайм пришлось сбрасывать и начинать заново. Такое на соревнованиях случается, но когда у тебя три часа на сорок задач, каждый сброс бьет по нервам (время закрытого этапа увеличили на пол часа, все по честному). Первый заход успел пройти 16 задач до сброса.

Потом я сам устроил себе ложную тревогу - и это прямое эхо сентября. Увидел, что в лидерборде я где-то в середине, и решил: все, перебираю с объемом ответов, лишнее штрафуется, надо резать. Перешел на “постный” режим, сжал ответы на целый прогон. И только потом сообразил проверить, что вообще показывает та таблица. А показывала она порядок по времени сдачи, а не по баллам. То есть я снова чуть не сделал вывод о качестве из метрики, не поняв, что она измеряет. Вернул полный разбор.

Ловушка финала: вывод из чужой метрики

Технически финал был устроен так. Почти все сорок задач оказались новыми семействами - автоматический конвейер на них честно останавливался, и дальше шел ручной разбор по чек-листу: вердикт из причинной цепочки, полнота состава, верный вид каждой меры, ничего лишнего. Цикл одной задачи выглядел буднично: компактный дамп сцены с обязательной маскировкой паролей и токенов (их нельзя тащить ни в логи, ни в ответ - это я поставил себе жестким правилом с самого начала), два-три пакетных поиска, чтобы раскрыть цепочку, сборка ответа скриптом, отправка, переход к следующей задаче.

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

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

Пятое из всех этапов - мой худший результат, и он честный. Финал - это ровно та ситуация, под которую я готовился весь месяц: незнакомые сцены, нет обратной связи, нельзя подогнать. Тут не работает ни один из приемов, которыми я брал открытые этапы. Работает только качество разбора цепочки да дисциплина “не доверяй метрике, которую не на чем проверить”. Я этой дисциплины держался - и все равно занял пятое. Это отрезвляет лучше любой победы: когда правды заранее не видно, потолок одного участника с парой ИИ-напарников вот такой, и это нормально.

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

Задачи от Standoff Defend - отдельный набор, за который я взял третье место. Сцены там ближе к практике реального противодействия, и подход у меня был тот же, что я выработал к финалу: сначала причинная цепочка, потом состав ответа. Метод, выстраданный на четырех этапах, перенесся сюда почти без изменений - и это, пожалуй, лучшее подтверждение, что он про логику, а не про подгонку.

Лидерборд задач Standoff Defend, 3 место

“Агентский блицкриг” - номинация на скорость. Тут ценилось, как быстро агент проходит дистанцию, и я попал в ТОП-10 с результатом 1612,72 секунды. Забавный контраст: весь месяц я сам себе повторял, что время не главное, качество важнее, - а отдельная номинация оказалась именно про время. И вот здесь неожиданно пригодился самый первый, “читерский” конвейер с открытого этапа: на знакомых семействах он отрабатывал задание за секунды, и общая дистанция сжималась.

Номинация Агентский блицкриг, ТОП-10

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

Если собрать месяц в несколько тезисов, которые переживут конкретное соревнование:

1. Собственная метрика без обратной связи. Она показывает то, что вы в нее заложили, а не то, насколько вы близки к правде. Моя шкала на закрытом этапе дала корреляцию с реальностью минус 0,873 - то есть уверенно врала в обратную сторону. Если оценку скрыли, честнее признать “я не знаю, какой прогон лучше”, чем довериться красивой цифре, которую не на чем проверить. А если выбирать все-таки надо - ищите наблюдаемый признак, который можно откалибровать на известных данных, как я сделал с суммой мер.

2. Правило, выведенное на тренировке, надо перепроверять на бою. “Лишнее не штрафуется” прекрасно работало на открытом этапе и перевернулось на закрытом. Любое правило из обучающей выборки - это гипотеза про тот этап, где его вывели, а не закон природы. Я один раз не перепроверил - и потерял зачетный этап.

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

4. Команда - это не результат. Половина легитимных сцен была именно про это: подозрительная команда сама по себе ничего не доказывает, важно, чем она кончилась и кто ее запустил. Остановка службы может быть и атакой, и плановым обновлением - разводит их не набор действий, а контекст полномочий. Это, кстати, ровно та дисциплина, которой не хватает и живым аналитикам первой линии.

5. Формулу оценки стоит вывести из данных, а не угадывать. Как только я перестал фантазировать про то, “что, наверное, ценит арена”, и честно подобрал коэффициенты на тысячах кейсов, сразу стало видно, где копать, а где я трачу силы впустую. В задачах со скрытой оценкой это самое дорогое знание.

6. ИИ-напарник - это толковый инженер, которого надо проверять. Codex и Claude сделали за месяц много работы, но несколько раз уверенно уводили меня не туда - от придуманных полей до ложных выводов по одному прогону. Ценность была не в том, чтобы им доверять, а в том, чтобы с ними спорить, сверять каждую гипотезу с данными и стравливать их находки между собой.

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

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

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

P.S. Наверное закономерный вопрос есть: А сколько токенов ты сжег?) Скажу честно, было много токенов сожжено впустую, на проверку гипотез и тд. Но целевая картина по двум соревам примерно такая:

• Claude Code ~36,9M

• Codex ~7,1M

• Генерации вышло ~ 44 миллиона токенов - это объём текста, кода и рассуждений, который две модели реально произвели за месяц. Для масштаба: это как несколько сотен книг.

• Валовые ~19,3 миллиарда - это в основном многократное перечитывание контекста (кэш). Цифра эффектная, но считать “работой” её нельзя.

Hima_Hahahai. Соревнование BlueSec1, осень 2026.