Экономика токенов ИИ-агентов: куда уходит контекст в агентном кодинге
Внедрение автономных ИИ-агентов для разработки (таких как Cursor, Cline, Roo Code, Aider или OpenCode) кардинально изменило продуктивность создания программного обеспечения. Инженер формулирует задачу на естественном языке, а агент самостоятельно исследует структуру репозитория, читает исходный код, запускает линтеры, правит ошибки компиляции и прогоняет тесты. Однако обратной стороной высокой автономности стал неожиданно высокий и трудноконтролируемый расход токенов больших языковых моделей (LLM). Разработчики регулярно сталкиваются с ситуацией, когда дневной лимит API или дорогая подписка сгорают буквально за 30 минут работы, хотя агент внес в код всего пару десятков строк итоговых изменений.
Анатомия запроса агентной системы
Чтобы понять причины быстрых трат, необходимо разобрать внутреннюю структуру контекстного окна при каждом обращении агента к LLM API. В отличие от стандартного чата, где отправляется только линейная история переписки, запрос кодинг-агента представляет собой сложный пакет с большим объемом служебных данных.
При каждом шаге агентной итерации в контекст упаковываются:
- Системный промпт — подробные инструкции о ролях, ограничениях и формате работы агента.
- Файлы проектных правил — указания из локальных файлов конфигурации (
.cursorrules,.clinerulesили.opencode/rules). - Полная история предыдущих шагов диалога, принятых решений и промежуточных гипотез.
- Вызовы инструментов (Tool Calls) — результаты чтения файлов, вывод поиска по кодовой базе (grep/rg), листинги каталогов, сообщения об ошибках компилятора, LSP-диагностика и дампы прохождения модульных тестов.
Каждый новый шаг агента требует повторной отправки всего накопленного контекста. Если история и прочитанные файлы занимают 90 000 токенов, то на десятом шаге итерации приложение заплатит за 90 000 входных токенов на каждом запросе к модели, даже если итоговый генеративный ответ агента содержит всего 30 токенов кода.
Диспропорция стоимости входных и выходных токенов
В экономической модели современных провайдеров LLM API (Anthropic, OpenAI, Google) стоимость генерации выходных токенов в 3–5 раз превышает стоимость обработки входных токенов. Однако в работе кодинг-агентов ключевую роль играет именно суммарный объем входных токенов (Input Tokens).
Поскольку агенты совершают от 10 до 50 итеративных шагов для решения одной инженерной задачи, кумулятивный объем переданных входных токенов быстро достигает миллионов единиц. Без использования механизмов оптимизации кэширования стоимость сбора контекста для задачи среднего размера может превысить несколько долларов за один запуск.
Главные каналы невидимых утечек контекста
Инженерный анализ показывает четыре ключевых фактора неэффективного расхода API-бюджета.
1. Повторное чтение файлов без кэширования
Когда агент выполняет задачу, он регулярно перечитывает модифицированные файлы для проверки корректности импортов и синтаксиса. Без использования механизмов Prompt Caching (кэширования префиксов промптов на стороне провайдера API) пользователь оплачивает полную стоимость входных токенов этих файлов при каждом последующем шаге.
2. Избыточные дампы вызовов инструментов
Многие агенты по умолчанию запрашивают слишком широкие выгрузки: например, читают весь файл на 3000 строк ради проверки одной функции или выполняют поиск, возвращающий сотни совпадений. Ошибки линтера или трассировки стека (stack trace) также уходят в контекст целиком, быстро забивая окно ненужной информацией.
3. Разросшиеся файлы правил проекта
Файлы .cursorrules или .clinerules создаются для того, чтобы задать агенту стиль кода и архитектурные границы. Однако когда разработчики копируют туда огромные статьи из документации, правила начинают занимать 5 000 – 10 000 токенов в каждом запросе к модели.
4. Зацикливание и неэффективные попытки исправления
Если агент сталкивается с ошибкой типов или падающим тестом и не может решить задачу с первой попытки, он начинает пробовать случайные гипотезы. Каждая неудачная попытка генерирует новый круг чтения файлов и вызова линтеров, раздувая контекст по экспоненте.
Управление токенами через Git и контрольные точки
Эффективный способ контроля расхода ресурсов заключается в фиксации промежуточных результатов через систему контроля версий (Git).
Когда агент успешно выполняет промежуточный этап задачи (например, создает необходимую структуру данных или исправляет модульный тест), разработчику следует сделать промежуточный коммит и очистить историю диалога (команда /clear или запуск новой сессии). Новый шаг начнется с чистого контекстного окна, а свежие изменения будут видны агенту через локальный git diff. Это предотвращает перенос десятков ненужных шагов рассуждений в новые итерации.
Многоагентная оркестрация и накладные расходы
При использовании мультиагентных систем (где один агент-планировщик раздает задачи субагентам-исполнителям) накладные расходы возрастают в разы. Каждый субагент инициализирует собственное контекстное окно, заново считывает правила проекта и генерирует дублирующие вызовы инструментов. Для предотвращения перерасхода необходимо жестко передавать между агентами только минимальный JSON-артефакт результата, а не всю историю переписки.
Стратегии оптимизации расходов на агентный кодинг
Для сохранения бюджета без потери качества работы ИИ-ассистентов рекомендуется использовать комбинацию технических настроек:
- Включайте кэширование промптов (Prompt Caching): провайдеры (Anthropic, OpenAI) предоставляют скидку до 90% на входные токены, если начальная часть контекста остаётся неизменной.
- Сокращайте файлы правил: оставляйте в
.clinerulesтолько ключевые соглашения по архитектуре и стеку, избегая очевидных описаний языков программирования. - Настраивайте ограничение контекста (Context Compaction): используйте режим автоматического сжатия истории шагов, когда старые вызовы инструментов заменяются краткими резюме.
- Применяйте эшелонирование моделей: используйте более дешевые и быстрые модели (например, Sonnet или Flash) на этапе первичного поиска файлов и сбора данных, а дорогие модели с высоким уровнем рассуждения подключайте только для написания критического кода.
- Четко ограничивайте область поиска: указывайте агенту конкретные пути к файлам и модулям, чтобы предотвратить хаотичный обход всего репозитория.