ИИ-агенты в корпоративном процессе: как задать бюджет токенов, лимиты и сигнал остановки

Начните не с токенов, а с единицы результата

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

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

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

В API токены тоже не образуют единого счётчика. Официальная справка OpenAI отдельно определяет входные, выходные, кэшированные входные и reasoning-токены; цена и ограничения зависят от модели и категории (справка по токенам). Поэтому видимый короткий ответ не доказывает ни малую стоимость, ни малую вычислительную работу. Агрегированный расход следует наблюдать вместе с моделью, временем, проектом и количеством запросов; именно для такой детализации предназначены usage и costs отчёты, а финансовая сверка идёт по данным расходов, а не по приблизительному пересчёту текста (Usage API).

Для одного маршрута полезно записать паспорт до первой нагрузки:

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

Бюджет одного запуска — контракт из четырёх границ

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

×

Четыре границы удобно утверждать вместе.

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

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

3. Время. У запуска должен быть deadline. Он ограничивает не только расходы, но и плохой пользовательский опыт: внешний сервис может ждать ответа, а очередь — расти. Rate limits провайдера ограничивают пропускную способность аккаунта, но не заменяют дедлайн конкретного бизнес-процесса (документация по rate limits).

4. Деньги. Это максимальная допустимая стоимость одного запуска и, отдельно, дневной или сменный лимит сценария. Сумму считают по текущей ставке выбранного провайдера и наблюдаемым категориям расхода. Не используйте в документации вечную «цену за запрос»: тарифы и состав счётчиков меняются.

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

стоимость запуска = некэшированный вход × ставка входа + кэшированный вход × ставка кэша + выход × ставка выхода + стоимость инструментов.

Если провайдер отдельно тарифицирует reasoning, кэш-запись, поиск или выполнение кода, эти части добавляют как самостоятельные строки. Формула полезна не тем, что выдаёт точную сумму заранее, а тем, что заставляет назвать допущения: какие документы войдут в контекст, сколько попыток разрешено, когда используется более дорогая модель и что считаем инструментом.

Кэширование также не нужно превращать в обещанную скидку. Некоторые API выделяют повторно использованный общий префикс как отдельную категорию; при этом порог, срок жизни и тариф зависят от модели. В официальном описании prompt caching OpenAI говорится, что кэшированный вход наблюдается в usage отдельно и применяется к повторяемым префиксам (Prompt Caching). Практический вывод проще: держите неизменяемую общую инструкцию и справочные материалы в стабильном порядке, измеряйте долю кэшированного входа и не жертвуйте актуальностью данных ради потенциальной экономии.

Почему нельзя заменить четыре лимита одним

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

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

Качество должно участвовать в stop-сигнале

Соблазнительно считать, что каждый дополнительный шаг повышает шанс на хороший ответ. Для агентных маршрутов это ненадёжное допущение. Исследование расходов на агентные задачи программирования наблюдает существенный разброс затрат между запусками одной задачи и не находит простой связи «больше токенов — выше точность» (Bai et al., 2026). Это не доказательство для договорного документооборота, но веская методическая причина не покупать дополнительную попытку без измеряемого критерия.

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

×

Выберите одно из трёх конечных состояний до запуска:

У fallback должна быть своя граница. Нельзя называть fallback «безопасным» и запускать в нём тот же дорогой цикл с другой инструкцией. Например, после двух безрезультатных обращений агент может сформировать список недостающих полей и открыть задачу оператору; он не должен бесконечно придумывать альтернативные формулировки документа. Разница между осмысленной деградацией и бесконечной попыткой — в заранее записанном конечном состоянии.

Проверка качества и правило остановки также нужны для честного сравнения моделей. Если одна модель запускается до тех пор, пока не выдаст приемлемый ответ, а другая останавливается после первой ошибки, сравнение цен неверно. Сравнивайте стоимость принятой единицы результата при одинаковых лимитах, той же тестовой выборке и одинаковом праве на эскалацию. Препринт о бюджетно-адаптивной надёжности агентов приходит к схожему методическому выводу: фиксированная комбинация модели и техники не является лучшей для всех задач (Cost-Aware Adaptive Reliability).

Как утвердить бюджет до масштабирования

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

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

Дальше полезен не один «средний» показатель, а три среза:

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

Не называйте перцентиль гарантией. Он описывает конкретную тестовую выборку и меняется с моделью, тарифом, входными данными и интеграциями. Зато он даёт ИТ-директору аргумент для первого потолка: например, пилот допускает расходы не выше консервативного порога на один запуск и небольшой дневной лимит, пока не накоплены реальные данные.

Затем утвердите карту сценария. Её можно включить в архитектурную запись, карточку процесса или регламент эксплуатации.

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

Вопросы, которые не решает бюджет

Бюджет не отвечает на вопрос, можно ли передавать данные конкретному провайдеру, и не заменяет контроль доступа. До запуска надо отдельно определить, какие документы разрешены в контексте, где хранятся файлы и логи, кто имеет право менять инструменты и какие действия требуют подтверждения. Эти темы раскрыты в материалах НТА о жизненном цикле памяти ИИ-агента и контроле доступов ИИ-ассистента.

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

Эксплуатационный контур: как не потерять бюджет между пилотом и процессом

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

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

Полезно заранее договориться о словаре причин. «Ошибка агента» почти всегда слишком общая формулировка. Разделите как минимум: неподходящий вход; отсутствие разрешённого источника; техническая недоступность инструмента; исчерпание временного лимита; исчерпание лимита шагов; исчерпание денежного лимита; непрохождение критерия качества; ручная отмена. Одно событие может иметь несколько причин, но первичная причина должна быть фиксированной. Иначе команда начнёт улучшать модель в ситуации, где проблема была в задержке OCR, либо поднимать дневной бюджет там, где оператору не хватает обязательного поля во входном документе.

Контекст — это ресурс, а не бесплатная справка

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

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

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

Повторы, ретраи и параллельные ветви

Почти любой агентный маршрут содержит повтор: сетевой запрос может не ответить, модель может вернуть невалидную структуру, инструмент может потребовать уточнения. Проблема начинается, когда все повторы выглядят одинаково в логе и имеют одинаковое право на расход. У каждого типа повтора должна быть причина и отдельный максимум. Технический ретрай внешнего сервиса отличается от повторной генерации; повторная генерация отличается от смены стратегии; смена стратегии отличается от передачи оператору. Если эти вещи объединить в «retry», ограничение три попытки не скажет, выполнил ли агент три полезные работы или трижды повторил ошибку.

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

Параллельные ветви требуют отдельного внимания. Два параллельных поиска могут сократить задержку, но удвоить расходы; параллельные варианты ответа могут быть полезны для оценки, но не должны маскировать отсутствие критерия выбора. В карте сценария фиксируют максимальную параллельность, способ объединения результатов и правило отмены остальных ветвей, если качественный результат уже получен. Иначе «ускорение» превращается в скрытый мультипликатор бюджета. При анализе учитывайте не только среднее число вызовов, но и пиковое число одновременных запусков: именно оно столкнётся с лимитами провайдера и внутренней очередью.

Бюджет и человеческая очередь должны быть связаны

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

Назначьте владельца очереди и целевое время реакции. Это не означает, что человек обязан исправить каждый ответ немедленно. У некоторых сценариев допустима отложенная обработка, у других — временная остановка всей партии. Но правило должно быть видно до запуска. Например, извлечение данных из договора может создать черновик с пометкой «нужна проверка», а отправка платежа или изменение прав доступа при первом же исключении должна остановиться без выполнения действия. Бюджетный stop и риск-ориентированная эскалация дополняют друг друга: первый контролирует ресурс, вторая — последствия.

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

Как пересматривать пределы без «ползучего» расширения

Лимит — это не константа, высеченная в конфигурации, но и не число, которое меняют после каждого раздражающего стопа. Установите период пересмотра и событие внеочередного пересмотра. Обычный пересмотр происходит после накопления репрезентативной серии запусков или изменения модели, тарифа, контекста, инструмента либо типа входа. Внеочередной — при резком росте остановок, неожиданных расходах, изменении права на действие или инциденте с данными. Изменение фиксирует владелец сценария; в записи остаются старый порог, новая причина и ожидаемый эффект.

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

Полезен режим «песочницы расходов» для новой версии маршрута. Сначала версия получает меньший дневной лимит, ограниченный круг входов и отдельную метку в telemetry. Результаты не смешиваются с основной версией, пока не подтверждены качество и управляемость исключений. Это не заменяет тестирование безопасности и не делает новую версию безрисковой; это способ не выдать эксперимент за нормальную эксплуатацию. Когда версия становится основной, прежняя должна быть либо отключена, либо иметь явно ограниченную роль fallback — иначе два похожих сценария начинают расходовать бюджет по разным правилам.

Минимальный отчёт для владельца сценария

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

В отчёте не стоит публиковать содержимое пользовательских запросов и документов ради наглядности. Владелец обычно принимает решение по агрегированным техническим и процессным признакам; доступ к отдельному примеру нужен только тем, кто расследует исключение по правилам данных. Так наблюдаемость остаётся полезной, но не становится новым хранилищем чувствительной информации. Если организация использует несколько провайдеров, нормализуйте не коммерческие ставки, а структуру события: вход, выход, кэш при наличии, число инструментов, время, итог качества, причина stop. Тогда сравнение не зависит от названия полей конкретного API.

Тест понедельником: заполните одну строку до пилота

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

На первой неделе не оптимизируйте среднюю цену. Сначала убедитесь, что у каждого stop есть понятная причина, у каждого fallback — конечное состояние, а у каждой эскалации — получатель. Только после этого сравнивайте версии маршрута и меняйте пределы на основании серии прогонов. Так бюджет остаётся способом управлять процессом, а не постфактум объяснять уже сделанные расходы.

В ближайший рабочий день выберите не «направление ИИ», а один маршрут, который уже имеет владельца и измеримый результат. Заполните следующую строку и обсудите её с владельцем процесса:

«Для сценария <название> результатом является <проверяемый артефакт>. На один запуск разрешены <контекст/токены>, <шаги>, <время> и <деньги>; качество проверяется по <критерию>. При <условии stop> система <завершает / использует fallback / передаёт> <роли-владельцу>».

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

НТА помогает связать агентный сценарий с существующим процессом, данными, интеграциями и эксплуатационной ответственностью. Узнать о команде и способах связи можно на странице компании.

Важное уведомление

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