Оркестр агентов: Архитектура, память и экономика мультиагентных систем

Почему нельзя хранить память агента только в горячей памяти (КV Cache)?

Три причины, почему это ловушка:

Привязанность к конкретному инстансу

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

Замедление при длинных диалогах

Горячая память линейно растёт с каждым новым сообщением. При 100 тысячах токенов (примерно 150 страниц текста) инференс - то есть процесс генерации ответа - замедляется в 3–5 раз. Вы будете ждать ответа по 30 секунд вместо 5.

Агенты не видят горячую память друг друга

Агент А «запомнил», что клиент Иван обещал оплатить завтра. Агент Б об этом не знает - потому что его горячая память отдельная. В мультиагентной системе это катастрофа.

Живой пример

Два агента: Планировщик (составляет график) и Отправитель (шлёт напоминания). Планировщик запомнил: «Встреча перенесена на 15:00». Он перезапустился через минуту - и забыл. Отправитель напоминает клиенту о встрече в 12:00, как в старом расписании. Клиент приезжает рано, злится. А виновата горячая память.

Вывод

горячая память (KV Cache) годится только для текущего шага рассуждения - например, чтобы помнить, что вы только что сказали внутри одного вызова модели. Для передачи состояния между агентами она не годится.

Уровень 2: Тёплая память (Operational State)

Где живёт

PostgreSQL (обычная реляционная база данных), MongoDB (документо-ориентированная БД), Vector DB в горячем слое (о векторных БД - чуть позже).

Время жизни: дни - недели.

Что хранит

Историю текущей сделки (шаги, кто одобрил, когда отправлено письмо), статус заявки («в обработке», «отправлено юристу»), последние 10 взаимодействий с клиентом.

Цена доступа: низкая - миллисекунды.

Риск

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

Инженерный совет

Используйте транзакционные базы (где операции «всё или ничего») для состояния процессов. Векторные базы здесь нужны только для быстрого поиска похожих кейсов - не пишите туда всю текущую болтовню агентов.

Расшифровка

Транзакционная база - это как банковская проводка: либо деньги переведены и у вас и у получателя всё сошлось, либо операция отменена целиком, без «половинчатых» состояний. Для статусов заявок это критично.

Уровень 3: Холодная память (Long-Term Semantic Memory)

Где живёт

Векторная база данных в холодном слое (например, Pinecone, Qdrant, или просто S3-хранилище с индексами), графовые базы данных (о них - на следующем уровне), S3 (облачное объектное хранилище, как Яндекс Облако или AWS S3) с отдельной индексацией.