Context Compaction

Суть

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

Общее у всех форм одно: это фоновая работа обслуживания памяти, а не шаг обработки запроса.

Профилактика сильнее уплотнения

Compaction отвечает на вопрос «что делать, когда transcript уже вырос». Для длинной процедуры есть более сильная форма: не использовать transcript как состояние вообще. В State Centric Execution следующий вызов собирается из неизменной процедуры, ограниченного канонического state и последнего наблюдения; полная траектория остаётся во внешнем журнале.

Это не два названия одного приёма. Rolling summary всё ещё реконструирует состояние из текста и наследует ошибки пересказа; state-centric цикл обновляет типизированный объект через валидированный patch. Compaction остаётся нужен для открытых рабочих заметок и задач, где заранее неизвестно, что окажется важным, но перестаёт быть единственной защитой от растущей истории.

Между полным state и compaction есть ещё один слой: Agent Status Bar добавляет у хвоста уже вычисленные агрегаты, не удаляя историю. Он становится compaction только в момент, когда сырые записи начинают заменяться этой проекцией. Такой переход допустим лишь после теста достаточности: статус отвечает на заранее предусмотренные вопросы, а неизвестная будущая деталь в него не попадёт.

Пять действий с рабочей сессией

Рост контекста не всегда требует compaction. У оператора есть пять разных решений:

Практический тест для субагента: «понадобится ли мне этот вывод инструмента снова или только заключение?» Второе оправдывает изоляцию.

Автоматическое уплотнение срабатывает у порога окна — в момент, когда длинная история уже сильнее всего подвержена context rot. Поэтому для предсказуемой длинной работы лучше сжимать до порога и вместе с явным следующим намерением. Если будущая ветка ещё неизвестна, ранняя сводка может выбросить именно то, что понадобится; тогда новая сессия с отобранным brief честнее автоматического пересказа.

Два слоя данных, которые нельзя путать

Уплотнение создаёт границу безопасности, и проходит она между:

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

Практически это значит, что после уплотнения исполнение продолжается по структурированному состоянию, а сводка идёт в подсказку как справочный материал (Approval Path, Agent Control Plane).

Не всё обновление памяти живёт в горячем пути

Один из самых полезных архитектурных сдвигов. В начале почти все пытаются сделать память «сразу готовой»: агент что-то увидел — немедленно переписал сводки, обновил профиль, сохранил знание. Это и дорого, и рискованно (Memory Write Policy).

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

Compaction не управляет всем внешним состоянием

У длинного агента за пределами окна могут жить переменные REPL, большие результаты инструментов и отдельные сессии субагентов. Их не освобождает сводка transcript: текст стал короче, но процесс, handle или объект продолжает занимать ресурс.

Поэтому рядом с compaction нужен другой цикл — agentic garbage collection: перечислить внешнее вычислительное состояние, сохранить необходимое, выгрузить idle-сессии и удалить временное. Долговечные skills и memory проходят уже третий цикл — versioned refinement. Разделение трёх операций и уровней состояния — в Agentic Context Management.

Сводка сохраняет происхождение

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

Почему плохая сводка не ловится вычиткой

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

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

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

Передача контекста субагенту — тоже уплотнение

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

Практическая метрика — размер переданного контекста рядом с причиной делегирования и итоговым качеством. Если пакет почти равен исходному диалогу, система не разделила работу, а размножила дорогой контекст (Multi Agent Systems).

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

Целевая полоса заполнения вместо уплотнения по факту

Уплотнение выше описано как реакция: окно заполнилось — разгружаем. Есть более строгая постановка, при которой весь рабочий процесс проектируется вокруг заполнения, а не вокруг задачи: заполнение удерживается в полосе порядка 40–60% и не доводится до порога срабатывания автоматики.

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

Практическая форма приёма: после каждой проверенной фазы статус уплотняется обратно в файл плана, а не в новый документ. Это существенно — иначе через три фазы появляется три сводки, между которыми надо выбирать, и вопрос «что считать текущей истиной» возвращается (State Centric Execution).

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

Что именно оптимизируется, если оптимизировать окно

Полоса заполнения отвечает только на вопрос «сколько», а решения приходится принимать про «что». Тот же источник раскладывает качество окна на четыре оси — правильность, полнота, объём, траектория — и, что полезнее, выстраивает порчу по тяжести:

1. неверные сведения — худшее;
2. отсутствующие сведения;
3. лишний шум.

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

Четвёртая ось — траектория — отличается от остальных тем, что не про содержание, а про порядок: окно, в котором верные сведения лежат в порядке, подсказывающем неверный следующий шаг, испорчено, хотя каждая его часть правильна (Paraphrase Drift).

Уборка не заменяет профилактику

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

Отсюда парность приёмов: уплотнение — уборка, ограничение вывода инструмента — профилактика (Bounded Tool Output). Одно без другого не работает: без уборки растёт хвост, без профилактики каждый отдельный вызов может испортить окно за раз.

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

Связано с

• Bounded Tool Output — профилактика, без которой уборка не справляется
• Agent First Repository — постепенное раскрытие в масштабе репозитория: карта вместо инструкции
• Agent Retrieval Policy — вторая половина цикла обслуживания памяти
• Memory Write Policy — что вообще попадает в фоновый конвейер
• Agent Memory — сводки против указателей как способ экономить контекст
• Context Layers — слои подсказки, которые уплотнение разгружает
• Approval Path — почему подтверждение живёт вне текста сводки
• Multi Agent Systems — передача контекста между агентами
• Durable Execution — контрольные точки как часть управляющего состояния
• Paraphrase Drift — почему каждое сжатие усиливает утверждение и как это ловить
• State Centric Execution — профилактика: следующий шаг строится по state, а не по сжатому transcript
• Agent Status Bar — code-maintained проекция состояния: добавление агрегатов до удаления сырой истории
• Agentic Context Management — где живут данные вне окна и чем compaction отличается от очистки вычислительного состояния