Ни для кого не секрет, что эра «спросить что-то у GPT» постепенно уходит в прошлое. На смену генеративному AI приходит Agentic AI, который не просто проконсультирует, а по вашему запросу придёт и сделает все сам. То же самое и с кодовыми агентами, они не просто отвечают на вопросы, они читают документацию, работают в терминале, дёргают API, правят файлы и в идеале закрывают задачу целиком, от тикета до мёрж-реквеста.
Звучит здорово, пока не выясняется, что ваш агент починил баг, сломав при этом три соседних модуля, или молча проигнорировал половину требований из задачи. Короче говоря, агенты умеют халтурить, и делают это красиво. А значит, их нужно постоянно тестировать. Причем тестировать в условиях, максимально приближённых к рабочим: с реальным репозиторием, CI-пайплайном и набором тестов, которые не обманешь.
Именно для этого в AI-сообществе появился целый класс таких инструментов как бенчмарки и песочницы, заточенные под оценку агентов. В этой статье мы разберём, какие подходы к тестированию кодинг-агентов существуют сегодня, в чём их сильные и слабые стороны, и расскажем, как мы в Doubletapp создаём кастомные бенчмарки на приватных данных.
Содержание
Какие бенчмарки сейчас используют
Список агентских бенчмарков давно перестал умещаться в одну таблицу, поэтому ограничимся четырьмя категориями, которые покрывают бóльшую часть реальных сценариев.
Кодовых агентов проверяют через SWE-bench и SWE-bench Verified. Задачи берутся из настоящих GitHub issues популярных Python-репозиториев. Агенту дают репозиторий на нужном коммите, текст issue и просят сделать патч, после которого пройдут скрытые тесты. SWE-bench Verified — это вручную отобранное подмножество на 500 задач, где OpenAI отдельно проверяли, что описание issue достаточно понятное, тесты корректно отражают баг, а задача в принципе решаема без подглядывания в будущее репозитория. На практике Verified — единственная версия, по которой имеет смысл сравнивать модели. На оригинальном SWE-bench слишком много шумных задач, и доля решённых начинает измерять везение, а не способности агента.
Для терминальных агентов есть Terminal-Bench. Здесь агент работает в живом терминале. Компилирует проекты, чинит зависимости, поднимает серверы, дебажит падающие скрипты, гоняет ML-пайплайны. Каждая задача — это контейнер с состоянием и набором сквозных проверок, которые должны пройти после действий агента. Рядом стоит упомянуть Harbor, фреймворк от тех же авторов для запуска агентских тестов на собственных задачах. Он закрывает контейнеризацию, изоляцию и запуск различных агентов, и его удобно брать как основу под кастомные бенчмарки.
Браузерных и десктопных агентов проверяют в OSWorld. OSWorld запускает агента в настоящей десктопной среде с Ubuntu/Windows. Реальные приложения, реальный файловый менеджер, реальный браузер. Задачи там открытые — от переноса данных между приложениями до настройки системы по запросу пользователя. Проверка идёт по состоянию ОС после прогона, а не по тексту ответа. Это самый честный сигнал, потому что симулятор GUI ломается ровно там же, где он ломается у реального пользователя.
Универсальных агентов гоняют в GAIA. GAIA проверяет ассистента — обобщённого работника. Вопросы требуют рассуждений, работы с вебом, чтения PDF, обработки изображений и грамотных вызовов инструментов. Ответы короткие и проверяемые точным сравнением, а не моделью-судьёй. Поэтому GAIA хорошо отделяет умение рассуждать от умения довести задачу до проверяемого ответа, а это две разные вещи.
Эти четыре бенчмарка отвечают на вопрос, как агент справляется с типовыми задачами рынка. Но для компаний куда важнее другое, а именно как он справится с нашим стеком, нашим кодом и нашим рабочим процессом.
Почему публичных бенчмарков недостаточно
Публичная таблица результатов — это усреднённая оценка по чужим задачам. У неё есть несколько встроенных ограничений, из-за которых на ней нельзя строить продуктовое решение.
Стек смещён. SWE-bench — это Python и преимущественно Django/sympy/sklearn/matplotlib-подобные репозитории. Если ваш продакшен — это Go, Kotlin, TypeScript-монорепа на 4 миллиона строк или Scala с собственной системой сборки, результат на SWE-bench Verified коррелирует с поведением агента на ваших задачах очень слабо.
Чистые задачи. В Verified описание issue понятное, тесты адекватные, баг локализован. В реальной жизни тикет приходит размытым и без логов, тесты нестабильные, в репозитории два конкурирующих способа делать одно и то же, а половина контекста живёт в Confluence пятилетней давности.
Утечка в обучение. Публичные бенчмарки попадают в претрейн и в данные дообучения. Чем громче бенчмарк, тем выше шанс, что часть задач модель уже видела, а доля решённых показывает запомненное решение, а не способность решать новое.
Тезис простой. Публичный бенчмарк показывает среднюю силу агента, кастомный показывает его полезность для конкретной компании.
Мы уже показывали этот подход на практике. Собрали свой SWE-bench-подобный бенчмарк на 15+ языках, прогнали через него Codex, Claude Code и Cursor в нескольких конфигурациях и сверили результаты с прогоном на приватном Python-репозитории. Самое интересное там не общий счёт, а то, что порядок лидеров на приватном коде не совпадает с публичными таблицами.
На приватном Python вперёд вышел Claude Code на Opus 4.6 (68%), на мультиязычном прогоне лучшим оказался Cursor с тем же Opus (71%), а Codex держится крепким середняком за счёт лучшего соотношения цены и качества. Разбивка по языкам и сравнение с SWE-Bench Verified, SWE-rebench и Multi-SWE-bench разобраны в статье «Как выбрать лучшего AI-ассистента для разработки: тестируем Codex, Claude и Cursor»
Кастомные бенчмарки как следующий слой тестирования
Мы в основном занимаемся именно кастомными бенчмарками на приватных данных. Это самый прямой способ увидеть, где модель и агент проваливаются на конкретном стеке, а где их уже можно ставить в работу.
У любой компании, которая активно пишет код или ведёт операции, уже лежит идеальный материал для тестов. Его нужно только собрать и обернуть в воспроизводимое окружение.
Возьмём типовой материал, который лежит в любой технической команде. Готовый бенч-тикет почти никогда не лежит в одном источнике целиком, его обычно склеивают из нескольких.
Самая частая фактура — это связка тикета и смёрженного PR. В YouTrack или Jira лежит описание бага, например, с экспортом отчёта в XLSX, где null-поля превращаются в пустые строки. В самом PR уже есть итоговый патч и тесты, которые этот баг ловят. Из тикета берём формулировку задачи, из коммита до фикса — репозиторий в нужном состоянии, из PR забираем патч и тесты как эталон проверки. Так мы и делали в кейсе с приватным Python-репозиторием. На таких связках хорошо собираются и фичевые задачи с критериями приёмки, и задачи на написание теста, который ловит конкретный регресс.
Если в команде есть on-call и постмортемы, появляется другой класс задач. В постмортеме уже есть симптомы, лог-выжимка и итоговый разбор причины. Сверху подмешиваются треды из Slack или Discord, где инцидент обсуждали в реальном времени, что даёт правдоподобный неструктурированный контекст, в котором агенту придётся работать. Сам бенч-тикет требует по логам докопаться до причины и предложить фикс или временный обход.
CI отдельно полезен тем, что в нём уже лежат готовые сломанные состояния. Каждая красная сборка с известной причиной превращается в задачу, где на входе репо в сломанном состоянии, а на выходе должна быть зелёная сборка. Сюда же отлично ложатся задачи на обновление зависимости с ломающими изменениями, потому что в логах уже есть точный список того, что именно отвалилось.
Документация, Confluence, спецификации внутренних API и runbook'и дают класс задач, в котором кода почти нет. Найти ответ, собрать справку из нескольких страниц, выполнить операцию по инструкции, разобраться, как наш сервис общается с другим. Это уже не про коммит, а про умение ориентироваться во внутреннем знании компании. И здесь склейка работает так же. Описание задачи берём из тикета или вопроса, эталон ответа — из самой документации, проверку — из ручной разметки или внутреннего FAQ.
Главное отличие от публичного бенчмарка в том, что задача с самого начала привязана к процессу, который компания хочет делегировать. Не просто решить абстрактный issue из опенсорса, а именно закрыть существующий тикет. Тогда доля решённых задач начинает означать что-то полезное, а именно долю работы, которую агент может делать без человека.
Как выглядит пайплайн кастомного SWE-style бенчмарка
Дальше показываем сборку на примере SWE-style бенчмарка, потому что это самый частый и понятный кейс. Берём реальные баги и фичи из репозитория и смотрим, может ли агент их закрыть. Для других категорий (терминал, браузер, документация) логика та же, меняется только содержимое задач и проверок.
Сборку мы выстроили из четырех шагов:
1. Собрать реальные задачи.
Из репозиториев берутся пары (коммит до фикса, коммит после фикса) с привязанным тикетом и PR. Из CI берутся падающие сборки с известной причиной. Из тикетов берутся задачи с явным критерием приёмки. На этом этапе важно сразу отбирать задачи с проверяемым результатом. Если успех нельзя проверить автоматически, задача в бенчмарк не идёт.
2. Очистить данные.
Секреты, токены, персональные данные, имена клиентов, внутренние ссылки убираются ещё до того, как задача уезжает на прогон агентам. На практике это самый недооценённый шаг. Без нормальной очистки бенчмарк нельзя ни показать наружу, ни безопасно гонять через сторонние API.
3. Завернуть в воспроизводимое окружение.
Каждая задача — это контейнер с зафиксированной версией кода, зависимостей, инструментов и набором проверок. Агент получает ровно то же, что инженер, а именно репозиторий, описание задачи и доступ к терминалу, браузеру, инструментам. Проверка автоматическая, через прогон тестов, сравнение с эталонным патчем и состояние системы после действий.
4. Прогнать и сравнить.
Сравниваем не только долю решённых задач. На каждом прогоне снимаем стоимость в токенах и в долларах, время до решения, стабильность как разброс между N запусками одной задачи, траекторию агента, а также сценарии отказа (потерянный контекст, неверная гипотеза, неправильное использование инструмента, отказ от задачи).
Только после этого видно реальную картину. Один агент решает на 5 п.п. больше задач, но стоит в три раза дороже и заметно медленнее. Другой проигрывает в среднем, но стабильно решает именно тот класс тикетов, который мы и собирались делегировать.
Хороший бенчмарк — это не набор задач, а воспроизводимая среда, в которой можно честно сравнивать агентов между собой. Задачи без среды — это упражнение для таблицы результатов. Среда без задач — это инфраструктура без сигнала. Полезность даёт только связка.
Всё описанное выше — это не теория. Мы уже собирали собственный мультиязычный SWE-Bench-style бенчмарк из 506 задач на 8 языках из реальных issues продовых репозиториев (Kubernetes, Prometheus, Mastodon и др.), прогнали через него шесть моделей в одинаковых условиях и сравнили pass@1, precision и F1.
И все для того, чтобы сделать главный вывод: порядок моделей на нашем бенчмарке не совпадает с публичными лидербордами. Лидер SWE-bench Verified на Python может заметно проседать на Go-монорепе или Kotlin-задачах с внутренними фреймворками. Собственно, ради таких инсайтов кастомные бенчмарки и собирают.
Методологию сборки, инфраструктуру прогона и детальный разбор, где именно модели ломаются и почему, мы описали в статье «Benchmark — разрушитель LLM'ок, или Как мы собрали свой мультиязычный SWE-Bench»
Заключение
Всё, о чём мы рассказали в статье — публичные бенчмарки, кастомные пайплайны, мультиязычные прогоны — можно применить к задачам конкретной компании. Собрать бенчмарк из её репозиториев, тикетов и рабочих процессов, прогнать несколько агентов в одинаковых условиях и получить честный ответ на вопрос, какой из них действительно подходит под наши задачи, а не просто хорошо выглядит на лидерборде.
В итоге agent testing превращается из разового «давайте попробуем GPT на наших задачах» в системный инструмент, который отвечает на три конкретных вопроса: какие задачи уже можно отдавать агенту, где по-прежнему нужен человек в цепочке и какой набор моделей даст лучшее соотношение цены и результата.
Мы в Doubletapp занимаемся обучением и оценкой кодовых AI-моделей и агентов. Работаем с международными компаниями и параллельно развиваем это направление в России. Тема agent evaluation в СНГ растёт быстро, и мы стараемся вносить свой вклад: накапливать экспертизу в сборке кодовых бенчмарков и оценке агентов здесь, а не просто ориентироваться на чужие таблицы результатов.
Если вы присматриваетесь к AI-агентам для своих процессов или уже попробовали, но пока не понимаете, насколько это эффективно, мы можем помочь подобрать подходящего агента и объективно оценить его работу на ваших задачах.