Агент, который сам решает, когда почистить память

Контекстное окно — ресурс, из-за которого агент рано или поздно упирается в потолок: чем длиннее сессия, тем больше context rot и тем выше счёт за токены. Большинство инструментов вроде Claude Code и Codex решают это по-простому — жёсткий порог, после которого срабатывает автокомпактация. IndyDevDan в свежем devlog предложил другой подход: самокомпактация контекста агента, когда решение о сжатии памяти принимает не харнесс по таймеру, а сам агент — на основе собственного самонаблюдения за контекстом.

Почему автокомпактация по умолчанию — не предел

Автокомпактация claude code и аналогичные механизмы в Codex работают честно, но негибко: один порог, один зашитый промпт сжатия, никакой возможности повлиять на момент и форму компактации. Для короткой интерактивной сессии этого достаточно. Но как только агент переходит в режим out-of-loop — работает часами без человека, как в сварм-системах на десятки и сотни параллельных агентов, — негибкость превращается в прямые издержки: либо агент сжимается слишком рано и теряет полезный контекст, либо слишком поздно и упирается в лимит модели.

Самокомпактация контекста агента: как это устроено

В основе решения — собственный инструмент self-compact, который агент может вызвать сам, плюс три уровня порогов: notice (мягкое уведомление), warning (агент обязан сжаться в ближайшее время) и force (жёсткий обрыв, харнесс не даёт вызывать другие инструменты, пока не пройдёт компактация). Каждому порогу соответствует свой промпт — никакого зашитого дефолта, всё переопределяется вручную. У Pi coding agent, в отличие от Claude Code, это можно сделать: перезаписать системное сообщение компактации своим текстом.

Отдельная деталь — note to self: при компактации агент не просто получает сжатую сводку истории, а сам оставляет себе заметку с целью, текущим статусом и следующим шагом, которая добавляется поверх стандартной суммаризации. Это мелочь, которая ощутимо повышает связность работы агента после каждого цикла сжатия.

Harness engineering вместо готового рецепта

Ключевая мысль devlog — не сам факт компактации, а то, что она стала объектом harness engineering агентов: инженер контролирует пороги, тексты промптов, интерфейс (полоса контекста с тремя отметками) и команды ручного вмешательства (посмотреть статус, форсировать компактацию, обычный /compact). План строился по схеме plan → build → verify с явным разделом «как вас будут оценивать» — приём, который заставляет модель следовать рубрике почти как при обучении с разметкой.

Что показал эксперимент с тремя моделями

Автор запустил одну и ту же спецификацию на трёх связках агент-модель: Codex с GPT-6 Astra, Pi coding agent с Fable 5.1 и с GLM 5.2. Результат разошёлся сильно: GLM 5.2 забуксовал в 98% контекста и не довёл задачу до конца — живая иллюстрация того, зачем нужна самокомпактация для долгоживущих агентов. Codex справился за 21 минуту против 50 у Fable 5.1, использовав в разы меньше токенов, но Fable писал заметно более качественные компактационные промпты — как более сильный «промт-инженер» для самого себя.

Кому это пригодится

Практический смысл — не в конкретном коде из видео, а в самой идее: если вы строите долгоживущих агентов или свармы, управление контекстным окном ИИ-агента — не второстепенная деталь, а рычаг, который напрямую бьёт по стоимости и качеству результата. Возможность переопределить промпт компактации и дать агенту собственный инструмент для этого есть не во всех харнессах (в Claude Code это сделать нельзя, в Codex и Pi coding agent — можно), и это стоит учитывать при выборе инструмента для автономных, out-of-loop сценариев.

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