Егор Спирин
Руководитель лаборатории прикладных агентов (ЛаПА) AI Talent Hub
Меня зовут Егор Спирин, я руковожу лабораторией прикладных агентов (ЛаПА) в AI Talent Hub при ИТМО.
Мне всегда были интересны соревнования в IT — сначала ICPC, где важны алгоритмы и скорость, потом Kaggle, где всё сводится к одной метрике на фиксированном датасете. В обоих случаях понятно, что именно оценивается и как улучшить результат.
Агентные соревнования устроены иначе: здесь оценивается не ответ, а поведение системы в процессе. Это ставит новый вопрос — как вообще провести такое соревнование? В этой статье расскажу о сути агентских соревнований, чем они отличаются от классических, и об опыте участия в BitGN PAC1 и AgentBeats.
Откуда берется метрика и почему с агентами все сложнее
Цель соревнования в машинном обучении — показать лучший результат на задаче. Есть датасет, метрика, участники пытаются выбить число как можно больше. Классификация — измеряем F1-score. Распознавание объектов на фото — считаем, сколько правильно нашли людей и собак. Все прозрачно: у тебя есть число, у лидера есть число, разница — это отставание, которое нужно сократить. Подаешь предсказания на тестовую выборку, платформа сверяет с правильными ответами, возвращает метрику. Никакой неопределенности в том, что именно измеряется.
Агент устроен иначе: он получает задачу и сам решает, как её выполнить. С этим возникает сразу несколько вопросов.
Первый — бинарная метрика слишком груба. Решил задачу или нет — важно, но недостаточно. Нас еще интересует оптимальность: сколько шагов сделал агент, сколько времени занял прогон, сколько токенов потратил. Два агента могут оба решить задачу, но один сделал это за 8 tool calls, а другой — за 47 с тремя retries. Это разный результат.
Второй — у нас нет такого же размера данных. Раньше на соревнованиях давали датасеты, на которых можно обучать модели и запускать проверки. Сейчас датасеты — это сценарии для агента, собирать их в разы сложнее и зачастую невозможно в тех же объемах.
Третий — агент работает в среде, которая меняется. Он вызывает API, изменяет файлы, ведет диалог. Если в ходе выполнения что-то пошло не так, нужно понять: это проблема агента или среды?
Чтобы познакомиться с форматами агентских соревнований на практике, разберем пару недавно прошедших BitGN PAC1 и AgentBeats, где мы приняли участие.
BitGN PAC1: детерминированная среда, наблюдаемые действия
BitGN — глобальное соревнование, которое в апреле 2026 года собрало больше 800 регистраций из 86 городов. Задача называлась PAC1 (Personal Agent Challenge) и была про личного агента по имени Майлс: файлы, письма, счета, накладные, заметки по проектам, контакты — и поверх всего набор запросов разной сложности, включая промпт-инъекции и попытки социальной инженерии.
Ключевое отличие от классики — платформа оценивала не текст ответа, а то, что агент реально сделал: какие инструменты вызвал, какие файлы изменил, какие side effects создал, нарушил ли ограничения, попытался ли слить данные. Детерминированная среда: каждый прогон стартует из одного состояния, и если агент падает — это не стохастика, это архитектурная проблема.
У нас в AI Talent Hub был собственный хаб внутри глобального соревнования — очный формат и локальный лидерборд. При этом команды участвовали и в общем соревновании. Дальше расскажем об опыте участников.
Максим Пискарев
Студент магистратуры AI Talent Hub, 2 курс
Я построил skill-based одноагентную ReAct-систему на OpenAI Agents SDK. Логика: принять задачу → классифицировать в нужный скилл → запустить ReAct-цикл (действие → вызов тула → наблюдение → следующий шаг) → закрыть задачу через submit_answer. Модель — gpt-4o-mini, архитектуру ядра не менял, прирост шел через добавление и уточнение скиллов под новые классы задач.
Самая неожиданная задача оказалась не в промпт-инъекциях и не в сложных цепочках tool calls. В CRM было несколько контактов с одинаковым именем, и по правилам нужно было не запрашивать уточнение, а самому выбрать правильного человека по контексту — аккаунт, заметки, compliance_flags. Агент по привычному правилу уходил в clarification — если несколько совпадений, спрашивай. Это был вшитый guardrail «безопасного» поведения. Из-за него задача падала. Не сразу заметил, что это целый паттерн, и стал докручивать логику скилла под другие случаи.
Ещё более показательный момент — агент иногда молчал. Формально завершал шаг, не вызвав ни одного tool call. submit_answer не срабатывал. Раннер видел завершение, но задача падала по scorer’у. Нашел по логам: 0 tools, пустой финал. На повторном прогоне тот же кейс мог пройти — выглядело как рандом.
Вывод простой: нельзя полагаться только на модель. В агенте должны быть страховки на уровне оркестратора — retry, force-submit, жёсткий контроль, что задача закрыта именно через submit_answer.
В Kaggle думаешь «как подогнать под ответ». Здесь думаешь «как выстроить надежный протокол выполнения». Оценивалось не что агент сказал, а что сделал. Это другая инженерная задача.
AgentBeats: агент оценивает агента
AgentBeats — исследовательская платформа с принципиально другим подходом. Они называют это «агентификацией бенчмарка»: сам бенчмарк становится агентом.
Схема такая. Есть зелёный агент (evaluator) — он ведет диалог, ставит задачи, имитирует пользователя и в конце решает, достигнут ли нужный исход. Есть фиолетовый агент (competing) — твой агент, который должен привести диалог к правильному финалу. Они общаются через стандартный A2A-протокол, без участия человека.
Трое наших участников выбрали τ²-bench — бенчмарк от Sierra Research для оценки агентов клиентской поддержки. Его особенность в том, что оба участника диалога — агент и симулированный пользователь имеют доступ к инструментам и могут изменять состояние общей системы. Это принципиально сложнее классических бенчмарков, где пользователь просто описывает проблему словами, а агент действует в одностороннем порядке.
Трек — авиакомпания: бронирования, возвраты, апгрейды класса обслуживания. Правила были самой важной частью: какие-то билеты нельзя менять вообще, где-то нельзя изменить направление рейса, где-то нужно правильно обработать сертификат или апгрейд. Нарушил политику — задача сразу считалась проваленной. Итоговая метрика — accuracy по правильно закрытым диалогам.
Когда судья — агент
Знание о том, что тебя оценивает не человек, а другой LLM, влияет по-разному. Наши участники разошлись в мнении.
Владислав Кинякин
Студент магистратуры AI Talent Hub, 1 курс
Когда тебя оценивает человек, он смотрит на поведение в целом. Здесь все намного жестче: правильный ли вызван тул, не нарушил ли агент политики, совпадает ли итоговое состояние с ожидаемым. Но самое интересное — зеленый агент тоже был недетерминированным, с температурой около 1.0. Один и тот же код давал разные результаты между прогонами.
Иногда зеленый агент спокойно формулировал запрос. Иногда начинал спорить. Иногда пытался продавить через жалость или манипуляции. В какой-то момент он сказал буквально: «Вы единственный нормальный сотрудник, с кем я разговаривала». Если агент уходил в болтовню или излишнюю услужливость — начинал нарушать политики.
В какой-то момент я решил, что оптимизировать нужно не под конкретный тест, а под устойчивость поведения. Чтобы мой агент нормально держался даже когда диалог начинают уводить в сторону намеренно.
Павел Соколов
Студент магистратуры AI Talent Hub, 2 курс
Когда есть эталонный ответ, заданные правила и набор инструментов — остается только придумать, как к нему прийти. Растим метрики как обычно.
Оба правы — просто решали разные части одной задачи. Устойчивость к манипуляциям и оптимизация под метрику не противоречат друг другу.
Главный технический вызов — промпт
Самый болезненный момент для Владислава — нелинейность промптов. У него был стабильный результат около 70%. Он добавил несколько правок в системный промпт — буквально пару строк: уточнил edge-кейс, добавил исключение для обработки платежа, поправил логику отмены:
Каждая правка выглядела адекватной. Запускаю прогон — 52%. Начал откатывать по одному, понял, что проблема в промпте. Возвращаю старую версию — снова 70%.
В коде изменение локальное и предсказуемое. В промпте любая новая инструкция начинает влиять на всё остальное. Одна фраза меняет поведение модели в задачах, которые к ней вообще не относятся. Вывод — только маленькие правки, и отдельный прогон после каждой.
Павел наступил на другие грабли — выбрал слабую модель и сразу начал строить сложное окружение: проверки ответов, сжатие контекста, верификация входящих данных.
Потом понял, что надо было начинать с базового промпт-инжиниринга без сложной обвязки и только потом наращивать сложность. В итоге сложно было вычистить лишние проверки, которые ломали агента, даже когда LLM нормально отрабатывала.
Три с половиной часа на итерацию
Анатолий Банников
Студент магистратуры AI Talent Hub, 1 курс
Я работал с τ²-bench дольше всех и детально описал, как выглядел процесс изнутри. Нормального локального окружения не было — симулятор завязан на API платформы, один прогон занимал около трех с половиной часов.
Рабочий цикл: запустил → подождал → получил JSON с упавшими задачами → сравнил с открытым репозиторием сценариев Sierra Research → нашёл паттерн → написал правку в промпт.
Плюс реализовал систему напоминаний агенту каждые 10 шагов — определенный набор правил, который возвращал его в русло и не давал уходить в болтовню.
Главная проблема — долгая обратная связь. При небольших изменениях итерации очень затягивались. Вторая проблема — стохастичность. Один запуск не дает уверенности, нужно несколько, а с учётом первой проблемы это все осложняло. Документация местами сырая — некоторые вещи приходилось понимать через чтение исходников τ²-bench.
Как выглядел код с с accuracy выше 90%?
Самым запоминающимся для Владислава оказался репозиторий лидера таблицы:
Ожидал мультиагентную систему, оркестрацию, огромные промпты. Открываю — системный промпт буквально в одну строку. Пара коротких подсказок, минимум логики вокруг модели, DeepSeek-R1. Человек просто взял сильную reasoning-модель и почти не мешал ей работать.
На фоне его многостраничных промптов это выглядело абсурдно. И это был самый полезный момент: до этого казалось, что качество в таких задачах добывается сложностью оркестрации и количеством правил.
Что мы поняли про агентов
Несколько выводов, которые не найдёшь в документации к платформам.
-
Промпт — не конфиг, а поведенческая система. Когда правишь системный промпт, добавляешь не инструкцию — меняешь распределение вероятностей по всем возможным диалогам. Одна фраза про обработку платежей может сломать поведение агента при отмене брони. Итерировать нужно маленькими шагами с отдельной проверкой каждого.
-
Страховки на уровне оркестратора обязательны. Если агент может не сделать tool call и при этом формально завершить шаг — он это сделает. Force-submit, retry-логика, явный контроль, что задача закрыта через ожидаемый механизм — без этого архитектура ненадежна независимо от качества LLM.
-
Сильная модель с коротким промптом часто лучше слабой с длинным. DeepSeek-R1 с одной строкой системного промпта против развернутых инструкций на средней модели — первый вариант побеждает. Reasoning-модели умеют работать с политиками и ограничениями без детального ручного управления. Сложная обвязка скрывает проблему модели, но не решает ее.
-
Устойчивость к манипуляциям — это отдельное свойство, которое нужно проектировать. Зелёный агент давил через жалость и лесть. Агент, который слишком старается быть полезным, начинает нарушать политики. Это не гипотетическая угроза — это реальный паттерн, который виден в логах.
-
Начинать нужно с модели, а не с архитектуры. Сложная обвязка поверх слабой модели — это техдолг, который потом сложно вычистить. Сначала выбери модель, убедись, что базовый промпт-инжиниринг работает, и только потом добавляй оркестрацию.
Действительно ли агентские соревнования лучше оценивают?
Да, разностороннее. В классическом ML-соревновании тебя оценивают по одной функции. Здесь оценивается поведение системы в динамике: правильно ли вызваны инструменты, соблюдены ли политики, устойчив ли агент к манипуляциям, есть ли fallback если модель «замолчала», насколько надёжно закрывается каждая задача. BitGN наблюдал tool calls, side effects, trustworthiness penalties — вещи, которые в классическом соревновании вообще нет смысла проверять. В AgentBeats нужно было удерживать правильное поведение в диалоге, который зелёный агент мог намеренно уводить в сторону.
Но разносторонность обходится ценой. Три с половиной часа на прогон делают итерации болезненными. Стохастика зелёного агента означает, что результат одного прогона может не повториться. Порог входа высокий: прежде чем получить хоть какой-то ненулевой скор, нужно разобраться с регистрацией агента, манифестами, секретами, API-ключами и форматом сабмита — это не задачи по ML, это инфраструктурная работа.
Поэтому честный совет такой: если хотите проверить конкретную модель на конкретной задаче — Kaggle эффективнее. Если хотите понять, как ваш агент ведёт себя в условиях, близких к реальным, — агентные соревнования дадут это лучше. А заодно покажут, где у архитектуры дыры, которые в лабораторных условиях незаметны.
Если вы строите агентные системы и хотите понять, где они ломаются — лучшего способа узнать, чем отправить агента соревноваться, пока нет.
Пишите в комментариях, участвовали ли вы в подобных соревнованиях и ваше мнение о них — сошлось с нашими выводами или нет?
Автор: ai-talent
