Оценка AI-агентов долго строилась по модели экзамена с вопросами и ответами: дай правильный вывод — получи балл. Это работает для знаний, но плохо предсказывает, что произойдёт, когда агент получит доступ к терминалу и реальным файлам. Terminal-bench — собирательное название для класса бенчмарков, которые закрывают этот разрыв. Агенту дают цель и командную строку, засчитывают только достигнутый проверяемый результат.
Бинарная метрика и изолированный контейнер
Ключевое отличие от стандартных тестов — строгость критерия. Задача либо решена и прошла автоматическую верификацию состояния файловой системы или процессов, либо не решена. Никакого частичного кредита за «почти правильный ответ» нет. Агент работает в изолированном контейнере, поэтому после каждой сессии можно точно зафиксировать итоговое состояние окружения и сравнить с ожидаемым.
Типичные задачи из таких наборов: настроить виртуальное окружение под конкретные зависимости, починить упавший сервис по логам ошибок, провести рефакторинг скрипта без изменения внешнего поведения, восстановить работоспособность CI-пайплайна. У каждой задачи нет единственного канонического решения — оценивается результат, не траектория. Это поощряет адаптивность, а не заученные паттерны.
Формат сложнее в подготовке, чем классические наборы: каждую задачу нужно обернуть в воспроизводимое начальное состояние контейнера и написать детерминированную проверку итога. Зато и диагностическая ценность несопоставимо выше — такие бенчмарки замеряют именно то, на что агента планируют использовать в production.
Три источника провалов
Анализ результатов выявил устойчивые паттерны неудач. Первый — деградация на длинных траекториях. Модель, уверенно справляющаяся с одиночным шагом, разваливается на сценариях из 15–20 действий: ошибки накапливаются, и агент не распознаёт момент, когда тупик стал неизбежен. Вместо того чтобы откатиться и попробовать иначе, он продолжает повторять неэффективные команды, расходуя бюджет вычислений впустую.
За этим стоит конкретная архитектурная причина: модель, обученная быть полезной и давать ответы, плохо обучена распознавать собственный тупик. На коротком горизонте сигнал ошибки очевиден. На длинной траектории состояние накапливается, и ошибка могла произойти пятнадцать шагов назад — теперь каждый следующий шаг кажется разумным сам по себе, но ведёт дальше в неправильном направлении.
Второй — проблема со state tracking. На длинных траекториях агент теряет из виду, что уже сделано и что ещё не сделано. Он может дважды выполнить одно действие, пропустить шаг, который сам же запланировал, или попытаться применить команду к файлу, который только что переименовал. Это не ошибка знаний — это ошибка внимания при многошаговом планировании.
Третий — разрыв между планированием и исполнением. Модель формулирует правильный план, затем ошибается в конкретных командах: путает пути, неверно цитирует аргументы, не учитывает ответ системы на предыдущий шаг. Высокий score на вопросно-ответных тестах слабо коррелирует с успехом здесь — можно прекрасно знать, как работает grep, и при этом систематически ошибаться в синтаксисе при реальном использовании.
Что говорят актуальные результаты
Данные по нескольким опубликованным наборам этого класса — включая SWE-bench Verified, который давно стал референсным для coding-агентов, и более новые терминально-ориентированные оценки — показывают одну тенденцию: лидеры меняются быстро, но абсолютные цифры остаются скромными. Даже лучшие агенты решают 40–60% задач средней сложности. На задачах, требующих длинных многошаговых траекторий, цифры падают ниже 30%.
Разрыв между моделями на этих тестах тоже иной, чем на классических. Модели, близкие по score на MMLU или HumanEval, могут радикально расходиться в интерактивных средах — из-за разного поведения при ошибке, разной стратегии восстановления, разной устойчивости к длинным контекстам действий. Бенчмарк выявляет характеристики, которые стандартные тесты полностью скрывают.
Динамика прогресса за последние полгода показательна: прирост на коротких задачах замедляется, а разрыв между короткими и длинными траекториями не сокращается. Это значит, что улучшения в базовом кодировании и знаниях не переносятся автоматически на агентную надёжность. Это разные компетенции, требующие разных подходов к обучению.
Почему классические бенчмарки не предсказывают агентное поведение
Разрыв между score на HumanEval и результатами в интерактивной среде объясняется несколькими факторами. HumanEval и аналоги проверяют, может ли модель написать правильный код при идеальных условиях: чёткая спецификация, изолированная задача, нет побочных эффектов. Реальный агентный сценарий — совсем другое: неполная спецификация, накопленное состояние среды, необходимость корректировать план по ходу.
Кроме того, классические кодовые тесты оценивают один выход — сгенерированную функцию или класс. Агентный бенчмарк оценивает последовательность из десятков действий, каждое из которых влияет на следующее. Это принципиально другая задача с принципиально другими требованиями к надёжности и согласованности поведения.
Практический вывод для команд
Для тех, кто внедряет агентов в рабочие процессы, из этого следует конкретная рекомендация: результаты на классических бенчмарках — необходимое, но недостаточное условие. Прежде чем выбрать модель для агентной задачи, нужно прогнать её именно на задачах, близких к целевому сценарию, и в первую очередь посмотреть, как она обрабатывает ошибки и восстанавливается из тупика.
Механизмы контроля на уровне оркестратора — тоже не опция. Если агент может выполнить разрушительное действие без подтверждения, вопрос не в том, произойдёт ли это, а в том, когда. Изолированные контейнеры, чекпойнты состояния, бюджеты на число шагов — стандартные меры, которые обязательны при production-деплойменте.
Появление строгих интерактивных бенчмарков — признак взросления всего направления. Пока агентов оценивали по демонстрациям на специально подобранных примерах, легко было переоценить их готовность к реальным задачам. Бинарная метрика в изолированной среде возвращает разговор к измеримым результатам — и отделяет реальный прогресс от хорошо поставленных показательных запусков.