ИИ-агент в production: как не получить счёт на 50 000 ₽ за ночь

Агент запустили в пятницу вечером. К субботнему утру он накрутил $340 API-вызовов — попал в логическую петлю и не мог выйти. Такой сценарий регулярно всплывает в обсуждениях на Reddit и GitHub Issues среди тех, кто деплоит первые production-агенты. Проблема структурная.

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

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

Обычный бэкенд-сервис при ошибке бросает исключение. Агент при ошибке генерирует новую гипотезу.

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

После первых недель с Dynamic Workflows на Claude Code сообщество зафиксировало схожую картину: один ран сжигал 20% недельного лимита Max-плана ($200/мес) за сутки. Тред на r/ClaudeCode с заголовком «безумно дорого» собрал дружный консенсус — не жалоба одного человека.

Anthropic сама предупреждает в документации: Dynamic Workflows потребляет «существенно больше токенов обычного», первый запуск блокируется подтверждением, а rate-limit при параллельной нагрузке обрывает агентов без авторетрая. При логической ошибке в оркестраторе агенты продолжают работать вхолостую до исчерпания бюджета.

Решается системно — до деплоя, а не разбором счётов постфактум.

Детектор H2 (Missing Constraint Scaffolding) — самый дорогостоящий класс дефекта в конфигурации агента. Агент без ограничения завершения уходит в бесконечный цикл выполнения, исчерпывая API-лимиты. Достаточно одного двусмысленного условия в рабочем цикле.

Lintlang — статический анализатор конфигураций агентов и системных промптов. Ключевое свойство: работает без единого вызова к LLM, не сжигает токены в процессе проверки. Встраивается в CI/CD и блокирует деплой дефектных конфигураций на этапе сборки.

Кроме H2 Lintlang ловит:

Важная деталь: анализатор не просто сообщает о дефекте, а выдаёт конкретные предложения по исправлению на естественном языке. «Найден H2» без инструкции по фиксу — бесполезно. Анализатор должен закрывать этот шаг.

Аналог для тех, у кого нет готового инструмента: явно проверить наличие условия завершения в каждом рабочем цикле и ограничения на максимальное число итераций. Это минимум — но даже он режет большинство runaway-сценариев.

Агент тратит токены не только на генерацию ответа. Он тратит их на чтение контекста при каждом вызове. Чем больше контекст — тем дороже каждый шаг рабочего цикла.

Стандартный RAG отдаёт флагманской модели всё, что нашёл. Двухуровневый сначала фильтрует:

Результат: −70…90% входных токенов. Флагман видит суть, а не весь документ целиком.

Стандартные MCP-инструменты общаются через JSON/XML — схемы выразительные, но токено-тяжёлые. Вложенный JSON-объект с описанием инструмента легко занимает 300–500 токенов там, где достаточно 30.

AINL (AI Native Language) компилирует графы выполнения агента в специализированный DSL высокой плотности. Интеграция через MCP-протокол — без переписывания архитектуры, только конфигурация.

Практический эффект: ×2–5 экономия токенов на задачу. Плюс — предсказуемость маршрутизации за счёт жёсткой схемы DSL.

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

Классический FinOps смотрит на стоимость токена и выбирает более дешёвую модель. У агентов это ловушка:

Агент A: $0.10 за попытку, pass-rate 30% → стоимость успешного результата $0.33Агент B: $2.00 за попытку, pass-rate 90% → стоимость успешного результата $2.22

Агент A «дешевле» в расчёте на токен. Но в расчёте на закрытую задачу — дороже в 6.7 раза. И это без учёта стоимости повторных запусков при провале, ручной обработки ошибок и цены доверия к результату.

Cost Per Success (CPS) — $ за успешно выполненную задачу. Правильная ось оптимизации. Без CPS команда стабильно выбирает дешёвую модель и потом удивляется счёту.

Инструменты для сбора CPS: Langfuse (облачная версия бесплатна до определённого объёма), Phoenix от Arize, любой APM с кастомными метриками. Выбор инструмента вторичен. Важно, чтобы CPS собирался с первого дня, а не ретроспективно — после инцидента данных нет.

Два механизма, закрывающие 80% риска:

Дневной бюджетный гейт. Жёсткий лимит расходов за 24 часа. При достижении — агент останавливается, уведомляет, ждёт подтверждения. evey-cost-guard и аналоги реализуют это за несколько строк конфигурации. Порог выбирается от стоимости ручного аналога: если менеджер делает ту же задачу за 500 ₽/день — агент за 2 000 ₽ уже сигнал для разбора, не норма.

Approval gate на критические команды. Операции с необратимыми последствиями — запись в БД, отправка сообщения, деплой — требуют явного подтверждения. Агент выполняет разведывательные шаги автономно, но перед финальным действием делает паузу. В нормальном потоке это не ощущается — зато при аномальном останавливает каскад.

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

Все механизмы выше операционные — снижают расходы сейчас. Дистилляция работает иначе.

Флагманская модель производит «золотые» ответы. Эти ответы собираются автоматически и используются для дообучения локальной малой модели (Llama 3 8B и аналоги). Со временем для повторяющихся задач флагман не нужен — хватает локальной.

В долгосроке маржинальные затраты на типовые задачи идут к нулю. Флагман остаётся для нетипового.

Дистилляция требует накопленных данных — минимум 500 «золотых» ответов с pass-rate ≥ 85% по конкретному классу задач. Но архитектуру под неё закладывать нужно сразу: логировать что выполнялось, когда и с каким результатом. Без этих логов дистиллировать будет нечего.

Минимальный контур для production-агента:

Минимум, без которого первые выходные в production превращаются в дорогой опыт.

Автономность агента — финансовый риск до тех пор, пока нет явных ограничений. Агент, который «сам справится», сам и накрутит счёт при первой нестандартной ситуации.

CPS важнее стоимости токена. Дешёвая модель с низким pass-rate системно обходится дороже — это просто не видно в одной строке счёта, а проявляется в сумме повторных запусков и ручных исправлений.

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

Можно ли контролировать стоимость агента без специальных инструментов мониторинга?
Технически — да, через встроенные лимиты API напрямую. Практически — нет: без CPS непонятно, что оптимизировать. Даже простой счётчик задач + счётчик затрат в Google Sheets лучше, чем ничего. Langfuse в облачной версии бесплатен до определённого объёма — хорошая точка входа.

Чем AINL отличается от стандартных tool descriptions в MCP?
Tool descriptions в MCP — человекочитаемый JSON: выразителен для разработчика, но токено-тяжёл для модели. AINL — DSL, оптимизированный под потребление языковой моделью: та же семантика, в 2–5 раз меньше токенов.

Когда начинать дистилляцию?
Когда есть ≥ 500 «золотых» ответов по типовым задачам и pass-rate стабильно выше 85%. Раньше — данных мало, дообучение даст переобученную модель, которая плохо обобщает.

Как выбрать лимит для дневного бюджетного гейта?
От стоимости ручного аналога. Агент за 500 ₽/день при ручной работе за 2 000 ₽ — норма. Агент за 5 000 ₽/день при ручном аналоге за 500 ₽ — что-то сломалось, гейт должен уведомить до этой отметки.

Применимы ли эти механизмы к self-hosted моделям?
Частично — и смысл смещается. На локальной модели нет счёта за токены, поэтому «экономия токенов» означает другое: меньше VRAM, меньше латентность, быстрее ответ. RAG-фильтрация и AINL-сжатие здесь актуальны — не ради денег, а ради скорости и стабильности под нагрузкой. Lintlang и approval gate работают без изменений: бесконечный цикл на локалке так же ломает процесс, просто сжигает не бюджет API, а CPU/GPU. CPS считать тоже имеет смысл — стоимость задачи в часах железа или электричестве. Бюджетный гейт в классическом виде не нужен, но ограничение на время выполнения или число итераций — его аналог.

Какой подход к контролю токен-бёрна используете — или пока всё на доверии к модели? Интересен реальный опыт, особенно сценарии, которые пошли не так.

Архитектуру production-агентов разбираю в Telegram: @dmitra_ai