Память агента - твой актив, а не фича вендора

За последние полгода я насмотрелся, как практики мечутся между обвязками для личного ИИ-агента. OpenClaw, потом Hermes, потом обратно в Codex или Claude Code. Новый сетап, и снова собирать всё с нуля. А главный вопрос так и висит: что вообще переезжает с тобой, когда ты меняешь инструмент?

Ответ простой. Переезжает то, чем ты владеешь сам: память и скилы. Модель и харнесс - расходники, просто арендуешь их под задачу.

Память - это главный артефакт, и у неё три измерения

Чтобы память была устроена просто и при этом надёжно, её удобно разложить на три измерения: где она лежит, как организована внутри и когда обновляется.

Storage - где лежит. Самый распространённый вариант - markdown. Cole Medin на конференции OME показывал ровно это: память его агента - просто файлы на компьютере, локальный волт, который он открывает в Obsidian. Никакого аккаунта у вендора. Слово “память” звучит солидно, но на практике это набор текстовых файлов в папках, которые агент читает выборочно в каждой сессии. Markdown легко читается и агентом, и человеком, открывается в любом редакторе. И живёт в одном месте: меняешь инструмент - файлы остаются там же, где лежали; ты их не трогаешь, новый агент просто читает их оттуда. Обязательно с Git: он даёт историю, откат и бэкап одним механизмом. Память - это не векторная база, а след работы: то, что агент реально делал и что ты решил сохранить.

Structure - как разложено. Тут работает один паттерн, и в последние месяцы про него говорят всё чаще - progressive disclosure, прогрессивное раскрытие. Идея: в контекст всегда грузится только тонкий индекс, а полные данные подтягиваются just-in-time, когда реально нужны. Anthropic так строит весь Claude Code: CLAUDE.md уходит в контекст сразу, а полные файлы проекта агент читает, только когда до них доходит дело. Тот же приём со скиллами - сначала в контексте лишь короткий фронтматтер (имя, описание, триггеры), а весь SKILL.md подгружается, только если скилл понадобился. Дошло даже до MCP: раньше определения всех подключённых тулзов висели в контексте сразу - легко десятки тысяч токенов до начала работы, - а с конца 2025 Claude грузит их по запросу через Tool Search: сначала индекс, полная схема инструмента подтягивается в момент вызова. Один и тот же приём везде, и его стоит применять ко всему - к памяти в первую очередь.

Чтобы progressive disclosure для памяти реально работал, продумывать надо в первую очередь сам индекс - файл, который подгружается в начале каждой сессии. От него зависит всё остальное: это не склад, а оглавление, рабочий стол агента. В нём лежит не контент, а указатели - что где находится и когда туда идти: на каждый раздел короткая строка-описание плюс адрес файла. У меня, например, так: «как считаем продуктовые метрики - в metrics.md», «решения по роадмапу и почему - в roadmap-decisions.md», «портреты сегментов и ICP - в icp.md», «правила работы с тикетами - в jira-conventions.md». Сами тематические файлы растут отдельно и подтягиваются под конкретную задачу. Оглавление держу тонким - каждая строка грузится в каждую сессию, - поэтому всё объёмное уходит в отдельные файлы, а в индексе остаётся только карта с очень кратким summary, чтобы агент знал, какой полный файл открыть.

И чем больше база, тем важнее дисциплина индекса - иначе он тихо деградирует. Несколько вещей, которые реально помогают. Уровни абстракции: обзор проекта → раздел → конкретная запись → деталь, и на каждом уровне короткое саммари, собранное снизу вверх. Понятные имена файлов и единое оглавление - без них агент банально перестаёт находить нужное. И самое важное - не давать индексу зарастать: дубли схлопывать, устаревшее помечать, а не копить, и не раздувать раздел-свалку вроде “прочее”. Такая свалка опаснее всего - она перетягивает на себя внимание агента и топит точные записи под собой.

Ручной дисциплины хватает надолго, но на больших базах подключают инструменты. Всё началось с идеи Karpathy про «вики для LLM»: агент сам пробегает по сырым файлам, вытаскивает топики и собирает индекс-файл, который каждый раз уходит в контекст; по нему агент находит нужные страницы и формирует ответ. Рядом с индексом он держит лог-хронологию сделанного, чтобы не переделывать одно и то же. Метод рабочий, но у него есть цена: индекс плюс куски найденных файлов - это много токенов и заметная задержка на каждый запрос. После Karpathy пошла волна инструментов, которые решают это иначе. Например, Graphify: он один раз офлайн прогоняет твою базу, строит граф из множества JSON-нод и кладёт рядом отчёт. Дальше релевантные ноды ищут обычные скрипты - без участия модели, поэтому на подбор контекста токены почти не тратятся. Авторы таких тулов обещают экономию в десятки раз. Это целый класс решений, не один проект, и для большой персональной базы он реально меняет экономику.

И ещё про индекс: переносить его между обвязками тоже не проблема. Он просто помечен как файл, который агент обязан прочитать в начале сессии, - ровно как CLAUDE.md, AGENTS.md или GEMINI.md. Куда переезжаешь, там и подключаешь его к обязательному чтению.

Сами эти файлы-инструкции называются по-разному - у Claude Code CLAUDE.md, у Codex AGENTS.md, у Gemini GEMINI.md, - и это именно инструкции, часть системного контекста, а не та память, которую агент ведёт сам (про неё ниже). Чтобы не плодить три копии, держат один источник: AGENTS.md де-факто стал кросс-тульным стандартом - его читают Codex, Cursor, Copilot и десятки других, - а Claude и Gemini подключают тот же файл симлинком. Я держу AGENTS.md симлинком на CLAUDE.md, оба харнесса читают один источник. Если симлинки неудобны, есть генераторы вроде rulesync: из одного файла раскладывают версии под каждый инструмент.

Process - когда обновлять. Самое недооценённое измерение. Cole на OME сформулировал точно: самое сложное в памяти - не достать нужное, а вовремя обновить устаревшее. Классический риск - агент откопает прошлоквартальные цели и примет их за актуальные. Тогда память не помогает, а вредит.

Поэтому важно понимать, что именно ты кладёшь в память и как обращаешься с обновлениями. Я делю её на два типа. Статическая - то, что меняется редко: правила, стиль, устройство проекта, устойчивые факты о тебе; продумал один раз и долго не трогаешь. Динамическая - то, что живёт своей жизнью: цели на квартал, текущие приоритеты, статус задач. Вот это в общую память сваливать не стоит. Меняющиеся вещи лучше держать в отдельных файлах, обновлять вручную и периодически пересматривать: устаревшую цель правильнее переписать или пометить, чем оставить агенту как действующий факт. Само разделение на типы и снимает главную боль - память перестаёт незаметно подсовывать прошлое за настоящее.

Отдельный слой - память, которую агент ведёт сам, а не ты, поверх твоих файлов, а не вместо них. У Claude Code это auto-memory: с версии 2.1.59 включена по умолчанию, живёт в ~/.claude/projects/<проект>/memory/, и агент сам решает, что достойно записи. Причём не дожидается конца сессии - может зафиксировать важное прямо посреди работы, по ключевым моментам; в контекст при старте подтягиваются только первые ~200 строк индексного MEMORY.md, остальное читается по запросу. У Codex есть свой склад (~/.codex/memories/, по желанию), у Gemini - экспериментальный, с ручным подтверждением. Это важно держать в голове при переезде: у каждого харнесса есть своя память, которую он ведёт параллельно с твоими файлами. Но и она - просто файлы в известной папке, так что при желании её можно забрать и подключить под новый харнесс.

Начинать с ручного режима тут нормально и часто даже полезнее. Пока выстраиваешь память, дописывай её после каждой значимой сессии или просто проси агента записать итоги, а повторяющееся действие оформи в скилл “обнови память по работе”. Так ты сам видишь, что и в какие моменты должно меняться. А когда логика обновления устаканится, вешаешь её на автоматику - хук в конце сессии. Cole пошёл дальше и сделал “сны”: по расписанию хук читает дневной лог всех диалогов и продвигает важное в основной файл памяти - машинная консолидация, как мозг раскладывает мысли во сне. Индустрия двинулась туда же: у Anthropic появился свой dreaming для managed-агентов, а в академии в работе “Storage Is Not Memory” доказывают, что вытаскивать смысл надо не на входе, а на извлечении, и хранить события дословно.

А теперь про векторные базы и графы. В разговорах про память чуть ли не первым всплывает вопрос: какую базу взять - векторную, графовую? Векторная база - быстрый и дешёвый дефолт, но для памяти она слабовата: работает с чанками и слепа к связям. Находит “похожее по смыслу”, а память живёт на точных фактах и отношениях между сущностями, которые в запросе словами и не названы, - поэтому на персональной памяти вектор регулярно промахивается и тихо не докладывает нужное. Граф (и LightRAG как его удобная упаковка) реально мощнее на связях, мультихопе и вопросах “как менялось во времени”, и незаменим в доменах с жёсткими отношениями - право, финансы, медицина. Но это тяжёлый инструмент: построение графа долгое и недешёвое, поддержка муторная, и для управления собственной памятью он чаще всего overkill. Брать его стоит осознанно, под конкретную задачу, а не потому что “так в роликах говорят”. Поэтому лестница простая: начинаешь с markdown-файлов и поиска по ним (этого хватает на удивление долго), вектор добавляешь, когда файлы перестают справляться, граф - в последнюю очередь. Память должна быть ровно той сложности, которая нужна.

И отдельная мысль про бэкап: бэкапить надо не только данные, но и конфигурацию. Был громкий кейс, когда цифровой сотрудник крашнулся и потерял все скиллы и базу, потому что бэкапили “только данные”. Конфиг агента - это production-артефакт: скиллы, промпты, MCP-конфиг, сессии, память. У себя я держу всё это под git ровно по этой причине.

Скиллы - второй актив, который переезжает с тобой

Рядом с памятью живёт второй актив - скиллы. Это отдельная сущность, не часть памяти. Хорошая формула: память - это что помнить, скилл - это как повторить. Память хранит факты и решения, скилл - воспроизводимую процедуру.

Скилл - дистилляция опыта в инструкцию для агента: как я готовлю PRD, как пишу release notes, как разбираю пользовательский фидбэк в задачи. Запаковал свои годы практики в инструкцию, и она осталась твоей. Только за две недели нормальный скилл не написать: он итерируется на реальных задачах месяцами - что-то отлетает, что-то дозревает. Я уже подробно писал про скиллы как замену SaaS-стеку; здесь интереснее другой угол - создание, поддержка и переносимость.

Хранить - так же, как память: под git, рядом с проектом. А переносимость скиллов сейчас даже лучше, чем у памяти. Формат стал де-факто стандартом: его в считанные дни подхватили Cursor, Codex, Gemini и другие - не фрагментация, а унификация. И тут опять работает прогрессивное раскрытие: в контекст грузятся только имя скилла, короткое описание и триггеры, а полный SKILL.md на 50-500 строк агент читает только когда триггер сработал. Иначе тридцать скиллов разом снесли бы контекстное окно. Поэтому скилл переезжает в Hermes, в Codex, в Antigravity почти без боли - и часто живёт дольше, чем агент, под который ты его писал.

Харнесс - это новая IDE, и его перебирают

Раньше перебирали IDE. Теперь - харнесс, саму обвязку вокруг модели. И развивается он быстрее моделей: сейчас результат всё чаще решает не ум модели, а её обвязка - инструменты, оркестрация, обратная связь.

И тут Claude Code сильнее всего именно экосистемой. Это не “модель в терминале”, а целый рантайм: инструменты, скиллы, субагенты с изолированными контекстами, MCP, слэш-команды и - ключевое - хуки. Хук это shell-команда, которая срабатывает в фиксированной точке жизненного цикла: перед вызовом инструмента, после, при завершении сессии. И срабатывает она вне контекста модели - модель её не видит и не может с ней “договориться”. Cursor силён в другом: это AI прямо в редакторе - мгновенный inline-completion на своей быстрой модели, Composer с дифами по нескольким файлам, индексация репозитория.

Но не всё переносится одинаково легко. Память, скиллы и сам файл-индекс переезжают без боли, а вот глубокую автоматизацию приходится перенастраивать под новый движок. Лучший пример - те же хуки. Они теперь есть почти у всех (Claude Code, Codex, Cursor, Gemini), но у каждого движка свои названия событий, свой формат и свой файл настроек, поэтому при переезде их приходится переписывать заново. Та же история с конфигами MCP и правами доступа: содержимое похожее, а лежит и настраивается по-разному, и за этим надо следить.

Плюс волна обвязок вроде Hermes, OpenClaw, Pi - со своими акцентами. Использовать можно любую: если память переносима, харнесс становится сменной деталью.

Из этого следует неочевидное про надёжность. Ограничения агента лучше держать в обвязке, а не в инструкции. Инструкция в промпте - это просьба к вероятностной системе: по мере роста диалога правила в середине теряют вес, а сторонний текст может их перебить. Жёсткую гарантию даёт проверка в самой обвязке - код, который просто не пускает агента дальше, пока условие не выполнено. Я видел кейс, где валидацию DESIGN.md встроили прямо в пайплайн: агент не двинется к следующему шагу, пока документ не пройдёт проверку. Не уговорами, а кодом. Разница как между “я попросил быть аккуратным” и “дверь не откроется без ключа”.

Один вендор - это риск

И тут же всплывает причина держать память отдельно от харнесса. Lock-in. В апреле 2026 Anthropic какое-то время блокировала запросы с конкретными фразами из system prompt OpenClaw: совпадение было лексическим, обходилось точечной переформулировкой, а не просто ренеймом. К концу апреля от этой политики отказались. Но прецедент показателен: фича и доступ вендора сегодня могут исчезнуть завтра. Если весь твой агент завязан на одну модель одной компании, ты не вполне владеешь своим рабочим процессом - ты заложник чужих апдейтов, биллинга и решений. Лекарство простое: мультимодельный стек как страховка и память в переносимом формате, чтобы при смене харнесса взять весь рабочий каталог - .md-файлы, код, тесты, настройки - и перенести.

Что я понял

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

Источники

1. Karpathy - LLM Wiki (GitHub Gist)
2. Graphify - граф-индекс знаний для агентов (GitHub)
3. Effective context engineering for AI agents - Anthropic (про progressive disclosure)
4. Advanced tool use: Tool Search Tool - Anthropic (on-demand загрузка MCP-тулзов)
5. LightRAG - граф+вектор RAG (GitHub)
6. Storage Is Not Memory: A Retrieval-Centered Architecture for Agent Recall (arXiv 2605.04897)
7. Anthropic - Bringing memory to teams (блог)
8. Memory and dreaming for self-learning agents - Anthropic (YouTube)
9. Claude Code - Memory (официальная документация)
10. Dive into Claude Code: The Design Space of Today’s and Future AI Agent Systems (arXiv 2604.14228)
11. Cole Medin - Build Your Own AI Second Brain with Claude Code (YouTube)