Перейти к содержимому

Память (memory)

У агента есть неприятное свойство: каждая сессия начинается с чистого листа. Вчера вы полчаса объясняли ему, что тесты запускаются через make test, что в проекте запрещены сырые SQL-запросы и что коммиты пишутся на английском. Сегодня новая сессия, и агент снова ничего этого не знает. Модель не запоминает диалоги: всё, что она «знает» о вашем проекте, должно каждый раз оказаться в контексте заново.

Память (memory) — механизм, который решает эту проблему без ежедневных повторений.

Основной инструмент — файл с инструкциями, который лежит в репозитории и который харнес (agent harness) автоматически подключает в начале каждой сессии. В Claude Code это файл CLAUDE.md, а во многих других харнесах он называется AGENTS.md; идея одна и та же: markdown-файл в корне проекта, написанный для агента.

Автоматичность здесь ключевая. Вам не нужно ничего вставлять в диалог: агент, запущенный в каталоге проекта, сразу видит содержимое файла. Один раз записали, и работает в каждой сессии, у каждого члена команды, у фонового агента в CI.

Обычно поддерживается и иерархия: общий файл в корне репозитория, уточняющие файлы в подкаталогах (например, свои соглашения у фронтенда и бэкенда), плюс личный файл пользователя вне репозитория, для индивидуальных предпочтений, которые не стоит навязывать команде.

Хороший тест: что вы рассказали бы толковому разработчику в первый день на проекте? Не «как программировать», а «как у нас».

  • Команды. Как собрать, как запустить тесты (все и один), как поднять окружение, как запустить линтер. Это первое, что нужно агенту, и то, на чём он чаще всего спотыкается в незнакомом проекте:
## Команды
- Сборка: make build
- Все тесты: make test
- Один тест: pytest tests/test_x.py -k name
- Линтер: make lint (запускать перед коммитом)
  • Архитектурные соглашения. Где что лежит, как ходят данные, какие слои нельзя смешивать: «доступ к БД только через слой repositories», «HTTP-обработчики не содержат бизнес-логики».
  • Стиль. То, что не ловит линтер: язык комментариев и коммитов, соглашения об именовании, предпочитаемые библиотеки («для дат только datetime, не сторонние пакеты»).
  • Запреты и опасные места. «Не редактировать файлы в generated/, они перезаписываются», «не менять схему БД без миграции», «каталог legacy/ не трогать без явной просьбы».

Чего писать не стоит: пересказ документации фреймворков (модель её знает), содержимое, которое агент легко найдёт сам (структуру каталогов он посмотрит за секунду), и длинные пошаговые регламенты: им место в скилах, см. Скилы.

Помимо файлов, которые пишете вы, харнесы развивают память, которую агент ведёт сам: заметки о проекте, накопленные выводы, запомненные по ходу работы факты, которые подключаются к следующим сессиям. Многие харнесы умеют и полуавтоматическое пополнение: вы говорите «запомни: тесты гоняем только через make test», и агент сам дописывает правило в файл памяти.

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

Память — не то место, где «больше — значит лучше». Две причины.

Устаревшие инструкции вредят. Инструкция в памяти задаёт указание, которому агент доверяет и следует. Если в файле написано «тесты запускаются через npm test», а команда полгода как переехала на make, агент будет раз за разом делать неправильно, и не потому, что глупый, а потому, что вы ему так велели. Противоречивые инструкции ещё хуже: агент непредсказуемо выберет одну из них. Мёртвые правила из памяти нужно выпалывать, как мёртвый код.

Память расходует контекст. Файл памяти загружается в контекстное окно (context window) каждой сессии, см. Токены и контекстное окно. Каждая строка памяти конкурирует за место и внимание модели с самой задачей. Раздутый файл на две тысячи строк не делает агента умнее, он делает его рассеяннее: чем больше правил, тем меньше вес каждого.

Практические ориентиры:

  • Держите файл компактным, как правило, до пары сотен строк. Лаконичный список фактов работает лучше эссе.
  • Пишите конкретно: не «соблюдай лучшие практики», а «каждая новая функция сопровождается тестом».
  • Обновляйте при изменениях: переехали на другой сборщик, правьте память тем же pull request’ом.
  • Периодически перечитывайте файл целиком и удаляйте устаревшее. Хороший повод для этого, когда агент сделал что-то странное «по инструкции».

Память — один из трёх слоёв инструкций агента, у каждого своя роль:

  • Память — короткие факты о проекте, нужные в каждой сессии.
  • Скилы — подробные процедуры, подгружаемые по требованию (Скилы).
  • Промпт задачи — то, что нужно только сейчас: постановка, ограничения, критерии готовности.

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

  • MCP-серверы: как подключить агента к внешним системам: трекеру, БД, браузеру.
  • Контекст-инжиниринг: как память встроена в общую стратегию управления контекстом.

Автор учебника — Шахматов Алексей