Контроль расходов на агентов: лимиты, токены, транзакции

Рынок вводит ограничения на самостоятельные действия агентов и усиливает надзор.

Что произошло

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

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

Сдвиг заключается в постановке вопроса. Год назад заказчик спрашивал: «Насколько хорошо агент справляется». Сегодня — «Кто утвердил это действие, сколько оно стоило и где это записано». Первый вопрос — про качество. Второй — про управляемость, и без ответа на него агент не проходит ни финансовый, ни комплаенс-контроль.

Как это устроено

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

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

Источник расходов	Как растёт	Чем ограничивать
Токены модели	На каждом шаге агент передаёт накопленный контекст заново; двадцать шагов стоят существенно дороже двадцати одиночных запросов	Лимит токенов на задачу, сжатие контекста
Вызовы инструментов	Поиск, внешние API, проверки — часть платные, часть медленные	Лимит вызовов на задачу и на период
Повторы	Ошибка — повтор — та же ошибка — повтор: цикл без выхода	Счётчик попыток, обнаружение повторяющихся действий
Вычислительные ресурсы	Для локальных моделей — GPU-часы, очередь, простой других задач	Квоты на уровне сервера инференса
Последствия действий	Ошибочный заказ, отправленное письмо, изменённая запись	Границы действий и подтверждение

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

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

Бюджет агента

Бюджет задаётся в трёх измерениях, и каждое закрывает свой сценарий перерасхода.

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

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

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

Границы действий: сам, с подтверждением, никогда

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

Класс	Признаки	Примеры	Реализация
Выполняет сам	Обратимо, без внешнего эффекта, без денег	Чтение данных, черновики, расчёты, внутренние заметки	Инструмент доступен без ограничений
С подтверждением	Внешний эффект или деньги, но обратимо или ограничено	Отправка письма контрагенту, создание заказа, изменение записи в учёте	Инструмент возвращает запрос на подтверждение владельцу
Никогда	Необратимо, регулируемо, за пределами полномочий	Изменение банковских реквизитов, платёж выше порога, удаление данных, изменение прав доступа	Инструмент не подключён к агенту

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

Границы действий должны быть описаны в конфигурации, версионированы и доступны для аудита. Когда служба безопасности спрашивает «что может этот агент», ответом должен быть файл, а не пересказ.

Правило остановки

Правило остановки — это набор условий, при которых агент прекращает работу, сохраняет состояние и уведомляет владельца. Минимальный набор:

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

Важно поведение при остановке. Не «завершить как получится», а заморозить состояние, записать причину, отправить уведомление и ждать. Частичный результат остаётся доступным для человека, который решит, продолжить или отменить.

Журнал действий и владелец

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

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

Агент — не программа, а подразделение: у него есть бюджет, полномочия, отчётность и руководитель.

Как это выглядит на практике

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

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

Аналитический агент на локальной модели. Выполняет запросы к хранилищу данных по вопросам финансовой службы. Стоимость — не в токенах, а в GPU-часах и нагрузке на хранилище: один неудачный запрос способен занять ресурсы на часы. Лимиты заданы на время выполнения и число запросов на задачу, владелец — из финансовой службы, журнал хранит текст каждого запроса.

Что это значит для российской компании

Закрытый контур не отменяет бюджет. Локальная модель, развёрнутая через vLLM или аналогичный сервер, не выставляет счёт за токены, и возникает ощущение, что расходы нулевые. Это не так: GPU-часы, электроэнергия, амортизация, очередь, в которой другие задачи ждут агента, — всё это стоимость. Она менее заметна, чем счёт от провайдера, и потому требует более дисциплинированного учёта, а не менее.

Регулируемые отрасли. Для банка, страховой компании, оператора связи журнал действий агента — доказательная база для внутреннего контроля и внешнего аудита. Требования к обработке персональных данных по 152-ФЗ распространяются на действия агента в полной мере: каждое обращение к данным должно быть обосновано сценарием и записано. Для субъектов КИИ добавляются требования к среде исполнения и к отечественному стеку.

Управленческий учёт. Расходы на агентов должны быть видны в учёте как отдельная строка с привязкой к владельцу и к процессу. Иначе они растворяются в «ИТ-инфраструктуре» и обнаруживаются только при годовом сравнении, когда объяснять разницу уже поздно.

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

Что делать: пошагово

Составьте реестр агентов и инструментов. Для каждого агента — какие модели вызывает, какие инструменты подключены, к каким системам и данным имеет доступ. Часто уже на этом шаге обнаруживаются агенты, о которых никто не помнил.
Классифицируйте каждое действие. Сам, с подтверждением, никогда — по признакам обратимости, внешнего эффекта и денег. Зафиксируйте результат в конфигурации, а не в документе для галочки.
Задайте бюджеты на уровне шлюза. Токены и вызовы на задачу, стоимость за период; мягкие и жёсткие пороги. Убедитесь, что агент технически не может обойти шлюз.
Опишите правило остановки. Перечень условий, поведение при остановке, канал уведомления. Проверьте его срабатывание на тестовой задаче до запуска.
Настройте журнал и атрибуцию стоимости. Каждое действие — с версией модели и инструкции, параметрами и стоимостью. Стоимость агрегируется по агенту, задаче, процессу, владельцу.
Назначьте владельца и договоритесь о его нагрузке. Подтверждения, разбор остановок, еженедельный просмотр журнала — в должностных обязанностях, с нормой времени.
Проводите ежемесячный разбор. Стоимость на единицу результата, число остановок и их причины, инциденты, запросы на расширение границ. Расширение автономии — только по итогам разбора, с обоснованием.

Типичные ошибки

Лимит записан в инструкции агента. Модель может его проигнорировать, и никакого технического барьера нет. Вместо этого: лимит на шлюзе, через который проходят все вызовы.
Запрещённые действия «запрещены» текстом. Инструмент подключён, а инструкция просит его не использовать. Вместо этого: запрещённый инструмент не подключён вовсе.
Повтор без счётчика. Инструкция требует «добиться результата», и агент добивается — за счёт бюджета. Вместо этого: счётчик попыток и обнаружение повторяющихся действий в правиле остановки.
Журнал ведётся, но никто его не читает. Инциденты обнаруживаются по жалобам. Вместо этого: еженедельный просмотр владельцем и автоматические сводки по отклонениям.
Владелец — подразделение. Уведомления приходят на общий адрес, подтверждения ждут неделями, лимиты повышают «чтобы не мешало». Вместо этого: конкретный человек с полномочиями и нормой времени.
Локальная модель считается бесплатной. Расходы на GPU и простой других задач не учитываются, и агент занимает ресурсы без ограничений. Вместо этого: квоты на сервере инференса и учёт GPU-часов как статьи расходов.

Как понять, что вы на верном пути

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

Вопросы, которые нам задают

Не убивает ли подтверждение сам смысл агента

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

Локальная модель в контуре — значит, бюджет не нужен

Бюджет нужен в другой валюте. Вместо токенов — GPU-часы и время очереди; вместо счёта от провайдера — амортизация и электроэнергия; вместо лимита расходов — квоты на сервере инференса. Без квот один агент способен занять весь вычислительный ресурс контура, и остальные задачи будут ждать. Сама логика — бюджет, границы, остановка, журнал, владелец — не зависит от того, где стоит модель.

В инструкции написано «никогда не делай этого». Разве этого мало

Мало. Инструкция — вход модели, а модель вероятностна; при определённом контексте она может интерпретировать инструкцию иначе, чем вы ожидали. Единственный надёжный запрет — отсутствие возможности: инструмент не подключён, права не выданы, шлюз не пропускает. Инструкцию оставьте как дополнительный слой, но не как единственный.

С какого бюджета начинать

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