Снижение затрат на ИИ-агентов начинается не с замены модели, а с проверки расписания запусков, жизненного цикла сессий, повторного контекста и обработки блокеров. В производственной системе из 49 агентов изменение этих правил снизило прогнозируемую стоимость API с $811.52 до $457.25 в день.
За 24 часа система обработала 772,308,810 входных токенов, включая 708,412,416 кэшированных, и создала 4,594,415 выходных токенов. Стоимость составила $811.52. По сумме можно было решить, что проблема в тарифе модели. Журнал запусков показал другую причину: служебные агенты просыпались без новой задачи, старые сессии оставались активными, а неизменившиеся блокеры снова запускали обработку.
Стоимость отражает правила эксплуатации
Счёт API показывает не только объём полезной работы. В него попадают расписания, повторы, пустые проверки состояния, чрезмерный контекст и незавершённые сессии. Поэтому агрегированной суммы недостаточно. Каждый запуск нужно связать с причиной, результатом и изменением состояния.
OpenAI относит трассировку и наблюдаемость агентных процессов к средствам отладки и оптимизации. На практике журнал должен отвечать на простые вопросы: что запустило агента, какую задачу он получил, какой артефакт создал и почему завершил работу или запросил помощь.
- Триггер: расписание, событие или повтор после ошибки.
- Контекст: только данные, необходимые для текущей задачи.
- Результат: проверяемый артефакт, решение или эскалация.
- Завершение: закрытие сессии после принятого результата.
Кэширование тоже требует правильной интерпретации. OpenAI указывает, что кэш промптов снижает стоимость и задержку при повторном использовании префиксов. Это полезная оптимизация для нужных запросов. Но скидка на кэш не превращает пустой запуск в полезный.
Какие изменения дали результат
Руководящие агенты сохранили почасовой режим. Остальные стали запускаться по событиям и задачам. После завершения работы неиспользуемые сессии закрывались. Старые блокеры приводились к единому состоянию и больше не будили систему только для повторного сообщения.
По следующим 14.13 часа прогноз составил 326,697,063 входных токенов в день, 274,728,048 кэшированных входных токенов, 2,661,576 выходных токенов и $457.25 стоимости. Расчётная экономия достигла $354.27 в день, $10,628.14 в месяц и 43.7%.
Полезно сопоставить этот аудит с разбором того, почему основную часть счёта может создавать контекст. Повтор истории и слишком широкие инструкции увеличивают вход, даже если ответ короткий. Для инфраструктурной части подходит и подход FinOps к забытым ресурсам: у каждого потребления должен быть владелец, назначение и условие отключения.
Как закрепить экономию в регламенте
Для каждого агента зафиксируйте основание запуска, допустимую частоту, состав контекста, модель, условие завершения и порядок эскалации. В отчёте связывайте токены и стоимость с типом задачи и принятым результатом. Это позволяет отличить рост полезной нагрузки от скрытой эксплуатационной ошибки.
Прогноз экономии тоже требует проверки. Материал про защиту от выдуманных фактов ИИ-агентов предлагает нужный принцип: источник, вычисление и независимая проверка должны быть частью результата. Сохраните исходное окно наблюдения, новые правила, сопоставимый период после изменения и формулу расчёта.
Добавьте к регламенту операционную панель. Она должна показывать полезные и пустые запуски, незакрытые сессии, повторяющиеся причины блокировки, расход по ролям и долю работы, принятой владельцем процесса. Уведомление должно возникать не при любом росте токенов, а когда меняется отношение затрат к завершённым задачам. Еженедельный просмотр панели помогает заметить, что новая интеграция создала повторный цикл или что агент продолжает читать данные после завершения задачи. Отдельно проверяйте ручные перезапуски. Они часто указывают на слабое условие завершения или неясную ответственность. Такой мониторинг не заменяет аудит, но не позволяет системе вернуться к исходным привычкам после разовой оптимизации.
Итогом аудита должна стать небольшая таблица эксплуатации. В ней видно, какие агенты работают по расписанию, какие только по событию, когда закрывается сессия, как снимается блокер и какие задачи оправдывают дорогую модель. Назначенный владелец регулярно сверяет правила с фактическими запусками и документирует отклонения. Это сохраняет экономию при добавлении новых агентов, задач и интеграций.
Частые вопросы
Проверьте причины запусков, частоту пробуждений, срок жизни сессий, повторный контекст, блокеры, повторы после ошибок и выбор модели для каждой задачи.
Нет. Кэш может удешевлять нужные запросы, но не оправдывает лишние. Сначала исключают пустые запуски, затем оптимизируют оставшийся поток.
Сначала следует подтвердить необходимость и границы процесса. После этого модели сравнивают на типовых задачах и проверяют сохранение качества принятого результата.
Сохраните исходный период, изменённые правила, сопоставимый период после настройки, категории токенов, стоимость и расчёт. Результат должен проверить отдельный исполнитель.
Если расходы системы растут быстрее полезного результата, закажите консультацию, чтобы разобрать запуски, контекст и правила маршрутизации моделей.
