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

У AI-агентов есть странная суперсила: внутри одной сессии они могут держать в голове почти весь проект, быстро связывать файлы, решения, ошибки и планы. Но стоит закрыть чат — и всё. Следующая сессия начинается как будто с амнезией.

Да, есть системные промпты, README, CLAUDE.md, длинные инструкции. Но это не совсем то. Они описывают проект в целом, а не то, что происходило вчера вечером: почему мы выбрали именно это решение, где остановились, какие файлы уже трогали, какой подход не сработал, что нужно проверить следующим.

Сегодня я собрал проект, который закрывает именно эту дыру. Я называю его «Память между сессиями».

Проблема не в памяти как таковой

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

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

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

И чтобы в новой сессии другой агент мог эту записку прочитать.

То есть память здесь — не «модель стала умнее». Память здесь — это нормальная инженерная дисциплина: короткие саммари, лежащие рядом с проектом.

Самый важный принцип: local-first

Я не хотел делать систему, где агент обязан ходить на сервер при каждом сохранении. Это неправильная зависимость. Сессия должна сохраняться сразу, на диске, даже если интернет умер или сервер временно недоступен.

Поэтому базовый формат максимально простой: Markdown-файлы в папке проекта.

Агент завершает работу, пользователь говорит: «сохрани сессию», и появляется файл вроде:

memory/sessions/2026-05-26-A4F2K9-refactor-auth.md

Внутри — человеческое саммари: что делали, ключевые решения, затронутые файлы, состояние на конец сессии, следующие шаги.

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

Это важный момент: если система памяти ломается, память всё равно остаётся. Потому что это просто файлы.

Второй слой: общий сервер для команды

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

Поэтому поверх локального слоя есть серверная реплика.

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

Это уже не просто личная заметка. Это командная память проекта.

При этом сервер не становится единственным источником правды в момент сохранения. Сначала файл пишется локально. Потом синхронизируется. Если сеть упала — запись не теряется, она просто доедет позже.

Третий слой: MCP для агентов

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

Локальный MCP-сервер даёт агенту набор понятных инструментов:

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

Это значит, что Claude Code, Cursor, Gemini CLI, Codex CLI или другой агент не должны знать внутренности проекта. Они просто получают инструмент «память сессий» и работают с ним.

А если MCP недоступен, остаётся запасной путь: обычный Markdown-скилл. Агенту можно дать инструкцию, как вручную записывать файл и обновлять индекс. Это менее красиво, зато переносимо почти в любой среде.

Почему я выбрал Markdown, а не базу данных

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

Markdown даёт несколько преимуществ:

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

Сервер при этом тоже достаточно простой: файловое хранилище, JSON-метаданные, FastAPI, веб-интерфейс, токены, права доступа. Не потому что «так проще написать», а потому что здесь простота — это свойство продукта.

Система памяти не должна сама становиться проектом, который нужно постоянно спасать.

Как выглядит поток работы

В обычном сценарии всё сводится к простой привычке.

В конце длинной работы я говорю агенту: «сохрани сессию».

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

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

Главное, что эта память не принадлежит одному чату. Её может прочитать другой агент. Сегодня работал один инструмент, завтра другой — контекст проекта всё равно остаётся в проекте.

Что в этом оказалось самым ценным

Для меня главная ценность не в том, что агент «запоминает». Главная ценность — в том, что появляется явная граница между хаосом разговора и состоянием проекта.

Чат — это процесс. Он шумный, длинный, с ошибками, разворотами и промежуточными мыслями.

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

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

Куда это может развиваться

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

Но ядро идеи я бы не усложнял.

Самая сильная часть этой системы именно в том, что она не пытается быть «вторым мозгом» с большой буквы. Она делает одну вещь: превращает завершённую AI-сессию в аккуратную запись, которую можно прочитать завтра.

И этого уже достаточно, чтобы работа с агентами стала менее похожа на бесконечное «давай я тебе снова объясню проект с нуля».

Память между сессиями — это не фантастика про вечного AI-помощника. Это маленький инженерный мостик между вчерашним контекстом и сегодняшней работой.