«Токеновый рэкет»: почему автономные агенты кодинга сжигают тысячи долларов в бесконечных циклах

Автономный coding-agent может потратить на задачу больше денег, чем стоила бы работа разработчика, который сделал бы её вручную. И проблема здесь не обязательно в дороговизне самой модели, а в том, что агент просто продолжает работать после того, как давно пора было остановиться. Разбираем, почему reasoning-модели уходят в бесконечные циклы правок и как ограничить аппетиты агентов с помощью файла AGENTS.md.

Если нет времени читать разбор целиком, вот краткая схема того, как устроен сбой Token Runaway, почему агенты зацикливаются на правках и как защитить бюджет разработки:

Чтобы перестать сливать бюджеты на бесконечные перегенерации, нужно разобраться, где именно в логике автономного цикла возникает сбой.

Типичный сценарий выглядит обманчиво просто. Разработчик поручает модели рутинную задачу — например, перевести небольшой модуль с JavaScript на TypeScript. Инженер задает спецификацию, запускает агента и уходит пить кофе в ожидании готового Pull Request.

В реальности всё часто идет иначе. Агент меняет одну функцию, после чего решает, что существующий тест недостаточно хорошо покрывает новый сценарий. Добавляет ещё один тест. Затем слегка правит сигнатуру функции, из-за чего ломаются соседние вызовы. Пытаясь починить их, алгоритм начинает переписывать фикстуры, запускает весь тестовый контур заново, ловит новые ошибки и уходит на второй, третий, десятый круг.

Для такого сценария удобно использовать термин Token Runaway — неконтролируемое разрастание агентного цикла и расхода токенов. У модели нет встроенного понимания стоимости вычислений: если оркестратор не задал жестких рамок, цикл может продолжаться гораздо дольше, чем это имеет смысл с точки зрения результата и стоимости. В итоге разработчик видит счет на сотни или тысячи долларов за API, а код проекта оказывается в еще более запутанном состоянии, чем до старта.

По мере того как сессия разрастается логами ошибок, промежуточными диффами и отчетами тестов, агент начинает стремительно терять фокус.

• Быстрый рост стоимости каждого следующего шага: каждый новый запрос может снова включать в контекст значительную часть истории неудачных попыток. Простая правка пары строк в раздутом контексте начинает стоить как отдельный большой запрос.
• Условные «галлюцинации второго порядка»: процесс перестает опираться на исходное ТЗ и начинает анализировать собственные промежуточные выводы из предыдущих итераций. Ошибка, допущенная на третьем шаге, к десятому превращается в фундамент для десятка новых бесполезных правок.

Надеяться, что алгоритм сам распутает клубок через сотню итераций, обычно бесполезно. Чем длиннее сессия, тем меньше шансов, что задача будет решена корректно.

На практике рабочий подход к агентному кодингу строится не на поиске «идеального промпта», а на жестком ограничении среды исполнения.

1. Разделение ролей: тяжелая reasoning-модель пишет только спецификацию и пошаговый план, а непосредственный код генерирует более быстрая и дешевая модель.
2. Четкие границы в AGENTS.md: в корне репозитория создается регламент для ИИ. В нем прямо перечисляют: какие файлы агенту разрешено менять, какие зависимости запрещено добавлять, какие тесты обязательны и сколько попыток дается на одну подзадачу (например, не больше 3 итераций до возврата человеку).
3. Не тащить старую сессию в новую: каждая подзадача выполняется в изолированном контексте. Агент получает только спецификацию текущего шага, целевой файл и команду. Закончил или произошла ошибка — контекст сбрасывается.

Файл AGENTS.md (а также аналогичные механизмы вроде CLAUDE.md или правил Cursor) можно использовать как постоянный набор инструкций для работы агента с проектом. Это не жёсткий технический барьер, но он задаёт правила, которых агент должен придерживаться.

1. Границы изменений (Scope): редактировать только файлы, необходимые для текущей подзадачи. Не менять архитектуру соседних модулей и не добавлять новые библиотеки без отдельного указания.
2. Изолированное тестирование: сначала запускать проверки, непосредственно связанные с изменяемым кодом. Не менять существующие тесты только для того, чтобы получить зелёный результат — сначала искать ошибку в реализации.
3. Лимит итераций: максимум три попытки автоматического исправления одной ошибки компиляции или теста.
4. Возврат управления: если после трёх попыток проблема не решена, остановиться, кратко описать причину и передать задачу разработчику.

Такой подход не устраняет зацикливание полностью, но резко ограничивает его цену: если подзадача не закрывается за несколько итераций, управление сразу возвращается человеку.

Для технического руководства и CTO здесь важнее всего сугубо практический вопрос: сколько агент может потратить без ведома команды и в какой момент мы узнаем, что он пошел не туда?

Слепое доверие к автономным агентам сменяется трезвым инженерным расчетом. Успех автоматизации зависит не от того, сколько свободы дали модели, а от того, насколько точно для нее очертили коридор действий.

Выпустили аудиоверсию этого материала. В ней подробный разбор причин, по которым reasoning-агенты кодинга сжигают тысячи долларов в бесконечных циклах, как работает сбой Token Runaway и как защитить бюджет проекта с помощью файла AGENTS.md.

Слушайте нас на своих любимых подкаст-платформах:

• Mave

• Звук

• Яндекс Музыка

• Pocket Casts