Формат — статья блога Протока.

{"title":"Как сократить расход токенов в ИИ-агенте без потери качества","body":"# Как сократить расход токенов в ИИ-агенте без потери качества\n\nИИ-агент может тратить токены не на решение задачи, а на повторную передачу собственного прошлого. На каждом новом шаге модель снова получает историю диалога, логи, содержимое файлов, результаты инструментов и их схемы. Если агент выполняет десятки действий подряд, объём контекста быстро становится главным фактором стоимости.\n\nПроблема особенно заметна при работе через API: списание в Протоке происходит по факту за каждый запрос, отдельно учитываются входные и выходные токены. Поэтому оптимизация контекста влияет не только на скорость, но и на итоговый бюджет сессии.\n\n## Откуда берётся лишний контекст\n\nРассмотрим типичный сценарий. Агент должен изучить проект, найти ошибку, изменить несколько файлов и проверить результат. За один цикл он может вызвать десятки инструментов. В историю постепенно попадают:\n\n- полные логи предыдущих действий;\n- содержимое уже прочитанных файлов;\n- повторяющиеся ответы инструментов;\n- промежуточные рассуждения и уточнения;\n- схемы всех доступных функций, включая те, которые сейчас не нужны;\n- результаты вычислений, которые больше не влияют на решение.\n\nНа ранних шагах такой подход удобен: модели доступна вся история. Но на длинной сессии каждый следующий запрос начинает переносить всё больше данных. Даже если агент добавляет к контексту всего несколько тысяч токенов, накопленный объём может вырасти в разы.\n\nВажно различать два показателя. Первый — размер одного запроса. Второй — сумма входных токенов за всю сессию. Агент может отправлять относительно компактные сообщения, но повторять их десятки раз. В результате именно накопленный входной контекст становится основной статьёй расходов.\n\n## Сначала измеряйте, потом сокращайте\n\nДо оптимизации стоит добавить в журнал как минимум четыре значения:\n\n1. число шагов сессии;\n2. входные и выходные токены каждого запроса;\n3. состав контекста: история, файлы, логи, инструменты;\n4. результат шага — успешное действие, ошибка или повтор.\n\nБез такой статистики легко оптимизировать не то место. Например, сокращение ответа модели на 20% может почти не повлиять на расходы, если входной контекст в десять раз больше. И наоборот: удаление одного повторяющегося лога способно дать заметный эффект на каждом последующем шаге.\n\nВ Протоке актуальные котировки на дату публикации позволяют быстро оценить разницу между стратегиями. Например, для GLM-5.2 стоимость составляет 3,66 ₽ за 1M входных токенов и 11,50 ₽ за 1M выходных. Для GLM-5.3 — 20,47 ₽ за 1M входных и 64,34 ₽ за 1M выходных. На длинной агентской сессии выбор модели и объём повторного контекста нужно рассматривать вместе.\n\n## Приём 1. Архивируйте историю, а не отправляйте её целиком\n\nПосле завершения шага необязательно оставлять в контексте весь текст ответа инструмента. Полезнее разделить данные на три слоя:\n\n- краткое резюме, которое остаётся в текущем контексте;\n- структурированные факты: изменённые файлы, найденные ошибки, выполненные команды;\n- полный архив, доступный по запросу.\n\nНапример, вместо нескольких страниц лога можно сохранить запись:\n\n``text\nТесты: 28 успешно, 2 завершились ошибкой.\nОшибки: tests/api_test.py:41, tests/cache_test.py:19.\nСледующий шаг: открыть только два файла и проверить сообщения об ошибках.\n`\n\nПолный лог при этом не удаляется. Он сохраняется локально или на сервере, а агент получает его только при необходимости. Такой подход уменьшает базовый контекст и сохраняет возможность вернуться к деталям.\n\nРезюме лучше делать машинно-читабельным. Формат JSON или таблица надёжнее свободного текста: агенту проще понять, какие файлы изменены, какие проверки пройдены и какие действия ещё не выполнены.\n\n## Приём 2. Держите оглавление сессии\n\nДлинную историю удобно представлять не как бесконечную ленту сообщений, а как оглавление. В нём можно хранить:\n\n- цель сессии;\n- текущий план;\n- принятые решения;\n- список изменённых объектов;\n- открытые вопросы;\n- ссылки на архивные фрагменты.\n\nПеред каждым запросом агент получает оглавление и только те материалы, которые относятся к текущему шагу. Например, для исправления функции ему нужны сигнатура, тесты и сообщение об ошибке. Полная история обсуждения архитектуры проекта на этом этапе не обязательна.\n\nОглавление также снижает риск потери цели. При агрессивном сжатии контекста модель может забыть первоначальные ограничения. Поэтому критические требования — формат результата, запрет на изменение определённых файлов, критерии готовности — лучше хранить отдельно и добавлять в каждый запрос.\n\n## Приём 3. Загружайте инструменты по требованию\n\nОписание всех инструментов тоже занимает токены. Если агенту доступны функции для работы с файлами, базами данных, браузером, вычислениями и внешними системами, нет смысла каждый раз передавать полные схемы всех функций.\n\nПрактичная схема выглядит так:\n\n1. в базовом контексте остаётся короткий каталог инструментов;\n2. агент выбирает нужную группу;\n3. перед следующим вызовом загружается полная схема только этой группы;\n4. после завершения операции подробное описание убирается.\n\nНапример, для анализа кода не нужны схемы функций отправки уведомлений. Для расчёта данных не всегда нужны операции с файловой системой. Динамическая загрузка уменьшает повторяющийся служебный контекст и делает выбор инструмента более предсказуемым.\n\n## Приём 4. Не передавайте модели то, что можно посчитать программно\n\nЧасть задач не требует участия модели. Подсчёты, сортировку, фильтрацию, проверку формата и сравнение версий лучше выполнять обычным кодом. Модели достаточно передать итог и, если нужно, небольшой фрагмент исходных данных.\n\nНапример, вместо передачи большого списка для поиска максимального значения приложение может вычислить результат самостоятельно:\n\n`python\nvalues = [12, 8, 41, 19]\nresult = max(values)\nprint(result)\n`\n\nМодель получает только 41 и использует его в рассуждении. Это быстрее, дешевле и надёжнее, чем просить её повторно обрабатывать весь массив на каждом шаге.\n\nПесочница вычислений особенно полезна для длинных таблиц, преобразований JSON и промежуточных расчётов. Но результат вычисления тоже не стоит бесконечно накапливать в истории: сохраняйте итог, параметры операции и путь к полному выводу.\n\n## Выбор модели по этапам задачи\n\nОдна модель не обязана обслуживать всю сессию. Для классификации, извлечения фактов и коротких вспомогательных действий можно выбрать менее дорогую модель. Более сложный этап — планирование, анализ конфликтующих требований или финальная проверка — передать более мощной.\n\nВ Протоке на дату публикации доступны, например, такие котировки за 1M токенов:\n\n- GLM-5.2 — 3,66 ₽ входных и 11,50 ₽ выходных;\n- GLM-5.3 Flash — 11,76 ₽ входных и 39,18 ₽ выходных;\n- GLM-5.3 — 20,47 ₽ входных и 64,34 ₽ выходных;\n- GPT-5.6 Luna — 8,57 ₽ входных и 51,26 ₽ выходных;\n- GPT-5.6 Sol — 13,60 ₽ входных и 81,58 ₽ выходных.\n\nЦены нужно оценивать вместе с качеством и количеством повторных шагов. Дешёвая модель, которая часто ошибается и запускает дополнительные циклы, не всегда окажется экономичнее. Поэтому полезно сравнивать не стоимость одного запроса, а стоимость успешно завершённой задачи.\n\nПример конфигурации клиента:\n\n`python\nfrom openai import OpenAI\n\nclient = OpenAI(\n api_key=\"\",\n base_url=\"https://dualchat.pro/v1\"\n)\n\nresponse = client.chat.completions.create(\n model=\"glm-5.2\",\n messages=[\n {\"role\": \"system\", \"content\": \"Ты анализируешь только переданные факты.\"},\n {\"role\": \"user\", \"content\": \"Составь краткий план проверки.\"}\n ]\n)\n`\n\nВ параметре model используется slug модели из котировок. Ключ вида sk-dc-… создаётся в кабинете, в разделе «Ключи».\n\n## Когда оптимизация может навредить\n\nСокращение контекста не должно быть самоцелью. На коротких задачах архивирование, дополнительные резюме и маршрутизация между моделями могут добавить задержку и собственные расходы. Если сессия состоит из одного-двух запросов, полная история обычно не успевает стать проблемой.\n\nЕсть и риск потери важных деталей. Слишком агрессивное резюме может удалить исключение, ограничение или точную формулировку требования. Поэтому тестируйте оптимизированный агент на наборе реальных сценариев и сравнивайте не только токены, но и:\n\n- долю успешно завершённых задач;\n- число повторных вызовов инструментов;\n- количество ошибок;\n- время выполнения;\n- стоимость одной успешной сессии.\n\n## Вывод\n\nГлавный резерв экономии в агентских системах — не механическое уменьшение ответов, а управление повторным контекстом. Архив вместо полной истории, оглавление сессии, загрузка схем инструментов по требованию и программные вычисления позволяют передавать модели только данные, нужные на текущем шаге.\n\nПроверьте эту стратегию на собственном сценарии: зафиксируйте токены по шагам, разделите историю на активную и архивную, затем сравните стоимость успешной задачи на нескольких моделях. В Протоке можно оплачивать запросы по факту в рублях — картой онлайн, по счёту для организации или через СБП.\n\nПосмотрите актуальные модели и котировки на [dualchat.pro](https://dualchat.pro/models?utm_source=blog&utm_medium=article&utm_campaign=format-statya-bloga-protoka), а подключение выполните через https://dualchat.pro/v1`. Попробуйте собрать первую оптимизированную сессию и измерьте результат в токенах, рублях и числе успешных действий.","excerpt":"Большой контекст быстро увеличивает стоимость ИИ-агента. Разбираем, как архивировать историю, загружать инструменты по требованию и выбирать модель по этапам задачи.","slug":"kak-sokratit-rashod-tokenov-v-ii-agente","seoTitle":"Как сократить расход токенов ИИ-агента","seoDescription":"Практические способы уменьшить контекст, число токенов и стоимость агентских сессий с моделями Протока без потери качества.","}