Как Amazon Bedrock учит ИИ‑агентов помнить: архитектура Namespace в AgentCore Memory — VogueTech

Что нового

Amazon добавила в Amazon Bedrock AgentCore Memory полноценную систему организации долговременной памяти ИИ‑агентов через пространства имён (namespaces). Это не просто «хранилище контекста», а архитектура, где:

Память структурируется по иерархическим путям, похожим на директории в файловой системе: /actor/{actorId}/session/{sessionId}/summary/ и т.п.
Один ресурс памяти может хранить сразу несколько типов памяти (факты, предпочтения, краткие конспекты сессий, эпизоды рассуждений) с разными стратегиями и разными схемами namespace.
Разработчик задаёт шаблоны пространств имён через namespaceTemplate для каждой стратегии памяти:
- например, /actor/{actorId}/facts/ для фактов
- и /actor/{actorId}/session/{sessionId}/summary/ для конспектов диалогов.
Retrieval‑API поддерживает два режима работы с пространствами имён:
- namespace — точное совпадение
- namespacePath — иерархический поиск по поддереву.
Управление доступом завязано на AWS IAM: можно ограничивать, какие namespace и namespacePath разрешено запрашивать, через condition keys bedrock-agentcore:namespace и bedrock-agentcore:namespacePath.

Цифровых бенчмарков по скорости, цене, объёму контекста или сравнению с другими LLM‑сервисами Amazon не приводит. Фокус — на архитектуре хранения и извлечения памяти.

Как это работает

Базовая модель памяти

AgentCore Memory — это ресурс в Amazon Bedrock, внутри которого живут долговременные записи памяти (long-term memory records). Эти записи появляются, когда агент обрабатывает события (диалоги, действия, запросы) и по заданным стратегиям извлекает из них факты, предпочтения, конспекты и т.д.

Ключевая идея — каждая запись памяти живёт под конкретным namespace. Namespace — это строка‑путь, например:

/actor/customer-123/preferences/
/actor/customer-123/session/session-789/summary/

По сути это логический путь, который определяет:

как записи группируются,
как их потом искать,
кому к ним можно дать доступ через IAM.

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

Namespace‑шаблоны и подстановка переменных

Когда вы создаёте ресурс памяти, вы описываете стратегии памяти и для каждой задаёте шаблон namespace через поле namespaceTemplate. В шаблоне можно использовать три переменные:

{actorId} — идентификатор «актора» (обычно пользователя или клиента), берётся из обрабатываемых событий.
{sessionId} — идентификатор сессии, тоже из событий.
{memoryStrategyId} — идентификатор стратегии памяти.

Пример создания ресурса памяти с двумя стратегиями:

response = agentcore_client.create_memory(
    name="CustomerSupportMemory",
    description="Memory for customer support agents",
    eventExpiryDuration=30,
    memoryStrategies=[
        {
            "semanticMemoryStrategy": {
                "name": "customer-facts",
                "namespaceTemplate": "/actor/{actorId}/facts/"
            }
        },
        {
            "summaryMemoryStrategy": {
                "name": "session-summaries",
                "namespaceTemplate": "/actor/{actorId}/session/{sessionId}/summary/"
            }
        }
    ]
)

Если в систему прилетает событие с actorId=customer-456 и sessionId=session-789, то шаблоны разворачиваются в конкретные пути:

/actor/customer-456/facts/
/actor/customer-456/session/session-789/summary/

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

Разные типы памяти — разная схема namespace

AgentCore Memory поддерживает несколько логических типов памяти, и для каждого Amazon предлагает свои паттерны namespace.

1. Семантическая память и предпочтения: привязка к актору

Семантическая память — это факты и знания, вытащенные из диалогов:

«У компании клиента 500 сотрудников»
«Клиент мигрирует с on-premises в облако»

Память предпочтений — это устойчивые выборы и стили:

«Пользователь предпочитает Python»
«Любит подробные технические объяснения»

Обе категории важны между сессиями: факт, выученный в январе, нужен и в марте. Для них Amazon предлагает актор‑ориентированную схему:

/actor/{actorId}/facts/
/actor/{actorId}/preferences/

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

Пример структуры:

Memory Resource: CustomerSupportMemory
│
├── /actor/customer-123/
│   ├── facts/
│   │   ├── "Company has 500 employees across Seattle, Austin, Boston"
│   │   ├── "Currently migrating from on-premises to cloud"
│   │   └── "Primary contact is the VP of Engineering"
│   └── preferences/
│       ├── "Prefers email communication over phone"
│       └── "Usually prefers detailed technical explanations"
│
├── /actor/customer-456/
│   ├── facts/
│   │   ├── "Startup with 20 employees"
│   │   └── "Using serverless architecture"
│   └── preferences/
│       └── "Prefers concise, high-level summaries"

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

/customer-issues/{actorId}/
/sales/{actorId}/

Тогда можно:

запросить namespacePath="/customer-issues/" и получить общую картину проблем всех клиентов,
или запросить namespace="/customer-issues/customer-123/" и увидеть только этого клиента.

2. Конспекты сессий (summary): привязка к сессии

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

Эти данные жёстко привязаны к конкретной сессии, поэтому Amazon предлагает схему:

/actor/{actorId}/session/{sessionId}/summary/

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

Пример:

Memory Resource: CustomerSupportMemory
│
├── /actor/customer-123/
│   ├── session/session-001/summary/
│   │   └── "Customer inquired about enterprise pricing, discussed
│   │       implementation timeline, requested follow-up demo"
│   ├── session/session-002/summary/
│   │   └── "Follow-up on demo scheduling, confirmed Q3 timeline,
│   │       discussed integration requirements with existing CRM"
│   └── session/session-003/summary/
│       └── "Technical deep-dive on API integration, reviewed
│           authentication options, chose OAuth 2.0 approach"

3. Эпизодическая память и рефлексии

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

Такие эпизоды логично привязывать к сессии, как и конспекты:

Эпизоды: /actor/{actorId}/session/{sessionId}/episodes/

Отдельно Amazon вводит «рефлексии» — обобщённые выводы из нескольких эпизодов. Например: «если тариф не позволяет изменить бронирование, сразу ищем альтернативные рейсы, а не просто объясняем политику».

Рефлексии живут на родительском уровне, чтобы покрывать несколько сессий:

Рефлексии: /actor/{actorId}/

Важно: namespace для рефлексий должен быть под‑путём для эпизодов, чтобы иерархический поиск работал предсказуемо.

API для извлечения памяти

AgentCore Memory даёт три основных способа доставать записи.

1. Семантический поиск: `RetrieveMemoryRecords`

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

Пример вызова:

# Retrieve memories relevant to the current user query
memories = agentcore_client.retrieve_memory_records(
    memoryId="mem-12345abcdef",
    namespace="/actor/customer-123/facts/",
    searchCriteria={
        "searchQuery": "What cloud migration approach is the customer using?",
        "topK": 5
    }
)

Поисковый запрос может быть:

напрямую вопросом пользователя, если он хорошо совпадает с тем, что хранится в памяти — вроде «What’s my budget?»;
сгенерированным LLM‑агентом запросом, если исходная фраза размытая. Например, из «Help me plan my next trip» агент может сделать запрос вида "travel preferences, destination history, budget constraints". Это добавляет задержку, но даёт точнее таргетирование.

2. Прямой список: `ListMemoryRecords`

Этот метод нужен, когда важно просто получить все записи в конкретном namespace, без семантического поиска. Например:

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

Пример:

# List all memories in a specific namespace
records = agentcore_client.list_memory_records(
    memoryId="mem-12345abcdef",
    namespace="/actor/customer-123/preferences/"
)

3. Точечный доступ и удаление: `GetMemoryRecord` и `DeleteMemoryRecord`

Если у вас уже есть memoryRecordId (например, вы его сохранили после предыдущего запроса), можно обратиться к записи напрямую:

# Get a specific memory record
record = agentcore_client.get_memory_record(
    memoryId="mem-12345abcdef",
    memoryRecordId="rec-abc123"
)

# Delete a specific memory record
agentcore_client.delete_memory_record(
    memoryId="mem-12345abcdef",
    memoryRecordId="rec-abc123"
)

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

namespace vs namespacePath: точное совпадение и дерево

В запросах на извлечение памяти есть два разных поля для скопа:

`namespace` — точное совпадение

Если указать namespace, сервис вернёт только записи, которые лежат ровно по этому пути.

# Returns ONLY records stored at /actor/customer-123/facts/
records = agentcore_client.retrieve_memory_records(
    memoryId="mem-12345abcdef",
    namespace="/actor/customer-123/facts/",
    searchCriteria={
        "searchQuery": "cloud migration",
        "topK": 5
    }
)

Это нужно, когда вы точно знаете, что ищете: только предпочтения, только факты, только summary одной сессии.

`namespacePath` — поиск по поддереву

Если указать namespacePath, сервис пройдёт по всем namespace, которые начинаются с этого пути.

# Returns records from
# /actor/customer-123/facts/,
# /actor/customer-123/preferences/,
# /actor/customer-123/session/*/summary/, etc.
records = agentcore_client.retrieve_memory_records(
    memoryId="mem-12345abcdef",
    namespacePath="/actor/customer-123/",
    searchCriteria={
        "searchQuery": "cloud migration",
        "topK": 5
    }
)

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

Amazon рекомендует использовать ведущие и завершающие слэши в путях (/actor/.../) и придерживаться одного стиля, чтобы не получить конфликтов префиксов.

IAM‑политики и контроль доступа по namespace

Namespaces тесно связаны с AWS IAM: можно описать, какие namespace разрешено использовать в запросах к Memory API.

Политики с точным совпадением

Для этого используется условие StringEquals с ключом bedrock-agentcore:namespace.

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:RetrieveMemoryRecords",
        "bedrock-agentcore:ListMemoryRecords"
      ],
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:memory/mem-12345abcdef",
      "Condition": {
        "StringEquals": {
          "bedrock-agentcore:namespace": "/actor/${aws:PrincipalTag/userId}/preferences/"
        }
      }
    }
  ]
}

Здесь пользователь не сможет запросить память другого пользователя, потому что namespace жёстко привязан к его userId.

Политики для иерархического доступа

Для доступа ко всему поддереву используется StringLike с ключом bedrock-agentcore:namespacePath.

Пример: разрешить пользователю читать все его ветки памяти (facts, preferences, summary и т.д.), но не видеть чужие:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:RetrieveMemoryRecords",
        "bedrock-agentcore:ListMemoryRecords"
      ],
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:memory/mem-12345abcdef",
      "Condition": {
        "StringLike": {
          "bedrock-agentcore:namespacePath": "/actor/${aws:PrincipalTag/userId}/*"
        }
      }
    }
  ]
}

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

Что это значит для вас

Для чего это удобно

Если вы строите ИИ‑агентов на Amazon Bedrock, новая схема namespace в AgentCore Memory закрывает сразу несколько практических задач:

Персонализация между сессиями.
- Актор‑ориентированные namespaces (/actor/{actorId}/facts/, /actor/{actorId}/preferences/) позволяют агенту помнить пользователя месяцами.
- Не нужно городить собственный слой над DynamoDB или S3 для организации памяти.
Контролируемый контекст для LLM.
- Session‑ориентированные summary (/actor/{actorId}/session/{sessionId}/summary/) дают краткий конспект вместо длинного лога.
- Это снижает расходы на токены и уменьшает риск «захламить» контекст нерелевантными сообщениями.
Прозрачный аудит и управление памятью.
- Через ListMemoryRecords и GetMemoryRecord можно строить UI, где пользователь видит, что именно «помнит» агент.
- Записи можно точечно удалять (DeleteMemoryRecord), что полезно и с точки зрения UX, и для соответствия требованиям по приватности.
Безопасность на уровне IAM.
- Namespace и namespacePath интегрируются в IAM‑политики. Это даёт чёткий ответ на вопрос «кто может прочитать чью память».
- Можно строить сценарии, где, например, администратор видит агрегированную статистику по /customer-issues/, а обычный пользователь — только /actor/{его_id}/....
Единый ресурс памяти для разных типов данных.
- В одном memoryId уживаются факты, предпочтения, summary, эпизоды и рефлексии.
- Всё разделяется логикой namespace, а не разными базами.

Где это особенно полезно

Саппорт и CRM‑агенты.
- Память о клиентах: история обращений, технические детали, предпочтения по каналу связи.
- Быстрая выдача «всего, что мы знаем» о клиенте через namespacePath.
Продажи и аккаунт‑менеджмент.
- Хранение контекста по сделкам, объектам интереса, прошлым встречам.
- Поиск похожих кейсов через инвертированную схему (/sales/{actorId}/).
Технические ассистенты и дев‑боты.
- Память о стеке, привычках команды, прошлых инцидентах.
- Эпизодическая память с рефлексиями помогает агенту «учиться» на прошлых ошибках.
Сложные рабочие процессы (booking, логистика, финансы).
- Эпизоды дают трассы решений, которые можно анализировать и дебажить.
- Рефлексии на уровне актора помогают улучшать стратегию агента по мере накопления опыта.

Где лучше не рассчитывать только на это

Приложения без доступа к AWS. Если вы не используете AWS или не готовы интегрировать IAM, AgentCore Memory вам не пригодится.
Сценарии с жёсткими on-prem требованиями. AgentCore Memory — облачный сервис внутри AWS. Для полностью локальных инсталляций придётся строить аналогичную архитектуру самостоятельно.
Простейшие чат‑боты без долговременной памяти. Если ваш бот не хранит информацию между сессиями, вам достаточно контекстного окна LLM и, возможно, простого кэша.

Доступность из России

Amazon Bedrock и AgentCore Memory работают в регионах AWS. Для разработчиков из России доступ может зависеть от регуляторных ограничений и политики AWS по аккаунтам. Если ваш AWS‑аккаунт активен и имеет доступ к Bedrock, VPN на уровне SDK не требуется, но сетевые ограничения в вашей инфраструктуре нужно проверять отдельно.

Место на рынке

Amazon позиционирует AgentCore Memory как часть экосистемы Bedrock, а не как отдельный векторный поиск или базу данных. По сути это «мозг памяти» поверх внутренних хранилищ AWS с чёткой интеграцией в IAM и в самих агентов Bedrock.

В контексте рынка решений для памяти ИИ‑агентов AgentCore Memory конкурирует не с конкретной моделью вроде GPT‑4o или Claude 3.5, а с подходами:

«сами соберём память на векторной БД + S3»;
встроенные механизмы памяти в платформах‑конкурентах.

Прямых цифр по сравнению с другими облачными реализациями (скорость, стоимость запросов, лимиты на размер памяти) Amazon не приводит. Основное отличие подхода — тесная увязка:

с AWS IAM,
с иерархическими namespace,
с стратегиями памяти (semantic, summary, episodic, preferences) внутри одного ресурса.

Если вы уже строите агентов на Bedrock, AgentCore Memory даёт родной механизм долговременной памяти без необходимости тянуть сторонние векторные БД и вручную решать вопросы изоляции и IAM.

Как запустить

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

Создание ресурса памяти с двумя стратегиями

response = agentcore_client.create_memory(
    name="CustomerSupportMemory",
    description="Memory for customer support agents",
    eventExpiryDuration=30,
    memoryStrategies=[
        {
            "semanticMemoryStrategy": {
                "name": "customer-facts",
                "namespaceTemplate": "/actor/{actorId}/facts/"
            }
        },
        {
            "summaryMemoryStrategy": {
                "name": "session-summaries",
                "namespaceTemplate": "/actor/{actorId}/session/{sessionId}/summary/"
            }
        }
    ]
)

При приходе событий с actorId=customer-456 и sessionId=session-789 будут использованы namespaces:

/actor/customer-456/facts/
/actor/customer-456/session/session-789/summary/

Семантический поиск по фактам пользователя

# Retrieve memories relevant to the current user query
memories = agentcore_client.retrieve_memory_records(
    memoryId="mem-12345abcdef",
    namespace="/actor/customer-123/facts/",
    searchCriteria={
        "searchQuery": "What cloud migration approach is the customer using?",
        "topK": 5
    }
)

Список всех предпочтений пользователя

# List all memories in a specific namespace
records = agentcore_client.list_memory_records(
    memoryId="mem-12345abcdef",
    namespace="/actor/customer-123/preferences/"
)

Поиск по всему дереву памяти пользователя

# Returns records from
# /actor/customer-123/facts/,
# /actor/customer-123/preferences/,
# /actor/customer-123/session/*/summary/, etc.
records = agentcore_client.retrieve_memory_records(
    memoryId="mem-12345abcdef",
    namespacePath="/actor/customer-123/",
    searchCriteria={
        "searchQuery": "cloud migration",
        "topK": 5
    }
)

Получение и удаление конкретной записи

# Get a specific memory record
record = agentcore_client.get_memory_record(
    memoryId="mem-12345abcdef",
    memoryRecordId="rec-abc123"
)

# Delete a specific memory record
agentcore_client.delete_memory_record(
    memoryId="mem-12345abcdef",
    memoryRecordId="rec-abc123"
)

IAM‑политика: доступ только к своим предпочтениям

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:RetrieveMemoryRecords",
        "bedrock-agentcore:ListMemoryRecords"
      ],
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:memory/mem-12345abcdef",
      "Condition": {
        "StringEquals": {
          "bedrock-agentcore:namespace": "/actor/${aws:PrincipalTag/userId}/preferences/"
        }
      }
    }
  ]
}

IAM‑политика: доступ ко всей памяти актора по дереву

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock-agentcore:RetrieveMemoryRecords",
        "bedrock-agentcore:ListMemoryRecords"
      ],
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:123456789012:memory/mem-12345abcdef",
      "Condition": {
        "StringLike": {
          "bedrock-agentcore:namespacePath": "/actor/${aws:PrincipalTag/userId}/*"
        }
      }
    }
  ]
}

Итог: как проектировать namespaces

Если вы собираетесь использовать AgentCore Memory, полезно заранее ответить себе на три вопроса:

Кто должен видеть эти воспоминания? Один пользователь, группа пользователей, все агенты?
На какой «глубине» вы хотите доставать данные? По одной сессии, по пользователю целиком, по всем пользователям определённого типа памяти?
Где проходят границы изоляции? Может ли один пользователь видеть чужие данные? Какие ветки нужны для админских запросов?

Из этого вытекают практические рекомендации:

Для фактов и предпочтений используйте актор‑ориентированные пути (/actor/{actorId}/) для консолидации между сессиями.
Для summary и эпизодов добавляйте sessionId в namespace (/actor/{actorId}/session/{sessionId}/), потому что они жёстко привязаны к разговору.
Применяйте namespace для точечного доступа и namespacePath для поиска по поддереву.
Следите за единообразием путей (ведущие и завершающие слэши), чтобы не получить коллизии.
Используйте IAM‑condition keys bedrock-agentcore:namespace и bedrock-agentcore:namespacePath, чтобы явно описать, какие ветки памяти доступны конкретному принципалу.

При аккуратном проектировании namespace AgentCore Memory превращается в управляемый слой долговременной памяти для ваших ИИ‑агентов, без самодельных костылей вокруг отдельных баз данных и сервисов поиска.