02 февр. 2026 г.·3 мин чтения

Пределы расходов для AI-агентов: как безопасно ограничить цикличные вызовы инструментов

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

Пределы расходов для AI-агентов: как безопасно ограничить цикличные вызовы инструментов

Почему одна задача агента быстро дорожает

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

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

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

Неясные подсказки тоже повышают траты. Задача вроде «разберись с этим и исправь» даёт агенту слишком много свободы для блужданий. Он может просмотреть логи, открыть тикеты, опросить базу, проверить документацию и задать себе уточняющие вопросы, прежде чем действительно продвинется. Много работы — не то же самое, что полезная работа.

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

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

Откуда берутся расходы

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

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

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

Вычисления добавляют ещё слой. Долгие задания загружают воркеры, используют CPU/GPU, хранят временные файлы и пишут логи. Фоновые работники могут продолжать работать после того, как пользователь ушёл. Задача, которая ждёт медленных инструментов 20 минут, может стоить мало в токенах, но много в инфраструктуре.

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

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

Установите три лимита до запуска

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

Начните с жёсткого денежного потолка на задачу. Это простое правило: остановить выполнение, когда суммарные расходы на модель и инструменты пересекли предел. Короткой задаче поддержки можно дать $0.25. Глубокому исследованию — $2.00. Число зависит от работы, но у каждой задачи должен быть потолок до старта.

Затем ограничьте число шагов в одном прогоне. Шагом может быть один ответ модели, один вызов инструмента или один полный цикл через ваш агентный цикл. Держите первый лимит ниже, чем кажется комфортно. Десяти шагов часто достаточно, чтобы понять, на верном ли агент пути. Если для простой вещи требуется 30 шагов — проблема обычно в подсказке, выводе инструмента или в самой задаче.

Время тоже нуждается в отдельном лимите. Некоторые циклы дешевы по шагу, но всё равно тратят деньги, потому что они ждут, повторяют попытки или вызывают медленные инструменты. Установите фиксированное окно времени и остановите запуск по его истечении. Для многих внутренних задач 30–60 секунд достаточно.

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

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

Как выбрать первые лимиты

Fix costly tool loops
Get a second set of eyes on retries, fallbacks, and noisy tool calls.

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

Это даёт потолок. Для большинства команд первый бюджет должен быть небольшой долей этой ценности, а не её полной суммой. Если законченная задача стоит $4, начальный автоматизационный лимит $0.20–$0.80 обычно разумнее, чем $3.50. Дешёвые неудачи учат быстрее, чем дорогие.

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

Практичное стартовое правило: оцените долларовую ценность одного завершённого задания, разрешите агенту тратить 5–20 % от этой стоимости, уменьшите эту сумму для тестовых прогонов и просмотрите реальные логи, прежде чем повышать лимиты.

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

Повышайте лимиты только после просмотра реальных прогонов. Посмотрите 20–30 примеров, а не одну удачную попытку. Если вы одновременно увеличите и траты, и шаги, вы не поймёте, какое изменение помогло. Поднимите один лимит, запустите новую партию и снова проверьте логи.

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

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

Часто задаваемые вопросы

What is a good first dollar cap for one agent task?

Начните с оценки стоимости одного завершённого задания, затем разрешите агенту тратить только 5–20 % от этой стоимости.

Если задача экономит примерно $4 труда, разумный начальный лимит — около $0.20–$0.80. Для ранних тестов ставьте ещё ниже, чтобы дешёвые неудачи быстро показали, где цикл ломается.

How many steps should I allow before I stop a run?

Для нового агента держите лимит шагов низким. Для многих задач поддержки и бэкофисов 8–12 шагов работает хорошо.

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

Should I set a time limit as well as a spend cap?

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

Короткий таймаут 30–90 секунд подходит для многих внутренних задач. Когда время истёкло, остановите запуск, зафиксируйте причину и передайте на проверку человека.

How many retries are too many?

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

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

How do I tell the difference between progress and a bad loop?

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

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

Should every agent task share the same budget and limits?

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

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

Should test runs have the same caps as production?

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

Если убрать лимиты на стадии staging, один сломанный цикл может съесть деньги прежде, чем кто-то заметит.

What should I log on every run?

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

Также отслеживайте расходы по шагам, по инструментам и по моделям — это поможет понять, откуда пришёл всплеск трат.

When should I send the task to a human instead of letting the agent keep trying?

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

Экспорты, массовые правки, отправки и всё, что связано с данными клиентов, должны требовать одобрения. Если lookup остаётся неизвестным после двух попыток — остановите и оставьте короткую заметку для человека.

What is the safest way to roll out a new tool-using agent?

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

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

Пределы расходов для AI-агентов: как безопасно ограничить цикличные вызовы инструментов | Oleg Sotnikov