AI-агенты тоже стареют: новый тест показывает, как память ломает долгие задачи

Агента надо проверять не только в первый день

Команда исследователей из University of Texas at Austin представила AgingBench — benchmark для проверки того, как AI-агенты ведут себя после долгой эксплуатации. Идея простая, но важная: постоянный агент не остаётся «свежей» моделью. Он сжимает историю, складывает факты в память, достаёт похожие записи, обновляет старые сведения и иногда проходит обслуживание вроде очистки или пересборки контекста.

Обычные тесты часто смотрят на day-one качество: дали задачу, получили ответ, сравнили с эталоном. Для чат-бота этого иногда достаточно. Для агента, который неделями ведёт проект, помнит договорённости, читает файлы, управляет задачами или помогает команде, этого мало. Надёжность становится свойством всей системы: модели, памяти, retrieval, сжатия контекста, инструментов и правил восстановления после сбоев.

В arXiv-статье авторы формулируют это как «agent lifespan engineering» — инженерия срока службы агента. AgingBench проверяет не только деградацию, но и механизм поломки: где именно система теряет качество и что надо чинить.

Четыре способа, которыми агент деградирует

Исследователи выделяют четыре типа старения. Compression aging возникает, когда краткое резюме прошлых сессий выбрасывает деталь, которая позже окажется важной. Interference aging появляется, когда в памяти накопилось много похожих записей и нужный факт тонет среди соседних. Revision aging — это ошибки обновления: агент помнит старую версию состояния или неправильно пересчитывает вывод после изменений. Maintenance aging связан с обслуживанием самой системы: очисткой истории, повторным сжатием, переносом памяти или другим lifecycle-событием.

Масштаб теста достаточно широкий для раннего benchmark: 7 сценариев, 14 моделей, разные политики памяти, runner-controlled и автономные агенты, более 400 прогонов длиной от 8 до 200 сессий. На сайте AgingBench команда приводит несколько показательных цифр. В одном сценарии максимальное падение recall за 10 сессий дошло до 85% при неизменных весах и том же scaffolding. В другом политика памяти дала 4,5-кратный разброс по half-life. В сценарии с flush-history обслуживание вызвало 67% post-shock cliff без восстановления.

Отдельно важно, что деградация не всегда выглядит как очевидная глупость. Поведенческие тесты могут оставаться зелёными, пока точность фактов уже падает. Один и тот же неправильный ответ может требовать разных исправлений: где-то проблема в записи факта, где-то в поиске, где-то в использовании найденного контекста.

Почему это важно для реальных ассистентов

Для рынка агентов это неприятный, но полезный поворот. Компании часто рассуждают так: если заменить модель на более сильную, агент станет надёжнее. AgingBench показывает, что это не обязательно. На сайте проекта отдельно отмечен пример, где переход внутри Claude Code CLI с Sonnet 4.6 на Opus 4.7 не дал автоматического улучшения в долгом сценарии: mean recall в S7 снизился с 0,82 до 0,79.

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

Практический вывод для команд довольно прямой. Если агент должен работать неделями, его нельзя проверять только на наборе одноразовых задач. Нужны longitudinal-тесты: прогон через серию сессий, проверка восстановления после обслуживания, измерение точности памяти, контроль конфликтов и понятный протокол ремонта. Иначе можно получить систему, которая отлично проходит демо, но постепенно теряет смысл именно тогда, когда пользователь начинает ей доверять.