Контекст растёт квадратично. Окно конечно. Lost-in-the-middle реально. Сегодня — четыре фундаментальных способа решить эту проблему. У каждого свой набор компромиссов, и ты должен уметь выбирать осознанно.
Когда длинный агент или длинный диалог упирается в окно контекста или в стоимость — есть четыре основные стратегии: обрезка (выбрасываем старое), суммирование (пересказываем своими словами), иерархия (свежее — детально, старое — сжато), внешняя память (выносим за пределы контекста). Это не «лучшее» и «худшее» — это разные компромиссы между качеством, ценой и сложностью реализации. AI-инженер выбирает под задачу.
Не всякий агент или чат нуждается в сжатии. Если задача решается за 5 итераций и итоговый массив — 20K токенов, тебе нечего оптимизировать. Сжатие становится обязательным, когда хотя бы один из трёх порогов сработал:
Если ни один порог не сработал — лучше ничего не сжимай. Любая оптимизация контекста — это потеря информации, и за это всегда платишь качеством, пусть и немного.
Сжатие контекста — это не оптимизация. Это вынужденная компрессия с потерями. Сжимать раньше времени — портить систему без причины.
Все способы сжатия истории сводятся к этим четырём — или их комбинациям. Идут от самого простого к самому сложному.
Тупо отбрасываем самое старое
Самый простой подход. Когда контекст превышает заданный лимит (например, 50K токенов или 20 последних сообщений), берём массив и отрезаем у него хвост из начала. То, что осталось — это скользящее окно последних N сообщений.
Обычно system и первое user-сообщение всё-таки сохраняют — это «фундамент» задачи, без которого агент потеряется. Режется именно середина-начало истории действий.
Пересказываем старое своими словами
Вместо того чтобы выбрасывать старые сообщения, мы их пересказываем коротко. Когда история переваливает за лимит, запускается дополнительный LLM-вызов: «вот история диалога из 20 шагов, перескажи её в 200 токенов, сохрани главные факты и решения». Получаешь короткое summary, кладёшь его в массив вместо вырезанной истории, продолжаешь работу.
Часто реализуется как «rolling»: при каждом превышении порога — переписывается заново. Старое summary + новые сообщения → новое summary.
Свежее в полном виде, давнее — в сжатом
Гибрид первых двух. Делим историю на «зоны»:
Иерархия имитирует то, как работает человеческая память: недавнее помнится в подробностях, давнее — в общих чертах. Дороже первых двух в реализации, но даёт лучший баланс.
Выносим из контекста, возвращаем по запросу
Самый мощный, но и самый сложный подход. Старая история не пересказывается и не выбрасывается — она сохраняется во внешнее хранилище (файлы, база данных, векторная БД). В контексте остаётся только короткий индекс: «в файле notes.md лежат заметки по задаче N, в файле research.md — три прочитанных статьи».
Когда модели нужна конкретная информация — она вызывает инструмент «прочитать файл» или «искать в памяти». Возвращает себе нужный кусок ровно тогда, когда он понадобился, и только то, что понадобилось.
Это уже не «сжатие истории», а полноценная архитектура памяти. К ней мы подробно вернёмся в Кластере 03.
На практике в серьёзных системах обычно комбинируют несколько стратегий: иерархия + внешняя память — типичная пара для длинноживущих агентов.
Условная матрица, по которой можно ориентироваться при первом выборе:
Есть два подхода ко времени сжатия:
Eager обычно лучше для UX (равномерная скорость), lazy проще в реализации. Для большинства систем — eager с порогом ~70% от окна.
Когда делаешь суммирование — можно вызвать ту же модель, что и для основной работы, либо отдельно — маленькую и дешёвую (gpt-4o-mini, claude-haiku).
Маленькая модель для сжатия — почти всегда правильно. Суммирование — несложная задача, маленькие модели справляются. А разница в стоимости огромная: каждое сжатие — это дополнительный LLM-вызов поверх основной работы. Делать его на gpt-5 — выкидывать деньги.
Наивная обрезка «выкини N токенов с начала» может срезать system prompt — и агент потеряет «правила игры»: описание инструментов, ограничения, формат. На следующей итерации он перестанет вызывать инструменты или начнёт делать это неправильно.
Правильная реализация всегда: «system всегда остаётся, режутся только assistant/tool/user сообщения из середины». Это не «удобная привычка» — это обязательный инвариант.
Суммируешь 30 предыдущих ходов в 200 токенов — и теряешь конкретику. Через 2 хода агент пытается вспомнить «какой именно URL мы открывали» — а в summary этого нет, написано «изучали статьи».
Лечение: в инструкции суммаризатору явно перечислять, что обязательно сохранять: имена, URL, числовые значения, конкретные цитаты. «Сохрани все упомянутые URL и числа дословно» — простое правило, которое спасает от 90% потерь.
«Раз суммирование помогает — буду делать на каждом шаге». Стоп: каждое суммирование — это отдельный LLM-вызов. Если ты делаешь его на каждой из 20 итераций, ты вместо 20 запросов делаешь 40. Это две агентских задачи параллельно, по цене.
Правильный паттерн: порог. Суммирование запускается только когда контекст реально подпёрся к лимиту. Большую часть времени работаешь без суммирования.
Сжал историю — оригинал выкинул. Через час пользователь сказал «а почему ты тогда выбрал то-то?» — и ты не можешь ответить, потому что в текущем контексте только summary.
Привычка: полная история живёт в логах (вне контекста модели), контекст работает со сжатой версией. Сжатие — для модели, лог — для тебя. Это два разных хранилища.
Веди диалог 50+ ходов на одну тему. Время от времени проверяй: помнит ли ассистент детали, которые ты упомянул в начале? В какой-то момент заметишь — «забыл». Это сработала встроенная стратегия обрезки/суммирования провайдера. Поэкспериментируй: после 30 ходов спроси конкретный факт из 5-го хода. Это даст тебе живое ощущение, как работают эти стратегии в продакшен-системах.
Возьми разговор с LLM из 10-15 ходов на сложную тему. Вручную напиши его summary в 200 токенов: что обсуждали, к чему пришли, какие конкретные факты выяснились. Затем — открой новый чат, вставь только этот summary и попроси «продолжить с этой точки». Сравни поведение с тем, как бы вёл себя ассистент, у которого был бы полный контекст. Какие нюансы потерялись?
Представь, что строишь агента «помощник для подготовки к собеседованиям»: он работает над одним собеседованием 2-3 часа, делает поиск в интернете, читает компании, генерирует вопросы, готовит ответы. Распиши на бумаге: что у этого агента «свежее, среднее, старое»? Какая информация должна точно остаться в полной детализации? Что можно сжать до summary? Что вынести в файл? Это сильно прокачает интуицию по архитектуре памяти.