Память для AI-агента: от усложнения к 300 строкам кода

Память ИИ-агента — одна из самых сложных проблем при создании автономных систем. Разработчик Nikolay Gusev потратил месяцы на поиск рабочего решения и рассказал, как дошёл до простоты и масштабируемости одновременно.

MemPalace и первая ошибка

Всё начиналось с амбициозной идеи — MemPalace, система памяти, вдохновлённая архитектурой средневековых дворцов. Выглядело умно на бумаге, но на практике создала 58 тысяч дублирующихся фрагментов и превратилась в непроходимый лабиринт. Слишком много слоёв абстракции, слишком много магии. Агент путался в собственной памяти.

Путь к простоте

После MemPalace автор упростил стек до четырёх компонентов: MEMORY.md (основная база), USER.md (контекст пользователя), SQLite state.db (состояние), HippoRAG (поиск) и wiki-файлы (структурированные данные). Но даже это казалось избыточным. Верный ход — написать `findings_to_wiki`, простой скрипт на Python из 300 строк, который автоматически сохраняет структурированные анализы (отмеченные заголовками типа `## Findings`) в markdown-файлы и преобразует их в wiki-страницы. Никаких фреймворков, никаких ORM, только файлы и текст.

Масштабирование: ClickHouse Когда агент один — файловое хранилище работает идеально.

Но если нужно поддерживать 100+ пользователей одновременно, требуется настоящая база данных. Здесь на сцену выходит ClickHouse 24.x. Ключевые возможности: Vector search через функцию `cosineDistance()` — быстрый поиск семантически похожих воспоминаний Text search с индексом `tokenbf_v1` — полнотекстовый поиск по памяти Партиционирование по user_id — изоляция данных пользователей встроена в БД TTL для автоматического удаления — старые записи удаляются без ручного вмешательства ClickHouse выполняет аналитику и поиск в миллионах записей за миллисекунды. Для памяти агента этого более чем достаточно.

Что это значит Главный вывод: не начинайте с масштабирования.

Решите проблему просто (файлы, markdown, 300 строк кода), потом масштабируйте только если понадобится. Николай показал, что лучший инженерный путь — от сложности к простоте, а не наоборот.