Сжатие контекста стирает треть античит-правил в ProgramBench

Длинные агентные задачи всё чаще не помещаются в контекстное окно, и каркасу агента приходится освобождать место: сжимать историю, выкидывать лишнее, продолжать работу по краткому конспекту. Этот приём называется компакцией, и он есть практически в любом кодинг-агенте. Систематически его на frontier-моделях и реалистичных задачах почти не проверяли: прежние работы гоняли небольшие открытые модели на игрушечных или синтетических траекториях. Группа Jeanne Salle с четырьмя соавторами закрыла этот пробел и получила результат с двойным дном. Бенчмарки компакцию почти не замечают, а вот реальная работа замечает.

Как поставили эксперимент

Авторы зафиксировали агентный каркас OpenCode и реализовали внутри него пять стратегий компакции. Затем прогнали три frontier-модели через три длинных бенчмарка. Два из трёх — модели с контекстом в 1 млн токенов, третья — GPT-5.3-Codex с самым маленьким окном в выборке. Варьировали порог, при котором срабатывает сжатие.

• Каркас: OpenCode, единый для всех прогонов.
• Стратегии: пять вариантов компакции, базовой считается самосаммаризация, когда модель сама пересказывает свою историю.
• Модели: две с окном 1M и GPT-5.3-Codex.
• Бенчмарки: PaperBench, ProgramBench, PostTrainBench.
• Дополнительный датасет: реальные пользовательские сессии SWE-chat.

Где компакция безопасна, а где нет

Для моделей с окном 1M порог сжатия не влияет на результат заметным образом. У GPT-5.3-Codex картина другая: на PaperBench при низких порогах качество падает, на PostTrainBench эффект слабее и менее определённый. Логика простая: чем меньше окно, тем чаще и агрессивнее приходится сжимать, и тем больше накапливается потерь.

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

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

На реальных сессиях SWE-chat разрыв ещё заметнее. Инструкции о том, как агенту работать и чего не делать, отбрасываются примерно в 6 раз чаще, чем спецификации того, что нужно построить. Модель хорошо помнит цель и плохо помнит манеру работы: стиль, запреты, договорённости с пользователем.

Почему бенчмарки вводят в заблуждение

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

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