«Токеновый рэкет»: почему автономные агенты кодинга сжигают тысячи долларов в бесконечных циклах
Автономный coding-agent может потратить на задачу больше денег, чем стоила бы работа разработчика, который сделал бы её вручную. И проблема здесь не обязательно в дороговизне самой модели, а в том, что агент просто продолжает работать после того, как давно пора было остановиться. Разбираем, почему reasoning-модели уходят в бесконечные циклы правок и как ограничить аппетиты агентов с помощью файла AGENTS.md.
TL;DR: Вся статья на одной схеме
Если нет времени читать разбор целиком, вот краткая схема того, как устроен сбой Token Runaway, почему агенты зацикливаются на правках и как защитить бюджет разработки:
Чтобы перестать сливать бюджеты на бесконечные перегенерации, нужно разобраться, где именно в логике автономного цикла возникает сбой.
Анатомия сбоя: как простой рефакторинг превращается в счета на тысячи долларов
Типичный сценарий выглядит обманчиво просто. Разработчик поручает модели рутинную задачу — например, перевести небольшой модуль с JavaScript на TypeScript. Инженер задает спецификацию, запускает агента и уходит пить кофе в ожидании готового Pull Request.
В реальности всё часто идет иначе. Агент меняет одну функцию, после чего решает, что существующий тест недостаточно хорошо покрывает новый сценарий. Добавляет ещё один тест. Затем слегка правит сигнатуру функции, из-за чего ломаются соседние вызовы. Пытаясь починить их, алгоритм начинает переписывать фикстуры, запускает весь тестовый контур заново, ловит новые ошибки и уходит на второй, третий, десятый круг.
Для такого сценария удобно использовать термин Token Runaway — неконтролируемое разрастание агентного цикла и расхода токенов. У модели нет встроенного понимания стоимости вычислений: если оркестратор не задал жестких рамок, цикл может продолжаться гораздо дольше, чем это имеет смысл с точки зрения результата и стоимости. В итоге разработчик видит счет на сотни или тысячи долларов за API, а код проекта оказывается в еще более запутанном состоянии, чем до старта.
Экономика контекста: почему длинные сессии убивают точность
По мере того как сессия разрастается логами ошибок, промежуточными диффами и отчетами тестов, агент начинает стремительно терять фокус.
Здесь работают два фактора:
- Быстрый рост стоимости каждого следующего шага: каждый новый запрос может снова включать в контекст значительную часть истории неудачных попыток. Простая правка пары строк в раздутом контексте начинает стоить как отдельный большой запрос.
- Условные «галлюцинации второго порядка»: процесс перестает опираться на исходное ТЗ и начинает анализировать собственные промежуточные выводы из предыдущих итераций. Ошибка, допущенная на третьем шаге, к десятому превращается в фундамент для десятка новых бесполезных правок.
Надеяться, что алгоритм сам распутает клубок через сотню итераций, обычно бесполезно. Чем длиннее сессия, тем меньше шансов, что задача будет решена корректно.
Паттерн изоляции: AGENTS.md и сброс сессий
На практике рабочий подход к агентному кодингу строится не на поиске «идеального промпта», а на жестком ограничении среды исполнения.
Рабочий фреймворк включает три правила:
- Разделение ролей: тяжелая reasoning-модель пишет только спецификацию и пошаговый план, а непосредственный код генерирует более быстрая и дешевая модель.
- Четкие границы в AGENTS.md: в корне репозитория создается регламент для ИИ. В нем прямо перечисляют: какие файлы агенту разрешено менять, какие зависимости запрещено добавлять, какие тесты обязательны и сколько попыток дается на одну подзадачу (например, не больше 3 итераций до возврата человеку).
- Не тащить старую сессию в новую: каждая подзадача выполняется в изолированном контексте. Агент получает только спецификацию текущего шага, целевой файл и команду. Закончил или произошла ошибка — контекст сбрасывается.
Файл AGENTS.md (а также аналогичные механизмы вроде CLAUDE.md или правил Cursor) можно использовать как постоянный набор инструкций для работы агента с проектом. Это не жёсткий технический барьер, но он задаёт правила, которых агент должен придерживаться.
Практический шаблон защиты от бесконтрольных циклов может выглядеть так:
- Границы изменений (Scope): редактировать только файлы, необходимые для текущей подзадачи. Не менять архитектуру соседних модулей и не добавлять новые библиотеки без отдельного указания.
- Изолированное тестирование: сначала запускать проверки, непосредственно связанные с изменяемым кодом. Не менять существующие тесты только для того, чтобы получить зелёный результат — сначала искать ошибку в реализации.
- Лимит итераций: максимум три попытки автоматического исправления одной ошибки компиляции или теста.
- Возврат управления: если после трёх попыток проблема не решена, остановиться, кратко описать причину и передать задачу разработчику.
Такой подход не устраняет зацикливание полностью, но резко ограничивает его цену: если подзадача не закрывается за несколько итераций, управление сразу возвращается человеку.
Что это значит для бизнеса и CTO
Для технического руководства и CTO здесь важнее всего сугубо практический вопрос: сколько агент может потратить без ведома команды и в какой момент мы узнаем, что он пошел не туда?
Слепое доверие к автономным агентам сменяется трезвым инженерным расчетом. Успех автоматизации зависит не от того, сколько свободы дали модели, а от того, насколько точно для нее очертили коридор действий.
Для тех, кто предпочитает слушать
Выпустили аудиоверсию этого материала. В ней подробный разбор причин, по которым reasoning-агенты кодинга сжигают тысячи долларов в бесконечных циклах, как работает сбой Token Runaway и как защитить бюджет проекта с помощью файла AGENTS.md.
Слушайте нас на своих любимых подкаст-платформах:
• Звук