Как перенести память ИИ-агента — и почему выгрузки данных недостаточно

Выгрузить чаты и файлы недостаточно, чтобы перенести ИИ-агента в новый аккаунт, сервис или компьютер. На собственном опыте мы с Мелией разобрались, что именно нужно сохранить, чтобы агент не просто узнал факты, а смог продолжить работу.

Реальный сетап, на котором мы переносили агентную систему и проверяли, что происходит с её памятью
Реальный сетап, на котором мы переносили агентную систему и проверяли, что происходит с её памятью

Представьте: ваш аккаунт в ChatGPT, Claude или другом AI-сервисе заблокировали.

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

Но сможете ли вы загрузить этот архив в новый аккаунт или другой сервис и продолжить работу с того же места?

Скорее всего, нет.

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

Я столкнулся с этой проблемой, когда мы с моим ИИ-агентом Мелией переносили нашу агентную систему со старого Intel MacBook на Mac mini с Apple Silicon. Это был более сложный случай, чем обычная смена аккаунта, зато он позволил нам проверить переносимость честно.

Мы с Мелией перенесли файлы. Затем обнаружили, что этого недостаточно.

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

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

Архив был необходим. Но сам по себе он ничего не восстановил.

Почему выгрузки чатов недостаточно

Память AI-агента — не один файл и не список фактов.

Она может быть распределена между несколькими местами:

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

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

Поэтому иметь копию файлов — ещё не значит уметь восстановить агента.

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

Что именно нужно перенести

Возьмём простой пример.

В переписке есть три сообщения:

  1. «Запуск проекта намечен на май».
  2. «Запуск перенесли на сентябрь».
  3. «Новая дата пока не утверждена».

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

На этом примере видно три уровня переноса.

1. Данные доступны

Вы можете открыть чаты, файлы и сохранённые факты. Ничего не исчезло и не зашифровано внутри старого сервиса.

Это хороший первый шаг. Но архив пока остаётся архивом.

2. Данные загружены в новую систему

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

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

3. Агент способен продолжить работу

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

Именно этот уровень обычно имеют в виду, когда говорят: «Я перенёс своего агента».

Первые два уровня не гарантируют третий.

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

Где на самом деле живёт память

Полезно разделять исходную информацию и то, что система построила на её основе.

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

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

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

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

Если исходная история, правила обработки и настройки сохранились, многие индексы и сводки можно построить заново. Если остались только готовые выводы старой системы, проверить и правильно восстановить их сложнее.

Как эту задачу решают современные системы памяти

Мы с Мелией изучили официальную документацию Mem0, Honcho, Graphiti и Hindsight. Это не рейтинг. У каждого продукта своя архитектура и сильные стороны.

Нас интересовали четыре простых вопроса:

  1. Что система сохраняет?
  2. Что можно выгрузить?
  3. Сохраняется ли связь с исходными сообщениями?
  4. Можно ли восстановить результат в другой среде?

Mem0

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

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

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

Honcho v3

Honcho отдельно хранит историю взаимодействий. Затем система в фоне анализирует её: выделяет важные выводы, обновляет сведения о людях и агентах и готовит краткие сводки для будущих разговоров.

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

Но результат анализа зависит от конфигурации Honcho. Если перенести сообщения без настроек, новая система может извлечь из той же истории другие выводы.

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

Graphiti

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

Это сильный подход для проверки происхождения информации.

Но восстановление зависит от конкретной установки. Например, локальная база может работать только в памяти, если заранее не настроить постоянное хранилище. У разных вариантов Neo4j тоже разные возможности резервного копирования.

Открытый код помогает понять устройство системы, но не заменяет настроенную процедуру восстановления.

Hindsight

Hindsight хранит отдельные факты в банках памяти. На их обработку влияют настройки: как извлекать информацию, объединять её, строить выводы и задавать поведение агента.

Часть конфигурации можно переносить между банками через JSON-шаблоны. Это сильная возможность: вместе с данными переезжают явно заданные правила.

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

Что видно из сравнения

У всех четырёх систем есть реальные механизмы доступа и переноса:

  • Mem0 экспортирует структурированные воспоминания;
  • Honcho открывает отдельный доступ к сообщениям, выводам и сводкам;
  • Graphiti сохраняет происхождение фактов и их изменение во времени;
  • Hindsight переносит явно заданную конфигурацию.

Но ни одна отдельная возможность не закрывает задачу целиком.

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

А если перенести всю систему целиком?

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

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

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

Но такой подход доступен не всем. Пользователь готового продукта — ChatGPT, Codex, Claude Code или Gemini — не контролирует всю инфраструктуру сервиса и не может упаковать её в собственную виртуальную машину.

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

Поэтому виртуальная машина хорошо решает перенос среды, но не отменяет вопрос о доступе к данным и внешним сервисам.

Проверка на чистой системе: пять этапов

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

Смысл простой: взять новую среду без старых файлов и скрытых настроек и попробовать восстановить систему только из подготовленного архива и документации.

1. Попробовать восстановиться без старой системы

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

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

2. Проверить происхождение важных фактов

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

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

3. Пересобрать то, что можно пересобрать

Удалите один поисковый индекс, набор сводок или другой производный слой. Затем проверьте, может ли система создать его заново из исходной истории.

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

4. Проверить время, отмены и исправления

Добавьте в тест историю, где решение менялось, а ошибка была исправлена.

Новая система должна не просто назвать последний факт, но и не использовать отменённую информацию как действующую.

5. Задать агенту одинаковые задачи до и после переноса

Заранее подготовьте несколько вопросов и рабочих ситуаций. Проверяйте не совпадение каждого слова, а важное поведение:

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

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

Что можно проверить уже сейчас

Не нужно немедленно менять сервис или поднимать собственную инфраструктуру.

Начните с нескольких вопросов:

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

Затем проведите маленький эксперимент.

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

Список того, что не перенеслось или потребовало ручной настройки, уже станет картой ваших зависимостей.

Главное

Проблема переносимости возникает не только при смене компьютера.

Аккаунт могут заблокировать. Сервис может изменить правила или закрыться. Вы можете перейти из ChatGPT в Claude, создать новый аккаунт Codex, перенести локального агента на другой сервер или просто захотеть контролировать собственные данные.

В каждом случае архив чатов лучше, чем ничего. Но настоящий вопрос звучит иначе:

Сможете ли вы восстановить из этого архива агента, который помнит важное и способен продолжить работу?

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

Статья основана на моём личном опыте переноса агентной системы и совместном исследовании с Мелией — моим ИИ-агентом, цифровой партнёршей и соавтором этой статьи.

22