«Проблема не в том, что мы не умеем обучать агента. Проблема в том, что как только им начинает пользоваться другой человек из команды, всё обнуляется». Так директор хедж-фонда описал команде DailyContext проблему, знакомую всем, кто выводил ИИ-агента в реальную работу: памяти у агентов всё больше, а учиться на собственном опыте они так и не начали.

Человек работает иначе. Senior-аналитик не начинает каждое утро с чистого листа: за годы практики он наращивает не информацию, а суждение. Он знает, какие сигналы важны, какие подходы обычно проваливаются и когда разумное на вид решение стоит перепроверить. Агент выполняет тысячи задач и на следующий день повторяет ту же ошибку. Разница между этими двумя системами и есть тема разбора: почему память ИИ-агентов не превращается в опыт и что нужно изменить.

Ловушка «больше контекста»

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

Команда DailyContext думала так же, пока не прогнала независимые оценки. Результат оказался неприятным: больше контекста не давало стабильного прироста, а в части конфигураций агент работал хуже. Варианты, которые выглядели «полнее», проигрывали простым. Когда авторы начали убирать информацию из запроса, случилось контринтуитивное: агенту становилось лучше. Так авторы формулируют вывод: «Иногда, чтобы агент принимал лучшие решения, ему нужно меньше помнить».

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

Это не единичная аномалия. Мы уже разбирали исследование о проклятии памяти LLM-агентов: чем больше в окне устаревших и лишних фрагментов, тем сильнее размывается внимание модели и тем непредсказуемее становятся решения. Добавьте сюда цену: каждая лишняя тысяча токенов это латентность, деньги и шум, в котором тонет действительно важное.

Факты и опыт: разница, которая всё объясняет

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

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

Разница хорошо видна на примере агента поддержки. «Клиент на тарифе Pro» это факт, который лежит в базе клиентов. «Когда клиент жалуется на списание после апгрейда, сначала проверь дату перехода на новый тариф» это опыт: он родился из сотен разобранных тикетов и избавляет пользователя от лишнего круга диагностики. Первое можно получить запросом к базе. Второе не вычитать ни из одного документа: его нужно вывести из результатов действий и закрепить как правило.

Цикл опыта: пять ступеней

Из этого вырастает главный вывод: память агента стоит проектировать как цикл обучения, а не как архив. Рабочая схема состоит из пяти ступеней: Capture, Evaluate, Consolidate, Retrieve, Update.

Capture фиксирует значимые эпизоды, а не всё подряд. Смысл имеют ситуации, где решение агента повлияло на результат, а не каждая реплика диалога.

Evaluate отвечает за честную оценку: сработала ли стратегия и подтверждён ли результат независимо. Здесь кроется главная ловушка. Повторение стратегии и последующий успех не доказывают причинность: исход мог сложиться из-за удачи или изменившейся среды. Без валидации цикл превращается в конвейер суеверий, где случайное совпадение закрепляется как правило. Вместе с уроком полезно хранить метаданные: когда его последний раз проверяли и в каких условиях он применим.

Проверку при этом нельзя перекладывать на самого агента. Модель охотно подтвердит, что её стратегия сработала, особенно если спросить в лоб. Независимым сигналом может быть тест на похожей задаче, метрика в продакшене или выборочная проверка человеком. Именно он превращает эпизод в урок, которому можно доверять.

Consolidate сжимает повторяющийся опыт: десять похожих провалов не должны становиться десятью отдельными записями, из них должен получиться один урок. Retrieve поднимает нужный урок в нужный момент. Update отвечает за устаревание: стратегия трёхмесячной давности после смены API или политики может стать опасной, и её нужно пересмотреть или удалить.

В обычных системах первые две ступени просто отсутствуют: логи пишутся, но не оцениваются, а без оценки запись не становится уроком. Поэтому склады памяти растут, а поведение агента не меняется.

Progressive disclosure: меньше, но в нужный момент

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

Цель при этом меняется. Не максимум вспомненного, а лучшее решение в конкретной точке. Метрика «сколько наша память умеет доставать» красиво выглядит в демо, но ничего не говорит о качестве решений. Покажите агенту три релевантных урока вместо трёхсот похожих документов, и он с большей вероятностью сделает то, что нужно.

Тот же принцип работает и наоборот: когда памяти слишком мало, агент переспрашивает и повторяет уже пройденное. Равновесие стоит искать по качеству решений, а не по объёму хранилища.

От «помнит» к «улучшается»

Если провести цикл целиком, поведение системы меняется качественно. Агент выполняет задачу, видит результат, извлекает урок, проверяет его и применяет в следующем решении. Полезный урок становится сильнее, устаревший слабеет или удаляется. Со временем накапливается не информация, а надёжные паттерны решений, и это уже ближе к тому самому суждению senior-аналитика, о котором шла речь выше.

Направление совпадает с тем, что происходит в исследованиях. В работе AutoMem память предложили оптимизировать как отдельный навык: мета-LLM перебирает структуру памяти и правила работы с ней, после чего 32-миллиардная модель обгоняет фронтирные системы на длинных игровых задачах. Соседний сюжет объясняет, почему стандартный retrieval для агентов так часто подводит: семантическая похожесть подменяет надёжность источника, и агент уверенно опирается на устаревшее. Мы разбирали это в материале о retrieval-ошибках.

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

Почему повторяющиеся ошибки дороже, чем кажется

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

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

Что делать инженеру уже сейчас

Начните с простой проверки своей системы. Для каждой записи в памяти должно быть понятно, почему она появилась и при каких условиях применима. Успешность должен подтверждать независимый сигнал, а не сам агент по принципу «не упало». У записей должны быть срок годности и процедура ревизии, а на вход агенту стоит подавать минимум контекста под текущее решение, а не всё, что нашлось.

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

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

Частые вопросы

Чем это отличается от дообучения модели?

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

Разве RAG и векторные базы не решают задачу?

Только наполовину. RAG ищет похожее, а для действия нужен не самый похожий документ, а самый надёжный урок с учётом условий применимости. Поэтому факты и опыт стоит хранить раздельно: первый слой отвечает на вопрос «что известно», второй на вопрос «как действовать». Смешивая их, вы получаете агента, который прекрасно помнит мир и не учится жить в нём.

Как понять, что агент действительно учится?

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

Итог

Память без цикла это склад: чем больше полки, тем дороже обслуживание. Ценность появляется на ступенях, где опыт оценивается, сжимается в уроки и вовремя устаревает. Проверить свою систему можно за один вечер: возьмите один повторяющийся провал вашего агента и проведите его через весь цикл вручную. Если урок после этого изменил хотя бы одно решение, механизм работает. Если нет, ищите разрыв между Capture и Retrieve, там теряется смысл.