Long-horizon задачи: почему ИИ-агенты теряют фокус

Дайте современному ИИ-агенту одну изолированную задачу — написать функцию, разобрать письмо, найти баг в двадцати строках — и он справится. Дайте ту же модель на длинную цепочку из десятков шагов: собрать проект, прогнать тесты, поправить зависимости, задеплоить — и на каком-то шаге агент забудет, зачем всё начиналось, зациклится на одной ошибке или начнёт чинить то, что уже работало. Это не единичный сбой, а системное свойство. Проблема long-horizon задач (задач с длинным горизонтом — многошаговых, где успех зависит от десятков последовательных действий) сейчас главный барьер между демо и реальным продуктом.

Что такое «длинный горизонт» и почему это отдельная проблема

Короткая задача измеряется одним-двумя обращениями к модели. Длинная — это план, который агент¹ держит в голове, пока выполняет цепочку из десятков или сотен шагов, каждый из которых зависит от результата предыдущего. И здесь работает жестокая арифметика.

Если на каждом шаге агент прав с вероятностью 95%, то на десяти шагах сквозная вероятность довести задачу до конца — примерно 60%. На двадцати — около 36%. На сорока — меньше 13%. Ошибки не прощаются, а накапливаются: один неверный вызов инструмента посреди цепочки уводит всё остальное в сторону, и агент честно продолжает выполнять уже сломанный план.

Одиночный шаг агента можно сделать почти безупречным. Длинную задачу это не спасает: надёжность перемножается, а не складывается.

Именно поэтому «горизонт» стал отдельной метрикой. Исследовательская организация METR в работе «Measuring AI Ability to Complete Long Tasks» (2025) предложила мерить не проценты на бенчмарке, а длину задачи: сколько времени заняла бы у человека работа, которую агент выполняет с 50-процентной надёжностью. Их вывод — эта «временная длина» задач у передовых моделей растёт экспоненциально, удваиваясь примерно каждые семь месяцев. То есть агенты действительно тянут всё более длинные цепочки, но абсолютный горизонт пока измеряется десятками минут человеческой работы, а не днями. Точные цифры и методику стоит смотреть в самом отчёте METR.

Где именно ломается фокус

Контекстное окно переполняется

Каждый шаг длинной задачи дописывает в контекст² новые данные: вывод команды, содержимое файла, сообщение об ошибке, промежуточные рассуждения. Окно не бесконечно, и даже там, где формально помещается 200 тысяч токенов, к середине задачи оно забито логами и мусором. Исходная цель, сформулированная в первом сообщении, оказывается погребена под гигабайтами вывода.

«Потерянное в середине»

Даже когда всё формально влезло в окно, модель использует его неравномерно. Работа Liu et al. «Lost in the Middle» (2023) показала: модели заметно хуже достают факты, лежащие в середине длинного контекста, чем те, что в начале или в конце. Для длинной задачи это значит, что важная инструкция, отданная на пятом шаге из сорока, к тридцатому уже фактически невидима для модели — она физически в контексте, но внимание до неё не дотягивается.

Дрейф цели и зацикливание

Без явной внешней «памяти» о цели агент подменяет исходную задачу локальной. Столкнувшись с ошибкой сборки, он углубляется в неё, пробует один и тот же фикс по кругу, тратит шаги — и теряет из виду, что ошибка была побочной, а не главной. Наблюдаемый паттерн: чем длиннее лог неудачных попыток в контексте, тем упорнее модель повторяет то, что уже не сработало, потому что весь недавний контекст «намекает» ей продолжать в том же направлении.

Как с этим борются: четыре подхода

Единого решения нет — есть набор инженерных приёмов, которые складывают в то, что Anthropic и другие называют context engineering: осознанное управление тем, что и когда попадает агенту в контекст. Основные стратегии:

• Компакция (сжатие истории). Периодически свернуть накопленный лог в короткое резюме: что сделано, что осталось, какие факты важны. Освобождает окно, но резюме теряет детали.
• Внешняя память и RAG³. Хранить факты и промежуточные результаты вне окна, подтягивая только релевантное под текущий шаг. Снимает переполнение, но добавляет риск подтянуть не то.
• Суб-агенты. Разбить длинную задачу на подзадачи, каждую отдать отдельному агенту с чистым контекстом, а координатору вернуть только итог. Изолирует ошибки, но усложняет систему и стоит больше вызовов.
• Явный план и чек-лист. Заставить агента вести отдельный документ с целью и списком шагов, сверяясь с ним на каждой итерации. Держит фокус, но требует дисциплины в промптах и всё равно упирается в качество самой модели.

На практике их комбинируют: планировщик ведёт чек-лист, суб-агенты выполняют куски, RAG кормит их фактами, компакция подчищает историю. Ни один приём в одиночку горизонт радикально не удлиняет.

Кому это пригодится, а кому нет

Понимание, где агент теряет фокус, полезно не всем одинаково.

Пригодится, если вы:

• строите продакшн-агента для кодинга или обработки данных, где задача — это десятки шагов, и вам важно, чтобы она доходила до конца, а не до середины;
• автоматизируете рутину с ветвлениями (разобрать входящие, классифицировать, ответить, эскалировать) — здесь дрейф цели бьёт по каждому пропущенному случаю;
• считаете деньги: суб-агенты и длинные контексты множат число токенов, и понимание, где реально нужна длинная память, а где хватит чек-листа, напрямую влияет на счёт.

Скорее не нужно, если вы:

• используете модель как ассистента для коротких разовых задач — один вопрос, один ответ, один документ; здесь горизонт короткий и проблема не проявляется;
• работаете в сценарии, где человек всё равно проверяет каждый шаг: тогда накопление ошибок гасится ручным контролем, и городить многоагентную архитектуру нет смысла.

Что это значит на ближайшее время

Маркетинговое «наш агент делает всё сам» стоит читать с поправкой на горизонт. Демо длиной в три шага почти ничего не говорит о том, что будет на тридцати. Если вы выбираете или строите агентную систему, спрашивайте не про размер контекстного окна, а про то, как система удерживает цель на длинной дистанции: есть ли компакция, ведётся ли план, изолированы ли ошибки. По данным METR горизонт растёт, но пока он ближе к десяткам минут человеческой работы, чем к автономному рабочему дню, — и планировать внедрение честнее исходя из этого, а не из обещаний.

¹ Агент — система, где модель не просто отвечает текстом, а в цикле сама решает, какие инструменты вызвать (запустить код, сходить в поиск, прочитать файл), и использует результаты для следующего шага.

² Контекстное окно — максимальный объём текста в токенах, который модель «видит» за один вызов: и ваш запрос, и вся история, и подтянутые данные. Что не влезло — для модели не существует.

³ RAG (retrieval-augmented generation) — подход, при котором нужные факты не держат в контексте постоянно, а достают из внешнего хранилища под конкретный запрос и подставляют модели только релевантный кусок.