Автор Operator Memory: ИИ-агентам нужна документация, а не RAG-память

В блоге опубликована статья «Agents Don’t Need Memory. They Need Documentation» («Агентам не нужна память, им нужна документация»). Её тезис: плагины памяти для ИИ-агентов решают не ту задачу. Автор описывает типичный плагин так: он анализирует разговоры, порождает, например, 1000 разрозненных фрагментов и кладёт их в векторную базу; к каждому запросу прикрепляет пять самых похожих фрагментов, а если агент в замешательстве, тот ищет дополнительно сам. По мнению автора, это «лотерея» по RAG-фрагментам, и даже когда она срабатывает, агент всё равно не понимает проект.

Автор утверждает, что любой плагин памяти на рынке устроен одинаково: пройти по транскриптам сессий, сгенерировать «воспоминания», вставить их в RAG-базу, на каждый запрос достать топ-5 и подставить в контекст, а при нехватке дать агенту инструмент поиска по базе. Более «навороченные» решения добавляют поиск по прошлым транскриптам дословно, многоуровневую память (краткосрочную и долгосрочную), фоновые процессы для просмотра, слияния и удаления дублей, «мечтателей» (dreamers), переписывающих память по ночам, сжатие контекста и реранкеры. Всё это, считает автор, лишь «сжигающие токены» надстройки над одной и той же ошибочной архитектурой, поэтому ни один такой плагин не работает надёжно.

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

Корень в общей предпосылке: агент забывает, значит надо лучше запоминать, больше захватывать, лучше индексировать, умнее извлекать. Но, по словам автора, так не поступают с знаниями люди: никто не пересматривает встречу команды трёхлетней давности, чтобы вспомнить ограничения фичи, люди записывают решения и пользуются записями. Давать агенту поиск по 10 миллионам токенов прошлых разговоров и заставлять восстанавливать картину по обрывкам, не решение. Решение, память на документах. Автор добавляет, что сегодня ИИ используют для выпуска продуктов и функций с огромной скоростью, часто не читая код, и документация при этом становится делом десятым, хотя должна быть важнее, чем когда-либо.

Автор напоминает, что файлы AGENTS.md придумали, чтобы агент не заходил в кодовую базу вслепую, и это работает, но нередко этот единственный файл, вся документация проекта. Одного файла мало: агенту нужен целый «мозг», структурированное рабочее пространство, куда он по своей инициативе записывает инструкции (например, как устроено код-ревью), спецификации обсуждённого с пользователем, переиспользуемые исследования незнакомой библиотеки или API, индексы. Перед работой агент читает нужные документы, после работы обновляет устаревшее и добавляет недостающее, пока полная картина ещё в контексте. Цикл меняется с «запрос → сборка → забыл» на «запрос → сверка с документами → сборка → обновление». Память из подключаемой к агенту RAG-базы превращается в рабочее пространство, которое можно читать, править и передавать другим.

Отдельный раздел о проверке на практике, личный рассказ автора. Более года назад, начав программировать с ИИ, автор завёл папку internal/, где агент записывал спецификации, планы и индексы, и обязал его читать нужные документы и индекс перед работой и обновлять их после. Эти инструкции постепенно превратились в формальную систему, а затем в плагин Operator Memory, который автор регулярно использует во всех своих проектах. Он даёт агенту Markdown-«мозг» для сохранения знаний: инструкций, спецификаций, исследований и индексов. В плагине нет векторных баз, эмбеддингов, саммаризаторов, кураторов, «обновляльщиков», «мечтателей» и фоновых процессов, сжигающих токены, нет и поиска «чёрным ящиком»: всё, обычные Markdown-документы, которые можно читать, править, коммитить и делиться с командой. По словам автора, плагин бесплатный и с открытым исходным кодом, репозиторий, aerovato/operator-memory на GitHub.

Ключевые факты

• Автор утверждает, что все плагины памяти для агентов устроены как RAG: фрагменты из разговоров попадают в векторную базу, на каждый запрос подставляется топ-5 похожих, при необходимости агенту дают поиск по базе.
• Пять проблем такого подхода по версии автора: выбор по сходству, а не по верности; потеря контекста; прошлое принимается за истину при меняющемся коде; агент не ищет то, о чём не знает; хранилище невозможно проверить.
• Предложение: вместо одного AGENTS.md дать агенту структурированный «мозг» из Markdown-документов (инструкции, спецификации, решения, исследования, индексы), который он читает перед работой и обновляет после.
• Автор представляет свой плагин Operator Memory: без векторных баз, эмбеддингов и фоновых процессов, всё в виде обычных Markdown-файлов, бесплатно и с открытым исходным кодом.
• Доказательство в тексте, только личный опыт автора за более чем год использования; замеров и сравнения с другими плагинами нет.

Почему это важно

Плагины «памяти» для кодинг-агентов, популярная категория, и статья ставит под сомнение саму её идею: автор считает, что проблема не в качестве поиска, а в том, что агенту нужно не вспоминать обрывки прошлого, а читать актуальную документацию проекта. Это сдвигает разговор от вопроса «как лучше запоминать» к вопросу «что и как записывать». Тезис высказан одним автором и подкреплён личным опытом, но он перекликается с уже привычной практикой файлов AGENTS.md.

Кому это важно

Разработчикам, которые работают с кодинг-агентами и сталкиваются с тем, что агент теряет контекст проекта между сессиями. Авторам и пользователям плагинов памяти, а также командам, которые решают, как хранить договорённости, спецификации и исследования, чтобы их мог читать и человек, и агент.

Как это применить

Идея из статьи не требует плагина: автор начинал с обычной папки internal/, где просил агента записывать спецификации, планы и индексы, всегда читать нужные документы и индекс перед работой и обновлять их после. Готовая реализация, плагин Operator Memory (репозиторий aerovato/operator-memory на GitHub), который автор называет бесплатным и открытым. В тексте не сказано, с какими агентами и моделями плагин работает, поэтому это стоит проверить в репозитории.

Можно ли доверять

Это авторская позиция в блоге, а не исследование. Автор при этом создатель рекламируемого плагина Operator Memory, то есть заинтересован в выводе. Замеров, тестов и сравнения с другими плагинами в тексте нет: раздел о проверке на практике, личный рассказ об использовании собственной системы больше года. Конкретные плагины памяти не названы и не разбирались, критика направлена на всю категорию. Числа про 1000 фрагментов, 10 000 эмбеддингов и 500 фрагментов об аутентификации, иллюстрации, не данные. Независимых отзывов и данных об использовании Operator Memory в тексте нет.

Риски и подводные камни

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

«Агентам не нужна память. Им нужна документация.»

— из статьи «Agents Don’t Need Memory. They Need Documentation.»