Comments 27
Человек который придумает реально элегантную память для агента и в целом RAG, станет кумиром. Это реальная боль.. Казалось бы пол года бился за красивые recall и прочее, перебрал десятки моделей БЯМ, реранкеров, эмбеддеров, добавил бм25, накатил еще граф сверху, но как только к системе нужно подключить другой отдел своей же компании с немного другим форматом документации, ее объёмом и структурой, все идет через одно место и нужно снова проводить тесты, гонять метрики и молиться чтобы ранее рабочий алгоритм не отвалился.
Но одну истину я уяснил, если объём и формат документации позволяют сделать через библиотекаря(навигатора, роутера), лучше сделать так. Это прослеживается более адекватно, а не надежда на вектора, это одна точка отказа - LLM, а не три - LLM, embedding, reranker. Не нужно БД лишние держать. Но это не всегда серебряная пуля и нужно реально гонять тесты, как я вначале сказал. Так что ждем гения, который даст такую пулю🙂
Я пишу свое(точнее Codex пишет), и мне реально помогает, конечно это нейрослоп в какой-то мере, но инструмент не должен быть красивым, он должен быть эффективным. Раньше у меня агенты после мегабайта проектного кода начинали дичь творить, сейчас все норм.
диалог примерно такой:
Я: продолжай
Агент:
Работал на протяжении 10s
Постановка задачи 1054b22f
Проблема: семантические запросы ошибочно маршрутизируются в лексический list_artifacts/list_open_tasks. Дефект снова воспроизведён при получении контекста этой задачи.
Цель:
отдельный маршрут семантического поиска;
Qdrant только формирует кандидатов;
каждый кандидат проверяется и загружается из SQLite;
orphaned refs доступны лишь как диагностические, не как существующие задачи.
В объёме: маршрутизация, ранжирование, подавление служебных слов, aliases, все статусы и типы артефактов, диагностические receipts.
Вне объёма: восстановление или удаление данных, миграция рабочей базы, признание индекса источником истины.
Критерии готовности:
запрос про reconstruction bundle находит релевантные материалы;
нет скрытого отката к lexical search;
8f39fa86-... показывается только как orphan diagnostic;
точный lookup остаётся fail-closed;
все write-тесты выполняются только в Docker.
Риск: утечка или ложное признание артефакта существующим. Защита: обязательная SQLite-валидация.
Первое действие: после claim исследовать текущие маршруты поиска и диагностический контур без записи в рабочую БД.
Подтверждаете старт реализации этой постановки?
Я придумал, точнее я объединил придуманное - но все хотят еще одну папочку маркдаун. https://github.com/holetron/hindsight-mempalace
Отличный разбор, особенно откликнулся тезис про "память состояния работы". Подскажите, а какими инструментами вы сами пользуетесь для удержания этого контекста? Используете готовые фреймворки (вроде LangGraph / Mem0) или это кастомная обвязка над SQLite и Git-хуками, которая собирает след работы автоматически?
К сожалению в задаче только постановка проблемы, которая в целом известна. С качественными решениями, особенно провалидированными на уровне лучше чем «мамой клянусь, на моих 3 проектах TODO-листа, агентского фреймворка и семантического хранилища памяти» есть проблема — их нет. А без валидации в этом никакого смысла нет, но это никого не останавливает, потому что сделать новый фреймворк, написать про него статью и получить свою тысячу звёзд на GitHub конечно интереснее и веселее чем оценивать его и убедиться, что с очередным Опусом фреймворк стал ухудшать процент задач, решённых за тот же бюджет токенов :)
Я оцениваю свой проект, писЯ :) его с помощью него же. Эффективность начал он показывать почти сразу, стал сильно меньше забывать контекст, можно было закрыть сессию, поднять ее в другой CLI иной моделью. Но приходилось ручками напоминать агенту правила. Но стало легче, агент сам формулировал задачи, ранжировал по приоритетам, добивал постановку, я лишь обеспечил его удобным механизмом сохранения памяти. Причем код не какой-то там слишком заумный, это список инструментов сохранения, извлечения, семантического поиска, можно сказать бойлерплейт. По сути справится мамкин вайбкодер, только он не справится. Мамкин вайбкодер не сможет сформулировать задачу. Вот самое сложное здесь.
Вот список, почему пишу сам:
1. Я тот еще велосипедист, т.к. считаю, что идеальный под себя инструмент ты можешь сделать только сам, в остальном ты будешь мириться с компромиссами.
2. В продолжение первого пункта скажу, есть мудрость: "Если хочешь изучить инструмент, сделай его сам." Звучит как тавтология, но по другому сказать сложно.
3 .Опыт - это единственная ценность, что у тебя никто не сможет отнять.
4. Большинство популярных инструментов хочет, чтобы я оформил подписку и перечислял им денежку, и их столь много, что после оплаты AI-сервисов, квартплаты, ипотеки понимаешь, что кушать в этом месяце ты будешь макароны.
Теперь по инструменту, у меня свой MCP, развернутый локально в Docker, однако никто не мешает обращаться к нему по сети, что я и делаю. Задача MCP держать модель в рамках протокола решения задачи и предоставить удобны доступ к базе данных. Причем, самым сложным оказалось не общение с БД, а держать агента в жестких рамках, на эту тему тоже есть статья, чуть ранее опубликованная, но ее пока никто не понял. :)
Вообще не спорим. Перешел с простого RAG на hindsight - совсем другая лига.
Оно жрет в пять-десять раз больше компьюта, но в отличие от рага оно во время простоя само перемалывает данные и находит связи - в том числе довольно неочевидные, строит графы знаний, что-то суммаризирует, что-то записывает как наблюдения о мире. Даже ментальные модели строит.
Но когда ему задаешь какой-то вопрос оно отвечает настолько качественно что ощущение будто это реальный человек прочитал нужную гору знаний и говорит свою экспертизу по теме.
Предлагаю еще выше лигу - это мод на хинсайт по Миле Йовович. https://github.com/holetron/hindsight-mempalace
Тот случай, когда статья хорошая, но явно написана LLM, хоть это и причёсывали.
Кажется, пора привыкать к этому унылому привкусу ллм текстов.
Главное, чтобы в тексте были свежие человеческие мысли.
Согласен, без LLM сейчас никуда, он лучше расставит пунктуацию, получит 5 в грамматике, но он пока не сформулирует идею как это может человек. В этом тексте опыт мой, и знания. а то что я свой черновик подсунул на доделку нейросетке, ну чтож такова современная реальность, человеческая жизнь дороже подписки, не стоит тратить ее день на то, что искусственный разум сделает за 5 минут.
Статья интересная, но я после двух третей текста спрыгнул на свой проект - https://mindstream.app.wiredgeese.com/ Нашёл поиском по ключу "почему мы" эту статью и прочитал вот эту LLM-выжимку:
LLM-выжимка LLM-текста
Текст представляет спор о памяти для AI‑агентов не как спор между конкретными технологиями, а как попытку развести понятия и понять, какие задачи памяти выполняют разные формы хранения. Автор разделяет концепцию памяти на четыре моделируемых слоя: (1) память как документация, где данные лежат рядом с кодом и облекают проект в AGENTS.md, MEMORY.md и т.п.; (2) память как поиск, где роль играют индексы и семантический поиск, позволяющие вытягивать релевантные фрагменты из большого массива материалов без перегрузки контекстом; (3) память как состояние работы, которая фиксирует текущее состояние проекта, гипотезы, статусы и чекпоинты, чтобы вернуться к задаче без повторной археологической экспедиции по репозиторию; (4) память как опыт, где сохраняются причины решений, компромиссы, цены ошибок и уроки, чтобы не повторять старые ошибки и сохранять контекст принятия решений. В тексте подробно анализируются преимущества и ограничения каждого слоя, приводятся примеры артефактов (markdown‑файлы, базы данных, Obsidian, knowledge graph), а также роль автоматизации и структуры данных в управлении контекстом и актуальностью информации. Далее исследуется, как смешение подходов обуславливает реальную рабочую память проекта: чем крупнее проект, тем важнее корректное сочетание поиска, структуры и состояния; задача не в том, чтобы выбрать один инструмент как универсальный ответ, а в том, чтобы понять, как разные инструменты взаимодействуют: хранение, индексация, выбор фрагментов и передача контекста к агенту. Автор делает акцент на границе между хранением и использованием, на различии между стабильной документацией и динамическим рабочим состоянием, а также на необходимости отбора и объяснения причин решений, чтобы не превратить память в бесконечный чердак. В финале подчеркивается, что спор начинается с того, какую задачу должен решать каждый инструмент: markdown, SQLite, Obsidian, поиск и т. п. — и что универсально правильного решения нет. ПС напоминает читателю, что речь идёт именно о задачах каждого инструмента, а приглашение к обмену опытом подчёркивает открытость темы.
В общем, инструмент, на мой взгляд, получился неплохой и вполне рабочий, но в массы не зашёл. Поэтому я его с тех пор и не дорабатывал (весь код агенты писали, так-то). Работает себе автономно и кушает себе по пять-десять баксов в месяц на OpenAI API. Как руки дойдут, доработаю. А нет, ну и нет.
Не переживай, мой массам тоже не зашел, 99% пул-реквестов с гитхаба - боты, так, что ждите мои идеи в антропике или дипсике:) Как-то пару лет назад в одной онлайн-конференции спросил, почему еще никто не додумался до узкоспециализированных SLM, вопрос тогда вообще не понят был, проходит полтора года, мы видим преймущество MOE- моделей.
В дополнению спрошу, как часто ходите в театр? Насколько чаще смотрите кино? Сыграть пьесу ведь намного трудозатратнее, чем прокрутить фильм. Однако явно популярнее второе. По сути так и с LLM, большой плюс в том, что они дают возможность выражать наши обрывочные мысли связным текстом. Генерят нам красивые КДПВ. Мой друг с дисграфией теперь на Дзене пишет, а он без 3 ошибок в слове не может сообшение написать.
Могу еще пример привести, сейчас почти все на "автомате" ездят, и я все реже слышу мнение "Только механика, только хардкор!", кстати этих "механиков" в потоке лекго видно, они движение на свеnофоре замедляют :)
Практический опыт: 100+ сессий Claude Code в день, файловая память.
Использую ровно тот подход, который описан в статье как “три файла”. CLAUDE.md хранит неизменяемые правила проекта (паттерны кода, ограничения безопасности, стиль). CHECKPOINT.md хранит текущее состояние: последнее действие, следующий шаг, и список DO_NOT_REDO, чтобы после compaction агент не переделывал уже выполненную работу.
Третий файл — topic-memory.md, по одному на рабочий поток. Каждый Telegram-топик (использую как диспетчер проектов) получает свою память с целями, блокерами и платформенными заметками.
Почему файлы, а не БД: git diff показывает, что именно изменилось в памяти между сессиями. Это бесценно для отладки, когда агент начинает вести себя странно. С базой данных такой прозрачности нет.
Главный инсайт после полугода: самое важное в памяти агента — не что он помнит, а что он НЕ должен переделывать. Секция DO_NOT_REDO экономит больше токенов и времени, чем все остальные оптимизации вместе взятые.
Я не спорю, каждый работает так, как привык, как ему удобнее, в крайнем случае,как заставляют? чтобы не быть голословным.
вот реальный фрагмент из сессии, где ни единого md, все только в БД, причем такую информацию мне даже 2b модель способна выдать:
что известно по проекту sloplesscode в памяти
Работал на протяжении 2m 47s
Что хранится о SloplessCode
SloplessCode задуман как MCP-система проектной памяти и управляемого рабочего процесса для AI-агентов. Она хранит контекст, правила, задачи, решения, подтверждения и подсказывает безопасное следующее действие. Система рассчитана на произвольные проекты, не только на собственную разработку.
Состояние памяти
Готовность: limited_pilot_ready, 55/100
Задачи: 32
Предложения улучшений: 30
Активные правила: 12
Decision memoirs: 20
Разделы документации: 3
Компоненты: 0
Runtime hints: 0
То есть рабочий процесс и накопленные решения описаны неплохо, но архитектурная карта компонентов пока не загружена.
Основные принципы
MCP является каноническим каналом памяти и управления работой.
Агентский UX проверяется через публичный MCP-интерфейс.
Live-runtime действия требуют явного согласия оператора.
Docker-проверки отделяются от экспериментов с живыми данными.
Универсальные спецификации не должны содержать детали конкретного проекта.
Нужно исправлять причины, а не симптомы.
Частные случаи должны решаться общими, data-driven механизмами.
Автономность агента нельзя выводить из фраз вроде «продолжай»: она должна быть явно ограничена областью и временем.
Последние открытые направления
34d8175c-... — явные границы автономного режима агента.
26ec82c4-... — диагностика ошибочной маршрутизации через публичные incident-пакеты.
c22ec2dd-... — компактные stage-aware подсказки вместо повторения полного контекста.
4568b52c-... — профили совместимости для stateless MCP-клиентов.
4a17e4af-... — периодические проверки того, помнит ли агент актуальный контекст.
Спасибо за статью. Хорошо зашёл тезис, что спор о памяти агента часто уходит в носитель: markdown, база, embeddings, retrieval. А на практике важнее не где лежит память, а что именно система считает памятью.
Я бы разделил несколько уровней: знание проекта, найденный контекст, текущее рабочее состояние и опыт. Последнее для меня самое важное. Опыт — это не просто сохранённый фрагмент, а связка: ситуация, действие, результат, резюме для обучения.
Для меня память агента не хранилище, а механизм, который четко понимает статус прошлого события и принимает решение, имеет ли это событие право влиять на следующее действие.
Сколько же тут нейрослопа то по поводу банального json-перекладывания и json-хранения.
Особенно вот это:
Документация должна быть относительно спокойной.
Чиво?
спор о памяти для AI-агентов начинается не с выбора между markdown и Obsidian
Этот спор вообще существует?
Все что нужно знать, агенты работает с контекстом. как вы будете этот контекст наполнять - вопрос удобства. хотите .md конвенциональные, хотите делайте файлы "этооченьважныйфайл.прочтинемедленно" при нормальном токенизаторе почти все llm с этим умеют работать, им плевать что откуда читать.
sql удобен только консистентностью памяти, хотя его в этом плане может полностью заменить git. В кодинге старые добрые комментарии "глупая LLM не удаляй этот кусок кода" вполне работают, а главное очень легко тестировать именно эту фразу, которая не относиться к проекту с подходом "самодокументирующий код", но явно показывает что трогать не надо.
У памяти для агентов есть две реальные проблемы:
1)пользователь не хочет это все заполнять сам (да и не должен);
2) память тратит токены и требует инференса, а это самый дорогой ресурс агента.
А дальше классическое монте-карло по управлению ресурсами, если без явных критериев - на глаз.
Для себя вышел на формулу полная история в sql chat + agent skills + knowledge. И суперагенты пишут под себя тулзы.
"Спокойной", как синоним "относительно статичной". Я рад, что "нейрослоп", на написание которого ушло несколько дней бесценной для меня жизни, нашел отклик в вашей душе настолько, что пару абзацев в ночью в выходной, вы сочли должным в ответ мне чиркнуть.
По существу отвечу что:
1. Спор существует, и вы это сами прекрасно доказали.
2. Я не хочу, чтобы моя работа вместо полета мыслей состояла из создания файлов "этооченьважныйфайл.прочтинемедленно".
3. почти все llm с этим умеют работать, им плевать что откуда читать. Это неверно, т.к. либо агент делает grep по директории проекта, получив пару процентов нужной информации и 98 связанного мусора, порою спотыкаясь о фортели Powershell. Либо специализированная система памяти сама выдаст ему только то, что нужно в данный момент.
4. И суперагенты пишут под себя тулзы - пишут. А потом читаю в новостях: команда разработчиков потратила 2 миллиона долларов на LLM за месяц. Слегка завидуя их бюджету и утирая скупую мужскую слезу, открываю страницу оплаты подписки на GPT Plus.
5. Практический пример, почему надо разделять контуры документации проекта и оперативно рабочей информации: мне добрый китайский нейропомощник заботливо положил api-ключи в маркдаун файл с примером проверки доступности облачной нейросети через curl. А я это заметил, когда с Гитхаба алерт прилетел, что у меня конфиденциальное в публичном доступе.
6. Через БД, удобно автоинформировать агента о том, что другой программист работает сейчас над этой задачей, и агент не должен даже случайно реализовать еще и ее.
7. Время течет, все меняется, когда я писал диплом, "золотым стандартом" хранения информации был DBF, и кто сейчас его вспомнит за исключением программистов из пенсионного фонда? Сейчас у нас есть SQL, noSQL, semantic search и много всякого другого. Публично сказать, что SQL лучше noSQL, можно такой ларец Пандоры открыть, что лучше и не спрашивать совсем.
К слову сказать что я более чем уверен, что вы прекрасный специалист, хорошо знакомы с методологией оценки рисков и собаку съели на AI-assisted кодинге. Но, процитирую одного уважаемого мною кинокритика: "Если вам не понравилось это кино, значит оно снято не для вас".
Тоже начал копать в сторону "память как состояние", но не для агентов, а для обычного чата. Разделил обработку памяти на три слоя (факты, паттерны, сессии) и пишу локальный runtime, который это всё оркестрирует и показывает пользователю как видимые слепки состояния.
IMHO, любой агент - обвязка для вызова LLM по итогу. Можно на агента (обвязку для LLM) навесить свою обвязку (только сегодня мне Чатик выдал термин external harness на мой продукт github-flows-app). Так вот, моё мнение, в external harness памятью может быть что угодно - база, файлы, оперативка, аудио-записи, картинки, видео, ... Но в Модель (LLM) агент передаёт (и получает из неё) только текст. Другие типы моделей могут работать со звуком, изображением и видео в другом формате, но языковые модели (которые генерируют код - текст) работают с текстом.
Поэтому любая память так или иначе должна быть преобразована в текст, для того, чтобы стать доступной Модели. И тут уже возникают вопросы к "обвязке" - к агенту, к тому, кто готовит для агента данные (если они есть). Как она (обвязка) эти данные преобразует в текст, чтобы LLM могла их "понять" (использовать в инференсе).
На мой взгляд, пока что самым оптимальным является иерархическая организация md-файлов с текущим состоянием проекта. Агенту не надо знать историю и причины тех или иных решений. Агенту нужно знать текущее состояние, направление движения и рамки (чего делать, и чего не делать). Остальное - задача человека. Таким образом, в моменте я разделяю все свои md-файлы на две части: документация проекта и документация инструментария. Первое - уникальное для каждого проекта и лежит в проекте, второе - оформляется скиллами и подключается по мере необходимости.
Это на мой взгляд, повторяюсь. В конце-концов, вы же сами просили "поделитесь в комментариях своим опытом и тем, что вы сами называете памятью агента" 🤗
Верно, про harness - вот только harness(пояс) может быть пеньковой веревкой, а может быть тактическим ремнем. Назначение одно, удобство разное.
Остальное - задача человека. На мой утопичный взгляд, задача человека, сказать: "Я хочу...", все остальное задача машины: спросить, что хочешь, предложить варианты, сопроводив их комментариями об эффективности и ограничениях, оформить и сохранить постановку задачи. При этом не забыв про Liskov Substitution и декларативный код. :)
вот только harness(пояс) может быть пеньковой веревкой, а может быть тактическим ремнем.
Но если у тебя в руках АК-74, то на поясе должны висеть магазины с патронами 5,45-мм и не важно - тактический это ремень или пеньковая верёвка :)
все остальное задача машины: спросить, что хочешь, предложить варианты, сопроводив их комментариями об эффективности и ограничениях, оформить и сохранить постановку задачи. При этом не забыв про Liskov Substitution и декларативный код. :)
Я имел в виду, что задача человека - научить машину вот этому "всему остальному" :) А так - да, в идеале машина должна мочь вытащить ТЗ и из Эллочки-людоедки.
Почему мы спорим о памяти для AI-агентов