Память агента без вектор-БД: 363 markdown-файла вместо эмбеддингов

У меня восемь агентов с постоянной памятью ^[1], и на всех вместе больше 360 файлов, около 1,4 МБ текста. Векторной базы нет ни одной: эмбеддинги я не считаю вообще.

И это не “руки не дошли”. Схема работает с мая 2026 года: сначала на одном агенте, с июня централизованно на всех восьми. За это время вопрос про вектор-БД я поднимал трижды, каждый раз с конкретным кандидатом на внедрение, и каждый раз закрывал его отказом. Ниже разберу, как это устроено, какими числами живет и в какой момент перестанет работать.

Рефлекс, от которого я отказался

Когда заходит разговор про долгую память агента, у всех в голове примерно одна картинка: накрошить знания на чанки, посчитать эмбеддинги, сложить в Qdrant или pgvector и на каждом запросе доставать топ-k по косинусу. RAG стал ответом по умолчанию, даже когда вопроса еще никто не задавал.

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

Два уровня, и только они

Память устроена в два слоя, и это вся конструкция.

Оглавление. Один файл, одна строка на воспоминание: заголовок, ссылка на файл, короткий хук из нескольких слов. Грузится в контекст целиком, каждую сессию, без исключений.

Тела. Отдельный markdown-файл на каждый факт. В отличие от оглавления, они подтягиваются не всегда, а по релевантности к текущей задаче: возникла задача, поднялись нужные файлы, и только они.

Числа одного из агентов, замер на 11 августа 2026 года:

Соотношение: один к тридцати четырем. Оглавление обязано быть маленьким, потому что это налог на каждый старт сессии: его читают всегда. Тела этим налогом не облагаются, поэтому растут свободно, их берут выборочно.

Отсюда недоразумение, которое стоит развеять сразу. “У агента всего двадцать килобайт памяти” неправда. Двадцать килобайт это потолок оглавления, а не памяти вообще: путать одно с другим примерно как судить о содержимом склада по описи на входной двери. Сама память на два порядка больше, и потолка у нее нет.

Разброс между агентами при этом большой: у одного 11 файлов памяти, у другого 60 файлов и 212 КБ. Второй просто дольше в работе и собрал больше боевых граблей.

Как выглядит одна запись

Одна запись это frontmatter плюс тело:

---
name: имя-записи
description: одна строка, по которой запись должны найти
metadata:
  type: user | feedback | project | reference
---

Сам факт. Для правил дальше идут два блока: Why (почему так решили)
и How to apply (как применять). Ссылки на соседние записи: [[имя-записи]].

Все держится на поле description, и это не заголовок и не украшение. Именно оно, и только оно, участвует в подборе. Поэтому пишу его не как название главы, а как поисковый запрос, по которому запись должна всплыть. Разница между “архитектура памяти” и “почему я не беру вектор-БД для памяти агента, порог пересмотра” это разница между “запись не нашлась” и “нашлась”.

Типов записей четыре: кто такой владелец, обратная связь и правила работы, состояние проектов, ссылки на внешние ресурсы. Больше заводить пробовал, не прижилось.

Семантический поиск здесь уже есть

Тут легко пропустить главное: подбор нужных записей делает сама модель, сопоставляя текущую задачу с их описаниями. Это и есть семантический поиск, просто выполняет его LLM по компактному оглавлению, а не косинусная мера по эмбеддингам.

И на этом масштабе, на сотне с небольшим записей, это работает точнее вектора. Модель понимает нюанс формулировки: что решение залочено и переоткрывать его можно только со сверкой, что правило про проверку цен относится к каталогу, а не к метрикам. Эмбеддинги ловят похожее по словам, а на маленьком корпусе разница между “похоже по словам” и “то самое” видна невооруженным глазом.

Где болит

Идеальной схема не бывает, и про три свои больные точки я знаю.

Налог на старте. Оглавление грузится всегда, а кириллица в UTF-8 стоит два байта на символ, то есть русскоязычный индекс вдвое дороже английского при том же смысле. Когда файл начинает подпирать бюджет, правильная реакция ^[2] консолидировать, а не дописывать дальше.

Как это выглядит на практике. 8 июля 2026 года индекс дорос до 30,4 КБ на 118 записях, и я прогнал два прохода подряд: сначала ужал распухшие строки, вынеся детали в тела, потом слил настоящие дубли. Вышло 26,5 КБ на 116 записях. Дубль-кластер при этом нашелся ровно один, и это, по закону жанра, было правило о том, как единообразно писать названия продуктов. Само записанное трижды.

Вывод из прохода неприятный, но полезный: дублей почти нет. Оглавление набито разными фактами, а не повторами, поэтому сжимать в нем особо нечего, и растет файл по делу. Строки я потом ужал еще сильнее, и сейчас 135 записей укладываются в 21 КБ, около 160 байт на строку против прежних 234.

И вот здесь самая честная часть. Файл растет монотонно: с 30 июля по 11 августа прибавилось 11 записей, примерно по одной в день, и остановиться этому неоткуда, ведь каждый разобранный промах превращается в правило. Консолидация выкупает время, но тренд не отменяет. Дублей нет, значит сжимать нечего, а два прохода подряд дали в сумме меньше, чем один месяц роста. То есть налог на старте сессии понемногу растет, и это долг, который придется отдавать. Как именно, разберу ниже, в разделе про порог.

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

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

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

Почему все-таки не вектор

Причин три, по убыванию веса.

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

Вторая, инфраструктура. Эмбеддинг-поиск тянет за собой эмбеддинг-модель, а это внешний вызов и расход токенов на каждый запрос. Сам стор еще один сервис, который надо поднять, бэкапить и чинить. Портфель я веду один, и каждый постоянно работающий сервис стоит в нем дороже, чем кажется на этапе docker compose up.

Третья, архитектура. Подбор записей делает харнесс, а не мой код. Вкрутить туда вектор-БД значит построить рядом вторую систему памяти, которая будет конкурировать с первой за право быть источником правды. Ровно этот сценарий и заставил меня в свое время отклонить готовые решения.

Что смотрел и не взял

За три подхода к вопросу я разобрал три конкретных решения.

agentmemory. Прямой аналог моей схемы. Миграция ради миграции, то самое шило на мыло.

FluxMem. Память как эволюционирующий граф. Разобрал ее примитивы по одному и обнаружил, что все они у меня уже есть, только руками: связи между записями через [[ссылки]], продвижение урока снизу вверх, периодическая консолидация, чистка протухших записей. Единственная реальная добавка это LLM-автоматизация эволюции графа, то есть постоянный фоновый расход токенов. Так что ценность этой работы оказалась для меня не в коде, а в подтверждении, что направление выбрано верно.

memoir. Самый интересный случай. Это git-based память для агентов: ветки, blame, откат, иерархические пути вида profile.skills.python. И вот что важно: memoir тоже отказался от векторной базы в пользу плоских файлов и двойного поиска, а аргументация его авторов почти совпала с моей. Отклонил я его по другой причине: memoir это отдельный инфраструктурный слой, сервис плюс модель на подборе, тогда как у меня zero-infra и обычный markdown, который харнесс читает нативно. Идею иерархических путей, впрочем, забрал в бэклог, она пригодится на следующем этапе.

Когда это сломается

Порог я назвал заранее, чтобы потом не спорить с собой задним числом: больше 150-200 записей И заметное падение качества подбора, когда модель начинает промахиваться мимо нужного файла. Два условия, не одно. Сейчас записей 135, промахов не видно, схема работает.

Разница в том, что второе число я теперь держу не как разовый снимок, а с производной. При темпе плюс одна запись в день к нижней границе, 150, подойду примерно к концу августа 2026-го, а к верхней, 200, ближе к концу октября. Это не “схема на исходе”; это ровно то, ради чего порог и назывался цифрой заранее: чтобы момент наступил по календарю, а не по ощущению “что-то агент стал туповат”.

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

Тут есть тонкость, которую я понял не сразу: подбор тел идет не через оглавление. Харнесс сопоставляет задачу с описаниями файлов напрямую. А это значит, что под-индексы срежут налог на старте, но на качество подбора не повлияют вообще. Полезно понять это до того, как разрежете файл и будете гадать, почему не помогло.

Вектор при всем этом не приближается ни на шаг. Он окупается на десяти тысячах документов, а у меня прибавляется по записи в день: до его точки безубыточности при таком темпе идти не годы, а десятилетия. Растущий индекс это проблема бюджета контекста на старте сессии, и лечится она нарезкой, а не сменой способа поиска. Две разные боли ^[3], которые легко перепутать и в итоге купить эмбеддинги от головной боли, которая болит в другом месте.

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