Почему мои сессии OpenClaw сожгли 21,5 млн токенов за день (и что действительно помогло)
Автор оригинала: MOSHIII
Оригинал: Пегги, BlockBeats
Редакционная заметка: На фоне быстрого распространения приложений на основе агентов многие команды столкнулись с кажущимся парадоксом: система работает без сбоев, но стоимость токенов незаметно и постоянно растет. Анализ реальной рабочей нагрузки OpenClaw выявил, что причина взрывного роста затрат часто не связана с пользовательским вводом или выводом модели, а обусловлена игнорируемым повторным воспроизведением кэшированного контекста (cached prefix replay). Модель повторно считывает огромный объем исторического контекста при каждом вызове, что приводит к колоссальному потреблению токенов.
Статья на основе конкретных данных сессии демонстрирует, как крупные промежуточные результаты, такие как вывод инструмента, снимки экрана браузера и JSON-логи, постоянно записываются в исторический контекст и повторночитываются в цикле агента.
На основе этого случая автор предлагает четкую стратегию оптимизации: от проектирования структуры контекста и управления выводом инструментов до настройки механизма компактизации. Для разработчиков, создающих системы агентов, это не просто технический отчет об устранении неполадок, но и реальный способ сэкономить деньги.
Следует оригинальный текст:
Я проанализировал реальную рабочую нагрузку OpenClaw и обнаружил паттерн, который, как я считаю, узнают многие пользователи агентов:
Объем использования токена выглядит очень «активным»
Ответ тоже выглядит нормально
Но потребление токенов внезапно взорвалось
Ниже приведены структурный анализ, корневые причины и практические пути устранения для этого анализа.
Коротко
Самым большим драйвером затрат является не слишком длинное сообщение пользователя, а многократное воспроизведение огромного количества кэшированных префиксов.
Из данных сессии:
Общее количество токенов: 21 543 714
cacheRead: 17 105 970 (79,40%)
4 345 264 (20,17%)
92 480 (0,43%)
Другими словами: большинство вызовов стоят не обработки новых намерений пользователей, а повторного чтения огромного исторического контекста.
Момент «Подождите, как это могло произойти?»
Я первоначально думал, что высокий объем использования токенов обусловлен: очень длинными пользовательскими запросами, большим объемом генерируемого вывода или дорогими вызовами инструментов.
Но действительно доминирующей моделью является:
От нескольких сотен до нескольких тысяч токенов
cacheRead: при каждом вызове 170 000–180 000 токенов
То есть модель на каждом этапе повторно считывает один и тот же огромный стабильный префикс.
Диапазон данных
Я проанализировал данные на двух уровнях:
1. Журналы выполнения (runtime logs)
2. Журналы сессий
Следует отметить, что:
Журналы выполнения используются в основном для наблюдения за сигналами поведения (такими как перезагрузки, ошибки, проблемы с конфигурацией)
Точная статистика токенов взята из поля usage в файле JSONL сессии
Используемый скрипт:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
Сгенерированный аналитический файл:
tmp/session_token_stats_v2.txt
tmp/session_token_stats_v2.json
tmp/session_duplicate_waste.txt
tmp/session_duplicate_waste.json
tmp/session_duplicate_waste.png
Где фактически расходуется токен?
1) Концентрация сессии
Один сеанс потребляет значительно больше, чем другие:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19 204 645 токенов
Затем следует очевидное резкое падение:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1 505 038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649 584
2) Концентрация поведения
Токены в основном поступают из:
toolUse：16,372,294
стоп: 5 171 420
Проблема заключается в циклическом вызове инструментов, а не в обычном чате.
3) Концентрация времени
Пики токенов не случайны, а сосредоточены в несколько временных интервалов:
2026-03-08 16:00: 4 105 105
2026-03-08 09:00: 4 036 070
2026-03-08 07:00: 2 793 648
Что именно находится в огромном префиксе кэша?
Не содержание диалога, а в основном крупные промежуточные продукты:
Огромный блок данных toolResult
Длинные цепочки рассуждений / мыслительные процессы
Большой JSON-снимок
Список файлов
Захват данных браузером
Диалоги подагента
В максимальной сессии количество символов составляет примерно:
366 469 символов
assistant:thinking：331,494 символов
53 039 символов
Как только эти данные сохранены в историческом контексте, последующие вызовы могут повторно считывать их через префикс cache.
Конкретные примеры (из файла сессии)
На следующих позициях многократно появляются огромные блоки контекста:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
Крупный JSON-журнал шлюза (около 37 000 символов)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
Снимок браузера + безопасная упаковка (около 29 000 символов)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
Огромный список файлов (около 41 000 символов)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
session/status снимок состояния + крупная структура prompt (около 30 000 символов)
«Потери из-за дублирования контента» против «Нагрузки от повторного воспроизведения кэша»
Я также измерил долю повторяющегося содержимого внутри одного вызова:
Повторный коэффициент примерно: 1,72%
Действительно существует, но не является основной проблемой.
Настоящая проблема заключается в том, что абсолютный объем префикса кэша слишком велик.
Структура: огромный исторический контекст, повторное чтение при каждом вызове, сверху добавляется лишь небольшой объем новых данных
Таким образом, основное внимание при оптимизации следует уделять не дедупликации, а проектированию структуры контекста.
Почему цикл Agent особенно подвержен этой проблеме?
Три механизма взаимно дополняют друг друга:
1. Большое количество инструментов было записано в исторический контекст
2. Цикл инструментов создает большое количество коротких вызовов
3. Префикс меняется незначительно → кэш каждый раз читается заново
Если компактизация контекста не стабильно активируется, проблема быстро усугубится.
Наиболее важные стратегии устранения ошибок (по уровню влияния)
P0 — Не заполняйте долгосрочный контекст огромными выходными данными инструментов
Для вывода супербольшого инструмента:
- Сохранить краткое содержание + путь / ID цитирования
- Исходный payload записан в файл artifact
- Не сохраняйте полный исходный текст в истории чата
Ограничьте в приоритетном порядке эти категории:
- Большой JSON
- Длинный список каталогов
- Полный снимок браузера
- Полная расшифровка суб-агента
P1 — Убедитесь, что механизм компактификации действительно работает
В этих данных неоднократно возникают проблемы совместимости конфигурации: недопустимый ключ компактизации
Это тихо отключит механизм оптимизации.
Правильный подход: используйте только совместимые версии конфигурации
Затем проверьте:
openclaw doctor --fix
Проверьте журнал запуска, чтобы убедиться, что компактизация принята.
P1 — Уменьшить постоянное хранение текста рассуждений
Избегайте повторного воспроизведения длинных текстов рассуждений
В производственной среде: сохраняйте краткое резюме, а не полное обоснование
P3 — Улучшение дизайна кэширования запросов
Цель — не максимизировать cacheRead. Цель — использовать кэш на компактных, стабильных и высокоценных префиксах.
Рекомендация:
- Включите стабильные правила в системный промпт
- Не добавляйте нестабильные данные в стабильный префикс
- Избегайте внесения большого объема отладочных данных за один цикл
Практический план стоп-лосса (если бы мне нужно было обработать это завтра)
1. Найдите сессию с наибольшим процентом cacheRead
2. Выполните /compact для runaway session
3. Добавить усечение + артефактизацию к выводу инструмента
4. После каждого изменения повторно запустите статистику токенов
Основные показатели для отслеживания: четыре KPI:
cacheRead / totalTokens
toolUse avgTotal/call
Количество вызовов >=100k токенов
Максимальный процент сессии
Успешный сигнал
Если оптимизация вступит в силу, вы должны увидеть:
Значительно сократилось количество вызовов токенов более 100 тыс.
Доля cacheRead снизилась
Вес вызова toolUse снижен
Снижение доминирования отдельного сеанса
Если эти показатели не изменились, значит, ваша контекстная стратегия все еще слишком мягкая.
Команды для воспроизведения эксперимента
python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
-- топ-20 \
--outlier-threshold 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
-- топ-20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
Заключение
Если ваша система Agent выглядит нормально, но расходы продолжают расти, сначала проверьте один вопрос: вы платите за новые вычисления или за массовое воспроизведение старых контекстов?
В моем случае большая часть затрат действительно приходится на воспроизведение контекста.
Как только вы осознаете это, решение становится очевидным: строго контролировать данные, поступающие в долгосрочный контекст.