Как устроена память ИИ-агента и зачем она нужна

Почему агент без памяти бесполезен

Представь сотрудника, который каждое утро приходит на работу с нуля. Не помнит, какие у вас проекты, где лежат файлы, какой тон в переписке с клиентами, что вы решили вчера и почему отказались от предыдущего варианта. Каждый день ты объясняешь всё заново.

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

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

Четыре слоя памяти

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

1. Контекст текущей сессии

Это то, что агент держит «в голове» прямо сейчас: твои сообщения, прочитанные файлы, результаты команд. Самый быстрый и самый точный слой — и самый недолговечный.

Ограничения простые: - контекст конечен, в длинной сессии начало вытесняется; - всё, что в нём лежит, оплачивается токенами на каждом шаге; - при закрытии сессии он исчезает целиком.

Вывод: контекст — рабочий стол, а не архив. Складывать туда что-то на хранение бессмысленно.

2. Файлы-инструкции (правила и факты)

Это текстовые файлы, которые агент читает автоматически в начале работы: правила поведения, описание инфраструктуры, список проектов, запреты. В экосистеме Claude Code эту роль играют файлы вида CLAUDE.md и MEMORY.md.

Сюда пишут то, что должно действовать всегда: - кто ты для агента и каким тоном он отвечает; - адреса серверов, пути к ключевым каталогам, имена сервисов; - жёсткие запреты («никогда не делай X», «перед Y сначала спроси»); - короткие ссылки на отдельные файлы с деталями по каждому проекту.

Главное правило этого слоя: он должен быть коротким. Если файл разрастается до нескольких сотен строк, агент начинает тонуть в нём, а ты — платить за перечитывание мусора на каждом запуске. Держи ядро компактным, а подробности выноси в отдельные файлы и ссылайся на них.

3. Векторная база (семантический поиск)

Файлы-инструкции отвечают на вопрос «какие у нас правила». Векторная база отвечает на вопрос «а мы это уже обсуждали?».

Работает так: выжимки задач и разговоров сохраняются как записи, каждая превращается в числовой вектор по смыслу. Когда агенту нужно вспомнить, он ищет не по точному слову, а по смыслу — и находит запись про «проблему с сертификатом» по запросу «сайт не открывается по https».

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

4. Структурированная БД

Когда данные однотипные и их много — задачи, лиды, ссылки, расписание, учётные записи — текст перестаёт работать. Нужна обычная база: SQLite или Postgres, таблицы, поля, выборки.

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

Сравнение слоёв

Что писать в память, а что нет

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

Писать стоит

• Решения и их причины. Не просто «перешли на другой домен», а «перешли, потому что старый оказался дропом с плохой историей».
• Грабли. Что сломалось, почему и как чинить. Это самая ценная часть памяти: один записанный баг экономит часы.
• Инфраструктуру. Пути, порты, имена сервисов, команды перезапуска.
• Запреты и предпочтения. Чего делать нельзя никогда и что требует согласования.
• Статусы проектов. Активен, остановлен, продаётся — одной строкой.

Писать не стоит

• Полные логи и простыни вывода команд. Нужен итог, а не стенограмма.
• Секреты в открытом виде. Пароли и ключи — в отдельное защищённое хранилище, в память только указатель «логин там-то».
• Промежуточные размышления. «Попробовали так, не вышло, попробовали иначе» — в память идёт только финальный рабочий вариант.
• То, что агент может посмотреть сам. Содержимое файлов, список процессов, текущую дату. Это добывается на месте и мгновенно устаревает в памяти.
• Дубли. Один факт — одно место. Если правило записано в двух файлах, рано или поздно они разойдутся.

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

Память деградирует не от объёма, а от противоречий. Вот рабочая гигиена.

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

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

Срок годности у заметок. Запись вида «сейчас разбираемся с задачей N» живёт до конца задачи, потом заменяется одной строкой результата. Иначе через полгода агент будет считать незавершённым то, что давно сделано.

Разделение по файлам. Большой проект — отдельный файл с деталями, а в ядре только одна строка со ссылкой. Так агент подгружает подробности только когда действительно работает с этим проектом.

Регулярная ревизия. Раз в месяц просить агента перечитать память и найти устаревшее, дубли и противоречия. Он справляется с этим лучше человека, потому что видит весь текст сразу.

Ритуал начала сессии

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

Выглядит это так:

1. Агент стартует и первым делом читает ядро правил и журнал последних сессий.
2. Если задача касается конкретного проекта — подтягивает файл этого проекта.
3. Если звучит знакомо — ищет в векторной базе похожие записи.
4. Только после этого начинает работать.

Три-четыре секунды на старте — и ты не объясняешь заново, что такое «БАЗА», где лежит бот и почему нельзя трогать конкретный сервис.

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

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

Как проверить, что память действительно работает

Память легко настроить на бумаге и не заметить, что она не используется. Проверяется это простыми тестами.

Тест на холодный старт. Открой новую сессию и задай вопрос, ответ на который есть только в памяти: «какой статус у проекта N?» или «почему мы отказались от варианта X?». Если агент идёт угадывать или переспрашивает очевидное — он память не прочитал, и дело в правилах запуска, а не в самих записях.

Тест на противоречие. Спроси о правиле, которое ты недавно менял. Если агент выдаёт старую версию или обе сразу — в памяти остался дубль, который нужно вычистить.

Тест на запись. После завершённой задачи проверь, появилась ли выжимка, и прочитай её глазами. Частая проблема: агент сохраняет запись, но формулирует так общо («поработал над сайтом»), что через месяц она бесполезна. Выжимка должна содержать конкретику — имена файлов, команды, причины решений.

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

Где память живёт физически

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

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

Память как общий ресурс

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

Поэтому структуру памяти стоит продумывать с первого дня, а не когда файл правил разрастётся до нечитаемого состояния.

Короткий чек-лист

• Раздели память на слои: контекст, правила, смысловой архив, структурированные данные.
• Держи ядро правил коротким, подробности выноси в отдельные файлы.
• Пиши решения и грабли, не пиши логи, секреты и то, что агент посмотрит сам.
• Правь старое вместо дописывания нового.
• Обязательное чтение памяти в начале сессии и выжимка в конце.
• Ревизия раз в месяц и регулярный бэкап.

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