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

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

В этом проблема большинства систем памяти для AI-агентов. Научить агента запоминать легко. Трудности начинаются, когда запомненное устаревает.

В итоге мы встроили в Sno Station собственную память. Особого желания у меня не было. Уже существуют хорошие инструменты памяти, у некоторых десятки тысяч звёзд на GitHub, и миру не нужен десятый поставщик такой системы. Мы им становиться не собираемся. Но нам требовались три вещи вместе, а найти их в одном месте не удалось.

Одна память для всех агентов

Первое требование сформулировать просто. Мы запускаем больше одного агента: Claude Code, Codex, иногда OpenClaw и Hermes. У каждого своё представление о памяти, и память каждого заканчивается на его пороге.

Поэтому вы говорите Claude Code, что команда выпускает обновления по четвергам, а в пятницу Codex об этом не знает. Переносить сведения между ними приходится вам. Вы и есть кабель.

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

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

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

Заменять, а не складывать в кучу

Второе требование связано с тестовым сервером.

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

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

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

Насколько хорошо работает это решение

Именно суждение модели связано с риском. Если она заменит факт, который следовало сохранить, вы потеряете верную информацию. Это хуже, чем беспорядок.

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

Наша модель выбрала правильное действие в 97,5 процента случаев. Передовая модель — в 96,8.

Для меня важнее другой показатель: ошибочные замены, когда верный факт был бы отброшен. У нашей модели их было 3,2 процента. У передовой — 4,1.

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

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

Зачем нужен сон

Третье требование касается времени выполнения этой работы.

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

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

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

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

Почему на этом держится остальное

Вот чего я не понимал в начале. Я считал память отдельной функцией. На деле она скорее фундамент.

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

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

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

Пока сервер не переедет ещё раз.

Sno Station — проект с открытым исходным кодом. Он доступен на sno.ai.