Лимиты на шаги для AI-агентов и контроль расхода в продакшене

Почему расход растет незаметно

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

Самый частый триггер - таймаут. Инструмент отвечает слишком долго, агент считает вызов неудачным и пробует снова. Потом тот же повтор делает управляющий слой. Если повторные попытки включены у клиента, у шлюза и в логике агента, один сбой быстро превращается в цепочку одинаковых запросов.

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

Обычно расход разгоняют четыре вещи:

• повторный вызов после таймаута
• тот же tool call с теми же параметрами
• растущий контекст с историей сообщений и выводами инструментов
• ошибка инструмента, которую агент принимает за повод попробовать еще раз

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

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

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

Что ограничить до релиза

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

Поэтому ограничения лучше задавать до первого релиза. Особенно в сценариях, где агент ходит во внутренние системы: базу знаний, CRM, биллинг, статусы заказов, внутренние API.

На старте имеет смысл ограничить пять вещей:

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

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

Для поддержки часто хватает такого старта: до 8 шагов на диалог, не больше 2 вызовов поиска по базе, 1 вызов CRM на задачу, таймаут шага 15 секунд, таймаут сессии 2 минуты и не больше 2 повторов на сетевую ошибку. Если агент не уложился, он должен остановиться и вернуть понятный статус: нужен оператор, не хватает данных или инструмент недоступен.

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

Бюджет сессии и лимиты на шаги

Если агент может думать и вызывать инструменты без потолка, счет растет тихо. Пользователь видит один диалог, а внутри уже прошло 12 шагов, несколько повторов и длинная история сообщений. Поэтому лимиты на шаги и бюджет сессии задают в самом начале, а не после первого перерасхода.

Даже для сложных задач жесткий предел нужен. Для большинства рабочих сценариев хватает 6-8 шагов: короткий план, несколько вызовов инструмента, проверка ответа и финальное сообщение. Если агент уперся в лимит, он не должен гадать и пробовать еще раз. Пусть завершает с ясным статусом: что уже найдено, чего не хватает и что лучше уточнить у пользователя.

Оставляйте запас на последний ответ. Хорошее правило - держать 15-20% бюджета нетронутыми до конца сессии. Иначе агент потратит все на поиск и промежуточные действия, а пользователю вернет обрывок или пустой ответ.

На практике удобно делить бюджет на части. Небольшая доля уходит на планирование, основная - на вызовы инструментов, еще часть остается в резерве для финального ответа и одной безопасной повторной попытки. Простая схема вроде 20% на планирование, 60% на инструменты и 20% в резерве уже неплохо работает.

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

Когда сессия подходит к лимиту, режьте контекст. Не переносите в следующий шаг весь сырой вывод из поиска, CRM или базы знаний. Оставляйте короткую выжимку, последние сообщения и только те данные, без которых ответ развалится. Один длинный JSON иногда стоит дороже, чем сам вывод модели.

Правила остановки без гаданий

Агент не должен сам решать, когда ему "еще немного попробовать". В боевой системе это правило приложения, а не промпта. Проверки остановки задают заранее и применяют на каждом шаге.

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

Рабочий минимум выглядит так:

• две одинаковые ошибки подряд - стоп
• повторный вызов того же инструмента с теми же аргументами - стоп
• остатка бюджета не хватает на еще один типичный шаг - стоп
• инструмент молчит дольше лимита времени - вернуть безопасный ответ
• пустой результат повторяется несколько раз - завершить сессию

Правило с бюджетом часто забывают. Команда ставит лимит по шагам, но не проверяет, хватит ли денег на еще один вызов. Если у вас осталось 5 центов, а средний шаг с этой моделью и инструментом стоит 7, новый запрос делать не надо. Сессия должна завершиться до него.

С таймаутами логика такая же. Если поиск по базе или внешний API не отвечают вовремя, агент не должен ждать бесконечно. Лучше вернуть безопасный ответ: попросить повторить запрос позже, отдать частичный результат или передать задачу человеку.

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

Лучше всего хранить эти пороги в конфиге сценария, а не в промпте. Код проверяет условия четко. Промпт только объясняет агенту, как ответить после остановки.

Как настроить повторы без лишних дублей

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

Обычно хватает простого правила: повторяйте только ошибки, похожие на короткий сбой инфраструктуры. Это 429, ответы 5xx и короткие сетевые проблемы вроде таймаута или разрыва соединения. Во всех остальных случаях лучше остановиться сразу и передать ошибку в лог или оператору.

Не повторяйте запрос, если проблема в самих данных. Плохой JSON, неверная схема, отсутствующее поле, 401, 403, 404, неверные аргументы инструмента - все это не лечится второй попыткой. Здесь повтор только раздувает бюджет сессии.

Нормальная настройка обычно такая: не больше 2-3 попыток на один запрос, пауза между ними растет по схеме 1, 2 и 4 секунды, а к паузе добавляется небольшой случайный разброс. После последней неудачи агент завершает шаг, а не крутится по кругу.

Самая частая ошибка прячется не в одном месте, а сразу в трех. SDK повторяет запрос сам, очередь повторяет задачу еще раз, а агент сверху делает свой retry. В логах кажется, что был один сбой, а по факту система отправила 6-9 одинаковых вызовов. Проверьте весь путь запроса и оставьте один уровень повторов, который вы контролируете.

Если инструмент меняет данные, добавьте идемпотентный ключ. Это спасает от дублей, когда ответ потерялся, а действие уже прошло. Простой пример: агент создает тикет в поддержке. Первый запрос дошел до CRM, но сеть оборвалась до ответа. Без идемпотентного ключа второй запрос создаст второй тикет. С ключом система поймет, что это та же операция, и вернет прежний результат.

Пример из поддержки

Клиент пишет в чат: "Где мой заказ?" Бот должен сделать три вещи: найти заказ, сверить статус в CRM и ответить человеку понятным текстом. На бумаге это 5-6 шагов, и сценарий выглядит дешевым.

Проблема начинается, когда CRM отвечает с таймаутом. Агент не понимает, что это временный сбой, и три раза подряд шлет один и тот же запрос. После этого он еще раз обращается к модели и спрашивает, что делать дальше, хотя ответ уже ясен: либо подождать, либо передать случай оператору.

Из-за такой мелочи сессия легко разрастается до 18 шагов вместо 6. Деньги уходят не на один большой запрос, а на цепочку дублей: повторный вызов инструмента, повторная проверка, новый запрос к модели, еще одна попытка сформировать ответ.

Здесь хватает простых рамок: не больше 6 шагов на сессию и не больше 1 повторной попытки для одного и того же запроса в CRM. Полезны и два правила остановки. Если CRM дважды вернула таймаут для одного заказа, агент прекращает повторы. Если после ошибки инструмента агент уже один раз спросил модель, новые запросы к модели он не делает.

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

Что проверить перед запуском

Перед релизом полезно пройтись по сценарию как по чек-листу, а не смотреть только на среднюю стоимость ответа.

Сначала разложите задачу на реальные шаги: вызов модели, поиск по базе знаний, запрос в CRM, постановка задачи в очередь, ожидание вебхука. Для каждого шага запишите, что считается ошибкой и сколько стоит повтор. После этого добавьте в состояние сессии три счетчика: число шагов, токены и деньги. Агент должен читать их перед каждым новым действием.

Дальше проверьте четыре вещи:

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

Хороший запасной ответ звучит просто: "Я не смог завершить проверку за отведенное число шагов. Могу продолжить с более узким запросом или передать задачу оператору". Такой текст снижает число повторов и не провоцирует новый дорогой цикл.

Если вы уже используете AI Router на airouter.kz, удобно держать такие ограничения рядом с аудит-логами и лимитами на уровне ключа. Один OpenAI-совместимый эндпоинт не решает проблему сам по себе, но помогает быстрее увидеть, где именно агент зациклился.

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

Что делать дальше

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

Стартовый набор обычно простой: 4-6 шагов на сессию, 1-2 повторные попытки только для сетевых сбоев, фиксированный бюджет в деньгах или токенах, остановка после повторного вызова того же инструмента и остановка, если за последние 2 шага агент не приблизился к ответу.

Эти числа редко остаются финальными. Но они хорошо ловят лишние циклы в первые дни, когда поведение агента еще неровное.

Дальше смотрите не на среднюю температуру, а на логи реальных сессий. Если 90% запросов укладываются в 3 шага, не давайте лимит 10 без причины. Такой запас почти всегда превращается в дорогие петли. Сначала зажмите рамки, потом расширяйте их там, где это правда нужно.