TL;DR
Исследователи разработали метод пошагового аудита и онлайн-обрезки токен-мусора (Token Waste Framework), который с помощью прокси-перехватчика и LLM-судьи отделяет полезную работу агента от четырёх типов пустых трат: повтора контекста (Restate), дублирующих вызовов инструментов (Duplicate-Fetch), словесной воды (Padding) и тупиковых разведок (Detour). Первые три типа являются строгим мусором (strict waste): если вырезать их прямо по ходу работы агента, можно удалить почти половину текста рассуждений без просадки точности решения задач.
Все привыкли оценивать экономичность агента по общему счёту за токены, но общий чек смешивает необходимую глубокую работу со скрытым холостым ходом. На практике почти пятая часть всего оплачиваемого вывода современных агентов — это чистый мусор, а почти в половине рабочих задач одни только мусорные токены одного агента превышают весь целиком взятый объём вывода другого агента, который успешно решил ту же самую задачу. При этом попытка сэкономить «вслепую» (например, просто зажать общий лимит токенов или отключить рассуждения целиком) резко обрушивает качество работы.
Метод решает эту проблему за счёт точечной фильтрации по принципу минимализма: LLM-судья размечает в логе или на текущем шаге агента фрагменты Restate (пересказ системного промпта, планов и ответов тулов, которые и так лежат в контексте), Duplicate-Fetch (повторное чтение тех же файлов и запросов) и Padding (вводные расшаркивания, сочувствие и озвучивание действия перед вызовом инструмента), после чего эти куски удаляются из истории перед следующим шагом, а полезная разведка (Detour) не трогается.
Схема метода
ШАГ 1 (Перехват траектории): Прокси (LiteLLM) записывает шаги агента: рассуждения + видимый ответ + вызовы тулов + биллинг токенов
ШАГ 2 (Разметка LLM-судьёй — LLMaJ): Классификация фрагментов на Strict Waste (Restate, Duplicate-Fetch, Padding) и Hindsight Waste (Detour)
ШАГ 3 (Онлайн-обрезка или аудит): Удаление только фрагментов Restate и Padding из текущих рассуждений перед сохранением в историю следующего шага
ШАГ 4 (Сверка экономии): Пересчёт токенов очищенной траектории → Оценка чистого сэкономленного бюджета без потери успешности задачи
Для ретроспективного аудита логов шаги 2–4 выполняются одним запросом к LLM-судье по готовой записи сессии; для онлайн-экономии фильтр встраивается между шагами агента через прокси.
Пример применения
Задача: Ваша команда использует кодинг-агента и агента технической поддержки (на базе OpenHands, Hermes или собственного конвейера через LiteLLM) для разбора тикетов клиентов и правок в репозитории. Счета за API выросли до 350 000 рублей в месяц, причём в длинных тикетах контекст пухнет на глазах. Вы хотите прогнать логи сессий через LLM-судью по методике статьи, чтобы точно посчитать долю «строгого мусора» (Restate, Duplicate-Fetch, Padding), отделить её от оправданной разведки (Detour) и понять, что именно сжигает бюджет — сама модель или промпт вашей агентной обвязки.
Промпт:
Ты — LLM-судья по аудиту эффективности токенов ИИ-агента (Efficiency Judge по принципу минимализма). Твоя задача — найти в траектории агента фрагменты текста и вызовы инструментов, которые можно полностью удалить без потери полезной работы, нужной для решения задачи.
Клиент интернет-магазина электроники в Казани написал в поддержку: заказ #RU-5519 оплачен картой, но курьерская доставка зависла в статусе "Ожидает комплектации" более 4 дней. Проверить статус на складе и при задержке начислить 500 бонусных рублей по регламенту.
[Шаг 1 — Reasoning]: Пользователь обращается по заказу #RU-5519. Согласно разделу 4.2 регламента поддержки: "Если заказ оплачен онлайн и находится в статусе Ожидает комплектации более 72 часов, оператор обязан проверить складской лог и начислить 500 бонусов". Мой план: 1) проверить заказ, 2) проверить складской лог, 3) начислить бонусы, 4) ответить клиенту. Сейчас я вызову инструмент get_order_status.
[Шаг 1 — Visible Reply]: Мне искренне жаль, что вы столкнулись с такой неприятной ситуацией и вынуждены ждать свой заказ! Я прекрасно понимаю ваше беспокойство и прямо сейчас проверю всю информацию по заказу #RU-5519 в нашей системе.
[Шаг 1 — Tool Call]: get_order_status(order_id="RU-5519") -> {"paid": true, "status": "AWAITING_PACKING", "hours_in_status": 104, "warehouse": "KZN-2"}
[Шаг 2 — Reasoning]: Как мы видим из ответа инструмента, paid=true, status=AWAITING_PACKING, hours_in_status=104, warehouse=KZN-2. Напомню мой план: 1) проверить заказ, 2) проверить складской лог, 3) начислить бонусы, 4) ответить клиенту. По регламенту при задержке свыше 72 часов нужно проверить складской лог. Сначала попробую поискать адрес склада KZN-2 во внешнем справочнике карт.
[Шаг 2 — Tool Call]: search_public_maps(query="склад KZN-2 Казань") -> {"error": "Blocked by robots.txt, no data"}
[Шаг 3 — Tool Call]: get_order_status(order_id="RU-5519") -> {"paid": true, "status": "AWAITING_PACKING", "hours_in_status": 104, "warehouse": "KZN-2"}
[Шаг 4 — Tool Call]: add_bonus_points(order_id="RU-5519", points=500) -> {"success": true}
Разметь каждый избыточный фрагмент и отнеси его строго к одной из 4 категорий:
1. RESTATE (Strict waste — подлежит удалению): Повтор информации, которая уже есть в текущем контексте (дословное цитирование системного регламента, пересказ только что полученного JSON от инструмента, повторение одного и того же плана на каждом шаге).
2. DUPLICATE-FETCH (Strict waste — подлежит удалению): Повторный вызов инструмента за теми же данными, которые уже были получены ранее и не изменились.
3. PADDING (Strict waste — подлежит удалению): Текст, не продвигающий решение задачи (пустые преамбулы, затянутое сочувствие, объявление "сейчас я вызову инструмент X" прямо перед его вызовом).
4. DETOUR (Hindsight waste — допустимая разведка, НЕ удалять в онлайне): Исследовательский шаг или вызов инструмента, который выглядел разумной гипотезой в момент попытки, но в итоге не пригодился (например, поиск, заблокированный robots.txt).
Выведи:
- Таблицу найденных фрагментов: [Шаг | Цитата фрагмента | Категория | Статус (Удалять / Оставить) | Почему это мусор].
- Очищенную версию рассуждений и вызовов инструментов (без Strict waste).
- Диагноз для инженера: какую долю текста составил строгий мусор и какое правило добавить в обвязку агента.
Результат:
Модель чётко разделит траекторию на полезное ядро и балласт: цитирование регламента, дословный пересказ JSON-ответа get_order_status и повтор плана из четырёх пунктов попадут в RESTATE; затянутые извинения и фраза «сейчас я вызову инструмент» — в PADDING; повторный вызов get_order_status(order_id="RU-5519") на шаге 3 — в DUPLICATE-FETCH. При этом неудачный запрос к картам на шаге 2 будет помечен как DETOUR (оправданная попытка разведки, которую не нужно путать с прямым мусором). В финале читатель получит сжатую траекторию (короче более чем вдвое) и конкретные рекомендации для настройки агента.
Почему это работает
В многошаговых задачах контекст агента работает как снежный ком с самоповтором. Поскольку на каждом новом ходе модель видит всю предыдущую историю, она склонна перед каждым действием заново пересказывать условие задачи, цитировать куски системного промпта, проговаривать вслух только что пришедший ответ функции (Restate) и обрамлять вызовы инструментов вежливыми вступлениями (Padding). Эти токены не несут новой информации для выбора следующего действия, но оплачиваются дважды: сначала как дорогие выходные токены (output tokens), а затем на всех последующих шагах — как растущий входной контекст.
Сильная сторона LLM-судьи при оценке траектории — умение отличить бесполезный самоповтор от рабочей гипотезы, если дать ей чёткую четырёхчастную таксономию. Обычное требование «пиши короче» часто ломает способность модели рассуждать, потому что режет и нужные вычисления, и поисковые попытки (Detour). Разделение на строгий мусор (Restate, Duplicate-Fetch, Padding) и разведку (Detour) позволяет хирургически вырезать только то, что уже и так лежит в окне контекста или является словесной водой.
Прямые эксперименты с вмешательством в ход работы агента подтвердили, что модели не нуждаются в собственном словесном балласте для принятия решений: когда из истории прошлых ходов принудительно удаляли весь размеченный строгий мусор, распределение следующих действий агента почти не менялось (сдвиг оказался в пределах естественного шума генерации), тогда как полное удаление всех прошлых рассуждений резко сбивало агента с курса.
Рычаги управления методом:
- Онлайн-обрезка против посмертного аудита → в живом цикле работы агента (онлайн) удаляй только Restate и Padding (их видно сразу на текущем шаге без знания будущего), а поиск Duplicate-Fetch и Detour запускай на полных завершённых логах для оптимизации обвязки.
- Защита первого шага в коротких задачах (Turn-1 Guard) → не включай агрессивную обрезку рассуждений после самого первого хода в коротких инструментальных задачах (на первом шаге закладывается каркас плана); начинай чистку со 2–3-го шага или после первой четверти длинной траектории.
- Смена и настройка агентной обвязки (Harness optimization) → если аудит показывает высокий процент Restate и Duplicate-Fetch, проблема чаще всего не в самой LLM, а в системном промпте и формате истории вашей агентной оболочки.
Шаблон промпта
Ты — аудитор токен-эффективности ИИ-агента (Token-Waste Judge). Твоя задача — проанализировать траекторию решения задачи по принципу минимализма и выделить фрагменты, удаление которых не убирает полезную работу.
{описание_задачи_агента}
{лог_шагов_рассуждений_ответов_и_инструментов}
Ищи и размечай избыточные фрагменты по 4 категориям:
1. [RESTATE] (Строгий мусор — УДАЛЯТЬ):
Агент повторяет сведения, которые уже присутствуют в доступном контексте: цитирует правила из системного промпта, пересказывает словами ответ инструмента из прошлого шага или повторяет один и тот же план перед каждым шагом.
2. [DUPLICATE-FETCH] (Строгий мусор — УДАЛЯТЬ):
Повторный вызов того же инструмента с теми же параметрами за данными, которые уже получены на прошлых шагах и не могли измениться (повторное чтение файла, повторный идентичный поиск).
3. [PADDING] (Строгий мусор — УДАЛЯТЬ):
Сгенерированный текст, не продвигающий задачу: пустые вводные фразы, избыточное сочувствие, прощания или проговаривание действия ("сейчас я вызову функцию...") непосредственно перед самим вызовом.
4. [DETOUR] (Разведка — ОСТАВИТЬ для анализа):
Поисковый шаг или проверка гипотезы, которые выглядели разумно в момент выполнения, но ретроспективно оказались тупиковыми или не пригодились в финальном решении.
1. Размеченные спаны мусора: укажи номер шага, категорию ([RESTATE], [DUPLICATE-FETCH], [PADDING] или [DETOUR]), точную цитату и причину.
2. Очищенная история шага (Cleaned Context): верни текст рассуждений и ответов с вырезанными спанами категорий [RESTATE] и [PADDING], готовый для подстановки в контекст следующих шагов.
3. Сводка потерь: оцени долю строгого мусора в рассуждениях и в видимых ответах/вызовах инструментов, и укажи, какой паттерн сжигает больше всего токенов.
Что подставлять в плейсхолдеры:
- {описание_задачи_агента} — исходный запрос пользователя и цель запуска агента.
- {лог_шагов_рассуждений_ответов_и_инструментов} — пошаговый лог сессии (блоки reasoning, visible reply и tool calls).
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита токен-мусора ИИ-агента (Restate, Duplicate-Fetch, Padding, Detour). Адаптируй под мою задачу: [опиши своего агента или вставь лог одной длинной сессии, которая съела много токенов].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, сохраняются ли рассуждения прошлых шагов в истории твоего агента и какие инструменты он вызывает — потому что структура мусора в скрытых рассуждениях и в видимых вызовах тулов сильно отличается. Она возьмёт паттерн из шаблона и проведёт разметку лога.
Ограничения
⚠️ Опасность ранней обрезки на первом шаге коротких задач: Если принудительно вырезать размеченный мусор сразу после первого хода в коротких задачах на вызов инструментов (как в бенчмарке MCP-Atlas), успешность решения заметно падает — начинать чистку истории безопасно со второго-третьего хода, когда агент уже зацепился за нужные данные.
⚠️ Для автоматической онлайн-экономии нужен прокси или доступ к контексту между ходами: В готовом закрытом чате нельзя на лету вырезать куски из чужого окна истории без своего API-прокси (например, на базе LiteLLM), а кроме того, часть провайдеров (например, модели Claude) скрывают сырые токены рассуждений от внешнего редактирования.
Как исследовали
Команда из четырёх американских университетов (UIUC, Northeastern, UCLA и UT Austin) построила единый прокси-стенд на базе LiteLLM и проверила расход токенов на 6 флагманских моделях (Kimi-K3, Gemini 3.1 Pro, GPT-5.6 Terra, GPT-6 Astra, Claude Sonnet 5 и Claude Fable 5.1), 4 бенчмарках ($\tau^2$-bench airline/retail, SWE-bench Verified, Claw-Eval и MCP-Atlas) и 5 популярных агентных обвязках (OpenCode, OpenClaw, OpenHands, Hermes и Kimi Code CLI). Чтобы доказать, что найденный LLM-судьёй мусор действительно не нужен для работы, авторы провели жёсткие причинно-следственные эксперименты: они останавливали агента посреди задачи, вырезали из истории все спаны строгого мусора и запускали выполнение дальше, а также сравнивали распределения следующих шагов на 16 параллельных продолжениях (по 2000 перестановок на шаг). На SWE-bench Verified удаление строгого мусора изменило выбор следующего действия лишь в 3,0% ходов (величина эффекта составила всего 1,8% от естественного разброса самой модели!), тогда как удаление всех рассуждений ломало 25,0% ходов. В режиме живой онлайн-чистки (online pruning) фильтр на лету удалил 41% всех токенов рассуждений на SWE-bench Verified (при этом точность решения даже слегка подросла — с 89,0% до 89,5%) и 46% рассуждений на MCP-Atlas (при сохранении точности 62,3% против 65,0%, тогда как полное удаление рассуждений роняло результат до 73,0% и 56,0%). Масштабный замер по всем моделям показал, что в среднем около 18% всех оплачиваемых выходных токенов агентов (от 11,0% у GPT-6 Astra до 24,9% у Claude Sonnet 5 и 26,6% в рассуждениях Kimi-K3) — это чистый удаляемый мусор, причём более «болтливые» и расточительные агенты не получают никакого выигрыша в точности по сравнению с экономными.
Адаптации и экстраполяции
🔧 Техника: Анти-мусорный блок в системном промпте агента /
CLAUDE.md→ профилактикаRestate,Duplicate-FetchиPaddingбез проксиДаже если вы не поднимаете свой LiteLLM-прокси для онлайн-вырезания текста между ходами, вы можете встроить три категории строгого мусора из исследования как прямые антипаттерны в системный промпт или
CLAUDE.md:## ЭКОНОМИЯ ТОКЕНОВ И ЗАПРЕТ НА СТРОГИЙ МУСОР (STRICT WASTE GUARD) При каждом шаге соблюдай принцип минимализма: 1. NO RESTATE: Никогда не цитируй заново правила из системного промпта, не пересказывай словами JSON-ответы инструментов, которые уже видны в истории, и не дублируй полный план из прошлых шагов — ссылайся только на изменившийся шаг. 2. NO DUPLICATE-FETCH: Перед вызовом инструмента чтения файла или поиска проверь историю: если этот же файл или запрос уже вызывался и ты сам его не модифицировал — используй результат из истории. 3. NO PADDING: Не пиши преамбулы, сочувствие и фразы вида «Сейчас я вызову инструмент X» перед вызовом функции — сразу вызывай инструмент.
Экстраполяция — сравнение агентных оболочек (OpenHands vs Hermes vs OpenCode) перед внедрением в компании:
Один из главных выводов статьи — обвязка агента (harness) и структура задачи влияют на долю мусорных токенов сильнее, чем выбор самой модели. Перед тем как масштабировать корпоративного агента на всю команду, прогоните 10–15 типовых рабочих задач через 2–3 кандидатов-обвязок на одной и той же модели, соберите логи через LiteLLM и запустите шаблон LLM-судьи выше: вы сразу увидите, какая оболочка заставляет модель на каждом шаге пересказывать контекст (Restate) или дёргать одни и те же файлы (Duplicate-Fetch), и сэкономите до четверти бюджета API ещё до старта продакшена.
Ресурсы
- Исследование: How Do AI Agents Waste Your Money? (arXiv:2611.07238, 2026)
- Код и датасет размеченных траекторий: github.com/huiminzeng/How_Do_AI_Agents_Waste_Your_Money · HuggingFace Dataset
- Авторы: Huimin Zeng, Yuxuan Lu, Jesse Cai, Eric Hanchen Jiang, Di Wu, Po-Nien Kung, Wenbo Hu, Ziyi Wang, Dakuo Wang, Jiaxin Pei, Kai-Wei Chang (UIUC, Northeastern University, UCLA, UT Austin)