теория
У модели один вход — : всё, что она «знает» в момент ответа. Промпт, история диалога, результаты инструментов — всё конкурирует за место в этом окне. Оно конечное и платное: каждый оплачивается на каждом вызове (кэширование префикса удешевляет повторную часть, но экономику не отменяет — и качеству длинного контекста не помогает).
Отсюда первая развилка — две памяти с разной механикой.
Короткая память — то, что лежит в окне прямо сейчас: текущий диалог, последние результаты инструментов. Быстро, точно — и дорого: чем длиннее контекст, тем дороже каждый шаг цикла.
Длинная память — то, что лежит вне окна, в обычном хранилище: факты о клиенте, прошлые обращения, знания. В окно попадает не целиком, а выборкой по релевантности: спросили про возврат — подгрузили правила возвратов и последний заказ, а не всю биографию.
Если это звучит знакомо — так и должно быть. Это рабочий набор и страничный кэш из модуля про базу: горячее — в дорогой быстрой памяти, остальное — на диске, и беда начинается, когда рабочий набор перестаёт влезать. С двумя поправками. Первая: у базы переполнение кэша роняло скорость, у модели длинный контекст роняет ещё и качество — факты из середины теряются, внимание размывается. Вторая важнее: промах кэша база замечает и идёт на диск, а модель «промаха» не видит — чего нет в окне, того для неё нет в мире, и ответ будет уверенным и без факта. «Page fault» (обращение к странице, которой нет в быстрой памяти) за модель делает оркестратор — если его спроектировали.
Поэтому память агента — это не свойство модели, а стратегия оркестратора: что подать целиком, что сжать, что вынести наружу и подгружать по запросу. Типовой набор: свежие реплики — дословно; старую часть диалога — в два абзаца; устойчивые факты — номер заказа, имя, адрес — в структурированное внешнее хранилище, откуда их достают инструментом. Каждый пункт — знакомый trade-off: точность против стоимости, свежесть против объёма.