Terminal Bench 4.0 можно использовать как стандартизированный способ проверить, как кодинг-агент решает задачи в терминальной среде. Но результат такого теста описывает поведение системы в заранее заданных сценариях. Он не гарантирует, что агент так же хорошо справится с конкретным репозиторием, внутренними правилами команды или задачей с неполной документацией.
Для повседневного выбора инструмента часто достаточно компактного evaluation-набора: 5-15 типовых задач, одинаковое окружение, автоматические проверки, сбор логов и расчёт стоимости успешного решения. Большой публичный бенчмарк даёт общий ориентир, а собственный harness отвечает на практический вопрос: как конкретный агент работает в вашем проекте, сколько времени и токенов он расходует и сколько контроля требует от разработчика.
В этой статье разберём, что можно оценивать с помощью Terminal Bench 4.0, почему бенчмарки быстро обновляют, как возникает saturation метрик и как собрать недорогую систему проверки для личного workflow, команды или production-процесса.
Terminal Bench 4.0: что он показывает и чего не показывает
Терминальный бенчмарк проверяет связку из нескольких компонентов: модель понимает задачу, планирует действия, работает с файлами и командами, получает обратную связь от тестов, исправляет ошибки и формирует итоговый результат. Поэтому такой тест ближе к проверке кодинг-агента, чем обычная задача на генерацию отдельной функции.
При этом итог зависит от правил конкретного evaluation. На результат влияют исходное состояние репозитория, доступные инструменты, лимит времени, ограничения на сеть, число попыток, способ запуска тестов и требования к финальному ответу. Без этих параметров балл трудно интерпретировать.
Почему одного результата на лидерборде недостаточно
Высокий benchmark score означает, что система часто проходит задачи из определённого набора при определённых условиях. Для рабочего pull request нужны дополнительные свойства: читаемый diff, отсутствие лишних изменений, сохранение обратной совместимости, корректные тесты и понятное объяснение решения.
Агент может пройти формальную проверку, изменив больше файлов, чем требовалось. Он может добавить тест, который подтверждает собственную реализацию, но не защищает важный сценарий. Он может исправить ошибку сборки ценой поломки другого компонента. Автоматический pass rate не всегда фиксирует такие последствия.
Результат в чужом репозитории плохо переносится на ваш проект, если отличаются язык, фреймворк, структура модулей, качество документации и требования к ревью. При сравнении Claude Code и Codex поэтому полезнее учитывать тип задачи, число итераций и уровень автономности, а не выбирать инструмент по одной строке лидерборда.
Какие данные о Terminal Bench 4.0 нужно проверить перед публикацией
Конкретные характеристики Terminal Bench 4.0, состав задач и изменения относительно предыдущей версии нужно сверять с официальным описанием релиза. В предоставленных материалах нет подтверждённых сведений о количестве заданий, списке моделей, правилах запуска или заявленном улучшении результатов. Эти параметры нельзя дополнять предположениями.
Перед публикацией результатов проверьте:
- дату релиза и точную версию набора;
- состав evaluation-задач и их тематические категории;
- исходные репозитории, commit или snapshot, на которых запускается тест;
- правила доступа к терминалу, сети, пакетным менеджерам и внешним инструментам;
- лимиты времени, токенов, шагов и числа повторных попыток;
- метрику успеха и порядок проверки финального состояния;
- версию окружения, операционной системы и зависимостей;
- наличие holdout-задач и риск знакомства моделей с публичными примерами.
Если часть методики не опубликована, это нужно прямо указать рядом с цифрами. Таблица с баллами без harness, промптов, tool adapters, разброса результатов и failure traces показывает лишь часть эксперимента.
Почему бенчмарки для AI-агентов быстро обновляют
Агентные системы меняются быстрее, чем традиционные наборы задач. Улучшения появляются в нескольких слоях сразу: модель лучше пишет код, эффективнее планирует длинную работу, точнее использует терминал и быстрее реагирует на сообщения компилятора или тестов.
Что меняется вместе с моделями и агентами
Новая система может по-другому работать с контекстом, разбивать задачу на подзадачи, читать логи и выбирать инструменты. Изменения в системном промпте или правилах остановки иногда дают заметный эффект даже при той же базовой модели.
Меняется и сама среда разработки. В агентный цикл добавляются поиск по репозиторию, трассировка, работа с issue, запуск тестов, редакторы патчей и специализированные адаптеры. Старый тест, который проверял лишь короткий кодовый ответ, перестаёт отражать реальную работу автономного инструмента.
Сквозная оценка должна учитывать весь путь задачи: получение контекста, выбор действия, изменение файлов, запуск проверки, обработку ошибки и завершение. Подход Deep Agents с отдельными наборами для автономной работы, диалогов и поиска по корпусу хорошо показывает, почему одного типа задач мало. Для быстрых итераций команда использует облегчённый набор, который, согласно описанию проекта, работает в 8 раз быстрее и стоит в 6 раз дешевле полного прогона.
Почему старые задачи перестают хорошо разделять модели
Когда большинство систем проходит почти весь набор, метрика приближается к потолку. Это и называют saturation. Разница между 91% и 94% может выглядеть убедительно, но без доверительного интервала, повторных прогонов и разбивки по типам задач непонятно, отражает ли она устойчивое преимущество.
На верхней границе сильнее заметны случайные свойства отдельных заданий: необычная формулировка, знакомая структура проекта, конкретная версия зависимости или один нестабильный тест. Несколько трудных кейсов могут изменить рейтинг сильнее, чем кажется по общей доле успешных запусков.
Устаревший набор создаёт две проблемы. Он перестаёт различать системы, которые уже научились решать типовые задачи, и начинает измерять знакомство с форматом теста. Для актуального сравнения набор приходится обновлять, добавлять новые failure modes и сохранять скрытую часть задач для проверки обобщаемости.
Saturation метрик: когда лидерборд теряет практическую ценность
Лидерборд полезен как внешний ориентир. Он помогает увидеть порядок величин и выбрать несколько систем для дальнейшей проверки. Его нельзя использовать как прямой прогноз продуктивности разработчика.
Высокий балл не равен качественному pull request
Рабочий патч оценивают по нескольким измерениям:
- проходит ли код unit- и integration-тесты;
- соответствует ли изменение acceptance criteria;
- затрагивает ли агент лишние файлы;
- сохраняет ли он публичные интерфейсы и обратную совместимость;
- понятно ли устроено решение для последующего ревью;
- добавлены ли тесты на исправленный сценарий;
- не появились ли регрессии, уязвимости и проблемы с производительностью.
Формальный успех отвечает на вопрос «прошла ли проверка». Инженерная оценка отвечает на вопрос «можно ли принять этот патч без длительной ручной переделки». Эти показатели нужно хранить раздельно.
Какие факторы искажают сравнение
Сравнение становится слабее, если системы запускают с разными промптами, лимитами или наборами инструментов. Существенны и технические детали:
- размер контекстного окна и объём переданных файлов;
- лимит входных и выходных токенов;
- число разрешённых шагов и повторных попыток;
- доступность поиска, сети, shell-команд и пакетного менеджера;
- версия компилятора, библиотек и операционной системы;
- правила остановки после ошибки или успешного теста;
- возможность задавать агенту дополнительные указания;
- стабильность внешних сервисов и зависимости от сети.
Есть и риск утечки данных. Если задачи, решения или тестовые репозитории давно опубликованы, модель могла встретить похожие примеры во время обучения. Без holdout-набора нельзя отделить способность решать новую задачу от воспроизведения знакомого шаблона.
Как тестировать AI-агентов на небольшом наборе задач
Компактный evaluation начинается с цели. Нельзя одним и тем же набором одинаково хорошо измерить качество модели, удобство CLI-агента, автономность, экономию времени и стоимость API-вызовов.
Шаг 1. Сначала определить, что именно сравнивается
Запишите объект сравнения и решение, которое должен поддержать результат:
- при выборе модели сравнивайте модели при одном агентном каркасе;
- при выборе CLI-агента оставляйте модель и репозиторий неизменными;
- при проверке промпта фиксируйте модель, инструменты и правила остановки;
- при оценке автономного режима запрещайте дополнительные подсказки человека;
- при расчёте экономики учитывайте стоимость всего завершённого workflow.
Цель определяет метрики. Для выбора модели нужен pass rate и характер ошибок. Для ежедневной разработки важнее стоимость успешного кейса, latency и объём ручной доработки.
Шаг 2. Собрать задачи из реального рабочего процесса
Начните с повторяющихся операций из собственного проекта. Подойдут исправление бага, небольшая функция, рефакторинг, написание тестов, изменение конфигурации, диагностика ошибки сборки и обновление документации.
Для каждой задачи зафиксируйте:
- исходный commit или отдельную рабочую копию;
- текст задания и доступный контекст;
- ожидаемое поведение;
- файлы или подсистемы, которые допустимо менять;
- автоматические проверки;
- ручные критерии качества;
- признаки корректного завершения и недопустимого результата.
Смешивайте простые и сложные кейсы. Набор из пяти почти одинаковых исправлений даст красивую, но узкую картину. Для первой версии лучше взять несколько разных задач, чем одну категорию и большое число повторов.
Шаг 3. Зафиксировать одинаковые условия запуска
Создайте воспроизводимый snapshot репозитория. Зафиксируйте версии зависимостей, доступные команды, системные ограничения, модель, системный промпт, лимит времени, лимит токенов и правила человеческого вмешательства.
Человек должен получать одинаковые права во всех вариантах сравнения. Если один агенту разрешают дополнительные подсказки, а другому нет, итог измеряет сочетание агента и оператора. Это допустимый сценарий, но его нужно называть режимом ассистирования, а не автономным тестом.
Шаг 4. Автоматизировать проверку результата
Минимальная проверка включает сборку, unit-тесты, линтер и type checker, если они используются в проекте. Для критичных функций добавьте integration-тесты и отдельные assertions на обратную совместимость.
Проверяйте diff автоматически: число изменённых файлов, удаление публичных интерфейсов, добавление подозрительных зависимостей и изменение конфигурации. Ручная оценка остаётся нужна для читаемости, архитектурной уместности и качества объяснения, но она должна дополнять автоматические критерии.
Собственный harness: недорогая основа для оценки качества AI-агентов
Harness превращает набор задач в повторяемый сценарий. Он подготавливает workspace, запускает агента, ограничивает ресурсы, собирает результат и выполняет проверки. После этого тот же набор можно запускать при смене модели, промпта или версии агента.
Из каких частей состоит минимальный harness
- Конфигурация задачи с идентификатором, описанием, commit и командами проверки.
- Подготовка чистой рабочей директории или контейнера.
- Запуск агента с заданными лимитами времени, токенов и шагов.
- Сбор stdout, stderr, команд, вызовов инструментов и финального ответа.
- Сохранение patch и состояния рабочей директории.
- Запуск тестов, линтера, сборки и дополнительных assertions.
- Сериализация итоговых метрик в JSON или другой машиночитаемый формат.
- Очистка окружения после завершения и маркировка инфраструктурных сбоев.
Изолированные рабочие директории снижают риск, что одна попытка оставит файлы или зависимости для другой. Контейнеры полезны, когда нужно жёстко ограничить сеть, права процесса и версии системных пакетов.
Какие результаты сохранять после каждого прогона
Для каждого запуска сохраняйте статус задачи, patch, логи, время выполнения, число шагов и вызовов инструментов, входные и выходные токены, ошибки проверок, факт вмешательства человека и ручную оценку качества.
Пример структуры результата:
{
"task_id": "build-failure-03",
"status": "failed",
"tests_passed": false,
"elapsed_seconds": 412,
"input_tokens": 18400,
"output_tokens": 6200,
"tool_calls": 27,
"human_interventions": 1,
"failure_type": "functional_failure"
}К этим данным стоит добавлять версии модели, агента, harness и репозитория. Иначе через месяц будет трудно понять, почему результат изменился.
Как отличить ошибку агента от ошибки тестового окружения
Перед запуском выполните базовую проверку: исходная ветка должна собираться, тесты должны проходить, зависимости должны быть доступны. Если baseline уже сломан, результат нельзя относить к агенту.
Ошибки разделяйте минимум на четыре категории: timeout, tool failure, infrastructure failure и functional failure. Сетевой сбой при загрузке зависимости не равен неверному исправлению кода. Повторный запуск инфраструктурной проверки помогает отделить случайный сбой от устойчивой ошибки агента.
Какие метрики использовать вместо одной цифры
Один pass rate скрывает важные различия. Два агента могут решить одинаковую долю задач, но один сделает это за 3 минуты и один проход, а второму потребуются 20 минут, четыре повторения и ручная правка.
Успешность выполнения и качество изменения
Считайте отдельно:
- долю задач, завершённых без помощи человека;
- прохождение автоматических проверок;
- соответствие acceptance criteria;
- число регрессий;
- объём лишних изменений в diff;
- ручную оценку читаемости и архитектурной уместности;
- необходимость последующей доработки.
Полезно хранить не только итоговый статус, но и причину неудачи. Ошибка планирования, неверный API-вызов, плохое чтение контекста и сбой тестового окружения требуют разных исправлений.
Надёжность и повторяемость
Запускайте одну задачу несколько раз при одинаковых условиях. Один успешный прогон ничего не говорит о стабильности. Даже три попытки уже помогают увидеть, воспроизводит ли агент результат или случайно попал в рабочую последовательность действий.
Фиксируйте среднее значение, медиану, разброс и долю успешных повторов. Для небольшого набора не нужно изображать статистическую точность, которой нет. Честная формулировка «4 успешных запуска из 5, один timeout» полезнее псевдоточности до сотых долей процента.
Стоимость успешного решения
Считайте стоимость неудачных попыток и повторов. Среднее число токенов на запуск может выглядеть низким, если дорогие сбои не попали в расчёт. Практичная метрика выглядит так: суммарные расходы на все прогоны, разделённые на число задач, завершённых с приемлемым результатом.
Рядом с этой цифрой храните время и объём ручной работы. Более дешёвый вызов может оказаться дороже для команды, если разработчик тратит много времени на проверку и исправление результата.
Как учитывать токены, latency и вмешательство человека
Оценка должна охватывать полный цикл решения. В него входят контекст, рассуждение, команды, результаты тестов, повторные запросы и финальный ответ.
Почему среднее число токенов может вводить в заблуждение
Разделяйте входные и выходные токены. Размер репозитория и объём истории команд могут сильно увеличить входной контекст, даже если итоговый patch небольшой.
Учитывайте неудачные прогоны, повторные попытки и разные правила остановки. Сравнение имеет смысл только на одном наборе задач при одинаковом лимите времени и сопоставимом объёме доступного контекста.
Latency тоже нужно раскладывать: время до первого действия, время выполнения команд и общая длительность задачи. Для интерактивной работы важна скорость первой полезной реакции. Для фоновой автономной задачи важнее вероятность завершения без контроля и общая стоимость.
Человеческое вмешательство как отдельная метрика
Фиксируйте количество подсказок, корректировок плана, ручных исправлений и перезапусков. Разделяйте:
- полностью автономный режим;
- режим с ответами на вопросы агента;
- режим, где человек направляет план и проверяет каждый шаг;
- режим, где агент только предлагает patch.
Эти режимы решают разные задачи. Смешивать их в одной таблице нельзя. Агент, который проходит тесты после нескольких подсказок, не равен агенту, который достигает того же результата самостоятельно.
Ограничения маленьких бенчмарков и защита от самообмана
Компактный набор отражает конкретную команду и её репозитории. Он не заменяет независимую публичную оценку и может давать большую дисперсию при малом числе задач.
Как уменьшить смещение выборки
Смешивайте задачи разного типа и сложности. Добавляйте новые кейсы, которые не использовались при настройке промпта или выборе инструмента. Разделите набор на development и holdout части: первую можно применять для отладки, вторую оставьте для финального сравнения.
Критерии приемки зафиксируйте до запуска. Версионируйте формулировки задач и периодически обновляйте их, чтобы набор не превращался в коллекцию шаблонов, знакомых одному агенту.
Полезно проводить слепое сравнение. Уберите из итоговой ручной оценки название модели и показывайте проверяющему только patch, логи ошибок и результат автоматических тестов.
Почему нельзя подгонять задачи под один инструмент
Одинаково описывайте задачи для всех кандидатов. Не меняйте правила после просмотра результатов и не исключайте неудобные кейсы, потому что они ухудшают рейтинг выбранной системы.
Если агенту нужен специальный адаптер, это можно разрешить, но такой адаптер должен быть доступен всем сравниваемым системам или учитываться как отдельная часть эксперимента. Иначе тест измеряет качество интеграции, а не только качество агента.
Практическая схема оценки для разных сценариев
Для личного workflow
Выберите 5-10 повторяющихся задач из своего проекта. Подготовьте команды проверки, сохраните исходные commit и сравните несколько запусков по четырём показателям: успешность, время, токены и объём ручной доработки.
Для личного выбора этого обычно достаточно. Через несколько дней повторите часть тестов на новых задачах, чтобы убедиться, что результат не зависит от одного удачного набора.
Для команды разработки
Превратите личный набор в версионируемый regression-тест. Назначьте владельцев задач и критериев, храните конфигурацию harness рядом с кодом, запускайте evaluation после смены модели, промпта или версии агента.
Командный отчёт должен показывать регрессии по категориям: тесты, качество diff, стоимость, latency и ручное вмешательство. Средний балл без разбивки затрудняет поиск причины ухудшения.
Для построения более формальной системы полезны практики из материала об автоматизации тестирования AI-агентов через репозиторий и трейсы. Контейнеризированные тесты и анализ трасс помогают сделать оценку частью инженерного цикла.
Для внедрения в production-процесс
Добавьте проверки безопасности, приватности и воспроизводимости. Ограничьте расходы, сетевой доступ и права на изменение критичных файлов. Логи должны позволять восстановить ход работы агента, а изменения нужно уметь откатить.
Для операций с высокой ценой ошибки оставьте обязательное human review. Автономный режим можно применять к локальным тестовым веткам и некритичным задачам, но правила допуска должны быть описаны заранее.
Итог: когда нужен Terminal Bench 4.0, а когда достаточно своего набора
Terminal Bench 4.0 полезен для общего ориентира, исследования и сопоставления систем по единым правилам, если его методика и результаты подтверждены официальными материалами. Он помогает увидеть, насколько агент справляется с терминальными задачами разработки в заданной постановке.
Собственный harness лучше отвечает на прикладной вопрос: как агент поведёт себя в конкретном репозитории и сколько будет стоить успешное решение. Для личного workflow обычно хватит небольшого smoke test. Команде нужен версионируемый regression-набор. Production-процесс требует контроля безопасности, журналирования, лимитов расходов и human review.
Короткий чек-лист перед сравнением агентов
- Одинаковы ли репозиторий, commit и версии зависимостей?
- Совпадают ли модельные лимиты, промпты, инструменты и правила остановки?
- Заранее ли определены acceptance criteria?
- Есть ли автоматические тесты, линтер, type checker и проверка сборки?
- Учитываются ли неудачные прогоны и инфраструктурные сбои?
- Сохраняются ли patch, логи, токены, время и число шагов?
- Фиксируется ли человеческое вмешательство?
- Есть ли новые или скрытые задачи для проверки обобщаемости?
- Считаете ли вы стоимость одного успешно завершённого кейса?
Какие результаты стоит публиковать или показывать команде
Показывайте описание набора задач, условия запуска, дату последнего обновления, pass rate, разбивку ошибок, стоимость успешного кейса, медианное время, число повторов и ограничения оценки.
Публичный benchmark и локальный evaluation решают разные задачи. Первый создаёт общий язык для сравнения. Второй помогает принять инженерное решение с учётом конкретного репозитория, инфраструктуры и бюджета. Надёжная оценка кодинг-агента начинается с заранее определённого критерия успеха и заканчивается анализом того, сколько контроля потребовалось человеку.
Для практического внедрения полезно дополнить метрики технического прохождения оценкой качества итогового изменения и трассировкой действий. Подходы к оценке сложных агентных сценариев, включая LLM-as-judge, faithfulness и анализ трейсов, разобраны в материале о проверке длинных отчётов AI-агентов. Принцип тот же: цифра становится полезной только вместе с условиями, ошибками и наблюдаемым ходом выполнения.