Дискуссия началась с вполне конкретного вопроса под статьёй о памяти для ИИ-агентов: чем база данных лучше обычных AGENTS.md и MEMORY.md, если модель в обоих случаях получает текст? Один читатель предлагал хранить заметки в Obsidian, другой держал общую память нескольких агентов в трёх файлах — описание проекта, текущее состояние, правила изменений. Кто-то работал с Hermes, кто-то складывал всё в Git и не видел смысла усложнять.
На поверхности это выглядело как очередной спор «файлы против базы». Но чем дольше разворачивалось обсуждение, тем очевиднее становилось: участники не столько защищают разные инструменты, сколько решают принципиально разные задачи и по привычке называют их одним словом — «память».
Самое простое представление о памяти агента — это документация. Если модель забывает проект между сессиями, достаточно записать всё важное в файлы рядом с кодом: AGENTS.md, ARCHITECTURE.md, CURRENT_STATE.md. Такие файлы меняются вместе с кодом, проходят через Git, открываются в любом редакторе без дополнительных сервисов. Для небольшого проекта, где правила занимают пару страниц, а архитектура помещается в голове одного человека, отдельная база памяти принесёт больше забот, чем пользы. Вопрос «зачем здесь база данных?» в таком контексте — не признак технической отсталости, а честная оценка соотношения затрат и результата.
Проблема возникает позже, когда документы начинают выполнять работу, для которой их не создавали. Сначала в MEMORY.md пять важных решений, потом двадцать, затем туда добавляются правила, исключения из правил, временные предупреждения, заметки о старых сбоях и причины нескольких странных компромиссов. Появляются новые файлы, чтобы разгрузить старые, их связывают ссылками и снабжают оглавлениями. Система продолжает работать, но задача незаметно меняется: раньше нужно было сохранить несколько сведений, теперь — выбрать из множества документов те, которые имеют отношение к очередной работе. Файлы не стали хуже; просто накопленное знание разрослось, а внимание агента осталось конечным.
Здесь на сцену выходят SQLite, полнотекстовый поиск, BM25, embeddings и векторные индексы. Но сами по себе эти инструменты памятью не являются — это каталог, который помогает не бродить между стеллажами. Если система складывает текст в таблицы, а затем по каждому запросу выгружает модели всё содержимое, она отличается от гигантского MEMORY.md главным образом тем, что у проблемы теперь есть схема данных. Экономия токенов возникает не от факта существования базы, а от правил отбора — того, что именно и по какому признаку попадёт в контекст.
За спором о носителе скрываются как минимум четыре разных сценария. Первый — контекст перед стартом: агенту нужно прочитать несколько сведений перед началом работы, и здесь файлы справляются не хуже базы. Второй — семантический поиск: из сотен записей нужно автоматически вытащить несколько уместных, и тут без векторных индексов или BM25 не обойтись. Третий — состояние процесса: вернуться к незавершённой задаче без повторного обхода всего проекта. Четвёртый — институциональная память: сохранить причины решений, старые тупики и опыт, который обычно исчезает быстрее любой документации. Каждый из этих сценариев требует разного подхода, и именно поэтому аргументы в дискуссии так часто проходят мимо цели: один доказывает удобство файлов для первого случая, другой объясняет ценность автоматического отбора для второго, и оба правы — просто о разном.
