Создание памяти агента, которая сохраняет информацию после окончания разговора без избыточного хранения данных.

Сценарий, который повторяется практически с каждым агентом, вступающим в работу, выглядит следующим образом.

В понедельник пользователь говорит, что управляет Северо-Западным регионом, интересуется только активными проектами и терпеть не может длинные ответы. Агент отвечает «Понял», и в течение всей следующей сессии это означает именно это: ответы краткие, касаются только Северо-Западного региона и не содержат черновиков. Пользователь доволен.

Во вторник тот же человек начинает новый чат и спрашивает, как идут его проекты. Агент весело спрашивает, о каком регионе он хочет узнать.

Выражение лица этого пользователя — причина, по которой стоит серьезно задуматься о системе хранения информации.

Почему сохранение всего не срабатывает

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

Предположим, что вся история диалога сохраняется и воспроизводится каждый раз, когда пользователь возвращается. Все происходит в предсказуемом порядке.

На первой неделе всё работает. Агент действительно помнит всё, и вам кажется, что вы умны. Это опасный этап, поскольку кажется подтверждением эффективности дизайна.

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

На шестой неделе всё идёт не так. Никто не предупреждает о этом этапе. В старых разговорах содержатся утверждения, которые уже не соответствуют действительности. Раньше сотрудник сосредотачивался на Северо-Западе, пока повышение не сделало его ответственным за всю страну. Проект задерживался до самого момента выпуска. Повторное просмотрение всего заставляет агента одинаково учитывать устаревшие и актуальные факты. Проблема теперь не в том, что он запоминает слишком мало — он запоминает слишком много, не понимая, что уже устарело.

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

Какие данные стоит сохранять, какие следует загружать по мере необходимости, а какие нужно удалять и генерировать заново?

Если на них ответить, архитектура памяти станет ясной.

Трёхуровневая структура

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

Уровень 1: память сессии, предназначенная для уничтожения

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

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

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

Не записи. Небольшой явный шаг извлечения выделяет три категории:

1. Стабильные факты о пользователе, такие как «управляет Северо-Западным регионом», действительные до отзыва.
2. Предпочтения, такие как «хочет краткие ответы» и «исключить проекты в черновике».
3. Решения, такие как «согласились на формат еженедельного резюме».

Этот чат в понедельник может достигнуть четырех тысяч токенов. То, что заслуживает сохранения, — это примерно сорок токенов структурированных фактов, что соответствует сжатию примерно в сто раз. В отличие от резюме, ничего важного не теряется, поскольку вы извлекали конкретные категории, а не общее впечатление. Резюме незаметно устраняют ограничения, а извлечение — это решение: предпочтение либо попадает в список слово в слово, либо нет, и для этого можно написать тест.

Уровень 2: долгосрочная память, компактная, структурированная и редактируемая

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

{
  "user_id": "u-2481",
  "facts": [
    {"fact": "manages Northwest region", "updated": "2026-08-03"},
    {"fact": "prefers concise answers", "updated": "2026-07-19"}
  ],
  "preferences": [
    {"pref": "exclude draft projects from reports", "updated": "2026-08-03"}
  ],
  "decisions": [
    {"decision": "weekly summary every Monday", "updated": "2026-07-28"}
  ]
}

Несколько десятков строк JSON на пользователя, загружаемых в контекст в начале каждой сессии. Это достаточно дешево, чтобы включать их всегда, и достаточно мало, чтобы не создавать избыточной нагрузки.

Три правила помогают поддерживать порядок.

Структурированный формат лучше прозы. Размытые описания вроде «этот человек, вероятно, отвечает за Северо-Запад и предпочитает краткость» позже бесполезны. Факты же можно показывать пользователю отдельно, корректировать и удалять по отдельности.

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

Позвольте пользователю увидеть информацию и самостоятельно её исправить. Даже простая команда вроде «Вот что я помню о вас» меняет ситуацию. Информация, которую пользователь не может проверить, со временем становится той, которой он не доверяет, обычно в тот момент, когда агент с полной уверенностью сообщает что-то, что уже устарело несколько месяцев назад.

Во второй категории остаётся всё, что можно найти поиском. Это относится к третьей категории, и команды чаще всего тратят на неё усилия впустую.

Третья категория: генерация по запросу, намеренное невоспроизведение в памяти

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

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

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

• Хранится информация «Проект Falcon отложен», а затем проект всё же выпускается. Неделями агент продолжает утверждать, что проект ещё не готов, хотя он уже сдан.
• Хранится информация «В команде 8 человек», а затем присоединяются ещё двое. Все ответы, касающиеся мощностей команды, оказываются неверными.

Самое точное краткое описание всей архитектуры, вероятно, звучит так:

Для фактов, касающихся конкретного человека, используйте память. Для фактов, касающихся всего остального, используйте инструменты.

Предпочтения пользователей редко меняются, и они сами сообщают вам об этом. Мир постоянно меняется, но не сообщает вам ничего. Поэтому помните о пользователе и запрашивайте информацию у мира.

Сценарий сбоя: «поделиться всем» встречается с многокомпонентной системой

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

Агент А общался с пользователями и собирал требования к отчётам. Агент Б готовил эти отчёты. Когда А передавал работу Б, команда повторила ошибку новичков в масштабах всей архитектуры: они передали Б весь контекст А — полные записи разговоров, результаты работы всех инструментов и весь текущий состояние системы. Логика казалась безупречной. Разве больше контекста не означает, что Б будет лучше осведомлён?

Сам способ, которым это произошло, и является важной частью. В ходе одной сессии пользователь вслух задал агенту A вопрос: а что, если включить архивированные проекты? Однако, подумав, он решил, что это исказит общие показатели, и предложил их не включать. Это было совершенно обычное мысленное высказывание, и агент A правильно с ним разобрался.

Затем произошла передача данных, и агент B получил полный текст переписки, включая несвязанные сутью комментарии. У агента B же не было никакого контекста разговора с агентом A, чтобы оценить эту информацию. В передаваемых данных не говорилось, что идея с архивированными проектами была отклонена, и вне контекста это выглядело как указание. Агент B верно включил архивированные проекты, в результате чего показатели в официальном отчете оказались неверными по причине, которую никто не смог выяснить, изучив его код, хотя код сам по себе был в порядке.

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

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

{
  "task": "generate weekly regional report",
  "requirements": [
    "region: Northwest",
    "active projects only",
    "exclude drafts AND archived"
  ],
  "format": "summary table first, details after",
  "constraints_confirmed_by_user": true
}

Это примерно пятьдесят токенов без какой-либо двусмысленности. B получает выводы, а не сложный путь к ним. Класс ошибок «archived-projects» стал недостижимым — его нельзя просто обнаружить или устранить, поскольку заброшенные идеи физически не могут сохраниться при включении в список требований.

Возьмем одно предложение в любой дизайне с участием нескольких агентов: агенты должны передавать друг другу выводы, а не протоколы разговора.

Чек-лист для применения на этой неделе

Пять решений, которые вы можете принять относительно существующего агента:

1. Позвольте памяти сессии исчезнуть. Добавьте шаг извлечения в конце сессии или после N ходов, который будет передавать только факты, предпочтения и решения, позволяя остальному утрачиваться вместе с чатом.
2. Сохраняйте Tier 2 в виде простого JSON. Дискретные элементы, временные метки, обновления. Никогда не позволяйте формироваться растущему блоку прозы, и никогда не используйте режим добавления только в конец.

Предоставьте пользователям возможность получить информацию. Вопрос вроде «Что вы помните обо мне?», даже самый примитивный, способствует формированию доверия и позволяет бесплатно выявить устаревшие данные.

Проводите аудит уровня 2 для фактов о мире. Всё, что инструмент может получить в актуальном виде — такое как статусы, количество, даты и цифры — должно быть заменено. Память предназначена для пользователя, а инструменты — для информации о мире.

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

Вывод

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

Успешная работа памяти агента во многом зависит от умения забывать. Состояние сессии может исчезнуть, долгосрочные заметки должны быть достаточно краткими, чтобы их можно было прочитать за один взгляд, а всё новое, что может сообщить мир, не сохраняется в памяти. Агенты, которые кажутся по-настоящему персонализированными, — это не те, что помнят всё. Они запоминают ровно сорок токенов.