Вашему AI-агентну для кода нужна память, а не новые инструкции

Meta выпустила очередного AI-агента для кода — Muse Code на движке Muse Spark 1.2. В ряду Claude Code, Codex, Copilot, Cursor и Gemini CLI это уже никого не удивит. Удивило другое: Muse Code ведёт журнал активности и умеет возобновлять прерванную долгую задачу, а не начинать всё заново.

О чём это говорит? О том, что даже самые продвинутые модели спотыкаются об одну проблему — отсутствие непрерывности. Ум без памяти — это вечный новичок, который каждый раз заново изучает ваш проект.

Инструкции не решают проблему

Серьёзные проекты уже обзавелись целыми стопками файлов для агентов: CLAUDE.md, AGENTS.md, .cursor/rules/, copilot-instructions.md. В них описывают структуру репозитория, команды, паттерны, запреты, тесты, архитектуру. Логика понятная: новому разработчику мы даём документацию — почему бы не дать её агенту?

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

Исследование "Do Context Files Help Coding Agents?" (июль 2026) прогнало 288 сессий Claude Code и Codex на 17 реальных задачах в 3 репозиториях. Вывод: контекстная стратегия практически не повлияла на корректность решения. Другое исследование, посвящённое AGENTS.md, показало, что контекстные файлы скорее снижают успешность задач и повышают расходы на inference более чем на 20%.

Это не значит, что нужно удалить все инструкции. Это значит, что мы путаем контекст с памятью. Контекст — это временный рабочий лист. Память — это то, что остаётся после и помогает не наступать на грабли.

Инструкция и память: в чём разница

Вот типичная инструкция для агента:

Инструкция: «Все изменения биллинга — только через BillingService. Никогда не писать напрямую в таблицу подписок.»

Полезно. Но вот как выглядит память:

Память: «Мы раньше писали обновления подписок напрямую в таблицу. Это обходило BillingService, из-за чего ретраи вебхуков затирали статус годовых планов. Мы исправили это, направив все обновления через BillingService. Если трогаете логику продления — проверьте ретраи вебхуков на годовом плане и убедитесь в идемпотентности.»

Второе описывает не только «что делать», но и что случилось, почему, что сломалось, как починили и как проверить, что это не повторится. Это «шрам» команды — след от прошлых инцидентов. Инструкции описывают дорогу. Память помнит, где вы врезались.

Опытные разработчики так и работают. Они знают не только текущую архитектуру, но и последствия решений: «мы это уже пробовали», «не используй эту библиотеку», «этот endpoint кажется синхронным, но воркер внизу — нет». AI-агенты сами по себе не накапливают такой опыт.

Текущая архитектура: всё в контекст, а потом забыть

Сегодня рабочий процесс выглядит так: README, AGENTS.md, CLAUDE.md, ещё что-то — всё скармливается в модель. Она выполняет задачу, сессия заканчивается, и всё забывается. При этом разработчики постоянно переключаются между инструментами. Вот обычная картина:

Muse Code делает фрагментацию очевиднее: длинные задачи, несколько сабагентов, журнал для возобновления. Но это поднимает вопрос, кто должен владеть памятью. Агент? IDE? Провайдер модели? Репозиторий? Или вы сами?

Что сохранять и как

Не всё подряд. Слепо копить все диалоги — это просто ещё один гигантский контекст. Нужна селективность. Для разработки подходят четыре категории:

• Решения — «выбрали Redis Streams вместо RabbitMQ, потому что…»;
• История работы — «рефакторинг чекаута затронул такие компоненты»;
• Предпочтения и конвенции — «используем маленькие сервисы, не раздуваем контроллеры»;
• Шрамы — упавшие инциденты с симптомом, причиной, предотвращением и проверкой.

Самая ценная — последняя. Если описывать сбой в структурированном виде: симптом, причина, предотвращение, как проверить — агент сможет не повторять ошибку и заодно объяснить, почему команда работает именно так.

Что делать прямо сейчас

Не нужно удалять AGENTS.md, но стоит разделить инструкции и память. Инструкции — это правила и кодировка. Память — это история инцидентов и решений. Создайте отдельный файл, например MEMORY.md, и переносите туда результаты неудач, а не только успехи.

Используйте структуру «симптом — причина — предотвращение — проверка» для каждого задокументированного случая. Это дорогого стоит, когда через полгода агент (или новый разработчик) столкнётся с похожим багом.

И, главное, проектируйте память как независимый слой. Модели сменят друг друга, а накопленный опыт останется. Интеллект агентов растёт быстро. Память — вот то, что делает их по-настоящему полезными.