1. Главная
  2. Блог
  3. ИИ-агенты для бизнеса
  4. Стоимость эксплуатации ИИ-агента: почему счёт непредсказуем

Стоимость эксплуатации ИИ-агента: почему счёт непредсказуем

10 августа 2026
10

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

Базовая методика — токены, входящий и исходящий контекст, облако против сервера — разобрана в статье «Сколько стоит эксплуатация ИИ-решения». Здесь только то, что специфично для агентов.

Из чего складывается стоимость задачи

Формула для прикидки:

```

стоимость задачи ≈ Σ по шагам (контекст шага + ответ шага) × ставка

```

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

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

Что попадает в контекст каждого шага:

  • системная инструкция;
  • описания всех переданных инструментов;
  • постановка задачи;
  • накопленные результаты предыдущих вызовов;
  • история диалога, если она есть.

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

Что раздувает счёт

Причина Влияние Что делать
Зацикливание катастрофическое лимит шагов и потолок расходов
Накопление контекста сильное структурированное состояние вместо истории
Много инструментов постоянная надбавка передавать релевантные под этап
Результаты вызовов целиком сильное отдавать модели только нужные поля
Дорогая модель на простых шагах среднее маршрутизация по сложности
Повторный разбор одних данных среднее кешировать неизменное

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

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

Как считать до запуска

Средняя стоимость мало о чём говорит — важен разброс.

  1. Прогнать реальные задачи на прототипе, не менее нескольких десятков разнородных.
  2. Записать число шагов по каждой.
  3. Взять не среднее, а верхнюю границу: сколько шагов у самых длинных задач.
  4. Умножить на ожидаемый поток.
  5. Заложить долю аномалий — задач, где агент пошёл длинным путём.

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

Чем ограничить

Меры ставятся до запуска, а не после инцидента:

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

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

Как снизить, не потеряв качество

Структурированное состояние вместо переписки. Вместо всей истории передаётся карточка задачи: что известно, что осталось. Самый эффективный рычаг — см. «Память ИИ-агента».

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

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

Релевантные инструменты под этап. Не весь набор с каждым запросом, а те, что уместны на текущем шаге.

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

Ограничение длины ответа там, где развёрнутый ответ не нужен.

Когда агент дороже пользы

Честная проверка перед запуском: стоимость обработки одной задачи агентом против стоимости ручной обработки.

Агент невыгоден, когда:

  • задача редкая, а настройка и сопровождение постоянны;
  • ручная обработка занимает минуты и стоит дёшево;
  • поток мал, а разработка и поддержка — фиксированные расходы;
  • почти всё требует подтверждения человеком, и экономия времени невелика.

В таких случаях лучше ассистент или обычная автоматизация. Решение о классе решения — «Агент или чат-бот».

Пример расчёта одной задачи

Числа условные, важна механика. Примем: системная инструкция — 500 токенов, описания шести инструментов — 1 500, постановка задачи — 300, средний результат вызова — 350, ответ модели на шаге — 150.

Задача из шести шагов, вся история в контексте:

Шаг Входящий контекст Исходящий
1 2 300 150
2 2 800 150
3 3 300 150
4 3 800 150
5 4 300 150
6 4 800 150
Итого 21 300 900

Входящих токенов в 23 раза больше исходящих. Это типичное соотношение для агентов, и оно определяет, на что смотреть при оптимизации: сокращать нужно контекст, а не длину ответов.

Прикидка месячного расхода:

```

на задачу: 21 300 входящих + 900 исходящих

при 2 000 задач в месяц:

входящих: 42,6 млн токенов

исходящих: 1,8 млн токенов

```

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

Поправка на разброс. Шесть шагов — это типичная задача. Прогон на прототипе обычно даёт такую картину:

Доля задач Шагов Вклад в расход
70 % 4–6 умеренный
25 % 7–12 заметный
5 % 15–30 непропорционально большой

Последние 5 % при 25 шагах несут контекст, выросший до 12 000 токенов на шаге, и дают вклад, сопоставимый с четвертью всего расхода. Планирование по среднему занижает счёт систематически — считать нужно по распределению.

Что даёт переход на структурированное состояние. Если вместо накопления истории передавать карточку задачи (~150 токенов вместо растущего хвоста), входящий контекст на каждом шаге останется около 2 450:

```

6 шагов × 2 450 = 14 700 вместо 21 300 — экономия ~30 %

```

На длинных задачах эффект сильнее: при 25 шагах разница становится трёхкратной. Механика — в статье «Память ИИ-агента».

Частые вопросы

Почему агент дороже чат-бота в эксплуатации?

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

Как посчитать стоимость до разработки?

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

Что делать, если счёт скачет от месяца к месяцу?

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

Какой самый эффективный способ снизить расходы?

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

Нужен ли лимит расходов, если агент работает стабильно?

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

Что дальше

Базовая методика расчёта — «Сколько стоит эксплуатация ИИ-решения». Главная причина неожиданных счетов — «Зацикливание ИИ-агента». Как сократить контекст — «Память ИИ-агента». Общая структура затрат проекта — «Структура затрат на внедрение ИИ».

Расчёт эксплуатации до разработки входит в этап discovery при разработке и внедрении ИИ-агентов.