Автор разобрал рабочую нагрузку OpenClaw и выяснил, что 79% потребления токенов происходит из кэширования повторов префиксов (cached prefix replay), а не из пользовательского ввода или вывода модели, и предложил три основные стратегии оптимизации контекста, которые эффективно снижают операционные расходы AI-агента. Эта статья основана на статье, написанной MOSHIII (Почему мои сессии OpenClaw сожгли 21,5 миллиона токенов за день (и что на самом деле это исправило)), редактированной и переведенной ДунгКу. (Предыстория: MEXC вошел в тройку лучших CEX в мире, углубив свои позиции на рынке спотовой и товарной торговли) (Фоновая информация: Быки зарабатывают на стабильных монетах: сравнение процентных ставок различных платформ OSL 18%, MEXC 15%, Binance 8%…) Я проанализировал реальную рабочую нагрузку OpenClaw и обнаружил модель, которую, как я думаю, многие пользователи агентов узнают: потребление токенов выглядит «активным», ответы кажутся нормальными, но потребление токенов внезапно возрастает в геометрической прогрессии. Ниже представлены структура анализа, коренные причины и реальные пути решения проблемы. Основной фактор затрат: кэширование префиксов. Основным фактором затрат не является слишком длинное сообщение пользователя. Скорее, это огромное количество кэшированных префиксов (cached prefix), которые многократно воспроизводятся. Исходя из данных сессии: Общие токены: 21,543,714 cacheRead: 17,105,970 (79.40%) input: 4,345,264 (20.17%) output: 92,480 (0.43%) Иными словами: большинство затрат на вызовы на самом деле не связано с обработкой новых намерений пользователя, а с многократным чтением огромного исторического контекста. Я изначально думал, что высокое потребление токенов вызвано: очень длинным пользовательским запросом, большим количеством генерируемого вывода или дорогими вызовами инструментов. Но действительно доминирующая модель такова: input: от сотен до тысяч токенов cacheRead: от 170,000 до 180,000 токенов за каждый вызов. Это означает, что модель каждый раз многократно читает один и тот же огромный стабильный префикс. Разделение данных сессии. Я проанализировал данные на двух уровнях: 1. Журналы выполнения (runtime logs) 2. Записи сессий (session transcripts) Следует отметить, что журналы выполнения в основном используются для наблюдения за поведенческими сигналами (такими как перезагрузка, ошибки, проблемы с конфигурацией). Точные статистические данные по токенам получены из поля использования в 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 Одна из сессий имеет потребление значительно выше других: 570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 токенов, а затем заметное резкое снижение: ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038 ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584 токенов. Основной источник: toolUse: 16,372,294 stop: 5,171,420 Указывает на то, что проблема заключается в цикле вызовов инструментов, а не в обычном чате. Откуда берутся пиковые значения токенов? Пиковые значения токенов не случайны, а сосредоточены в несколько часов: 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-снимки Список файлов Данные, захваченные браузером Записи диалогов дочерних агентов В самой большой сессии количество символов составляет: toolResult:text: 366,469 символов assistant:thinking: 331,494 символов assistant:toolCall: 53,039 символов Как только эти данные сохраняются в историческом контексте, каждый последующий вызов может повторно считывать их через кэшированные префиксы. В следующих местах многократно встречаются огромные блоки контекста: sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70 Огромный JSON-журнал шлюза (примерно 37 тысяч символов) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134 Снимок браузера + безопасная упаковка (примерно 29 тысяч символов) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219 Огромный вывод списка файлов (примерно 41 тысяча символов) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311 session/status Снимок состояния + крупная структура префикса (примерно 30 тысяч символов) Я также измерил процент дублирующегося контента внутри одного вызова: Процент дубликатов составляет примерно: 1.72%. Действительно существует, но не является основной проблемой. Реальная проблема заключается в том, что абсолютный объем кэшированных префиксов слишком велик. Структура такова: огромный исторический контекст, многократное чтение при каждом вызове, при этом добавляется лишь небольшое количество новых вводов. Таким образом, основное внимание оптимизации не должно быть на удалении дубликатов, а на проектировании структуры контекста. Три механизма расширения контекста. Три механизма накладываются друг на друга: 1. Огромное количество выводов инструментов записывается в исторический контекст 2. Циклы инструментов создают множество вызовов с короткими интервалами 3. Изменения префикса очень небольшие → кэш каждый раз будет считываться заново. Если уплотнение контекста не будет стабильно инициировано, проблема быстро усугубится. Стратегии оптимизации в практике. Для очень больших выводов инструментов: · Сохранять резюме ...