Графическая память против Markdown: Почему плоские файлы становятся долгом подсказок в масштабе

Разработчик на r/openclaw рассказывает, как их система памяти на Markdown для ИИ-агента превратилась из чистого решения в 'промпт-долг'. Изначально хранение памяти агента в виде Markdown-файлов казалось идеальным — читабельно, редактируемо, без привязки к вендору. Но после достижения 80+ файлов и более 5 миллионов символов подход сломался. Каждый запуск требовал сканирования 'огромной кучи заметок', чтобы угадать, какие части все еще важны.

Проблема: плоский текст становится промпт-долгом

Как описывает разработчик, 'хранение было решено, а память — нет'. Факты о проекте, старые баги, решения, предпочтения и полумертвые планы — все это лежало фрагментами равного веса в контексте. Агенту приходилось перечитывать всё, как будто всё одинаково релевантно, что приводило к ухудшению производительности и потере токенов.

Инсайт: отображать релевантную память, а не всю

Переломный момент наступил, когда поняли, что им нужна не лучшая записная книжка, а чтобы агент 'отображал релевантную часть своей памяти для текущей задачи'. Решением стало внедрение графовой памяти: каждая память хранится как узел, отношения — как ребра, а извлечение — как запрос 'какая часть этой карты должна загореться сейчас?' вместо того, чтобы сбрасывать в контекст топ-10 похожих заметок.

Практический вывод

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