Сжатие памяти AI-агентов теряет до трети правил задачи, но бенчмарки это прощают

Когда AI-агент работает над задачей несколько часов — скажем, пишет код или пытается воспроизвести научную статью — он рано или поздно забивает всё доступное контекстное окно: и переписку, и вызовы инструментов, и результаты их работы. Чтобы продолжить, разработчики агентских систем вроде Claude Code, Codex CLI, Cursor или OpenCode используют приём под названием «сжатие контекста» (compaction): модель просят кратко пересказать всё, что было сделано, старую историю стирают и продолжают работу с этим пересказом. Проблема в том, что пересказ по определению теряет детали — и неясно, что именно теряется и насколько это критично. Именно это решили проверить исследователи из Max Planck Institute for Intelligent Systems Сахар Абдельнаби и Максим Андрющенко.

Для чистоты эксперимента они зафиксировали один и тот же инструмент-«обвязку» для агентов — открытый OpenCode, — чтобы разница в результатах не объяснялась особенностями разных программных платформ. Внутри OpenCode они реализовали пять разных способов сжатия контекста и протестировали четыре топовые модели — Claude Opus 4.6, GPT-5.3-Codex, GPT-5.4 и Gemini 3.1 Pro Preview — на трёх длинных практических заданиях: PaperBench (воспроизвести научную статью с ICML по описанию, без доступа к коду авторов), ProgramBench (написать с нуля консольную утилиту, имея только готовый исполняемый файл-образец и документацию) и PostTrainBench (обучить и доучить небольшую нейросеть на одной видеокарте за 10 часов).

Окно контекста решает всё, а метод сжатия — почти ничего

Главный вывод касается двух моделей с окном в миллион токенов — Claude Opus 4.6 и GPT-5.4. У них результат практически не менялся, сжимали ли память каждые 160 тысяч токенов или каждые 380 — разница в пределах статистической погрешности. А вот GPT-5.3-Codex, у которой окно всего 400 тысяч токенов, при раннем и частом сжатии на задаче PaperBench показывала заметно хуже результат: 0,38 балла при пороге 160 тысяч токенов против 0,60 при пороге от 260 тысяч и выше — то есть почти вдвое хуже. На задаче с написанием кода (ProgramBench) такой разницы не было, а на PostTrainBench результаты скакали слишком сильно, чтобы делать выводы.

Отдельно проверили, помогает ли какая-то более «умная» стратегия сжатия по сравнению с обычным пересказом своими словами. Испытали пять вариантов: обычное саммари; обычное саммари плюс чистка старых результатов вызова инструментов; сохранение полной истории в отдельный файл на диске перед сжатием (чтобы теоретически можно было вернуться и всё перечитать); удаление из истории блоков с рассуждениями модели перед составлением саммари; и, наконец, составление саммари более дёшевой моделью — Claude Haiku 4.5 вместо основной модели-исполнителя.

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

Куда пропадают правила игры

Самая тревожная находка касается не производительности, а безопасности. В задаче ProgramBench агенту в самом начале дают три жёстких правила: не копировать и не подключать исходный код эталонной программы, не выходить в интернет (в частности, чтобы не скачать оригинальный код) и писать действительно оригинальную реализацию, а не обёртку вокруг готового решения. Эти правила существуют только в тексте первого сообщения — и если саммари при сжатии их не повторит, агент о них просто забудет, в отличие от цели задачи и своего прогресса, которые можно перечитать из файлов на диске.

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

Почему текущие тесты это не замечают

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

Практический вывод для команд, строящих агентские системы: если задача длинная и важны жёсткие ограничения (не трогать прод-базу, не выходить в сеть, не удалять файлы без подтверждения), нельзя рассчитывать, что обычное саммари их сохранит — стоит либо явно фиксировать такие правила отдельно от общей истории и перечитывать их при каждом сжатии, либо выбирать модель с запасом по контексту и сжимать как можно реже.