Шаблоны проектирования AI-агентов. Часть 6: Agent Memory in Practice

В Части 5 я обозрел подходы к памяти агента: от файлового мозга OpenClaw до управляемого слоя mem0. Мы выбрали гибрид — слои памяти как у MemPalace, файловая структура как у OpenClaw. Но обзор — это одно, а инженерная механика — совсем другое. Как именно файлы попадают в контекст? Почему одни инжектятся всегда, а другие — по требованию? Как агент вообще узнаёт, что ему нужно что-то прочитать? И что происходит, когда память превращается в помойку — кто её чистит?

В этой статье — deep dive в механику. Пять файлов памяти, четыре стратегии контекст-сборки, TOOLS.md с двумя источниками ответственности, и — самое интересное — Dreaming: фоновая консолидация памяти, которую Anthropic и OpenAI реализовали в 2026 году. Я покажу, какие инженерные решения принимаются за кулисами, почему мы выбрали именно такой путь, и когда придётся его менять.

1. Пять файлов памяти: полный каталог

В первой части я описал четыре слоя памяти и упомянул SOUL.md, ABOUT.md, TOOLS.md. Но реальная файловая модель — богаче. Пять файлов, каждый со своей зоной ответственности, своим способом попадания в контекст и своим scope-ом изоляции.

1.1. Исчерпывающая таблица

Ключевое разделение — injection vs on-demand. Три файла (SOUL, ABOUT, TOOLS) инжектятся в system prompt при каждом запросе. Это «горячая» память — агент всегда видит свою идентичность и описание инструментов. Два файла (USER, MEMORY) — по требованию, через memory tools. Агент решает сам, когда ему нужен контекст пользователя.

graph TB
    subgraph "Bootstrap Injection (~1-2K tokens, КАЖДЫЙ запрос)"
        SOUL["SOUL.md
идентичность"]
        ABOUT["ABOUT.md
профиль"]
        TOOLS["TOOLS.md
заметки по тулам"]
    end

    subgraph "On-demand (через memory tools, по решению агента)"
        USER["USER.md
профиль пользователя"]
        MEMORY["MEMORY.md
долговременная память"]
    end

    SOUL --> SP["System Prompt"]
    ABOUT --> SP
    TOOLS --> SP
    SP --> LLM["LLM"]

    LLM -->|"memory tools"| USER
    LLM -->|"memory tools"| MEMORY

    style SOUL fill:#6a1b9a,color:#fff
    style ABOUT fill:#6a1b9a,color:#fff
    style TOOLS fill:#6a1b9a,color:#fff
    style USER fill:#e65100,color:#fff
    style MEMORY fill:#e65100,color:#fff

1.2. SOUL.md — идентичность

SOUL.md — это «кто я». Ценности, характер, стиль общения. Лимит — 2000 символов. Инжектится в каждый запрос как секция ## Agent Identity в system prompt.

Почему не больше? Потому что каждый символ в SOUL.md оплачивается на каждый запрос. 2000 символов ≈ 500 токенов. Если увеличить до 10K — агент будет тратить 2.5K токенов только на собственную идентичность, прежде чем скажет хоть слово. Для платформы с сотнями агентов это неприемлемо.

Кто пишет? Пользователь через UI — задаёт характер при создании агента. Или сам агент через memory tools — когда пользователь просит «будь более формальным» или «используй русский язык по умолчанию».

1.3. ABOUT.md — профиль

ABOUT.md — это «чем я занимаюсь». Роль, специализация, типичные задачи. Тот же лимит — 2000 символов, та же инъекция в каждый запрос.

Зачем отдельный файл, если можно объединить с SOUL? Разделение identity и profile — не случайно. Identity (SOUL) — это постоянная величина, она редко меняется. Profile (ABOUT) — более динамичный: «сейчас я помогаю с миграцией на gRPC» → через месяц → «помогаю с настройкой мониторинга». Раздельные файлы позволяют обновлять профиль, не трогая ядро личности.

1.4. USER.md — профиль пользователя для конкретного агента

А вот тут начинается интересное. USER.md хранится в scope agent_user — это значит, что у каждого агента свой профиль для каждого пользователя. Агент А знает, что «Алиса предпочитает YAML» — но агент Б в том же проекте этого не знает, пока сам не прочитает.

Что хранится:

Лимит — 2000 символов. И вот почему USER.md — on-demand, а не injection: не всем агентам нужен профиль пользователя. Coding-ассистент — да, ему важно знать, что вы предпочитаете Go. А агент-суммаризатор текстов — ему всё равно, какой у вас timezone. Зачем тратить 500 токенов на профиль, который агент не использует?

1.5. MEMORY.md — долговременная память

MEMORY.md — это «что я знаю». Ключевые решения, контекст клиентов, текущие задачи, выводы из диалогов. Scope agent_user — привязан к паре «агент + пользователь». Лимит — 5000 символов (soft limit — при превышении агент получает инструкцию сжать).

MEMORY.md реализует паттерн write-manage-read, который я описывал в первой части:

Write (кто и когда сохраняет):

• Агент — через memory tools, когда выявляет важный факт
• Auto-capture (future): перед compaction/завершением сессии — автоматический flush важных фактов

Manage (сжатие, дедупликация):

• Агент получает инструкцию: «Регулярно сжимай MEMORY.md, удаляй устаревшие факты»
• Если MEMORY.md > 5000 символов — инструкция агенту сжать
• Future: автоматическая дедупликация через LLM

Read (когда поднимается):

• Агент читает через memory tools по требованию
• Инструкция в system prompt: «search memory before acting» (паттерн OpenClaw)
• НЕ инжектится в system prompt на boot (экономия токенов)

Почему MEMORY.md — on-demand, а не injection? Потому что MEMORY.md растёт. Сегодня — 500 символов, через месяц — 5000. Если инжектить — каждый запрос будет тратить всё больше токенов на память. OpenClaw решает это truncation’ом (обрезает > 20K символов), но обрезание означает потерю данных. Мы предпочитаем, чтобы агент сам решал, что ему нужно из памяти прямо сейчас.

1.6. Сводка по слоям

┌──────────────────────────────────────────────────────────┐
│                СЛОИ ПАМЯТИ АГЕНТА                         │
├──────────────┬──────────────┬───────────────┬───────────┤
│ Слой         │ Файлы        │ Загрузка      │           │
├──────────────┼──────────────┼───────────────┤           │
│ Agent        │ SOUL.md      │ Всегда        │           │
│              │ ABOUT.md     │ Всегда        │ Injection │
│              │ TOOLS.md     │ Всегда        │           │
├──────────────┼──────────────┼───────────────┤           │
│ Agent+User   │ USER.md      │ По требованию │ On-demand │
│              │ MEMORY.md    │ По требованию │ (tools)   │
└──────────────┴──────────────┴───────────────┴───────────┘

Агент получает Prompt Hint в system prompt:
"У тебя есть memory tools. Загрузи USER.md и MEMORY.md при необходимости."

Два scope’а, два уровня изоляции. agent — общие файлы агента, видны всем пользователям. agent_user — персональная память, изолированная для пары «агент + пользователь». Никакой утечки контекста между пользователями.

2. Стратегия контекст-сборки: почему Hybrid v2

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

2.1. Вариант 1: Full Injection (как OpenClaw)

Все файлы памяти читаются из хранилища и инжектятся в system prompt при каждом запросе.

graph LR
    S3[(Storage)] -->|"read all files"| ASM[Context Assembler]
    ASM --> SP[SystemPrompt]
    SP --> LLM[LLM]

    subgraph "Всегда инжектится (~5-10K tokens)"
        SOUL["SOUL.md"]
        ABOUT["ABOUT.md"]
        USER["USER.md"]
        MEMORY["MEMORY.md"]
        TOOLS["TOOLS.md"]
    end

    SOUL --> ASM
    ABOUT --> ASM
    USER --> ASM
    MEMORY --> ASM
    TOOLS --> ASM

Плюсы: простая реализация (~30-50 строк), предсказуемый контекст, легко отлаживать.

Минусы: 5-10K токенов на каждый запрос, несколько reads из хранилища, MEMORY.md растёт → truncation → потеря данных, агент не может обновлять файлы через инструменты.

OpenClaw именно так и делает. И это работает — для coding-ассистента с одним пользователем. Но на платформе с сотнями агентов, где каждый запрос оплачивается, сжигать 10K токенов на boot — роскошь.

2.2. Вариант 2: On-Demand (Tool-Based)

Файлы памяти НЕ инжектятся. Агент получает memory tools и сам решает, что читать.

Плюсы: 0 токенов от памяти на boot, агент может обновлять файлы, масштабируется неограниченно.

Минусы: агент может «забыть» прочитать контекст → некачественные ответы. Каждое чтение = итерация react-loop. Сложнее отлаживать — контекст зависит от поведения агента.

Это крайность, противоположная Full Injection. Дёшево на старте, но ненадёжно. Агент без идентичности — как человек без имени: может работать, но не знает, кто он.

2.3. Вариант 3: Hybrid v1 — L0/L1 Boot + L2 Tools

L0 (SOUL, ABOUT) — всегда инжектятся. L1 (USER) — тоже инжектится. L2+ (MEMORY) — через инструменты.

Плюсы: ~2-3K на boot, предсказуемая база, близко к MemPalace pattern.

Минусы: USER.md тратит токены, даже если агенту не нужен профиль пользователя. На платформе с 50+ типами агентов далеко не всем нужен USER.md — суммаризатор, переводчик, ревьюер кода не взаимодействуют с пользователем персонально.

2.4. Вариант 3b: Hybrid v2 — Minimal Injection + Prompt Hint ← выбран

Ключевой инсайт из исследования OpenClaw: даже OpenClaw не инжектит MEMORY.md в system prompt. Если memory tools доступны, агент получает hint «use memory_search», а MEMORY.md загружает самостоятельно. USER.md в Codex-интеграции тоже не всегда инжектится.

Отсюда — Hybrid v2: минимальная инъекция (SOUL + ABOUT + TOOLS) + prompt hint, направляющий агента к memory tools для USER.md и MEMORY.md.

graph TD
    subgraph "System Prompt Injection (~1-2K tokens)"
        SOUL2["SOUL.md / ABOUT.md
идентичность агента"]
        TOOLS2["TOOLS.md
заметки по инструментам"]
        AUTO["Автогенерация тулов
описание инструментов"]
    end

    subgraph "On-demand через memory tools"
        USER2["USER.md
профиль пользователя"]
        MEMORY2["MEMORY.md
долговременная память"]
    end

    SOUL2 --> SP2["System Prompt"]
    TOOLS2 --> SP2
    AUTO --> SP2
    SP2 --> LLM2["LLM"]

    LLM2 -->|"memory tools"| USER2
    LLM2 -->|"memory tools"| MEMORY2

Prompt Hint (добавляется в system prompt):

У тебя есть доступ к memory tools. При необходимости загрузи USER.md (профиль пользователя) и MEMORY.md (долговременная память).

2.5. Сравнение четырёх вариантов

Почему не Hybrid v1? Потому что USER.md в injection — это токены, которые тратятся впустую, когда агенту не нужен профиль. На платформе с десятками типов агентов (суммаризатор, переводчик, аналитик кода) далеко не каждый агент взаимодействует с пользователем персонально. Зачем грузить USER.md в каждый запрос?

Итог: Hybrid v2 — минимальный токен-бюджет на boot, максимальная гибкость, согласованность с тем, как OpenClaw реально работает (не инжектит MEMORY.md, а даёт hint).

2.6. Prompt Hint — как агент знает, что читать

Агент не прочитает USER.md или MEMORY.md сам по себе — ему нужно сказать об этом. Prompt Hint — это инструкция, добавляемая в system prompt:

У тебя есть memory tools. Загрузи USER.md (профиль пользователя) и MEMORY.md (долговременная память) при необходимости.

Это аналог подхода OpenClaw: агент получает hint «use memory_search», а MEMORY.md загружает самостоятельно. Мы добавили «при необходимости» — агент решает, нужен ли ему контекст пользователя в данном запросе.

Риск: агент может «забыть» загрузить USER.md → ответы без персонального контекста. Митигация: чёткий Prompt Hint + примеры в system prompt («В начале сессии загрузи USER.md и MEMORY.md»). На практике — USER.md маленький (~200-500 токенов), загрузка занимает одну итерацию react-loop.

3. TOOLS.md: два источника — две ответственности

TOOLS.md — самый нетривиальный файл памяти. В системе уже существует программный механизм описания инструментов: ToolSet.RegisterInAgent() генерирует SystemPromptInjection с описанием инструментов для LLM. Зачем ещё один источник?

3.1. Проблема: механика ≠ практика

Система автоматически генерирует описание каждого инструмента: название, параметры, типы, краткое описание. Этого достаточно, чтобы LLM понял как вызвать инструмент. Но auto-generated описание не содержит практического опыта — а именно он определяет, когда и зачем агент будет обращаться к инструменту.

Что auto-generated даёт (механика):

• Названия инструментов и их параметров
• Типы данных и обязательность параметров
• Краткое описание из ToolSettings

Чего auto-generated НЕ даёт (практика):

• Когда лучше использовать конкретный инструмент, а когда другой
• Особенности работы с конкретными данными (quirks)
• Типичные паттерны использования в контексте проекта
• Ограничения, неочевидные из описания (rate limits, размер ответа)
• Предпочтения пользователя по работе с инструментами

Разрыв между «как вызвать» и «когда использовать» — это разрыв между документацией API и реальным опытом работы с ним. TOOLS.md заполняет этот разрыв.

3.2. Решение: auto-generated + user extensions

System Prompt (tools section) формируется из двух источников:

{auto-generated description from RegisterInAgent()}     ← механика (в памяти)
---
## Tool Notes
{contents of TOOLS.md, if exists}                       ← практика (из хранилища)

Два источника — две ответственности:

Ключевой инвариант: auto-generated часть существует только в памяти и никогда не записывается в хранилище. TOOLS.md хранится персистентно и никогда не перезаписывается автоматически. Два источника не конфликтуют.

3.3. Примеры

Knowledge DB (RAG)

Auto-generated (формируется при каждом запросе):

search_knowledge_db: Search documents in knowledge databases.
Parameters: query (string), db_name (string, optional)

Available knowledge databases:
- "Product Docs" (product documentation)
- "Internal Wiki" (internal processes)

TOOLS.md (пользовательские заметки):

## Knowledge DB Notes

- Для поиска по Product Docs используй точные названия продуктов, не описания
- Internal Wiki обновляется раз в неделю — если не нашёл актуальную информацию,
  попроси пользователя подтвердить
- Рекомендуемый паттерн: сначала search → затем read_knowledge_db_document
- Предел результата search — 5 чанков, если нужно больше — уточни запрос

3.4. Почему не «полностью авто» и не «полностью ручное»

Полностью авто (вариант, который мы рассматривали): только auto-generated описание, без TOOLS.md. Плюс — всегда актуально, нет рассинхронизации. Минус — пользователь не может дописать quirks, tips, контекст использования. Агент видит «search_knowledge_db(query, db_name)», но не знает, что «для Product Docs нужны точные названия».

Полностью ручное (как OpenClaw): пользователь/агент пишет TOOLS.md вручную, система ничего не генерирует. Плюс — полная кастомизация. Минус — при добавлении нового скилла или MCP-инструмента TOOLS.md устаревает. Пользователь должен не забыть обновить. А если забыл — агент видит описание трёх инструментов, хотя подключено пять.

Разделение на auto-generated + user extensions решает обе проблемы: механика всегда актуальна (генерируется из ToolSettings), практика добавляется вручную (TOOLS.md). И когда появится MCP — auto-generated часть автоматически включит MCP-описания.

3.5. Lazy lifecycle

Ещё один нюанс: TOOLS.md не создаётся по умолчанию. Файл появляется в хранилище только когда пользователь или агент впервые запишет в него контент. «Пустой» TOOLS.md — это отсутствующий файл, а не пустая строка.

Это же правило действует для всех файлов памяти. Отсутствие файла — не ошибка:

Graceful degradation — новый агент без файлов памяти не падает, а работает с минимальным контекстом. Prompt hint добавляется всегда — даже если файлов ещё нет, агент знает, что инструменты существуют.

4. Dreaming: фоновая консолидация памяти

А теперь — самое интересное. Всё, что я описал выше, — это inline-механизм: агент пишет в MEMORY.md во время сессии, управляет размером через инструкцию «сжимай регулярно». Консолидации (дедупликация, разрешение противоречий, удаление устаревшего) — нет.

Вопрос: стоит ли добавить фоновый процесс консолидации, запускаемый после завершения сессий? И если да — как? Anthropic и OpenAI уже ответили «да» и реализовали это в 2026 году. Давай разберёмся, как они это делают.

4.1. Anthropic: Auto Dream (Claude Code)

4-фазный фоновый процесс, запускаемый между сессиями отдельным sub-agent’ом (solaius, 2026):

graph LR
    LOGS["Логи завершённых
сессий"] -->|"Phase 1: Orient"| MAP["Базовая карта
памяти"]
    MAP -->|"Phase 2: Gather Signal"| SIGNAL["Сигналы:
новые факты, дрейф,
противоречия"]
    SIGNAL -->|"Phase 3: Consolidate"| UPDATED["Обновлённые
файлы памяти"]
    UPDATED -->|"Phase 4: Prune & Index"| CLEAN["Чистый индекс
MEMORY.md"]

    style LOGS fill:#1565c0,color:#fff
    style CLEAN fill:#2e7d32,color:#fff

Триггер: двойной гейт — 24+ часов с последней консолидации И 5+ новых сессий. Это не «после каждого диалога», а «когда накопилось достаточно материала». Умно: частые короткие сессии не запускают dreaming каждую минуту.

Безопасность: sub-agent пишет только в memory/, не имеет git/npm/MCP инструментов. Не может сломать код, не может уйти в интернет — только чистка памяти.

Результаты (Harvey, legal AI): 6x рост task completion rate (solaius, 2026). Но Harvey — юридический AI, где память критична. Реалистичная оценка для типичных сценариев — 1.5–3x.

Стоимость: стандартные токен-рейты Claude. 913 сессий консолидируются за 8–9 минут. При частоте «раз в сутки при 5+ сессиях» — это копейки на фоне основных LLM-вызовов.

4.2. Anthropic: Dreams API (Managed Agents, Enterprise)

Enterprise-версия Auto Dream с дополнительными возможностями (solaius, 2026):

Review gate — ключевое отличие от базового Auto Dream. Enterprise не может позволить себе «LLM молча переписала память». Каждое изменение — на ревью. Версионирование — immutable: можно откатиться к любой предыдущей версии. Это критично для regulated workflows (healthcare, legal, finance).

4.3. KAIROS (unreleased, внутренний Anthropic)

А вот это — предварительный взгляд на архитектуру постоянных (always-on) агентов (solaius, 2026). Append-only логи + nightly dreaming.

• Логи: logs/YYYY/MM/YYYY-MM-DD.md — append-only, никогда не модифицируются
• Nightly /dream дистиллирует логи в topic files и MEMORY.md
• Аналогия с WAL (Write-Ahead Log) в БД: полный audit trail + lean working memory

Почему это важно? Потому что это решает фундаментальную проблему текущих подходов: что если dreaming удалит что-то важное? В KAIROS — не удалит никогда. Логи append-only, они не меняются. /dream создаёт новое представление (MEMORY.md), но оригинал остаётся. Как WAL в PostgreSQL: даже если checkpoint упал — логи на месте, можно восстановиться.

Это тот же принцип, что в событийном моделировании (event sourcing): состояние — это функция от истории событий. MEMORY.md — это projection, а логи — это event store. Projection можно пересоздать, event store — нельзя.

4.4. OpenAI: Dreaming V3 (июнь 2026)

Фоновый процесс синтеза, полностью заменивший ручные «saved memories» (OpenAI, 2026):

Эволюция впечатляет: с 41.5% до 82.8% за два года (OpenAI, 2026). Но ещё интереснее — как Dreaming V3 работает:

• Читает всю историю диалогов пользователя
• Автоматически синтезирует профиль: факты, предпочтения, инструкции, неявные паттерны
• Self-updating: «пользователь едет в Сингапур в июле» → после поездки автоматически переписывается на «пользователь ездил в Сингапур в июле 2026»
• Запускается между диалогами, не внутри

Self-updating — это киллер-фича. В нашем подходе MEMORY.md содержит «пользователь едет в Сингапур в июле». После июля — это устаревший факт. В Dreaming V3 — факт автоматически обновляется. Никакого ручного управления.

Но есть и проблемы:

• Платформа молча переписывает записи — нет лога ревизий (OpenAI, 2026; solaius, 2026). Вы не можете узнать, что было до перезаписи.
• Audit trail непрозрачен — критично для regulated workflows. В healthcare вы обязаны знать, почему агент принял решение, а если память молча изменилась — вы этого не узнаете.
• 5x сокращение compute позволило расширить на Free-тир — но ценой качества для сложных сценариев.

4.5. Сравнение подходов

4.6. Почему мы пока НЕ делаем dreaming

Четыре причины:

1. Базовый механизм достаточен — inline-запись через memory tools + инструкция «сжимай» покрывает 80% ценности. Память работает, факты сохраняются, агенты вспоминают контекст. Проблема «память превращается в помойку» — теоретическая, пока мы не увидели её в проде.

2. Инфраструктура — dreaming требует worker, очередь задач (NATS stream или BullMQ), триггеры по завершению сессии, промпт консолидации. Этого нет, и это не «пара строк кода».

3. Нет данных — без накопленного опыта работы с MEMORY.md в проде неясно, насколько критична проблема. Возможно, инструкция «сжимай» достаточно. Возможно — нет. Нужно смотреть метрики: размер MEMORY.md, частота устаревания, количество дубликатов.

4. Стоимость и риски — LLM может ошибочно мержнуть разные факты, удалить важное как «устаревшее». На первом этапе нужен review gate (не авто-применение), а это уже другой UX.

Рекомендуемый путь:

1. Текущий эпик — реализовать inline-механизм
2. Наблюдение — собрать метрики по MEMORY.md в проде
3. Следующий эпик — если метрики покажут деградацию → реализовать Вариант B (batch-консолидация) с review gate
4. Future — если потребуется audit trail → Вариант C (append-only + nightly distillation)

Приблизительная стоимость batch-консолидации: ~5500 токенов за run (3000 на лог сессии + 1000 на MEMORY.md + 500 на промпт + 1000 на output). При частоте «раз в 24ч при 5+ сессиях» и дешёвой модели (OSS 20B) — ~$0.01–0.05 за агент/день. Это 1–3% от стоимости обслуживания агента. Копейки — но только если базовый механизм уже работает.

5. Write-Manage-Read на практике

В первой части я описал write-manage-read loop (Du et al., 2026) как абстрактную модель. Давайте посмотрим, как это выглядит в нашей реализации.

5.1. Write: кто, когда, через что

5.2. Manage: сжатие, дедупликация, устаревание

Текущий механизм — инструкция агенту:

Регулярно сжимай MEMORY.md. Удаляй устаревшие факты. Мержни дубликаты. Если MEMORY.md > 5000 символов — сожми.

Это не автоматическая консолидация, а делегирование агенту. Работает? В большинстве случаев — да. LLM вполне способна сжать 5000 символов фактов до 3000, убрав дубли и устаревшее. Но не всегда корректно — может удалить важное или мержнуть разное. Поэтому soft limit, а не hard truncation.

Future: автоматическая дедупликация через LLM (как Auto Dream Phase 3). Но — после накопления метрик из прода.

Temporal validity: у каждого файла памяти есть last_modified. Если факт не обновлялся дольше TTL (настраивается) — он помечается stale. Проще, чем Knowledge Graph с valid_from/valid_to у MemPalace, но для платформы с сотнями агентов — достаточно. Графовые запросы — территория Zep.

5.3. Read: injection vs on-demand

Итого на boot: ~1-2K токенов. На первый запрос с загрузкой USER.md + MEMORY.md: ~2-4K. На каждый последующий: зависит от задачи — агент может не обращаться к памяти вообще.

6. Итоги

6.1. Сводная таблица файлов памяти

6.2. Стратегии контекст-сборки

6.3. Dreaming: не «если», а «когда»

Anthropic и OpenAI уже реализовали фоновую консолидацию памяти. Результаты впечатляют: 82.8% factual recall у OpenAI, 6x task completion у Harvey (Anthropic). Но оба подхода имеют компромиссы: OpenAI молча переписывает без audit trail, Anthropic требует отдельного sub-agent и двойного гейта.

Наш путь — сначала inline-механизм, потом метрики, потом dreaming. Не потому, что мы не верим в консолидацию, а потому что нужно понять что именно консолидировать. Без данных из прода — это стрельба вслепую.

Когда будем реализовывать — скорее всего Вариант B (batch-консолидация с review gate), как у Anthropic. А если понадобится audit trail — Вариант C (append-only логи + nightly distillation), как в KAIROS. Но это уже совсем другая история.

Предыдущая статья серии: Часть 5: Agent Memory Management Следующая статья серии: Часть 7: Cloud-Native Standards

Источники

1. OpenAI. “Dreaming: Better memory for a more helpful ChatGPT.” 4 июня 2026. openai.com/index/chatgpt-memory-dreaming
2. solaius (Red Hat Research). “Claude Memory & Dreaming Deep Dive.” Июнь 2026. github.com/solaius/ai-asset-registry