kaeru даёт Claude Code и Codex долговременную память в виде графа через MCP

Любой, кто работает с ИИ-агентами дольше недели, знает эту сцену. Вы открываете проект, и агент спрашивает то, на что вы уже отвечали вчера. Через полчаса он предлагает починить то, что вы решили не трогать, и звучит убедительно, потому что не знает причины. А когда контекст переполняется и разговор сжимается в пересказ, половина обсуждения превращается в пару строк.

Команда Lamantin AI предлагает решать это отдельным слоем памяти. Инструмент называется kaeru, исходники лежат на GitHub. Ниже разбор того, как он устроен и где у него слабые места. Автор текста — разработчик самого инструмента, так что воспринимайте это как взгляд изнутри.

Почему мало файла с правилами

Первый шаг у всех одинаковый: CLAUDE.md, AGENTS.md, .cursorrules или заметка в Obsidian. Примерно через месяц начинаются проблемы:

• файл пополняется, когда о нём вспомнили, то есть через три дня и с потерей деталей;
• он только растёт: дописывать легко, вычёркивать страшно, и агент одинаково верит правилу вчерашнему и правилу, отменённому месяц назад;
• в нём есть «что», но нет «почему»: «парсер не трогать» без причины нельзя ни проверить, ни отменить;
• у каждого участника команды свой файл.

ADR и трекеры задач вроде beads закрывают часть проблем, но не рабочий слой между коммитами: гипотезы, проверки, особенности стендов. Тащить всё это в репозиторий значит засорять историю, а не записывать значит терять. Для этого слоя kaeru и сделан.

Как это устроено

kaeru работает на вашей машине как MCP-сервер, к нему подключаются Claude Code, Codex, Cursor и другие клиенты. Память хранится графом: наблюдения («файлы заказчика приходят в cp1251»), решения, задачи со сроками, гипотезы с результатом проверки, документы. Связи типизированы: «выросло из», «заменяет», «опровергает», «подтверждает», «блокирует», «противоречит». Цепочку от наблюдения до решения агент может сохранить целиком как рассуждение.

Пример из статьи: агент подозревает, что ночная выгрузка падает из-за размера файла. Проверяет на файле в 2 ГБ и записывает гипотезу сразу с вердиктом «опровергнуто». Если через неделю выгрузка упадёт снова, следующий агент начнёт с другой версии. Без памяти отрицательный результат теряется первым: удачные решения попадают в код, неудачные никуда.

Старое можно заменить явно. Вызов replace помечает прежнюю запись как замещённую и показывает, какие выводы на неё опирались. Запись не удаляется, у неё остаётся история, и можно открыть её версию на любой момент.

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

Что делают хуки, а что сам сервер

Сервер отвечает за хранение и сводку. Когда её запрашивать и что делать при сжатии контекста, решает клиент, через хуки в Claude Code и Codex. Часть хуков автор написал под себя, и в kaeru они пока не входят. В репозитории есть kaeru-first: перед тем как агент задаст вопрос человеку, хук ищет совпадения в памяти и предлагает сначала прочитать найденное.

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

Ограничения

• kaeru не гарантирует истинность записей. Агент может записать ерунду так же, как в файл правил. Выигрыш в том, что видно, из каких наблюдений вырос вывод, и что ошибку можно пометить и переделать цепочку.
• Замену старого агент должен вызвать сам. У автора две недели жили два правила с разными ID одних и тех же людей в GitLab: новое записали, старое не заменили.
• Совпадение по словам не означает, что в записи есть ответ.
• Командный сервер kaeru-cloud вы поднимаете у себя. Он рассчитан на доверенную команду, одно общее пространство с разделением по проектам, изоляции пользователей и организаций пока нет. По умолчанию проекты приватны, а перед отправкой записи сканируются на ключи и токены.

Что с этим делать

Если агенты у вас живут дольше пары дней на одном проекте, стоит разделить знания на два слоя. Устойчивые договорённости остаются в репозитории (правила, ADR) и проходят ревью. Рабочие находки, отвергнутые гипотезы и «почему» нужны отдельному хранилищу с историей и явной заменой устаревшего. Даже без kaeru полезно перенять две практики: записывать гипотезы вместе с вердиктом и подкладывать агенту короткую сводку автоматически, а не надеяться, что он прочитает сам.