Long-Horizon-Terminal-Bench: почему AI-агенты теряют нить в долгих terminal-задачах
LHTB показывает, где ломаются long-horizon AI-агенты: 46 terminal-задач, dense reward, 9,9 млн токенов на запуск и слабый pass@1 даже у лучших моделей.
Long-Horizon-Terminal-Bench: почему AI-агенты теряют нить в долгих terminal-задачах
По состоянию на 13 июля 2026 года Long-Horizon-Terminal-Bench, или LHTB, — это новый бенчмарк для AI-агентов, которые работают в терминале не пять минут, а десятки и сотни шагов подряд. В arXiv-версии авторы дают 46 задач из девяти категорий: от воспроизведения научных экспериментов и разработки ПО до мультимодального анализа, игр, научных вычислений и профессиональных APEX-сценариев.
Главный вывод неприятный для всей идеи автономных агентов: даже сильные модели пока плохо держат длинную траекторию. В arXiv v1 лучший pass@1 при пороге partial reward 0.95 — 15,2%, при идеальном reward 1.0 — 10,9%. Средний запуск требует около 9,9 млн токенов, 231 эпизода и 85,3 минуты. Это уже не демо «модель вызвала инструмент». Это проверка, может ли агент не потерять цель, когда работа тянется почти полтора часа.
Что именно измеряет Long-Horizon-Terminal-Bench
LHTB проверяет не знание синтаксиса и не способность написать один файл. Агент попадает в контейнеризированную terminal-среду, получает задачу, запускает команды, читает вывод, чинит ошибки, пересобирает артефакты и в конце проверяется скрытым верификатором. Самоотчёт «я почти сделал» не считается: зачёт даёт только воспроизводимый результат.
В этом LHTB отличается от коротких проверок кода. Если задача заканчивается после пары команд, pass/fail ещё терпим. Но в длинной работе почти все модели могут застрять на промежуточном прогрессе: восстановили часть конвейера, нашли часть данных, прошли часть тестов, но не дошли до финала. Поэтому авторы используют dense reward: дробную оценку от 0 до 1, где агент получает частичный зачёт за реально пройденные подзадачи.
| Что проверяет LHTB | Как это устроено | Почему это важно |
|---|---|---|
| Длинный горизонт | Задачи требуют сотен действий и до 90 минут работы в терминале | Модель должна удерживать цель, состояние среды и историю решений |
| Реальный прогресс | Скрытый верификатор переигрывает артефакты и начисляет частичный reward | Самоотчёт агента не засчитывается, только проверяемая работа |
| Разнообразие задач | 46 задач в девяти категориях: код, научные вычисления, мультимодальность, игры, security и APEX | Нельзя выиграть бенчмарк одной узкой способностью |
| Цена траектории | Авторы считают токены, эпизоды, время и стоимость запусков | Долгий агентный цикл дорог сам по себе, даже если финальный результат не получен |
Эта рамка хорошо стыкуется с соседним разбором Toolarium о том, почему pass/fail уже мало для coding agents. Чем сложнее задача, тем хуже бинарная метрика: она превращает разные степени прогресса в один и тот же ноль. LHTB делает этот ноль более информативным.
Результаты arXiv v1: прогресс есть, устойчивости мало
В arXiv v1 авторы проверили 15 передовых моделей. По их данным, сильнейшая конфигурация в таблице — GPT-5.5: 17,4% pass@1 при reward ≥ 0.9, 15,2% при reward ≥ 0.95 и 10,9% при reward = 1.0. Средний pass rate по моделям намного ниже: 4,3% при пороге 0.95 и 1,7% при идеальном reward.
Здесь не стоит делать заголовок «GPT-5.5 провалился». Результат тоньше. Модель явно умеет продвигаться дальше других, но даже лучший результат оставляет большую часть задач незавершённой. Если смотреть на строгий финальный зачёт, бенчмарк почти пустеет: десять из пятнадцати моделей в arXiv v1 не решают ни одной задачи на идеальный reward.
Отсюда и польза partial credit. На сложных задачах бинарная метрика показывает в основном «почти никто не прошёл». Dense reward показывает, кто дошёл до 20%, кто до 60%, а кто действительно собрал воспроизводимый результат. Для разработчиков агентных систем это важнее красивой таблицы результатов: можно понять, где агент застрял, а не только увидеть красный крестик в конце.
Почему агенты ломаются на длинной траектории
У LHTB есть простое объяснение сложности: агенту нужно не один раз угадать правильный ход, а долго поддерживать рабочий цикл. Он должен планировать, запускать команды, читать ошибки, менять гипотезу, не потерять старые ограничения и вовремя понять, что он ушёл в тупик. Это ближе к настоящей работе разработчика или исследователя, чем к задаче «исправь один тест».
Официальная страница проекта формулирует проблему жёстко: агенты «break at the horizon», то есть ломаются не на старте, а на длине. В выводах проекта указано, что средний run всё равно занимает 231 шаг, 9,9 млн токенов и около 85 минут, а 79% unresolved runs завершаются таймаутом, пока агент ещё активно делает что-то полезное. Это важная деталь: многие провалы не выглядят как мгновенная ошибка. Скорее агент медленно сжигает бюджет, не доводя работу до проверяемого финала.
В практическом языке это четыре типовых сбоя:
- дрейф состояния: агент забывает, почему уже принял решение или какой файл был источником правды;
- зацикливание: команды и исправления повторяются, но reward почти не растёт;
- плохая самопроверка: агент считает задачу почти решённой, но скрытый верификатор видит недостающий артефакт;
- неуправляемая стоимость: токены и время тратятся быстрее, чем растёт проверяемый прогресс.
Этим LHTB перекликается с материалом про другую проверку long-horizon AI-агентов. CEO-Bench смотрит на бизнес-симуляцию, LHTB — на терминальную работу. Но слабое место похоже: локальные умения уже есть, устойчивой линии на длинном горизонте всё ещё не хватает.
Стоимость тоже не всё объясняет
Ещё один полезный слой LHTB — цена. В arXiv v1 Figure 5 показывает cost-reward frontier: более дорогой запуск не гарантирует лучший pass rate. GPT-5.5 находится на верхней границе по результату, но рядом видны модели, которые дают заметный partial reward за меньший бюджет. Это не значит, что дешёвые модели «лучше». Это значит, что оценивать агента только по названию модели бессмысленно: важны обвязка оценки, лимиты, число шагов, стратегия сжатия контекста и способность восстанавливаться после ошибок.
Это напрямую связано с темой как token budget меняет оценку AI-агентов. Увеличить бюджет можно, но это не равно «дать агенту больше интеллекта». Иногда дополнительное время помогает исследовать пространство решений. Иногда оно только растягивает неудачную траекторию и делает провал дороже.
Почему arXiv v1 и срез проекта нельзя смешивать
У этой новости есть редакционный нюанс. arXiv v1 был отправлен 9 июля 2026 года и описывает эксперимент с 15 передовыми моделями. Официальный сайт проекта и GitHub README уже показывают обновлённый срез July 2026: в README перечислены 20 моделей, а в тексте сайта встречаются формулировки про 17/18 моделей и живую таблицу результатов. Там Grok 4.5 выходит на первое место с mean reward 0.505 и 13 решёнными задачами из 46 при пороге 0.95.
Это не обязательно ошибка. Скорее проект живёт быстрее paper: arXiv фиксирует версию v1, сайт и README обновляют таблицу результатов. Но для статьи это стоп-сигнал: нельзя брать 15 моделей из arXiv, 20 моделей из README, один график с сайта и смешивать их в одну таблицу без даты. Поэтому в этом материале стабильная основа — arXiv v1, а срез проекта упоминается отдельно как живой слой, который надо перепроверять перед любым обновлением.
| Источник | Что фиксирует | Как использовать в статье |
|---|---|---|
| arXiv v1, submitted 9 Jul 2026 | 46 задач, 9 категорий, 15 моделей, 9,9 млн токенов, 231 эпизод, 85,3 минуты, 15,2% pass@1 при reward ≥ 0.95 | Основная база фактов и графиков |
| Project page / GitHub, проверено 13 Jul 2026 | Живой July-срез, обновлённая таблица результатов, GitHub README с 20 моделями | Только как отдельный обновляемый слой, без смешивания с arXiv-таблицами |
Что это меняет для команд, которые строят агентов
Первый вывод: демо с удачным tool call больше ничего не доказывает. Агент может красиво исправить один файл и всё равно развалиться на задаче, где нужно держать 200 шагов, перезапускать проверки и помнить, что было сделано час назад.
Второй вывод: обвязка оценки становится частью продукта. Если команда хочет запускать AI-агента в разработке, аналитике или операционных задачах, ей нужны не только промпты, но и журнал действий, контрольные точки, откат, таймауты, частичная оценка прогресса и понятное правило остановки. Иначе длинный агентный запуск превращается в дорогой чёрный ящик.
Третий вывод: long-horizon agents надо оценивать по траектории, а не только по финальному ответу. В LHTB важны команды, промежуточные артефакты, скрытые проверки и кривая reward. В реальной компании аналогично: недостаточно спросить, «сделал ли агент задачу». Нужно видеть, как он к ней шёл, где потратил бюджет и почему решил остановиться.
Короткие ответы по Long-Horizon-Terminal-Bench
Что такое Long-Horizon-Terminal-Bench?
Long-Horizon-Terminal-Bench — бенчмарк из 46 долгих terminal-задач для AI-агентов. Агент работает в контейнере, выполняет команды, создаёт артефакты и получает оценку от скрытого верификатора.
Почему LHTB использует partial credit?
На длинных задачах бинарный pass/fail часто превращает почти все результаты в ноль. Partial credit показывает, насколько далеко агент продвинулся, даже если финальная задача не закрыта полностью.
Какой главный результат arXiv v1?
В arXiv v1 лучший pass@1 при reward ≥ 0.95 равен 15,2%, а при reward = 1.0 — 10,9%. Средний запуск требует около 9,9 млн токенов, 231 эпизода и 85,3 минуты.
Можно ли сравнивать arXiv v1 и GitHub README напрямую?
Только с явной маркировкой источника и даты. arXiv v1 фиксирует эксперимент с 15 моделями, а сайт проекта и GitHub README уже показывают обновляемый July-срез с другими числами.
Главное
Long-Horizon-Terminal-Bench полезен не как очередная таблица победителей. Он показывает более важную границу: современные AI-агенты уже умеют делать отдельные шаги, но длинная terminal-работа требует устойчивой памяти, самопроверки, управления бюджетом и способности не терять нить после десятков команд.
Для разработчиков агентных систем это трезвый сигнал. Следующая гонка будет не только за более сильной моделью, но и за harness, который умеет держать состояние, измерять частичный прогресс и вовремя останавливать бесполезную траекторию.
Источники и проверка фактов
Факты, даты, числа бенчмарка, внутренние ссылки и изображения проверены 13 июля 2026 года. LHTB — свежий исследовательский проект: перед публикацией или обновлением текста нужно перепроверить arXiv, страницу проекта, GitHub README и таблицу результатов.
- arXiv: Long-Horizon-Terminal-Bench, submitted 9 Jul 2026; использовано для даты, авторов, abstract, 46 задач, 9 категорий, 15 моделей, 9,9 млн токенов, 231 эпизода, 85,3 минуты и pass@1.
- arXiv HTML version; использовано для Figure 3, Figure 5, описания структуры задач, dense reward и arXiv-графиков.
- Официальная project page LHTB; использована для формулировок про 90-минутный budget, hidden verifiers, task categories, выводы и живой срез проекта.
- GitHub: zli12321/LHTB; использован для проверки README, открытого репозитория, Apache-2.0 license, task layout, assets и обновлённого July-среза.
