Агент зациклился и потратил бюджет: как это ловить заранее

Знакомая история: оставили агента с задачей, вернулись через полчаса, а половина месячного бюджета ушла. В логе — двадцать одинаковых попыток прочитать один и тот же файл.

Это не редкость и не поломка. Разберём, откуда берётся и как подстраховаться.

Почему агент зацикливается

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

Инструмент возвращает одно и то же. Команда падает с ошибкой, агент делает вывод «надо попробовать иначе», пробует почти то же самое, получает ту же ошибку. Цикл замыкается.

Контекст переполнился и модель потеряла нить. На длинной сессии ранние шаги вытесняются, и агент перестаёт помнить, что уже пробовал. С этого момента он способен повторять один и тот же путь бесконечно.

Модель не тянет задачу. Дешёвая модель на сложной задаче может уходить в круги: не может ни решить, ни остановиться. Это, кстати, скрытая цена экономии — формально запросы дешевле, фактически их может оказаться намного больше.

Как заметить

Самое простое — смотреть на расход не в конце месяца, а в процессе.

curl https://api.zukko.pro/v1/balance -H "Authorization: Bearer fetch_ваш_ключ"

Ответ содержит точный баланс аккаунта в центах (поле balance_cents). Агенты обычно работают в потоковом режиме, а у потоковых ответов нет заголовков стоимости, так что следить за расходом удобнее именно так или через GET /v1/usage. В кабинете есть разбивка по моделям и история запросов. Резкий скачок числа запросов в одной задаче при отсутствии прогресса — верный признак цикла.

Признак на глаз: агент делает пятый шаг, а в его рассуждениях появляются слова «попробую ещё раз», «видимо, дело в другом», «давайте проверим снова». Если он говорит это дважды подряд — останавливайте.

Три способа подстраховаться

Лимит на ключ. Самый надёжный. Отдельный ключ под агента с дневным потолком — тогда цикл упрётся в лимит, а не в ваш баланс. Настраивается в кабинете: у ключа есть дневное и месячное ограничение, и после исчерпания он просто перестаёт работать — запросы получают 429 key_daily_limit_reached (сброс в 00:00 UTC) или key_monthly_limit_reached.

Заодно имеет смысл ограничить список моделей, доступных этому ключу: агент не сможет случайно уйти на самую дорогую.

Отдельный ключ на каждый проект. Тогда перерасход локализован: лимит сработает только у ключа, который зациклился, а остальные продолжат работать. Учтите, что история в /v1/usage общая на аккаунт (все ключи вместе, фильтра по ключу нет), и баланс тоже один на аккаунт. Чтобы разделить расход по проектам, логируйте у себя X-Zukko-Cost-Micros по каждому ключу (для нестриминговых запросов) или заведите отдельный аккаунт.

Ограничение числа шагов в самом агенте. Почти все харнессы позволяют задать максимум итераций. Значение по умолчанию часто щедрое; двадцать–тридцать шагов на задачу — разумный потолок для начала.

Что делать, когда уже случилось

Прервите сессию, не дожидаясь завершения. Начните новую — с конкретикой вместо общей формулировки.

Плохо: «разберись, почему падают тесты». Хорошо: «тест test_weekly_stats падает с TypeError: days must be int. Посмотри app/models.py, поле days объявлено строкой. Поправь тип и запусти этот тест».

Разница в расходе между этими двумя формулировками бывает очень большой.

Если задача действительно неразрешима без вас — скажите агенту об ограничении прямо: «переменной DB_URL в окружении нет, считай, что база недоступна». Это избавляет его от бесплодных попыток.

Про выбор модели

Соблазн взять модель подешевле на сложную задачу понятен, но арифметика обычно против. glm-5.3 при $0.10 за миллион втрое дешевле флагмана — но если она уходит в цикл на десять лишних шагов, вы платите больше, чем заплатили бы claude-opus-5-5 за один правильный.

Разумная схема — дешёвая модель на механические шаги, флагман на те, где надо разобраться. Подробнее — в сравнении GLM 5.3 и Opus 5.5→.