Дизайн памяти AI‑агента: сохраняйте факты, убирайте дорогой шум

Почему сохранение всего создаёт проблемы

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

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

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

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

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

Тут начинается проблема доверия. Кто‑то спрашивает: «Что агент помнит?» и никто не даёт ясного ответа. Один думает, что хранятся полные чаты. Другой — что только сводки. Третий не знает, что приватные заметки всё ещё в базе. Когда память размыта, отладка замедляется, а решения по политике принимаются неубедительно.

Именно поэтому дизайн памяти AI‑агента должен начинаться с удаления, а не с коллекции. Сохраняйте факты, которые помогают в следующей задаче. Удаляйте остальное прежде, чем оно превратится в расход, путаницу и риск.

Что заслуживает место в памяти

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

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

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

Эти факты заслуживают места, потому что они меняют будущее поведение. Если агент знает, что у команды месячный бюджет $10,000, нет доступа к production‑данным и запуск через три недели, он сразу даст более полезные рекомендации.

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

Как выглядит полезная запись в памяти

Запись в памяти должна быть похожа на факт, а не на дневниковую заметку. «Бюджет ограничен $10,000 до Q3» — полезно. «Пользователь, казалось, волновался о тратах во время длинной беседы» — размыто и быстро устареет.

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

Хорошая память остаётся скучной. И это хорошо. Сохраняйте то, что долговечно, применимо и вероятно снова пригодится.

Что нужно убрать немедленно

Когда команды начинают думать о сохранении фактов для AI‑агентов, первый выигрыш обычно приходит через удаление. Если агент хранит каждое приветствие, отступление и опечатку, память заполняется текстом, который не помогает в следующей задаче. Это не только тратит место — это повышает стоимость и ухудшает точность поиска.

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

Опечатки и перезаписанные инструкции тоже должны исчезать. Люди часто повторяют одно и то же по‑разному, особенно при уточнении запроса. Сохраняйте чистый смысл, а не грязный след правок. Если пользователь сначала пишет «отправить отчёт в пятницу», а потом исправляет на «отправить отчёт в следующий понедельник в 9», храните финальную инструкцию, а не обе версии.

Заметки только для задачи нужно быстро истекать. Если агент создал напоминание «использовать CSV‑импорт для этой загрузки» и загрузка завершена, удалите его. По окончании работы должны оставаться результаты, а не черновые заметки — иначе агент будет нести устаревшие инструкции в другие задачи.

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

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

Небольшая модель памяти, которая остаётся прозрачной

Чистая модель памяти отделяет то, чем агент занимается сейчас, от того, что нужно помнить позже. Такое разделение предотвращает много проблем. Большинство сбоев происходит из‑за смешения живого контекста с фактами, которые должны пережить окончание задачи.

Контекст текущей задачи

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

Долговременный профиль

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

Датированные резюме

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

Временные заметки

Это напоминания вроде «ждать счёт в пятницу» или «использовать черновой план до ответа юридического отдела». Даём каждой заметке дату истечения при сохранении. Если срок прошёл и никто не продлил её — удаляем.

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

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

Как выстроить поток шаг за шагом

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

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

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

Держите каждую запись короткой и структурированной. Предложения в одну‑две строки часто достаточно. Сохраняйте факт, метку времени и источник, если нужна прослеживаемость. Не храните дамп сообщений, когда аккуратное резюме справится с задачей.

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

Тестируйте на «грязных», реальных разговорах. Синтетические примеры аккуратны. Реальные пользователи болтают, меняют мнение и смешивают полезные факты с шумом. Прогоните поток на реальных протоколах и посмотрите, что агент сохранил. Обрежьте всё, что выглядит интересно, но никогда не помогает.

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

Команды часто пропускают это, потому что система «всё ещё работает». Это ошибка. Память растёт незаметно, и поздняя чистка причинит больше вреда, чем ранняя дисциплина.

Реалистичный пример

Мария пользуется ассистентом по путешествиям несколько раз в месяц. Сначала она говорит, что обычно вылетает из Берлина, избегает red‑eye рейсов, ориентируется на средний бюджет и предпочитает тихие отели, а не модные. Эти детали стоит держать в памяти, потому что они помогают при следующем поиске поездки.

Много другого чата должно исчезнуть. Однажды утром Мария пишет, что ей нужно пять минут, потому что кофе‑брейк затянулся после тяжёлой встречи. Это может иметь значение для следующего ответа в диалоге, но не помогает с будущими планами поездок. Агент должен использовать это в моменте, а затем удалить.

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

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

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

Простое правило работает: если факт, вероятно, улучшит следующую задачу — сохраняйте. Если он только объясняет момент в разговоре — отпустите.

Ошибки, которые делают память грязной

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

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

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

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

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

Более чистая запись разделяет подтверждённые факты, временные заметки с датой истечения, открытые вопросы и отвергнутые гипотезы. Это делает последующее извлечение намного понятнее.

Представьте себе sales‑ассистента после 20‑минутного звонка. Ему не нужны все фразы. Нужны несколько фактов: размер компании, диапазон бюджета, сроки покупки и одна явная преграда. Всё остальное можно оставить в стороне.

Пересмотрите правила памяти

Прямой аудит ловит большинство проблем. Если команда не может в одной ясной фразе защитить поле памяти, вероятно, ему там не место.

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

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

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

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

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

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

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

Следующие шаги для вашей команды

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

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

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

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

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

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

Если команде нужен второй взгляд, Oleg Sotnikov at oleg.is предлагает Fractional CTO‑консультации, которые помогут проверить правила памяти, дизайн агентов и компромиссы затрат вокруг AI‑первых процессов. Двигайтесь скромно: выпустите один поток памяти, измерьте его, зачистите и только потом копируйте паттерн на другие агенты.