Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Сжатие файлов сокращает счёт многошагового агента для программирования слабее, чем обещает степень сжатия. В препринте Paritok, который не прошёл рецензирование и приводит числа из замеров самих авторов, фильтрация описаний инструментов оказалась единственным стабильно выгодным приёмом, а сжатие содержимого начало выигрывать лишь по мере накопления истории. Значит, шлюз для экономии токенов стоит проектировать вокруг структуры запросов, а не только вокруг модели-компрессора.
Счёт растёт из повторно отправленного контекста
На каждом ходу агент передаёт основной LLM не только новую команду. В запрос снова входят системные инструкции, описания доступных инструментов, история диалога, прочитанные файлы и результаты команд. По мере работы этот префикс растёт и многократно отправляется модели.
Провайдер может учитывать повторно отправленный префикс как чтение из кэша. У Claude Sonnet такие токены стоят примерно в десять раз дешевле нового ввода, но длинная сессия всё равно оплачивает их на каждом ходу. Поэтому число ходов влияет на итоговый счёт сильнее, чем степень сжатия отдельного файла.
Paritok разделяет экономию на три независимых механизма. Первый оставляет в запросе полные описания только нужных инструментов. Второй сжимает чтения файлов и вывод команд. Третий пересказывает старую историю, когда она приближается к пределу контекстного окна.
Эти механизмы решают разные задачи. Фильтрация инструментов удаляет постоянный блок на каждом ходу. Сжатие содержимого уменьшает небольшую часть текущего запроса, но эта часть остаётся в истории и повторно передаётся дальше. Пересказ истории прежде всего позволяет продолжить сессию, а не гарантирует минимальную стоимость.
Фильтрация даёт сразу, сжатие — после нескольких ходов
В агенте с большим набором инструментов фильтрация удаляла от 21 до 57 тысяч токенов на каждом типичном ходу. Экономия растёт линейно: каждый новый запрос снова не содержит тот же лишний блок. Для агентов с коротким списком инструментов эффект почти исчезает, а основные команды выполнения нельзя скрывать даже временно.
Сжатие чтений файлов экономило около 2% кэшированного префикса на отдельном ходу. Однако сжатый фрагмент остаётся в истории, поэтому каждый следующий запрос повторно экономит токены на всех предыдущих чтениях. Накопленный результат в эксперименте приближался к формуле 3350 × N², где N — число ходов, и догонял фильтрацию примерно на шестом ходу.
Такой рост ограничивает контекстное окно: когда клиент сокращает старую историю, прежние чтения перестают накапливаться. Кроме того, агент иногда запрашивает исходный фрагмент без сжатия. Paritok возвращает его только для нужного хода, а затем снова заменяет ссылкой, поэтому возврат съедает экономию одного сегмента, но не раздувает все последующие запросы.
Замеры охватывали Claude Code с Claude Sonnet и Codex с GPT-5, набор Python-репозиториев и компрессор Paritok-4B. Квадратичную зависимость получили на короткой последовательности из пяти ходов, поэтому её форма объясняется устройством накапливаемой истории, а конкретный коэффициент относится к этой конфигурации.
Результат SWE-bench Lite здесь отвечает на другой вопрос. Однократный тест показывает, сохранила ли модель достаточно смысла после сжатия, но в нём нет повторной отправки истории, большого блока инструментов и возврата к точным байтам файла. Поэтому качество компрессора в SWE-bench нельзя превращать в обещание такой же экономии для многошагового агента.
Что менять в архитектуре агента
Сначала стоит сократить описания инструментов. Это предсказуемая экономия для агентов с большим набором API и подключёнными серверами MCP. Выбор инструментов нужно фиксировать на всю сессию, чтобы блок не менялся и продолжал попадать в кэш. Команды оболочки, применения патчей и другие базовые средства выполнения должны всегда оставаться доступными.
Сжатие файлов имеет смысл как ставка на длинную сессию. Оно подходит для аудита репозитория, поиска причин ошибки и ответов по большой кодовой базе, где прочитанные фрагменты долго остаются в истории. В коротком исправлении выигрыш мал, а частые запросы исходного текста постепенно его съедают.
Возврат оригинала нельзя убирать ради экономии. Без точного текста агент начинает повторно читать файлы через команды, искать нужные строки и делать дополнительные ходы. Лучше сохранять исходные байты вне контекста, выдавать один нужный фрагмент по запросу и отдельно измерять частоту таких возвратов.
Пересказ истории нужен для вместимости. Он становится полезен, когда задача упирается в предел контекстного окна. Для обычной сессии фильтрация инструментов и контроль числа ходов дадут более понятный результат.
При проверке собственной реализации нужно включать механизмы по одному, фиксировать набор инструментов и брать расход токенов из отчёта провайдера с учётом тарифа кэша. Сравнение единичных запусков ненадёжно: поведение агента меняет число ходов и легко перекрывает небольшой выигрыш от сжатия файлов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
