Почему мы спорим о памяти для AI-агентов

Введение

На днях я читал статью про память для AI-агентов.

Сама статья была вполне типичной: SQLite, хранение контекста, поиск по накопленным знаниям, экономия токенов.

Но гораздо интереснее оказались комментарии.

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

Одни утверждали:

Зачем вообще база данных? Есть AGENTS.md и MEMORY.md.

Другие отвечали:

База позволяет доставать только релевантные части контекста.

Третьи рассказывали про Obsidian, SQLite, FTS, векторные индексы и собственные реализации памяти.

Чем дольше я читал обсуждение, тем сильнее возникало ощущение, что люди спорят не о технологиях.

Они спорят о разных вещах, используя одно и то же слово.

Слово «память».

Для одних память — это документация.

Для других — поисковая система.

Для третьих — текущее состояние проекта.

Для четвёртых — накопленный опыт.

Поэтому дискуссия быстро превращается в разговор людей, которые отвечают на разные вопросы.

Один объясняет, почему markdown-файлов достаточно.

Другой доказывает необходимость retrieval.

Третий рассказывает про автоматизацию рабочего процесса.

И все оказываются правы одновременно.

Проблема в том, что они говорят о разных типах памяти.

Читая комментарии, я неожиданно понял, что большинство споров вокруг агентной памяти на самом деле являются спорами о её определении.

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

Чтобы разобраться, почему это происходит, попробуем посмотреть на основные представления о памяти AI-агентов, которые сегодня существуют в сообществе.

1. Первая школа: память как документация

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

Это представление можно сформулировать просто:

Память — это знания о проекте.

Если память — это знания, то следующим логичным вопросом становится:

Где эти знания хранить?

И здесь ответ кажется очевидным.

В документации.

Именно поэтому появились такие артефакты как:

• AGENTS.md
• MEMORY.md
• AI_CONTEXT.md
• PROJECT_CONTEXT.md

и десятки их вариаций.

Почему этот подход работает

На самом деле у него есть много достоинств.

Во-первых, он предельно прост.

Вся память проекта лежит в обычных текстовых файлах.

И человек, и агент работают с одной и той же информацией.

Во-вторых, такая память легко версионируется.

Git прекрасно хранит историю изменений.

Можно посмотреть:

• когда появилось правило;
• кто его добавил;
• почему оно изменилось.

В-третьих, такой подход практически не требует инфраструктуры.

Нужен только репозиторий.

Никаких серверов.

Никаких индексов.

Никаких дополнительных сервисов.

Почему сторонники этого подхода скептически относятся к memory-системам

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

Представим разработчика, который уже использует:

AGENTS.md

MEMORY.md

ARCHITECTURE.md

Ему показывают систему памяти на SQLite.

Первая реакция вполне естественна:

А что она умеет такого, чего не умеет markdown?

Это хороший вопрос.

И во многих случаях ответ оказывается:

Ничего принципиально нового.

Потому что для хранения знаний markdown действительно подходит отлично.

Где начинаются проблемы

Однако у такого подхода есть одно важное ограничение.

Он предполагает, что память — это статический набор знаний.

Другими словами, основная задача памяти выглядит так:

Сохранить информацию

↓

Позволить её прочитать

До определённого масштаба это работает прекрасно.

Но по мере роста проекта начинает происходить интересная вещь.

Память постепенно увеличивается.

Появляются:

• новые правила;
• новые решения;
• новые задачи;
• новые ограничения;
• новые архитектурные компромиссы.

Количество знаний растёт быстрее, чем способность человека или агента эффективно ими пользоваться.

Документация отлично хранит знания

Но плохо отвечает на другой вопрос.

Не:

Что известно о проекте?

А:

Что из известного важно именно сейчас?

Это тонкое различие.

Но именно из него рождается следующая школа памяти.

Для которой память — это уже не документ.

А механизм поиска нужного знания среди множества известных.

2. Вторая школа: память как поиск

В какой-то момент объём накопленных знаний начинает создавать новую проблему.

Не проблему хранения.

Проблему поиска.

Представим проект, который существует уже несколько месяцев.

За это время накопились:

• архитектурные решения;
• правила проекта;
• десятки завершённых задач;
• история исправлений;
• заметки по исследованию проблем.

Вся информация сохранена.

Формально память работает идеально.

Но возникает новый вопрос:

Как понять, что из этого нужно агенту прямо сейчас?

Именно здесь появляется вторая школа.

Память перестаёт быть архивом

Для этой школы память — это не место хранения знаний.

Память — это механизм их извлечения.

Главным становится не вопрос:

Что известно?

А вопрос:

Что нужно вспомнить?

Разница кажется незначительной.

На практике она полностью меняет архитектуру системы.

Почему появились SQLite, FTS и Vector DB

Интересно, что многие современные memory-системы внешне похожи друг на друга.

Кто-то использует:

• SQLite;
• FTS5;
• BM25.

Кто-то использует:

• embeddings;
• vector search;
• semantic retrieval.

Кто-то комбинирует оба подхода.

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

Но технология здесь вторична.

Главный сдвиг произошёл раньше.

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

Её начали воспринимать как поисковую систему.

От полного контекста к релевантному контексту

Рассмотрим две модели работы.

Первая модель:

Есть память проекта

↓

Агент читает память

Вторая модель:

Есть память проекта

↓

Формируется запрос

↓

Извлекаются релевантные части

↓

Агент получает только их

Для небольших проектов разница почти незаметна.

Для больших проектов она становится критической.

Почему возникают споры

Именно здесь появляются комментарии вроде:

Markdown-файлов можно сделать несколько и связать ссылками.

С точки зрения школы документации это абсолютно разумное замечание.

Если память хранит знания, то действительно можно.

Но сторонники retrieval-систем решают уже другую задачу.

Их интересует не хранение.

Их интересует автоматический выбор нужного контекста.

Поэтому участники дискуссии часто говорят мимо друг друга.

Они обсуждают разные уровни системы.

Память начинает напоминать поисковик

Любопытно, что многие проекты постепенно приходят к похожей модели.

Появляются:

• индексы;
• ранжирование;
• summaries;
• semantic search;
• retrieval pipelines.

Фактически память начинает вести себя как специализированный поисковик по проектным знаниям.

Именно поэтому такие системы часто вызывают одновременно интерес и скепсис.

Для одних это естественная эволюция документации.

Для других — неоправданное усложнение.

Обе позиции имеют право на существование.

Потому что пока речь всё ещё идёт о знаниях.

Просто одна группа делает акцент на хранении знаний, а другая — на их извлечении.

Но и retrieval не решает всё

Со временем выясняется, что даже идеальный поиск не отвечает на некоторые вопросы.

Представим ситуацию.

Агент нашёл все релевантные документы.

Поднял нужные правила.

Прочитал архитектурные решения.

Вспомнил похожие задачи.

Возникает вопрос:

А достаточно ли этого для работы над проектом?

Оказывается, не всегда.

Потому что проект состоит не только из знаний.

Проект состоит ещё и из состояния.

Какие задачи активны?

Какие гипотезы сейчас проверяются?

Какие решения ещё обсуждаются?

Что было отклонено вчера?

Что считается актуальным сегодня?

В этот момент память начинает постепенно выходить за пределы документации и retrieval.

И превращается во что-то большее.

В память о самом процессе работы.

3. Третья школа: память как состояние проекта

Именно на этом этапе многие дискуссии начинают ломаться.

Потому что люди продолжают обсуждать память как знания.

А некоторые проекты уже давно используют память для другой цели.

Не для хранения знаний.

Для хранения состояния работы.

Знания и состояние — не одно и то же

Представим обычный проект.

Существует архитектурное правило:

Все внешние интеграции проходят через единый слой адаптеров.

Это знание.

Оно может храниться:

• в документации;
• в wiki;
• в базе знаний;
• в markdown-файлах.

Теперь рассмотрим другой факт:

Сейчас команда проверяет гипотезу о разделении адаптеров по доменам.

Это уже не знание.

Это текущее состояние проекта.

Завтра гипотеза может подтвердиться.

Или быть отвергнутой.

Через месяц она вообще может потерять актуальность.

Почему это важно для агентов

Большинство memory-систем хорошо отвечают на вопрос:

Что известно о проекте?

Но в реальной работе агент постоянно сталкивается с другим вопросом:

Что происходит в проекте прямо сейчас?

Это совершенно другой тип информации.

Например:

• какие задачи активны;
• какие решения обсуждаются;
• какие гипотезы проверяются;
• какие ограничения появились вчера;
• какие изменения находятся в работе.

Такую информацию неудобно хранить как документацию.

Она слишком быстро меняется.

Проект как процесс, а не как набор знаний

Мне кажется, именно здесь проходит важная граница.

Документация описывает проект.

Рабочая память описывает его текущее состояние.

Если провести аналогию с человеком, то получится примерно так:

Документация отвечает на вопрос:

Что я знаю?

Рабочая память отвечает на вопрос:

Чем я сейчас занимаюсь?

Это разные когнитивные механизмы.

Почему появляются задачи, решения и гипотезы

Если внимательно посмотреть на многие современные системы памяти, можно заметить интересную тенденцию.

В них начинают появляться сущности вроде:

• Task;
• Decision;
• Rule;
• Proposal;
• Incident;
• Hypothesis.

На первый взгляд это выглядит странно.

Почему память хранит задачи?

Почему память хранит решения?

Почему память хранит обсуждения?

Ответ становится понятен, если рассматривать память не как библиотеку знаний.

А как отражение текущего состояния проекта.

Память начинает приближаться к рабочему процессу

В этот момент память неожиданно начинает напоминать совсем другие системы.

Не wiki.

Не документацию.

Не поисковик.

А скорее:

• issue tracker;
• knowledge base;
• decision log;
• work management system.

Причём все эти роли начинают смешиваться.

Именно поэтому некоторые проекты выглядят необычно для сторонников классической документации.

Они пытаются хранить не только знания.

Они пытаются хранить сам процесс принятия решений.

Но даже этого оказывается недостаточно

Интересно, что после появления рабочей памяти возникает ещё одна проблема.

Представим, что агент знает:

• активные задачи;
• текущие решения;
• ограничения;
• состояние проекта.

Казалось бы, теперь у него есть всё необходимое.

Но довольно быстро обнаруживается новый класс информации.

Информации, которая не является ни знанием, ни состоянием.

Например:

• этот подход уже пробовали полгода назад;
• похожая идея привела к проблемам;
• этот компромисс был принят осознанно;
• этот путь исследования оказался тупиковым.

Такие вещи редко попадают в документацию.

Часто исчезают из задач.

И почти никогда не представлены в виде формальных правил.

Но именно они оказываются чрезвычайно полезными для агента.

Потому что содержат не факты.

А опыт.

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

4. Четвёртая школа: память как опыт

На мой взгляд, именно здесь начинаются самые интересные изменения.

Потому что на этом этапе память перестаёт отвечать на вопрос:

Что известно?

И даже перестаёт отвечать на вопрос:

Что происходит сейчас?

Она начинает отвечать на вопрос:

Что мы уже поняли?

Самая дорогая информация в проекте

Попробуем представить два проекта.

В первом есть только код.

Во втором есть код и история решений.

Через полгода второй проект почти всегда окажется проще для сопровождения.

Причина очевидна.

Код показывает:

Что было сделано.

История решений объясняет:

Почему это было сделано.

Именно это знание обычно теряется быстрее всего.

Забытые причины

Любой опытный разработчик сталкивался с ситуацией:

В коде обнаруживается странное решение.

Первая реакция:

Кто вообще так сделал?

Через несколько часов исследования выясняется:

Потому что все остальные варианты были ещё хуже.

Проблема в том, что память проекта часто хранит решение.

Но не хранит причины появления решения.

Со временем исчезает контекст.

Остаётся только результат.

Память начинает хранить опыт

Именно здесь возникает принципиально новый тип информации.

Например:

• этот подход уже проверяли;
• эта идея не сработала;
• этот компромисс был сознательным;
• этот баг появлялся раньше;
• это решение приняли после трёх неудачных попыток.

Заметим интересную особенность.

Это не факты.

Не правила.

Не задачи.

Это выводы из прошлого опыта.

Почему опыт плохо хранится в документации

Большинство проектной документации ориентировано на конечное состояние.

Документация описывает:

• что существует;
• как устроено;
• как использовать.

Но редко отвечает на вопрос:

Почему мы пришли именно сюда?

Поэтому значительная часть опыта обычно живёт:

• в головах людей;
• в старых обсуждениях;
• в комментариях к задачам;
• в забытых чатах.

И постепенно исчезает.

Когнитивная память

Если посмотреть на эту проблему шире, становится заметно, что речь уже идёт не о знаниях.

И не о рабочем состоянии.

Речь идёт о накопленном опыте системы.

Почти как у человека.

Когда опытный инженер сталкивается с новой задачей, он использует не только знания.

Он использует память о прошлых решениях.

О прошлых ошибках.

О прошлых компромиссах.

О прошлых неудачах.

Во многих случаях именно это позволяет ему двигаться быстрее новичка.

От знаний к пониманию

В какой-то момент я заметил интересную закономерность.

Все предыдущие школы памяти отвечают на вопрос:

Что нужно помнить?

Когнитивная память отвечает на другой вопрос:

Что нужно понимать?

Это уже не поиск информации.

Это попытка сохранить накопленный опыт проекта.

Почему появляются "вторые мозги"

Именно здесь становятся понятны проекты вроде:

• Obsidian-based knowledge systems;
• personal knowledge management;
• second brain;
• memory operating systems.

Многие из них выглядят странно, если считать память просто хранилищем знаний.

Но если рассматривать память как накопление опыта, логика становится очевидной.

Они пытаются сохранить не документы.

Они пытаются сохранить ход мыслей.

Причины решений.

Контекст появления идей.

Историю понимания проблемы.

Самое интересное наблюдение

Любопытно, что каждая следующая школа включает предыдущую.

Когнитивная память не отменяет документацию.

Не отменяет retrieval.

Не отменяет рабочую память.

Она строится поверх них.

Потому что опыт невозможно хранить без знаний.

Невозможно интерпретировать без состояния проекта.

И невозможно извлекать без механизмов поиска.

Поэтому современные memory-системы часто выглядят похожими.

Они используют:

• документы;
• поиск;
• задачи;
• решения;
• заметки.

Но делают это по-разному, потому что пытаются решить разные проблемы.

И именно здесь становится понятно, почему споры вокруг памяти агентов часто оказываются такими эмоциональными.

Люди используют одно слово.

Но подразумевают совершенно разные вещи.

5. Почему все спорят друг с другом

После чтения нескольких статей и комментариев о памяти для агентов у меня возникло ощущение дежавю.

Дискуссии выглядели знакомо.

Люди задавали разумные вопросы.

Получали разумные ответы.

Но всё равно не приходили к согласию.

Сначала это казалось странным.

Потом причина стала очевидной.

Участники обсуждения спорили не о решениях.

Они спорили о разных определениях памяти.

Типичный пример

Представим такой диалог.

Один человек говорит:

Зачем база данных? Всё это можно хранить в markdown.

Другой отвечает:

База позволяет поднимать только релевантный контекст.

На первый взгляд кажется, что кто-то из них ошибается.

Но если присмотреться внимательнее, оба оказываются правы.

Первый участник обсуждает документацию

В его картине мира память отвечает на вопрос:

Что известно о проекте?

Для такой задачи markdown действительно подходит прекрасно.

Он прост.

Прозрачен.

Удобно хранится в Git.

Не требует дополнительной инфраструктуры.

Если память — это документация, то аргумент выглядит абсолютно логичным.

Второй участник обсуждает retrieval

Но он решает уже другую проблему.

Его интересует не хранение знаний.

Его интересует извлечение знаний.

В его картине мира память отвечает на вопрос:

Что из известного нужно вспомнить сейчас?

И здесь появляются:

• поиск;
• индексация;
• ранжирование;
• retrieval.

Для этой задачи markdown уже не выглядит очевидным решением.

Они не противоречат друг другу

Это, пожалуй, самый интересный момент.

Часто такие обсуждения выглядят как спор двух взаимоисключающих подходов.

На самом деле они могут прекрасно сосуществовать.

Например:

Markdown

↓

Источник знаний

SQLite

↓

Механизм поиска

или

Obsidian

↓

Хранилище опыта

Retrieval

↓

Механизм доступа

Конфликт появляется только тогда, когда оба участника считают, что обсуждают одну и ту же задачу.

Разные проекты решают разные проблемы

Именно поэтому многие системы памяти внешне похожи, но развиваются в разных направлениях.

Одни делают акцент на:

• документации;
• структурировании знаний;
• накоплении заметок.

Другие на:

• поиске;
• ранжировании;
• сокращении контекста.

Третьи на:

• задачах;
• решениях;
• истории работы.

Четвёртые на:

• опыте;
• причинах решений;
• накопленном понимании проекта.

Все они используют слово "память".

Но подразумевают разный смысл.

Почему возникает ощущение холивара

Со стороны такие дискуссии часто напоминают споры редакторов кода или языков программирования.

Каждая сторона приводит убедительные аргументы.

Каждая сторона демонстрирует реальные преимущества.

И каждая сторона остаётся при своём мнении.

Причина проста.

Люди оценивают решения относительно собственной боли.

Если человек работает над небольшим проектом, ему действительно может хватать нескольких markdown-файлов.

Если другой человек пытается накопить историю сотен задач и решений, он начинает искать другие инструменты.

Если третий строит систему долговременной памяти для агентов, он сталкивается уже с совершенно другими ограничениями.

Они находятся на разных этапах развития одной и той же идеи.

Возможно, все правы одновременно

Именно к такому выводу я пришёл после чтения этих обсуждений.

Большинство участников не заблуждаются.

Они просто отвечают на разные вопросы.

Когда один говорит:

Память — это документация.

Он прав.

Когда другой говорит:

Память — это retrieval.

Он тоже прав.

Когда третий утверждает:

Память должна хранить решения и задачи.

Он также прав.

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

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

На самом деле это разговор о том, что именно мы считаем памятью.

6. Что происходит прямо сейчас

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

Сообщество не движется от одной правильной идеи к другой.

Скорее оно постепенно открывает новые слои одной и той же проблемы.

Первый этап: документация

Самый естественный путь выглядит так:

Промпт

↓

AGENTS.md

↓

MEMORY.md

На этом этапе возникает понимание, что важные знания нужно сохранять между сессиями.

Появляются:

• правила;
• архитектурные заметки;
• описания проекта;
• инструкции для агента.

Для многих проектов этого оказывается достаточно.

Второй этап: retrieval

Рано или поздно память начинает разрастаться.

И тогда возникает новая проблема.

Не хранения.

Поиска.

Так появляются:

• SQLite;
• FTS;
• embeddings;
• vector search;
• semantic retrieval.

Фокус смещается с вопроса:

Что нужно сохранить?

на вопрос:

Что нужно поднять в контекст?

Третий этап: память рабочего процесса

Следующий шаг обычно происходит неожиданно.

Оказывается, что агенту недостаточно знать проект.

Ему нужно понимать текущую работу.

Появляются:

• задачи;
• решения;
• гипотезы;
• инциденты;
• рабочие заметки.

Память начинает хранить не только знания, но и состояние проекта.

Четвёртый этап: память опыта

Самый молодой и пока наименее исследованный слой.

Здесь память начинает хранить:

• причины решений;
• историю компромиссов;
• отклонённые варианты;
• результаты экспериментов;
• накопленные выводы.

На этом этапе появляется стремление сохранять не факты.

А понимание.

Почему возникают похожие проекты

Интересно, что многие современные системы памяти проходят через похожую эволюцию.

Сначала появляется документация.

Потом поиск.

Потом задачи.

Потом история решений.

Потом опыт.

Со стороны это выглядит как множество независимых проектов.

На практике многие из них движутся примерно в одном направлении.

Просто стартуют из разных точек.

Кто-то приходит из мира wiki.

Кто-то из мира issue tracker.

Кто-то из мира knowledge management.

Кто-то из мира AI-агентов.

Возможно, мы наблюдаем формирование новой дисциплины

Любопытно, что ещё несколько лет назад подобные обсуждения практически отсутствовали.

Большинство агентов были одноразовыми.

Контекст заканчивался вместе с диалогом.

Память как отдельная задача практически не существовала.

Сегодня ситуация изменилась.

Появились агенты, которые:

• работают неделями;
• сопровождают проекты месяцами;
• накапливают знания;
• возвращаются к старым задачам.

И вместе с ними появилась новая инженерная проблема.

Как сохранить накопленный опыт так, чтобы он действительно помогал в дальнейшей работе?

Пока индустрия явно находится в стадии экспериментов.

Именно поэтому появляется так много разных подходов.

Резюме для тех, кто пролистал

Читая статьи и обсуждения про память AI-агентов, мне казалось, что спор идёт вокруг технологий.

SQLite против markdown.

Obsidian против базы данных.

Vector search против FTS.

Но постепенно стало понятно, что технологии здесь вторичны.

На самом деле люди спорят о гораздо более фундаментальной вещи.

О том, что именно считать памятью.

Для одних память — это документация.

Для других — механизм поиска.

Для третьих — состояние проекта.

Для четвёртых — накопленный опыт.

Каждое из этих определений описывает реальную проблему.

И каждое порождает собственный класс решений.

Поэтому вопрос:

Какая память для агента лучше?

часто оказывается некорректным.

Сначала стоит уточнить другой вопрос:

Какой именно тип памяти мы пытаемся построить?

Возможно, именно поэтому дискуссии вокруг агентной памяти выглядят такими бесконечными.

Участники обсуждения используют одно и то же слово.

Но подразумевают под ним совершенно разные вещи.

И пока термин "память" одновременно означает документацию, retrieval, состояние проекта и опыт, такие споры будут возникать снова и снова.

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

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