Память ассистента стала сквозной. К API это не относится

25 августа Anthropic объявила, что память Claude стала общей между чатом и настольным агентом: то, что вы рассказали в переписке, теперь доступно и в рабочих сессиях. Одновременно появилось управление — сохранённое видно по темам, любую запись можно отредактировать или удалить. Отдельно оговорено, что чувствительные темы по умолчанию не сохраняются: здоровье, раса и этническая принадлежность, гендерная идентичность, религия, политические взгляды; включить их можно только осознанным действием. Сразу главное для нашего читателя: к API это не относится. Через API контекст формируете вы, и никакая внешняя память к вашему запросу не подмешивается. Но прочитать стоит по другой причине — в своём продукте память придётся строить самому, и здесь видно, какие вопросы при этом возникают.

Что именно изменилось

Три части объявления, каждая по-своему интересна.

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

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

Исключение чувствительных тем по умолчанию. Целый класс сведений не сохраняется, пока пользователь явно не разрешит.

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

Почему исключение по умолчанию — правильное решение

Разберём, потому что в своём продукте вы столкнётесь ровно с этим выбором.

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

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

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

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

Что из этого применимо в API

Практическая часть, потому что через API память не приходит сама.

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

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

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

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

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

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

Как устроена память в продукте на API

Раз строить придётся самому, разберём типовую конструкцию — она проще, чем кажется, и состоит из трёх частей.

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

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

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

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

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

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

Разграничение, которое стоит проговорить, потому что их постоянно смешивают.

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

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

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

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

Про общую память между агентами

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

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

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

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

Три вопроса перед тем, как строить память

Если после всего написанного вы решаете, нужна ли память вашему продукту, начните с этих трёх.

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

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

Готовы ли вы отвечать за хранение? Сведения о пользователе — это данные, которые вы теперь храните со всеми вытекающими: доступ, срок, удаление по требованию, ответственность при утечке. Технически память проста, организационно — нет.

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

Чего мы не утверждаем

Мы не тестировали изменения. Все подробности — из публикаций, перечисленных в источниках.

Не проверяли полноту исключения чувствительных тем. Заявленный список приводим как есть; как это работает на практике, со стороны не проверить.

Это про потребительские приложения. Тарифы, поверхности и поведение памяти относятся к продуктам вендора, а не к API.

На стороне KeyDealer памяти нет. Мы передаём запросы и не сохраняем их содержимое; перечень того, что остаётся, — в llms.txt. Никакие сведения о ваших прошлых запросах в новые не подмешиваются.

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

Что держать в голове

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

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

Как мы отделяем проверенное от предполагаемого — на странице о проекте. Модели Claude и остальной каталог — по одному ключу: keydealer.ru/login.