Comments 12
можно просто память хранить в agents.md а в claude.md просто шим @AGENTS.md
Да, так можно. Я отчасти раньше так и делал. Тут у меня скорее вопрос к тому, что хранить в этом файле.
Если складывать туда всю накопленную память, со временем файл разрастается. Можно регулярно его чистить, но мне ближе аналогия с принципом единственной ответственности: в AGENTS.md оставить инструкции по работе с проектом, важные ограничения, команды и проверки, а накопленные знания хранить отдельно по темам. В инструкциях достаточно указать, где лежит память, когда ее читать и как обновлять.
По организации файлов инструкций полезны рекомендации Anthropic по CLAUDE.md и руководство OpenAI по AGENTS.md.
Для себя я выбрал компактный основной файл с указателями на подробности и условиями их чтения.
Хороший ход — держать память в репозитории, а не в служебной папке одного инструмента. Сам пришёл к тому же, но потом упёрся в другую проблему: со временем в памяти копятся противоречия. Агент в одной сессии записал «бот ещё не выкачен», в другой — «бот работает на сервере», и дальше уверенно берёт ту запись, что первой попалась. Как вы с этим боретесь — чистите MEMORY.md руками или есть какое-то правило «новая запись заменяет старую»?
Для поддержания порядка использую свои скиллы instruction-health-skills. В нем guardian перед добавлением записи проверяет, не описано ли это уже где-то, а cleanup помогает разбирать накопившиеся материалы. Но отдельного автоматического разрешения противоречий у меня нет: скиллы помогают соблюдать порядок, а актуальность спорной записи все равно нужно проверять.
Спасибо, понял. У меня, похоже, та же граница: дубли ловятся, а вот «какая из двух записей сейчас правда» — нет. Я в итоге сделал так: у каждого факта есть ключ (например, deploy.bot), и когда под одним ключом появляются разные версии, агент получает самую новую, но с пометкой «есть расхождение», а человеку в интерфейсе приходит один простой вопрос «какая верная?» — с вариантами рядом. Плюс у записи хранится, из какого файла она взята: если файл изменился, запись помечается устаревшей. Вынес это в отдельный сервис памяти (MMW, работает с Claude Code, Codex и Cursor) — если интересно, могу показать, как это выглядит.
Специально, чтобы победить эти беды создал вот такую штуку https://github.com/Deadatreides/PTG-MEM. Графово-векторный с избыточностью. Берет на входе полный хаос и выдает через mcp четкий контекст. Причем вживую.
Посмотрел — интересно, у вас та же идея со связями «заменяет» и «противоречит», что и у меня. Вопрос: кто решает, что две записи противоречат и какая из них верная, — модель сама или человек? Я в итоге пришёл к тому, что модель только находит расхождение, а выбор оставляю человеку: один раз она уверенно «победила» правильный ИНН устаревшим. И второе: если работаешь с двух компьютеров или командой — память у вас общая или у каждого своя локальная? Его ответ покажет, где у PTG-MEM граница. Если «модель решает сама» или «только локально», это ровно то, чем MMW отличается. https://docs.mmwhub.ru/
Модель не решает, это принципиально. Правка того же файла - новая версия заменяет старую, старая уходит в историю и в поиск больше не попадает. Между разными записями «заменяет» ставится только по явному маркеру вроде «вместо» и при сильном сходстве текстов. Иначе живут обе, а агенту в контексте приходит пометка «противоречит записи от такого-то числа». Выбирает тот, кто читает, по датам. ИНН был бы как раз таким случаем.
Память локальная, демон на машину. Общая - папка проекта: если она синкается, каждая машина строит из нее то же самое у себя. Общего сервера нет, это сознательно.
P.S. кажется, в комментарий попала заметка вашего агента про MMW. Наверное стоит подтереть, пока никто не спалил.
Если вы остаётесь на уровне графа "функция вызывает функцию" и не проваливаетесь глубже (а это требует огромных усилий), то вместо одного огромного хаоса вы получаете большие куски разных хаосов. Рекомендую ознакомиться: https://habr.com/ru/articles/1087078/
Согласен, граф вызовов сам по себе дает карту, понимания он не добавляет. Я это даже замерил: на своем архиве поиск по графу находил нужное хуже, чем простой поиск по смыслу, 64,9% против 70,3%. Поэтому в PTG-MEM ищет косинус, а граф только помечает, что чем заменено, и показывает соседей уже найденного. Подход из статьи с описаниями агентом по графу интересный.
Столкнулся с такой же проблемой, только память хотел шарить между opencode и остальными агентами. Пересмотрел немного структуру. Использую подход OKF от Google, только дополненый. Документация распределяется по разным файлам по направлениям/модулям. Причем устаревшие решения не удаляю, а помечаю ка кdeprecated, тогда в проекте остается понимание какие решения были ошибочными и какие новые правила нужно использовать.
Потом оформил это в плагин, который сам занимается заполнением документации. Для кодекса с поддержкой клода можно попробовать EchoesVault, Для opencode немного другой, но с теми же протоколами работает. Стало удобнее шарить память и знания о проекте между разработчиками
Покуда вы называете "памятью" якобы-структурированные и необязательные к исполнению (как ни умоляй) портянки текста, вы обречены ходить по кругу галлюцинаций, коллизий и перепроверок. Рекомендую ознакомиться: https://habr.com/ru/articles/1087078/
Общая память проекта для Claude Code и Codex