AI Agent Memory Architecture 2026: продакшен

Симптом: память агента смешивает диалоги, факты, ошибки и состояние задач, поэтому ответы становятся непредсказуемыми, а удаление данных ломает аудит. Быстрое решение: в AI Agent Memory Architecture 2026 разделите систему минимум на краткосрочный контекст, факты, события, состояние задач и аудиторские записи — с отдельными правилами записи, поиска, срока хранения и доступа.

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

Почему единое хранилище памяти не выдерживает продакшен-нагрузку

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

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

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

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

Наконец, единая память усложняет расследование. Для ответа нужно отличать пользовательский факт, результат поиска, правило системы, вывод модели и выполненное действие. Такая трассировка должна сохраняться отдельно от обычного контекста. В рекомендациях по безопасным агентным системам отдельно выделяются риски отравления памяти, утечки общей памяти и необходимость изоляции сессий. (docs.aws.amazon.com)

Поэтому Agent Memory следует проектировать как набор специализированных слоёв, а не как «векторную базу для всего».

Какие слои нужны в архитектуре Agent Memory

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

1. Краткосрочный контекст — сообщения текущей сессии, последние результаты инструментов, активные инструкции и временный план. Его задача — поддерживать текущий запуск, а не становиться вечной памятью.
2. Фактическая память — устойчивые сведения о пользователе, проекте, организации или объекте. Каждая запись должна иметь владельца, источник, время подтверждения, уровень уверенности и признак актуальности.
3. Событийная память — последовательность значимых событий: обращение клиента, изменение настроек, завершение шага, ошибка внешнего API или решение оператора. Здесь важнее время и причинная связь, чем семантическое сходство.
4. Состояние задачи — цель, параметры запуска, уже выполненные шаги, ожидающие подтверждения действия, внешние идентификаторы и контрольные точки. Этот слой нужен для возобновления, повторов и идемпотентности.
5. Аудиторский слой — неизменяемая или отдельно защищённая запись о входных фактах, найденных источниках, применённых правилах, вызовах инструментов, ответе модели и финальном действии.

Краткосрочное состояние и долгосрочные данные действительно имеют разные функции: первая часть привязана к текущему потоку, а вторая может использоваться между несколькими потоками и взаимодействиями. Документация по персистентным агентным процессам также разделяет контрольные точки текущего выполнения и долговременное хранилище пользовательских фактов или общей информации. (langchain-ai.github.io)

Для каждого слоя заранее задайте пять полей политики:

• кто может читать данные;
• кто может создавать, изменять и удалять записи;
• какие условия допускают запись;
• как выполняется Memory Retrieval;
• когда данные истекают, архивируются или удаляются.

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

Как перестроить архитектуру под реальные сценарии

Клиентский сервис: факты пользователя отдельно от корпоративных знаний

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

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

Каждый ответ стоит связывать с:

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

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

Кодовый агент: правила проекта не равны опыту отладки

Для агента, работающего с кодом, полезно разделить:

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

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

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

Мультиагентная платформа: общее чтение, ограниченная запись

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

• приватную память пользователя;
• память конкретной задачи;
• память команды или проекта;
• общую справочную память;
• аудиторские записи.

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

При конфликте не перезаписывайте старую запись молча. Создайте новую версию, отметьте противоречие и передайте решение в детерминированное правило или человеку. Подход с ограниченными правами записи и единым контролем общих взаимодействий снижает риск повреждения общей памяти и упрощает аудит. (docs.aws.amazon.com)

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

Длинные процессы: состояние задачи должно быть восстанавливаемым

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

task_id
goal
tenant_id
current_step
completed_steps
pending_approval
external_effects
idempotency_keys
last_checkpoint
state_version

Перед возобновлением выполните пять проверок:

1. существует ли задача и принадлежит ли она нужной организации;
2. совпадает ли версия схемы состояния;
3. подтверждены ли внешние результаты предыдущего шага;
4. не истёк ли срок действия разрешения;
5. можно ли безопасно повторить следующий вызов.

Контрольная точка не гарантирует безопасность повторного выполнения. Если после сохранения состояния агент снова отправит платёж, создаст заказ или изменит запись, операция должна иметь ключ идемпотентности либо предварительную проверку результата. Документация по возобновляемым графам прямо предупреждает, что после сбоя узел может выполняться повторно; побочные эффекты нужно делать идемпотентными или отделять в повторно используемые задачи. (langchain-ai.github.io)

Где хранить Agent Memory и как выбирать хранилище

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

Векторный индекс полезен для поиска похожих фактов и эпизодов, но не должен быть единственным источником истины. Для прав, удаления, версий и транзакционного состояния вам потребуется структурированное хранилище. Для документов с разными уровнями доступа фильтр по метаданным должен применяться до или одновременно с поиском, иначе релевантный, но запрещённый фрагмент может попасть в контекст. (docs.aws.amazon.com)

Если данные чувствительные, разделяйте ключи и политики как минимум для пользовательской памяти, знаний, состояния и аудита. В руководствах по защищённым AI-платформам отдельно предлагается разделять области шифрования и точки доступа для этих категорий, а действия агентов связывать с централизованными журналами. (docs.aws.amazon.com)

Как настроить срок действия и удаление без потери контроля

У каждой записи должны быть не только created_at, но и:

• valid_from;
• valid_until;
• retention_class;
• source_id;
• subject_id;
• deletion_status;
• supersedes_id.

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

Для персональных данных используйте двухконтурную модель:

1. удаление или обезличивание содержимого;
2. сохранение минимальной аудиторской связи, если она необходима по политике или закону.

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

В качестве стартовой политики можно использовать категории, а не универсальный срок: «сессия», «активная задача», «подтверждённый факт», «историческое событие», «обязательный аудит». Конкретные сроки определяйте после классификации данных, требований бизнеса и юридической проверки. В официальных рекомендациях по агентной памяти также подчёркивается, что краткосрочное хранение должно иметь явный срок, а для долгосрочных записей требуется собственный процесс автоматического удаления. (docs.aws.amazon.com)

Какие компоненты нужны перед производственным запуском

Production-ready архитектура — это не только модель, оркестратор и база. Минимальный состав обычно включает:

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

Трасса должна иметь единый идентификатор на всём пути: запрос пользователя, получение памяти, вызов модели, инструмент, изменение состояния и финальный ответ. Системы распределённой телеметрии описывают трассу через вложенные операции, идентификаторы, атрибуты, события и статус выполнения — это удобная основа для реконструкции цепочки решений. (opentelemetry.io)

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

Пошаговый план перехода от прототипа к продакшену

1. Нарисуйте карту потоков данных. Для каждого входа укажите источник, класс данных, владельца, разрешение, место записи и путь удаления.
2. Разделите схемы памяти. Не храните состояние задачи, пользовательские факты и аудит в одной таблице без разных политик.
3. Определите контракт записи. Поля источника, субъекта, времени подтверждения, уверенности, версии и срока действия должны проверяться до сохранения.
4. Настройте контекстный поиск. Сначала применяйте фильтры организации, пользователя, роли и статуса записи, затем выполняйте семантическое ранжирование.
5. Добавьте контроль конфликтов. Новая запись должна либо подтверждать старую, либо создавать версию с указанием причины расхождения.
6. Сделайте внешние действия идемпотентными. Для каждой операции, которая меняет внешний мир, храните ключ повтора и результат проверки.
7. Реализуйте удаление по цепочке. Проверьте оперативную базу, поисковый индекс, кэш, очереди, резервные копии и экспортированные наборы.
8. Проведите тест восстановления. Остановите worker между двумя шагами, восстановите checkpoint и убедитесь, что завершённое действие не повторилось.
9. Проверьте границы доступа. Выполните запросы от разных пользователей, агентов, организаций и ролей, включая намеренно подменённые идентификаторы.
10. Зафиксируйте критерии приёмки. Архитектура считается готовой только после проверки роста данных, недоступности хранилища, просроченных записей, конфликтов и задержек поиска.

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

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

Ниже — компактная матрица выбора для команды, которая решает, где запускать первый производственный контур.

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

Если сейчас вы используете локальный сервер, Windows- или Linux-среду, у такого варианта есть реальные ограничения: сложнее быстро получить изолированный стенд для нескольких команд, физический ресурс приходится делить между экспериментами, а восстановление после сбоя часто проверяется нерегулярно. Публичная облачная машина снимает часть административной нагрузки, но добавляет вопросы к сетевой задержке, хранению чувствительных данных и контролю постоянных расходов. Для архитектурного этапа часто разумнее сначала арендовать изолированный Mac в kvmboot, развернуть предпродакшен, проверить рост памяти, права и восстановление, а уже затем выбирать долгосрочную инфраструктуру.

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