Как работает Compaction в Builder?
Сегодня выпустил обнову 0.10.0 Builder CLI, и в ней заехали серьёзные улучшения для компакшена и эффективности кэширования.
Почему локальный компакт лучше нативного
По умолчанию, когда вы проходите онбординг, Builder рекомендует локальный проприетарный компакт, который намного более подробный, чем нативный. Нативный компакт всё ещё можно выбрать или настроить в файле конфигурации, если ваш провайдер его поддерживает. Я рекомендую локальный - вот почему.
Алгоритм нативного компакта Claude Code и Codex уже давно реверс-инженернули, и в них буквально 5-7 строчек инструкций в духе: “сделай описание, что за работа там камиты ну красиво короче чтобы было опиши внатуре”. Я сам реверс-инженерил нативный компакт, чтобы убедиться в этом и взять оттуда всё лучшее.
Единственное реальное преимущество нативного компакта - сохранение reasoning-трейсов из предыдущей переписки, но этого можно добиться другим способом. Локальный компакт в Builder использует детально проработанный промпт, который я полировал несколько месяцев, который покрывает все важные моменты, влияющие на продолжение работы агента. Благодаря этому компакт может переживать буквально десятки сессий без потери общего контекста задачи. У меня есть большие рефакторинги, которые автономно работали сквозь больше чем 37 компактов подряд, всю ночь - без каких-либо проблем.
Весь код Builder open source, так что промпт можно посмотреть. Но без улучшений harness-а, которые я также провёл для компакта, и без возможности этот промпт менять в официальных harness-ах, это мало чем пригодится.
Пример: Билдер работал сквозь 22 компакта
Компакт в Builder лучше оригинального ещё и потому, что он сохраняет всю историю переписки, сколько бы компактов у вас ни было - но модель при этом видит только свежую историю. То есть вы можете в любой момент откатиться на 19 компактов назад, сделать новую переписку, форкнуть её и пойти в какую-то отдельную ветку. Более того, в отличие от некоторых провайдеров, Builder сохраняет историю кэша, поэтому обходится намного дешевле. Это, конечно, компенсируется тем, что мой компакт более подробный - но, как я уже говорил, главная цель Builder - это качество, а не ценник или скорость. В будущих версиях планирую оптимизировать компакт так, чтобы он не содержал лишнего и был дешевле, чем у других провайдеров.
Проактивный компакт - новое в 0.10.0
Помимо самого промпта, компакт в Builder проактивный. В версии 0.10.0 заехал первый экспериментальный инструмент, который позволяет модели самостоятельно решать, когда выполнять компакт. Модель в Builder знает о том, что у неё ограниченная память, знает, сколько пространства осталось, знает, когда нужно делать чекпоинты - и получает уведомление об оставшемся контексте.
Включить через:
[tools]
trigger_handoff = trueПри этом это реализовано не так, как в Claude Code, где это дико пугает модель и она отказывается работать. И не так, как в Codex, где он постоянно останавливается “передохнуть”. В Builder это просто один из автономных процессов агента, который не приводит к ненужным паузам или ухудшению качества работы!
Проактивный компакт предотвращает потерю изменений, поломку билдов, тестов или перезаписывание ваших решений в ситуации, когда у модели заканчивается контекст и компакт вызывается в неудобный момент - из-за чего она забывает, что у неё частично отредактирован файл или реализована спецификация. На моих тестах модель сама знает, когда ей нужно делать хендофф следующему агенту, и подготавливает рабочее пространство к этому, вследствие чего коллаборация между агентами сквозь компакты намного лучше.
Плюс основной агент может передать так называемое письмо в будущее следующему агенту. Общий промпт для компакта, особенно нативный, часто не содержит специфических вещей из внутреннего мышления модели - того, о чём она знает, но ещё не успела воплотить в жизнь. Так как reasoning-трейсы не сохраняются, моё решение позволяет модели самостоятельно их сохранить и передать дальше.
Билдер подготовился к компакту, передал инструкции по сохранению важной инфы, вызвал нативный компакт, и продолжил работать
Pre-compact перед началом задачи
Ещё одно UX-улучшение, которого нет в других harness-ах: pre-compact перед началом задачи. Harness постоянно смотрит при отправке любой команды агенту, хватит ли контекста для выполнения задачи, и на основе эвристического анализа решает: стоит ли выполнять задачу сейчас, или сначала нужно сделать компакт и потом перейти к следующей части плана.
Таким образом ваша команда сохраняется напрямую, не проходит через цикл суммаризации LLM-кой, не тратит токены впустую, и агент начинает работу с чистым контекстом без галлюцинаций. Это позволяет просто общаться с моделью, не думая о компакте - harness всё решает за вас вместе с моделью, освобождая от необходимости вручную вызывать slash-команды или беспокоиться о начинающейся “тупой зоне”. Это включено по умолчанию.
Очереди сквозь компакты
Последнее улучшение, которое я очень люблю - поддержка очередей сквозь компакты. Ваши промпты, slash-команды и любые процессы, включая фоновые субагенты, могут переживать компакты и переходить во владение следующему агенту без каких-либо потерь.
Например, вы можете поставить в очередь: сразу после выполнения задачи - компакт с кастомным промптом, затем slash-команду, и при этом запустить три фоновых субагента. Когда компакт завершится, модель автоматически получит ваш промпт, summary, послание от предыдущего агента, вашу slash-команду и вывод всех трёх субагентов - и продолжит выполнение с этой точки, как будто ничего не произошло. Никакой потери информации, никаких остановок, никаких ограничений на то, что можно делать во время работы агента.
Это сильно упрощает workflow: дать агенту задачу, сразу назначить компакт, и после этого сказать открыть pull request и пофиксить в нём комменты с фоновыми агентами для планирования и для выполнения. Такого не встретишь ни в одном harness-е из коробки. Может быть, какие-то позволяют это сделать хуками, но преимущество Builder в том, что это всё реализовано нативно - с максимальным уровнем интеграции из коробки.