Amazon Bedrock AgentCore Memory — сервис долгосрочной памяти для ИИ-агентов, который AWS развивает как часть платформы Bedrock. Центральный механизм организации данных в нём — пространства имён (namespaces): иерархические пути, напоминающие директории в файловой системе. Путь вида /actor/customer-123/preferences/ указывает, где хранятся предпочтения конкретного пользователя, а /actor/customer-123/session/session-789/summary/ — где лежит сводка отдельной сессии.
Проблема, которую решает такая архитектура, хорошо знакома разработчикам агентов: без структурированного хранения агент либо тянет нерелевантный контекст из чужих сессий, либо вовсе теряет нужные данные. AgentCore Memory предлагает три стратегии памяти с разными требованиями к скоупингу. Семантическая память (факты о пользователе — например, «компания клиента насчитывает 500 сотрудников») и память предпочтений накапливаются поверх сессий и привязываются к актору: /actor/{actorId}/facts/. Сводки сессий (summary memory), напротив, фиксируют конкретный разговор и включают идентификатор сессии: /actor/{actorId}/session/{sessionId}/summary/. Эпизодическая память — полные цепочки рассуждений агента — также скоупится на сессию.
| Стратегия памяти | Скоуп | Пример пути |
|---|---|---|
| Семантическая (факты) | Актор | /actor/{actorId}/facts/ |
| Предпочтения пользователя | Актор | /actor/{actorId}/preferences/ |
| Сводка сессии (summary) | Сессия | /actor/{actorId}/session/{sessionId}/summary/ |
| Эпизодическая | Сессия | /actor/{actorId}/session/{sessionId}/episodes/ |
При создании ресурса памяти разработчик задаёт шаблоны через поле namespaceTemplate. Три встроенные переменные — {actorId}, {sessionId} и {memoryStrategyId} — разрешаются автоматически, когда в систему поступают события. Если агент обрабатывает событие для actorId=customer-456 в sessionId=session-789, пути /actor/customer-456/facts/ и /actor/customer-456/session/session-789/summary/ формируются без дополнительного кода.
Три типа памяти требуют разного скоупинга: семантическая и пользовательские предпочтения — на уровне актора, сводки сессий — на уровне сессии.
Главное отличие от partition key в Amazon DynamoDB — поддержка иерархических запросов. Можно запросить память на уровне конкретной сессии, на уровне пользователя по всем сессиям или на уровне всего ресурса. Это открывает паттерн «инвертированной иерархии»: если нужно, чтобы агент поддержки видел проблемы, о которых сообщали разные клиенты, структура /customer-issues/{actorId}/ позволяет сделать запрос к /customer-issues/ и получить данные по всем акторам — при этом запрос к /customer-issues/customer-123/ вернёт только записи одного пользователя.
Контроль доступа строится на AWS IAM: политики определяют, какой агент или пользователь может читать и писать в конкретное пространство имён. Это закрывает сценарий, при котором один пользователь случайно получает доступ к памяти другого — уязвимость, типичная для агентов с наивной реализацией хранилища. Все записи разных пространств имён физически сосуществуют в одном ресурсе памяти; изоляция обеспечивается логически, через иерархию путей и IAM-политики.
Summary memory решает ещё одну практическую задачу: вместо того чтобы передавать в контекстное окно LLM полную историю переписки, агент получает компактную сводку сессии. Это снижает расход токенов и ускоряет ответ. Пример из документации показывает, как три сессии одного клиента хранятся отдельными записями под /actor/customer-123/session/session-00X/summary/, но при этом доступны единым запросом на уровне актора для построения сквозного контекста.
