Объяснение памяти агента: рабочая, эпизодическая, семантическая и процедурная

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

В первой сессии агент взял задачу BUG-142, выявил причину сбоя в порядке выполнения миграций, изменил код, запустил тесты на интеграцию и увидел, что они прошли. Затем сессия завершилась.

Перед следующей сессией система очистила историю разговоров, чтобы снизить затраты на токены. Это был разумный выбор, ведь перезапуск постоянно растущего текста разговора стоит денег, увеличивает задержку и мешает формулировке запросов. Но исчез не только текст разговора. Результаты прошедших тестов хранились только в старом окне контекста. Не было никакой записи о том, что ошибка была устранена, а система отслеживания задач по-прежнему отображала BUG-142 как нерешённую.

Началась вторая сессия: был обнаружен открытый тикет, и было сделано то, что требовалось по этому тикету. Было проведено расследование, был сделан тот же вывод и применена та же коррекция.

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

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

• Рабочая память: задача, которая в настоящее время выполняется.
• Эпизодическая память: что произошло и когда.
• Семантическая память: что считается истинным.
• Процедурная память: как следует выполнять действия.

Память — это не единое понятие. Она выполняет как минимум четыре функции, и большинство ошибок в работе памяти возникают из-за путаницы между ними. Такое разделение заимствовано из когнитивной науки и находит отражение в исследованиях вроде CoALA (Cognitive Architectures for Language Agents), в которых языковые агенты описываются с точки зрения модульной памяти, структурированных действий и процесса принятия решений.

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

Окно контекста — это рабочая поверхность

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

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

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

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

Память — это не текущая истина системы

Сравните два утверждения. Одно — это запись в памяти: «BUG-142 был исправлен во время вчерашней сессии». Другое — это состояние приложения: поле статуса заявки показывает COMPLETED.

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

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

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

Рабочая память: текущая задача

Рабочая память хранит то, что необходимо агенту для выполнения текущей задачи, и немногое другое. Для BUG-142 к этому могут относиться сама задача, текущая гипотеза (таблица зависимостей инициализируется слишком поздно), текущий шаг (запуск набора инструментов для интеграции), последние наблюдения (три теста на миграцию не прошли) и файлы, которые в настоящее время редактируются.

Она отвечает на практические вопросы: какова цель? Какой шаг выполняется в настоящее время? Что вернул последний вызов инструмента? Какие файлы изменились? Что ещё не завершено?

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

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

Её кратковременная продолжительность не является недостатком. После завершения задачи редко бывает причина хранить все промежуточные гипотезы, незаконченные фрагменты текста, неудачные команды или отказанные идеи. Проблемы возникают, когда важный результат существует только здесь. В данном случае исчезли две вещи: результат прохождения теста и факт устранения ошибки BUG-142. Система рассматривала значимый результат как временное хранилище, которое можно игнорировать.

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

Эпизодическая память: запись событий

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

Для BUG-142 полезный описатель эпизода может быть представлен в виде краткой структурированной записи:

• Событие: BUG-142 воспроизведён во время инициализации миграции.
• Контекст: таблица зависимостей не была доступна при запуске сервиса.
• Действие: изменилось порядок выполнения миграций.
• Результат: тесты интеграции пройдены.
• Доказательство: коммит a7f43d2.
• Время: 8 сентября 2026 года, 14:20.

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

Эпизод также не является тем же, что и история чатов. Транскрипт может содержать сотни сообщений, результаты работы инструментов, предположения, корректировки и повторы. Необходимо провести четкое разделение между первоначальным логом, например фразой «Вероятно, стоит проверить порядок инициализации», и кратким описанием эпизода: переупорядочивание процесса инициализации зависимостей решило проблему BUG-142, и тесты прошли успешно при коммите a7f43d2. Второй вариант гораздо проще найти и гораздо полезнее при выполнении последующих задач.

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

Семантическая память: что знает агент

Эпизод фиксирует то, что произошло. Семантическая память фиксирует то, что было извлечено из него.

Эпизод BUG-142 может содержать полезный факт, который можно использовать снова: сервис миграции нуждается в наличии таблицы зависимостей до начала инициализации. Речь уже не идёт о конкретной сессии отладки — это общее утверждение о системе.

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

Разница с эпизодической памятью тонкая, но важная для понимания. В эпизодической версии говорится, что ОШИБКА-142 произошла вчера из-за отсутствия таблицы зависимостей при запуске. В семантической версии указывается, что для инициализации сначала необходимо наличие этой таблицы. Одна память сохраняет сам опыт, другая — уроки, извлеченные из него.

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

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

Процедурная память: как выполняются задачи

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

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

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

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

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

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

Одна ошибка, пять вариантов представления

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

• Рабочая память: «В настоящее время устраняется BUG-142; следующим шагом будут тесты на интеграцию». Она обеспечивает продолжение текущей работы.
• Эпизодическая память: «На первой сессии BUG-142 был устранен путем изменения порядка зависимостей, и тесты пройдены». Она сохраняет определенный опыт.
• Семантическая память: «Службе миграции необходима таблица зависимостей перед инициализацией». Она сохраняет знания, которые можно использовать повторно.
• Процедурная память: «Перед инициализацией миграций необходимо проверить таблицу и запустить тесты на интеграцию». Она сохраняет методы, которые можно применять снова и снова.
• Авторитетное состояние: статус COMPLETED, коммит a7f43d2, тесты PASSED. Оно фиксирует то, что приложение считает истинным.

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

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

Каждый тип выходит из строя по-своему

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

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

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

Семантическая память дает сбои, когда агент уверенно применяет устаревший факт, поскольку этот факт изменился, а старая версия так и не была заменена.

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

Авторитетное состояние дает сбои, когда агент действует на основе неверного статуса задачи, поскольку запись источника истины не была обновлена или проверена.

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

Краткий чек-лист для классификации

Когда агент сталкивается с какой-либо информацией, последовательно задавайте себе эти вопросы.

1. Необходима ли она только для текущей операции? Это рабочая память. Речь идет о текущем плане, последних результатах работы инструментов или временной гипотезе.
2. Является ли это конкретным событием, которое произошло? Это эпизодическая память. Например, неудачная попытка развертывания вчера, несработавшая попытка ремонта или дизайн, отклоненный пользователем.
3. Является ли это знанием, которое можно использовать снова? Это семантическая память. Архитектура, предпочтения, ограничения области, бизнес-определения.

Это рабочий процесс, правило или навык? Процедурная память. Процедура развертывания, чек-лист тестирования, политика использования инструментов или схема передачи задач на более высокий уровень.

Является ли это текущим источником правды? Авторитетное состояние приложения. Статус заявки, баланс счета, состояние развертывания, инвентарь, статус утверждения.

Один опыт часто требует нескольких способов представления. Неудачное развертывание может привести к описанию события (оно провалилось в 14:20), факта (сервису X нужна версия схемы 17), процедуры (проверьте совместимость схемы перед развертыванием) и изменению состояния (развертывание откатировано). Это не бесполезное дублирование, поскольку каждая форма отвечает на разный вопрос.

Что должен был сделать инструмент

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

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

К чему это приводит

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

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

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