Память агента заперта у вендора: почему переезд ломает историю

Память агента — то, что делает ассистента полезным на длинной дистанции: он помнит имя вашей компании, стек, тон переписки, прошлые решения. Проблема в том, что эта память живёт внутри конкретной платформы. У OpenAI это ChatGPT Memory и связка с Assistants/Responses API, у Anthropic — свои механики через файлы и контекст, у Google — память в Gemini. Экспортировать «мозг» ассистента из одной системы и залить в другую в один клик нельзя: общего стандарта нет, а внутренние представления памяти у вендоров устроены по-разному.

Что вообще называют «памятью агента»

Под одним словом скрываются как минимум три разные вещи, и переносятся они по-разному.

• История диалогов. Сырые сообщения. Их обычно можно выгрузить, но это не память, а лог — модель не «помнит» их, пока вы снова не подадите в контекст.
• Извлечённые факты (long-term memory). Короткие утверждения вроде «пользователь работает с Postgres» или «зовут компанию N». Именно они и есть ценность, и именно их формат у каждого вендора свой.
• Внешняя база знаний под RAG¹. Документы и векторные индексы. Это чаще всего ваша собственная инфраструктура, и её переносить проще всего — если вы её изначально держали у себя, а не в проприетарном хранилище.

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

Почему перенос ломается

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

Добавьте разные форматы вызова инструментов и системных промптов. Инструкция, которая у одной модели давала предсказуемый результат, у другой требует переписывания. Память без совместимого способа её подавать в модель работает вполсилы.

Где границы контекстного окна

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

Как обстоят дела у основных платформ

Сравнение ниже — про механику переносимости, а не про качество моделей. Конкретные лимиты и наличие функций меняются, сверяйтесь с документацией вендора на дату чтения.

Вывод из таблицы простой: единственная строка, где перенос не проблема, — последняя. Если память живёт в вашей базе, а вендор используется как сменный «движок» рассуждений, смена вендора становится заменой одного API-вызова, а не переездом с потерями.

Что делать, чтобы не запереть себя

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

1. Держите факты о себе отдельно. Ведите короткий текстовый «профиль контекста» — стек, предпочтения, важные решения. При смене платформы вы вставите его в первый же диалог руками.
2. Не привязывайте базу знаний к вендору. Документы и векторный индекс держите в своей инфраструктуре или у нейтрального провайдера, а не внутри проприетарного хранилища ассистента.
3. Абстрагируйте вызов модели. Для продуктов используйте слой (LangChain, LlamaIndex или собственную обёртку), где модель — параметр конфигурации, а память — ваша схема.
4. Периодически экспортируйте. Раз в квартал выгружайте данные аккаунта, чтобы у вас был свежий дамп на случай ухода с платформы или изменения её политики.
5. Проектируйте память под минимальное окно. Если факты помещаются в небольшой контекст, вы не зависите от того, у кого окно больше.

Кому это пригодится, а кому нет

Пригодится:

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

Можно не заморачиваться:

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

¹ RAG (retrieval-augmented generation) — подход, при котором модель перед ответом достаёт релевантные фрагменты из внешней базы и опирается на них, а не только на то, что «знает» из обучения.

² Контекстное окно — максимальный объём текста (в токенах), который модель обрабатывает за один запрос: и ваш ввод, и подмешанная память, и ответ.