← Университет

Память и общий мозг: контекст, RAG, scratchpad, долгосрочная память и обмен знаниями между агентами — разбор для завода Лучиана

Зачем это вообще отдельная тема, а не деталь оркестрации

Оркестрация отвечает на вопрос «кто что делает и в каком порядке». Память отвечает на другой вопрос — «что агент вообще ЗНАЕТ в момент, когда действует, и откуда это знание берётся». Это разные слои архитектуры, и их смешение — источник половины проблем, с которыми Лучиан уже столкнулся на практике (раздутие контекста до ~1M токенов на 12-шаговой задаче). Материал memory-state.md формулирует это жёстко: контекстное окно — это ОЗУ (RAM), «летучая, эфемерная, исчезает после завершения сессии», а долгосрочная память — это диск, сохраняющий информацию между сессиями. «Всё в контекстном окне исчезает по окончании сессии, включая предпочтения, изложенные на первом ходу, ограничения, установленные на третьем ходу, и решения, принятые на седьмом ходу» (Mem0, 2026). Ошибка путать эти два слоя приводит к предсказуемым отказам: нарушение ограничений, размывание предпочтений, внутренние противоречия в середине сессии.

У Лучиана уже есть физическое воплощение этого принципа — memory-bank, отдельный docker-сервис (порт 4600), который «диск», в то время как каждая сессия claude -p в генераторе — «ОЗУ», которое исчезает сразу после рендера видео. Это не метафора для обучения — это буквально то, как устроен его завод. Задача этого урока — объяснить, ПОЧЕМУ его архитектура уже правильная в этом смысле, и что нужно доделать, чтобы она стала «общим мозгом», а не просто складом.

Отдельно стоит подчеркнуть, почему тема памяти для него — не факультативная. Все три больших направления его года (video-заводы, консультант-фабрика MVP, автономный строитель) объединяет одна общая зависимость: КАЖДОЕ из них требует, чтобы система становилась дешевле и точнее с опытом, а не повторяла одни и те же ошибки на каждом новом канале/клиенте/проекте. Оркестрация решает вопрос «кто делает работу сейчас», но именно память решает вопрос «станет ли система умнее к завтрашней ночи» — и это прямая реализация его требования «этап 2: путь к самоулучшению». Без работающей памяти автономия ночью превращается не в самообучение, а в бесконечное повторение одного и того же цикла проб и ошибок за его деньги.

Три типа памяти — и где они уже живут на заводе

memory-state.md (State of AI Agent Memory 2026, Mem0) делит память агента на три типа, и это не академическая классификация — она напрямую мапится на структуру memory-bank Лучиана.

Эпизодическая память (episodic) — конкретные события в последовательности: «пользователь запросил анализ 15 июля, получил CSV с 10 000 записей». На заводе это log.jsonl внутри per-channel банка (data/channels/<id>/profile.json + log.jsonl) — журнал того, что случилось с конкретным каналом: какие видео вышли, какие метрики собрались, какие правки правились вручную.

Семантическая память (semantic) — обобщённые факты и правила: «клиент X предпочитает еженедельные отчёты», «максимум 5 задач на агента». На заводе это global.json — кросс-канальные правила (то, что применимо ко ВСЕМ каналам, независимо от ниши) и profile.json каждого канала (маскот, DNA, scene-mix — устоявшиеся факты о том, «какой этот канал»).

Процедурная память (procedural) — «как делать вещи», выученные методы. На заводе это per-generator банк (data/generators/{photo,omni,remotion}.json) — «channel-агностичный крафт: правила+wins», то есть не факты про конкретный канал, а выученные приёмы генерации в принципе («такой промпт для сцен даёт лучший рендер», независимо от того, какой это канал).

Важно понимать: это разделение — не бюрократия, а защита от одной конкретной ошибки — протечки контекста между уровнями. В досье memory-bank прямо описана эта грабля: «синтетические (тренировочные) каналы раньше протекали в общий банк и портили правила для реальных каналов» — решение был isSynthetic-гейт, который закрывает все пишущие двери. Другая такая же грабля описана там же: «AVOID-лайны раньше текли между стадиями (script/visual) без разбора kind» — то есть дефект, найденный на стадии написания сценария, ошибочно применялся к стадии генерации визуала. Решение — читать steering-правила scoped по стадии (kind=). Это универсальный принцип для любой памяти с несколькими уровнями: без строгой изоляции «кто что пишет и кто что читает» общая память быстро превращается в общий шум, где правило одного контекста заражает другой.

От чистого векторного поиска к гибридному retrieval — почему это критично для памяти агента

Ранняя интуиция про память агентов — «просто засунь всё в vector DB и делай semantic search» — устарела в 2025-2026. memory-state.md описывает переход индустрии от чистой векторизации к мультисигнальному поиску (multi-signal retrieval): семантическое сопоставление через dense embeddings + ключевой поиск через BM25 (для точных сущностей и дат) + entity matching через графовые отношения. Цифры конкретны: система Mem0 (апрель 2026) достигла 92.5 балла на бенчмарке LoCoMo и 94.4 на LongMemEval при потреблении 6 900 токенов на запрос против ~26 000 в full-context подходах — сокращение на 73%. Наибольший прирост дал multi-hop поиск (+23.1 точки) — способность агента прослеживать цепочки зависимостей в памяти, а не просто находить один похожий факт.

Для завода Лучиана это прямая практическая рекомендация: если он захочет заменить сегодняшний memory-bank (плоские JSON-файлы + log.jsonl) на что-то более умное для масштаба «десятки каналов», НЕ нужно сразу бросаться в чистый vector DB. Правильная эволюция — гибрид: JSON/структурированные поля (per-channel profile, per-generator rules) остаются для точных lookup по ключу (это дешевле и надёжнее векторного поиска для структурированных данных), а vector search добавляется ТОЛЬКО там, где нужен смысловой поиск по свободному тексту — например, «найди похожие проблемы у других каналов» по описанию дефекта, где точный текст не совпадает, но смысл тот же. Materials про Vector Databases (_HQ2H_0Ayy0, v0ynfDPpe4E) объясняют механику: индексация через approximate nearest neighbor (например, Locality Sensitive Hashing) позволяет искать по миллиардам векторов за миллисекунды, но это оверинжиниринг для базы данных с сотнями записей на десяток каналов — векторный поиск оправдан, когда объём данных исчисляется тысячами+ документов, а не десятками правил.

Двухуровневая архитектура памяти — модель, которую нужно скопировать буквально

Ключевая рекомендуемая архитектура из memory-state.md: Уровень 1 — контекстное рабочее окно (5-10 релевантных воспоминаний на ход, извлечённых специализированным retriever-ом ПЕРЕД каждым вызовом LLM), Уровень 2 — персистентное хранилище (полная история, все факты и паттерны). Ключевая деталь, которую легко пропустить: «производительность деградирует задолго до достижения лимита токенов из-за эффекта "потерянного в середине" (lost-in-the-middle)» — модель хуже обрабатывает информацию из центра длинного контекста. Это значит, что даже если у модели теоретически влезает 1M токенов, НЕ стоит скармливать ей весь memory-bank целиком «на всякий случай» — нужен активный retriever, который решает, ЧТО из банка релевантно ИМЕННО этой задаче, и передаёт только это.

Практическая проблема Лучиана («12+ шагов → 1M токенов, платил за перечитывание одного и того же») — это симптом отсутствия Уровня 1. Если каждый субагент вместо retriever-а получает «весь контекст на всякий случай», система деградирует именно так. Решение прямо совпадает с его собственным выводом из практики: «контекстная изоляция: каждый субагент получает минимальный контекст под свою подзадачу», «внешняя память вместо контекста: промежуточные результаты в файлы/scratchpad/memory-bank». Он это уже сформулировал интуитивно — теория лишь даёт этому название и обосновывает, почему это не экономия ради экономии, а требование архитектуры (иначе retrieval quality падает независимо от размера окна модели).

Letta / MemGPT — «LLM как операционная система» и self-editing память

Материал memory-state.md описывает Letta (преемник MemGPT, Berkeley) — концептуальный прорыв: модель рассматривается как операционная система, управляющая СОБСТВЕННОЙ памятью. Архитектура включает: Core Memory — критические блоки (human-блок: данные о пользователе; persona-блок: идентичность агента; константные ограничения «никогда не делай X»), которые ВСЕГДА в контексте, встроены в системный промпт; Self-Editing Capabilities — агент сам может редактировать свою память («О, я неправильно запомнил имя — обновляю»), реорганизовывать её при новых паттернах, архивировать устаревшее; Recall & Archival — старые разговоры автоматически суммируются («пользователь обсудил требования 100 раз за 6 месяцев» → одна-две страницы конденсата вместо 100 диалогов); Inner Thoughts — приватные цепочки рассуждений перед действием, невидимые пользователю.

Это прямая архитектурная модель для второго этапа целей Лучиана — «путь к самоулучшению: система дописывает своих агентов». Сегодня его memory-bank статичен в смысле self-editing: правила туда пишут внешние сервисы (photo/omni через bank.py), а не сам агент по собственной инициативе в реальном времени во время работы. Летта-подход подсказывает следующий шаг эволюции: дать генерирующему агенту инструмент «обнови свою память прямо сейчас», а не только пассивно логировать после факта. Важное предостережение из этой же концепции: self-editing без guardrails опасен — если агент может свободно переписывать global-банк (правила, применимые ко ВСЕМ каналам), одна ошибочная генерация может испортить правило для десятков каналов сразу. Именно поэтому у него УЖЕ есть защитный механизм — порог count≥5 суммарной повторяемости перед промоушеном дефекта в generator-bank («при малом числе реальных каналов (n=2) один разовый артефакт FastGen становился вечным глобальным правилом» — это реальный баг, который он поймал и починил). Это конкретный пример принципа «self-editing требует порога уверенности», выведенного не из теории, а из его собственной практики — теория лишь подтверждает, что решение верное.

OneContext / git-like память — сохраняющаяся структура branch/commit/merge

Транскрипт pAIF7vZm5k0 («Agent memory resolved?») описывает конкретный, воспроизводимый паттерн под названием "get context controller" (OneContext), заявляющий 13% прирост качества на задачах разработки и позволяющий более дешёвым моделям работать на уровне frontier-моделей за счёт лучшей памяти, а не большей модели. Идея: агент ведёт память как git — четыре файла: main.md (глобальная дорожная карта проекта), и для каждого «branch» (альтернативного подхода/направления работы) — свою папку с commit.md (высокоуровневые вехи — резюме после каждой завершённой подзадачи, как git commit), log.md (полная сырая история действий — OTAA, observation-thought-action-action), metadata.md (техническая информация для навигации).

Четыре действия: branch (когда агент пробует альтернативную стратегию — например, «попробую Playwright вместо API»), commit (после каждой значимой вехи — обновляет commit.md и опционально main.md), merge (когда подход завершён и успешен — сливает commit.md в главный, комбинирует log.md). Ключевое преимущество, прямо процитированное: «этот branch-commit-merge метод позволяет агенту форкать разговор очень легко, не теряя общий контекст» — и это решает ровно ту проблему, которую Лучиан описывает как боль №1: раздутие контекста при многошаговых задачах, где приходится «платить за перечитывание одного и того же».

Это прямая рекомендация для его будущего «универсального строителя» (первый приоритет по его профилю): вместо одной длинной сессии на 12+ шагов, где всё накапливается в контексте, строитель должен вести файловую структуру именно так — при попытке нового архитектурного подхода создаётся branch, при завершении вехи — commit (короткое резюме, не полная история), а при успехе — merge в main. Читать заново нужно только main.md (обзор) + при необходимости конкретный commit.md конкретного branch, а не всю сырую историю. Это точная файловая реализация принципа «двухуровневая память»: main.md/commit.md — Уровень 1 (сжатое, читается всегда), log.md — Уровень 2 (полная история, читается только при явной необходимости «покопаться»).

Anthropic Blueprint — context anxiety, context reset и «прогресс-файл» как scratchpad

Материал 9d5bzxVsocw (разбор поста Anthropic про harness для long-running агентов) вводит два термина, критичных для «строителя», работающего ночью без человека. Context anxiety — по мере заполнения контекстного окна модель не просто теряет связность, она МЕНЯЕТ поведение: «начинает сворачивать разговор преждевременно, торопится через шаги и объявляет вещи сделанными, когда они не сделаны». Это прямая угроза автономной ночной работе — если строитель Лучиана работает 6-8 часов без надзора, context anxiety означает, что он может «сдаться раньше», объявив задачу завершённой, хотя она не завершена.

Решение первого поколения (Sonnet 4.5) — context reset: «начать с чистого контекстного окна, прочитать последнюю фичу из progress-файла, протестировать ранее построенные фичи, построить конкретную задачу. Закончив — триггернуть структурированный хендофф, и следующий агент стартует с чистого листа». Progress-файл здесь — это буквально scratchpad, внешний файл состояния, который переживает смену сессии (аналог main.md из OneContext, аналог factory.json/state.json в проектах Лучиана). Важная деталь, которую стоит подчеркнуть Лучиану прямо: даже когда модели улучшаются (Opus 4.6 с 1M-контекстом якобы не имеет context anxiety), сам факт наличия внешнего progress-файла остаётся полезным НЕЗАВИСИМО от качества модели — это не костыль под слабую модель, это архитектурная гарантия, что прогресс не теряется при сбое, крахе процесса или обрыве сессии. У Лучиана это уже есть буквально: generators/<gen>/projects/<slug>/state.json + config.json — тот же самый паттерн, тот же принцип.

Второй ключевой инсайт — adversarial evaluation (генератор + независимый оценщик по GAN-аналогии), уже разобранный подробно в orkestratsiya.md, но здесь важна именно memory-часть этого паттерна: «Claude из коробки — слабый QA-агент... находил легитимные проблемы и потом сам себя убеждал, что это неважно, и одобрял работу». Причина отчасти в памяти — если оценщик видит ту же историю рассуждений, что и генератор, он наследует те же слепые пятна (эхо-камера, уже знакомая Лучиану по thumbnail-studio). Решение архитектурное: оценщик получает МИНИМАЛЬНО необходимый контекст — только артефакт и критерии, не цепочку рассуждений генератора. Это опять прямое совпадение с verifier pattern из autonomous-coding.md.

Shared Memory / Blackboard для мультиагентных систем — координация без раздутия

solo-operator-scale.md формулирует критическую архитектурную проблему прямым текстом: «traditional message-passing теряет контекст между агентами; решение — Shared Memory (common knowledge graph), где все агенты видят одно состояние». memory-state.md детализирует это через трёхуровневую иерархию AWS: Working Memory (контекстное окно LLM, эфемерна), Individual Long-Term Memory (персистентная память каждого агента между сессиями), Shared Multi-Agent Memory (коллективное состояние и открытия, доступные ВСЕМ агентам). Без третьего уровня система «неизбежно дублирует работу, производит противоречивые действия и впустую тратит бюджет токенов» — то есть если один канал уже узнал (через QC), что определённый визуальный стиль плохо работает, а другой канал не имеет доступа к этому знанию, он повторит ту же ошибку и потратит те же токены на её обнаружение заново.

Это ровно то, зачем существует memory-bank Лучиана в его нынешнем виде — но здесь важно отметить незавершённость: per-generator банк («channel-агностичный крафт») — это и есть Shared Multi-Agent Memory, потому что photo/omni/remotion генераторы для РАЗНЫХ каналов читают ОБЩИЕ правила рендеринга. Но per-channel банк («AVOID/steering») — это Individual Long-Term Memory, специфичная для одного канала. Правильная архитектура держит их раздельными (как у него уже сделано), а промоушен из индивидуального в общее должен проходить порог доверия (тот самый count≥5) — иначе один канал «загрязняет» знание для всех остальных.

Критичная и пока не закрытая проблема, прямо описанная в его же документации: «learning-loop... сейчас холостая — оркестратор выключен, метрики не текут автоматически». Это значит, что Уровень 9 (LEARNING) конвейера — тот самый механизм, который должен закольцовывать shared memory (метрики видео → уроки → следующий цикл генерации) — физически существует в архитектуре, но не подключён к реальному потоку данных. С точки зрения памяти это не мелкий баг, а отсутствие обратной связи в самом важном месте: без него banks накапливают структуру, но не учатся на реальных результатах публикации. Это первый и самый очевидный приоритет для «памяти как общего мозга» — включить оркестратор именно чтобы замкнуть петлю LEARNING, а не строить что-то новое поверх незамкнутой.

OpenClaw MEMORY.md — эталонная минимальная реализация двухуровневой памяти

Прежде чем строить что-то сложнее, стоит внимательно разобрать самую простую рабочую реализацию, которую Лучиан уже пробовал руками — память OpenClaw (systems/openclaw.md). Структура буквально четыре сущности: SOUL.md (идентичность агента — «кто я и как себя веду», аналог persona-блока Letta), USER.md (профиль пользователя — стабильные факты о том, с кем агент работает), MEMORY.md (долгосрочная память — «стабильные правила и предпочтения», семантическая память в чистом виде), memory/YYYY-MM-DD.md (ежедневные логи — эпизодическая память, по одному файлу на день), и отдельно .learnings/mistakes.md + .learnings/best-practices.md (процедурная память — «ошибки и как их избежать»). Цикл работы прост и достоин копирования буквально: «1) инициализация — агент загружает SOUL.md и USER.md для понимания контекста; 2) текущая сессия — события пишутся в ежедневный лог; 3) обучение — ошибки анализируются и записываются в .learnings/; 4) долгосрочное развитие — MEMORY.md обновляется с выводами».

Это ровно та же трёхчастная типология (эпизодическая/семантическая/процедурная), что и в memory-bank Лучиана, только на файлах markdown вместо JSON — и это важное наблюдение: формат хранения (markdown-файлы vs JSON vs база данных) вторичен, первична СТРУКТУРА разделения по типу и владению. Известные грабли OpenClaw из того же досье стоит учитывать заранее, потому что они предсказывают будущие проблемы memory-bank при масштабе: «конфликты при параллельных запросах — если много агентов одновременно пишут в MEMORY.md» (у Лучиана это уже частично решено через API-эндпоинты memory-bank вместо прямой записи в файл, но при росте параллелизма — резонно спросить, есть ли там file-locking или это чисто HTTP-сериализация записей) и «утечки памяти при длительной работе — требуется периодический перезапуск daemon'а» (актуально для любого долгоживущего процесса, который накапливает состояние в памяти процесса, а не только на диске).

RAG как частный случай памяти — не путать инструмент с архитектурой

Материалы _HQ2H_0Ayy0 и v0ynfDPpe4E («RAG Explained») и fundamentals-agents.md полезно развести терминологически, потому что в разговорной речи «RAG» и «память агента» часто смешивают, а это разные уровни абстракции. RAG (Retrieval-Augmented Generation) — это ТЕХНИКА: запрос превращается в эмбеддинг → ищутся похожие документы в векторной базе → найденное добавляется в промпт → модель генерирует ответ с этим дополнительным контекстом. Это механизм retrieval, а не архитектура памяти сама по себе — RAG можно применить и к статичной базе знаний (документация компании), и к динамической памяти агента (история его же прошлых решений). fundamentals-agents.md даёт полезный ориентир по зрелости: «истинные агенты имеют разрешение задач на 40-80%, RAG системы только 10-20%» — то есть чистый RAG-бот, который просто ищет и отвечает, качественно слабее настоящего агента, который решает задачи итеративно. Для Лучиана вывод такой: retrieval (поиск релевантного) — это ОДИН из инструментов, которые должна использовать система памяти, но сама по себе не гарантирует «умную» память — важнее СТРУКТУРА хранения (что с чем связано, какие поля есть у записи, кто и когда может писать), а RAG — это просто способ найти нужную запись, когда её структурированный lookup невозможен (запрос на естественном языке, а не по точному ключу).

Karpathy LLM Wiki и Open Knowledge Format — стандартизация «второго мозга» как знаниевого графа

Транскрипт T33iI6izAKw описывает паттерн, вышедший за пределы одного агента — Karpathy LLM Wiki (гист, набравший 40 000 звёзд): идея не «просто индексировать документы для RAG», а дать LLM инкрементально СТРОИТЬ и поддерживать персистентную wiki со структурированными взаимосвязанными markdown-файлами. Ключевое отличие от плоского RAG: «по мере добавления новых источников (транскрипты встреч, планы, статьи), LLM не просто индексирует их, а читает каждый файл, извлекает ключевую информацию и интегрирует её в существующую wiki» — обновляя entity-страницы (страницы конкретных сущностей — людей, проектов, каналов), формируя «граф знаний, по которому агент может перемещаться». Это принципиально отличается от memory-bank в его нынешнем виде: memory-bank — это плоские записи (правила, дефекты, wins) без связей между собой, а LLM Wiki — это связный граф, где, например, страница «канал X» ссылается на страницу «дефект Y», которая ссылается на страницу «генератор Z».

Проблема, которую решает Open Knowledge Format (Google): у каждого, кто строит свою LLM Wiki, получается своя структура, что делает их несовместимыми и непереносимыми — «если агент не знает точно, как структурирована wiki, с какими метаданными, он не сможет искать по ней оптимально». Для Лучиана это не абстрактная забота (он не планирует делиться memory-bank с чужими агентами), но сама идея важна для дальнего горизонта: если он планирует масштабировать завод до десятков каналов и параллельно строить консультант-фабрику MVP для внешних клиентов, ценность в том, чтобы memory-bank ЭВОЛЮЦИОНИРОВАЛ от плоских записей к связному графу знаний — не «список дефектов канала X», а «дефект Y связан с генератором Z, связан со стилем W, связан с тремя другими каналами, где повторялся». Практический первый шаг в эту сторону — не переписывать всё под graph DB, а начать явно проставлять cross-reference поля (channel_id, generator, related_defect_id) в уже существующих JSON-записях, чтобы при будущем переходе на графовую модель миграция была дешёвой.

Скретчпад-файлы и .agent-паттерн — низкоуровневая гигиена контекста

Транскрипт MW3t6jP9AOs (.agent-папка) даёт практическую механику context engineering на уровне Claude Code: «контекст состоит из системного промпта (не меняется), инструментов/MCP (можно отключить неиспользуемое), memory-файла (CLAUDE.md — может разрастись и съесть весь контекст), и сообщений (можно уменьшить через субагентов)». Ключевая рекомендация: субагенты как инструмент СЖАТИЯ контекста — если субагент делает исследовательскую работу (поиск в кодовой базе, чтение документации), он возвращает в главную сессию только ВЫВОД, а не весь процесс поиска, тем самым «сберегая» контекстное окно оркестратора. Это то же самое правило, что «оркестратор передаёт выжимки, не сырьё», уже присутствующее в его собственном профиле требований.

Практический вывод для его будущей системы: любой служебный/промежуточный файл (черновики промптов, результаты неудачных попыток, сырые логи ошибок) должен жить в scratchpad-файлах на диске, а не в разговоре с моделью — модель должна ЯВНО решать, когда читать этот файл (retrieval по запросу), а не носить его постоянно в контексте. Это одновременно снижает токенокост и защищает от context anxiety (меньше «шума», из-за которого модель раньше «устаёт» и хочет закончить).

Память для консультант-фабрики MVP — отдельный контур, который пока не существует

Всё вышеописанное касается памяти внутри УЖЕ работающего конвейера видео. Но третье приоритетное направление Лучиана — консультант-фабрика MVP («боли клиента → ночь → веер решений → продажа») — требует принципиально ДРУГОГО контура памяти, которого сегодня в архитектуре завода просто нет, и об этом стоит сказать прямо, потому что легко ошибочно предположить, что существующий memory-bank «и так справится».

Разница в природе данных: video-конвейер работает с ОДНОРОДНЫМИ сущностями (каналы, генераторы, ниши), где имеет смысл кросс-канальное обучение («что сработало на канале X, вероятно, сработает на канале Y, если жанр похож»). Консультант-фабрика работает с ГЕТЕРОГЕННЫМИ клиентами из произвольных доменов (кофейня, стройка, финансовая контора) — и здесь кросс-клиентское обучение куда более рискованно: то, что решило проблему кофейни («автоматизировать учёт смен бариста»), почти наверняка НЕ переносится напрямую на строительную компанию. Это значит, что для этого контура нужна память с ИНОЙ структурой промоушена: не «повторилось у 5 клиентов → стало глобальным правилом» (как для video-каналов), а скорее «per-domain банк» — отдельная семантическая память по КАЖДОЙ отрасли (кофейни, стройка, школы), куда факты про конкретного клиента промоутятся только внутри своей отрасли, и отдельно — meta-банк процедурных уроков про сам ПРОЦЕСС консалтинга («как быстро извлечь боль клиента», «какие вопросы дают наибольший сигнал за 15 минут интервью») — это уже честно кросс-доменное знание, применимое к любому клиенту независимо от отрасли.

Практическая рекомендация: когда Лучиан начнёт строить этот контур, стоит СРАЗУ проектировать его по той же трёхуровневой типологии (эпизодическая: конкретные интервью с конкретными клиентами и что они сказали; семантическая: устоявшиеся факты про отрасль/клиента; процедурная: выученные методы ведения консалтинга и генерации MVP), но с явным разделением на domain-scoped и process-scoped банки с первого дня — переделывать плоскую структуру памяти после того, как накопилось 50 клиентов вперемешку, будет значительно дороже, чем начать правильно, опираясь уже на готовый опыт исправления похожей ошибки в video-конвейере (synthetic-каналы, протёкшие в общий банк).

Экономика памяти — кеширование и стоимость «вспоминания»

Память не бесплатна — каждый раз, когда агент читает файл памяти или получает результат retrieval в промпт, это токены, которые нужно оплатить и обработать заново, если не используется кеширование. Это прямо связано с тревогой Лучиана про «монстра, кушающего $1000 в минуту», и с его собственным правилом стоп-крана («>250k cache-read или >$0.50 — стоп и пересборка»). Материал reliability-cost-security.md фиксирует важный практический нюанс токеномики: prompt caching резко снижает стоимость повторного чтения СТАБИЛЬНОГО контента (system prompt, инструкции, статичные части CLAUDE.md/MEMORY.md), но НЕ помогает, если содержимое памяти меняется от вызова к вызову — а именно так устроена динамическая память (log.jsonl растёт, profile.json обновляется). Отсюда практическое архитектурное правило: разделять память на стабильную часть (правила, DNA канала, редко меняющиеся факты — кешируется эффективно, ставится в начало промпта) и volatile-часть (последние N событий, свежие метрики — меняется часто, должна быть маленькой и идти отдельно, чтобы не «сбивать» кеш стабильной части). Если Лучиан кладёт весь profile.json целиком в каждый вызов генератора без разделения на «то, что не меняется» и «то, что меняется», он теряет выгоду от кеширования на самой большой, стабильной части файла из-за того, что рядом лежит быстро меняющаяся часть.

Второй экономический принцип из memory-state.md, прямо применимый: retrieval 5-10 релевантных записей вместо полного банка — это не только про качество (lost-in-the-middle), но и про деньги: 6 900 токенов на запрос вместо 26 000 — это разница почти в 4 раза на каждый вызов, при десятках каналов и сотнях генераций в месяц это конкретная сумма в его $500-2000/мес бюджете. Лестница моделей (его собственное правило: haiku на механику, sonnet на код, opus на архитектуру) тоже касается памяти напрямую — извлечение релевантных записей из банка (retrieval) само по себе МЕХАНИЧЕСКАЯ задача (grep/lookup по полям, а не творческое рассуждение), и её не нужно делать дорогой моделью; дорогая модель нужна только на этапе, когда извлечённый контекст уже передан и требуется рассуждение над ним.

Временные рассуждения и multi-hop — почему «что случилось» и «когда» — разные вопросы

Отдельного внимания заслуживает деталь бенчмарков из memory-state.md, легко упускаемая при поверхностном чтении: наибольший прирост качества у современных гибридных систем памяти пришёлся на временны́е рассуждения (+29.6 точки) — способность агента понимать ЭВОЛЮЦИЮ истории, а не просто найти похожий факт. Пример из практики Лучиана: вопрос «какой стиль обложки сейчас работает лучше для канала X» — это не поиск одной похожей записи, это вопрос, требующий сравнить историю ПОСЛЕДНИХ решений с более старыми и понять тренд (может быть, стиль A работал хорошо три месяца назад, но последние две недели стабильно проигрывает стилю B — простой семантический поиск найдёт обе записи как «релевантные», но не скажет, какая актуальнее). Это прямой аргумент в пользу того, чтобы log.jsonl per-channel банка хранил не только факт («видео с обложкой A получило Z просмотров»), но и явную временную метку, используемую при retrieval с весом «свежести», а не только релевантности по смыслу — иначе память рискует давать советы, актуальные для прошлого канала, а не для сегодняшнего.

Второй момент — multi-hop запросы (+23.1 точки): способность агента проследить ЦЕПОЧКУ зависимостей («дефект Y на канале X был вызван правилом Z в generator-банке, которое было добавлено после промоушена из канала W»). Это ровно то, для чего полезен переход к связному графу знаний (см. раздел про Karpathy LLM Wiki выше) — плоский список записей плохо поддерживает такие цепочки, а явные cross-reference поля их поддерживают почти бесплатно.

Практический тест для Лучиана, чтобы понять, готов ли его memory-bank к этим двум сценариям уже сегодня: попробовать вручную задать боту два вопроса — «что изменилось в подходе к обложкам за последний месяц» (временной) и «почему это правило вообще появилось в generator-банке» (multi-hop). Если ответ на оба требует ручного пролистывания сырых JSON-файлов, а не структурированного запроса к API memory-bank, — это конкретный, измеримый разрыв между «складом фактов» и «общим мозгом», который стоит закрывать по мере роста числа каналов, а не откладывать до момента, когда объём данных сделает это болезненным.

Фреймворки-подходы к памяти — AutoGen/AG2 и CrewAI, полезный контраст

Полезно сравнить, как готовые фреймворки решают задачу памяти, потому что это показывает диапазон решений от «наивного» до «продуманного». В AG2/AutoGen (systems/autogen.md) краткосрочная память по умолчанию устроена буквально наивно: «полная история сообщений в текущем чате... автоматически передаётся ВСЕМ агентам в GroupChat» — то есть все участники группового чата видят весь диалог целиком, без фильтрации. Это ровно тот антипаттерн, о котором предупреждает `memory-state.md» и который Лучиан уже прожил на своей практике: чем дольше идёт групповой диалог, тем больше каждый агент вынужден «перечитывать» одно и то же на каждом шаге — контекст растёт линейно с числом сообщений, умноженный на число агентов, которым он передаётся. AG2 компенсирует это долгосрочной памятью через Context Variables (явно переданные структурированные переменные между чатами, а не сырая история), TTL Policy (автоматическое удаление устаревших данных по времени — полезный принцип, которого пока НЕТ явно описанным в memory-bank Лучиана: старые дефекты и wins накапливаются, но нет механизма их «затухания» по давности) и Hindsight Memory (специализированная система именно для обучения на прошлом опыте, а не просто хранения).

CrewAI, для контраста, продвинулся дальше в автоматизации: «LLM-powered система памяти с семантическим поиском и cross-run обучением позволяет агентам учиться на пройденных выполнениях без ручного тегирования» (systems/crewai.md) — то есть память сама решает, что важно запомнить, без явного программирования правил экстракции. Это привлекательно на словах, но стоит отнестись с осторожностью: «без ручного тегирования» означает меньше контроля над тем, ЧТО именно система решает запомнить, а бесконтрольная авто-экстракция — прямой путь к той же проблеме единичного случая, ставшего глобальным правилом, которую Лучиан уже ловил вручную через порог count≥5. Вывод: полностью автоматическая память удобна для старта, но production-система для денег (как у Лучиана) выигрывает от ЯВНЫХ порогов и правил промоушена, а не от «магии» LLM, решающей за вас, что важно запомнить.

Типичные ошибки в архитектуре памяти — сводка антипаттернов

  1. Смешение RAM и диска. Хранение долгосрочных правил ТОЛЬКО в контексте разговора (например, «я уже объяснял агенту это в начале сессии, он должен помнить») — гарантированная потеря при новой сессии или компакции. Решение: если правило должно пережить сессию — оно обязано быть записано во внешний файл/банк, а не оставлено «в голове» модели.

  2. Протечка между уровнями памяти без scoping. Уже дважды случалось у Лучиана на практике (synthetic-каналы → общий банк; AVOID-лайны между стадиями script/visual). Общий урок: любая многоуровневая память нуждается в явных границах записи/чтения (namespace, kind, scope), иначе она деградирует до общего шума быстрее, чем накапливает полезные знания.

  3. Промоушен единичного случая в глобальное правило. «При n=2 каналов один разовый артефакт FastGen становился вечным глобальным правилом». Решение — статистический порог (count≥5) перед тем, как индивидуальный опыт становится частью общего мозга. Это прямая аналогия иммунной системы, не реагирующей на каждый единичный сигнал как на угрозу — нужна повторяемость, чтобы выработать «антитело»-правило.

  4. Оценщик, унаследовавший контекст генератора (эхо-камера). Оценщик, видящий полную цепочку рассуждений генератора, склонен подтверждать его же логику вместо независимой оценки. Решение — минимизировать контекст, передаваемый оценщику: только артефакт + критерии.

  5. «Полный контекст на всякий случай». Скармливание модели всего memory-bank целиком вместо активного retrieval 5-10 релевантных записей. Даже при большом контекстном окне (1M токенов) качество деградирует из-за lost-in-the-middle — большой контекст не отменяет необходимость retrieval-слоя, он просто делает ошибку менее заметной (дороже, но незаметнее).

  6. Незамкнутая петля обучения. Наличие архитектуры для памяти (банки, стадия LEARNING) без реально текущих данных — структура есть, а обратная связь отсутствует. Это тихая ошибка: система выглядит «умной» по устройству, но фактически не учится, пока конкретный оркестратор/шов не включён и не проверен на живых данных.

  7. Полная автоматизация экстракции памяти без порогов. Соблазн доверить LLM самой решать, что важно запомнить (как в CrewAI cross-run learning «без ручного тегирования»), без явного статистического фильтра — риск повторить ошибку единичного случая, ставшего глобальным правилом, только теперь без возможности объяснить, ПОЧЕМУ система это запомнила (чёрный ящик вместо прозрачного порога count≥5).

  8. Отсутствие TTL / затухания памяти. Банки, которые только растут и никогда не «забывают», со временем накапливают устаревшие правила (актуальные для канала полгода назад, но не сейчас — тренды в нишах меняются). Без политики затухания (TTL) или периодической ревизии старые записи продолжают влиять на решения генератора так же весомо, как свежие, что при быстром масштабировании каналов создаёт незаметный, но растущий шум.

Практические выводы — что делать Лучиану дальше

Первое и самое дешёвое: включить оркестратор и замкнуть петлю LEARNING. Это не новая архитектура, а активация уже построенной — самый высокий ROI для темы памяти прямо сейчас, потому что banks без потока метрик — это склад без пополнения.

Второе: формализовать retrieval-слой между memory-bank и генераторами. Сегодня, по всей видимости, генератор читает весь profile.json канала целиком — для десятков каналов это не проблема (профиль одного канала маленький), но при масштабировании до сотен правил в global-банке нужен активный отбор релевантного (5-10 записей на конкретную задачу генерации), а не «отдай всё».

Третье: для будущего универсального строителя внедрить git-like scratchpad (main.md/commit.md/log.md по паттерну OneContext) — это прямое, проверенное решение его самой болезненной проблемы (раздутие контекста на многошаговых задачах), не требующее новой инфраструктуры, только дисциплины файловой структуры.

Четвёртое: держать shared memory (per-generator banks) строго отдельно от individual memory (per-channel banks) — это уже сделано правильно, важно только не размывать это разделение при добавлении новых сервисов (consultant-фабрика MVP, opportunity scout) — у каждого нового агента должно быть чёткое решение: что он пишет в общий банк (после порога доверия), а что остаётся в его собственной памяти.

Пятое: не бросаться в vector DB преждевременно. Для текущего масштаба (единицы-десятки каналов) плоские JSON+scoped-lookup дешевле и надёжнее семантического поиска. Векторный/гибридный поиск оправдан, когда объём накопленных уроков перерастёт то, что помещается в структурированный обзор одним взглядом — вероятно, при масштабе в сотни каналов и тысячи записанных дефектов/побед.

Шестое: ввести TTL/ревизию для правил в global- и per-generator банках — простое дополнение к уже существующей логике порога count≥5: рядом с полем «сколько раз повторилось» добавить поле «когда в последний раз подтвердилось», и раз в месяц (механически, скриптом, не ИИ — по его же правилу №3 «скрипт вместо ИИ где можно») помечать неподтверждавшиеся давно правила как «под вопросом» для ручной или агентной ревизии, а не давать им влиять на генерацию бессрочно.

Седьмое, к вопросу о железе и хостинге памяти: сам memory-bank — лёгкий сервис (Node/Express, плоские JSON-файлы), ему не нужен GPU и не нужна мощная машина — он прекрасно живёт на текущем Hetzner VPS рядом с остальным заводом. Векторный/гибридный слой поиска (если и когда он понадобится по росту масштаба, см. пятый пункт) — тоже не требует GPU (эмбеддинги можно считать дёшево через API или лёгкую CPU-модель), поэтому решение «где жить памяти» не завязано на его RTX 3090 — она нужна для генеративных задач (рендер, локальный инференс), а не для хранения и поиска по банкам. Это разделение стоит держать в голове при планировании инфраструктуры: мозг-планировщик и генераторы могут требовать разного железа, но слой памяти — почти всегда самый дешёвый и переносимый компонент системы, и именно поэтому его разумно развивать в первую очередь, до того как тратить бюджет на более мощное железо под остальные задачи.

Восьмое, финальный акцент на его собственную рамку «деньги»: качественная память — это не абстрактная инженерная добродетель, а прямой рычаг экономики завода. Каждый раз, когда per-generator банк предотвращает повторение уже известного дефекта («такой промпт даёт плохой рендер»), это сэкономленные токены на генерацию и повторную QC-проверку. Каждый раз, когда per-channel банк удерживает канал в его «DNA» без дрейфа стиля, это меньше отклонённых на APPROVAL видео. Замыкание петли LEARNING — это не абстрактное «пусть система умнеет», это конкретное снижение стоимости одного успешного видео со временем, что при цели «десятки каналов» и бюджете $500-2000/мес — единственный путь, которым рост числа каналов не масштабирует расходы линейно.

Источники (корпус, не точные сноски)

Материал синтезирован из следующих разделов базы mas-research, без точной постраничной атрибуции внутри текста:

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