Vendor‑neutral agent memory для федеративных агентов

Почему агенты «забывают» после смены модели

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

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

Это быстро видно в поддержке. Клиент говорит: «Пожалуйста, отправляйте обновления в наш офис в Берлине, не в Лондон», и агент правильно отвечает несколько раз. Потом вы сменили модель, эта заметка оказалась глубоко в стенограмме, и следующий ответ снова спрашивает адрес или отправляет обновление не туда.

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

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

Именно поэтому важна vendor‑neutral agent memory. Когда факты и состояние задач живут в базе данных, системе тикетов или CRM, вы можете менять модели, не теряя нити. Модель по‑прежнему помогает в написании и рассуждении, но она уже не единственное место, где агент «знает» что‑то.

Что хранить вне модели

Модель не должна быть единственным местом, где агенты что‑то помнят. Если факты, незаконченная работа и прошлые результаты инструментов живут только в подсказках, смена провайдера может стереть контекст за день. Vendor‑neutral agent memory начинается с общего хранилища, которое любая модель может читать и обновлять.

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

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

Простая запись задачи обычно должна содержать:

• текущий статус, например open, waiting, blocked или done
• недавние результаты инструментов, как проверка API или поиск по документам
• решения, которые уже были приняты, и кем
• дедлайны, напоминания и сроки
• следующее действие и его владелец

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

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

Разделяйте факты, состояние задачи и историю

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

Подтверждённые факты требуют строгих правил. Сохраняйте только те детали, которые можно подтвердить: ID клиента, тарифный план, статус оплаты или адрес доставки. Если агент делает вывод на основе контекста, храните это в отдельном поле, например "assumption", или не сохраняйте вовсе, пока человек или другой доверенный источник не подтвердят.

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

Состояние задачи лучше хранить в фиксированных полях, а не в свободном тексте. Вместо заметки вроде «ожидается ответ от клиента, возможно возврат завтра» храните структурированные значения: status: waiting_for_reply, owner: billing_agent, next_action: send_refund_form, due_at: 2026-04-15. Это делает передачу дел гораздо безопаснее, когда разные модели читают одну и ту же запись.

Разделение может быть простым:

• Факты: подтверждённые детали с источником и меткой времени
• Состояние задачи: текущий статус, владелец, дедлайн, следующее действие
• История: полная стенограмма и короткая скользящая сводка

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

Пример для поддержки делает это конкретным. Если один агент говорит: «Клиент раздражён и, наверное, хочет возврат», это не факт. Факт — «Клиент спросил про неудачную оплату». Состояние задачи — «billing review open». История хранит точную формулировку. При смене модели такое разделение помогает новому агенту не терять опору.

Постройте API общего хранилища памяти

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

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

API должен обеспечивать единую схему для всех провайдеров. Держите её простой. Факт — это факт, задача — это задача, событие — это событие, независимо от того, пришёл ли запрос от Claude, GPT или открытой модели. Если одна модель возвращает длинный прозаический текст, а другая — плотный JSON, нормализуйте оба перед сохранением.

Храните подсказки, инструкции и правила памяти в своей системе, а не в панели провайдера. Тогда команда сможет вести версии, проверять изменения и применять одни и те же правила везде. Это и есть vendor‑neutral agent memory на практике.

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

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

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

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

Начните с малого. Если пытаться придумать идеальную схему с первого дня, вы потратите время и всё равно упустите что‑то, что реально нужно пользователям.

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

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

Рано выберите стабильные ID. Дайте каждому пользователю, задаче, проекту и разговору собственный ID и используйте эти ID повсеместно. Это звучит скучно, но предотвращает много путаницы, когда один провайдер называет что‑то "thread", а другой — "session".

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

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

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

Держите историю отдельно от активного состояния. История нужна для обзора. Активное состояние помогает агентам действовать сейчас.

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

Пример: команда поддержки

Входящая поддержка наглядно показывает смысл vendor‑neutral agent memory. Клиент пишет и просит вернуть деньги, потому что заказ пришёл с опозданием и одного из товаров не было в посылке.

Первый агент читает письмо и сохраняет факты в общую запись, вместо того чтобы запихивать их в подсказку и надеяться, что следующая модель всё запомнит. Он сохраняет номер заказа, ID клиента, причину возврата, недостающий товар, заявленный срок и тон сообщения клиента. Также открывается задача со статусом типа "awaiting order check".

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

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

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

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

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

Вот смысл слоя памяти агента. Модели могут меняться. Запись дела остаётся на месте, и команда продолжает работу.

Ошибки, которые ломают переносимость

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

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

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

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

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

Несколько полей предотвращают много проблем: source, owner, timestamp, verification status и version. Без них память превращается в слухи.

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

Проверки перед сменой провайдера

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

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

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

Потом прервите одного агента посередине обновления. Общая запись должна остаться целой: либо в старом состоянии, либо в новом, но не в наполовину записанном виде.

Также полезно намеренно внести одну неверную деталь в систему, например план клиента или дедлайн проекта. Кто‑то из команды должен суметь быстро её исправить без редактирования подсказок или настроек модели.

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

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

Если она этого не делает, у вас не vendor‑neutral agent memory. У вас стенограмма, которая работает только с привычками одной модели.

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

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

Выберите один рабочий процесс, который каждую неделю теряет время, и начните с него. Хорошие кандидаты — support triage, sales follow‑up или передача багов из чата в трекер. Если процесс уже приводит к потере контекста, повторным вопросам или ручному коп‑пейсту, это хорошее место для испытания vendor‑neutral agent memory.

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

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

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

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

Если нужна внешняя помощь, Oleg Sotnikov at oleg.is работает как fractional CTO и консультант для стартапов и небольших компаний. Он помогает командам проектировать практичные AI‑ориентированные рабочие процессы и общие настройки памяти, которые переживут реальные смены провайдеров, а не только демо.