Демонстрация агента обычно показывает результат: он нашёл материал, заполнил форму, подготовил ответ. Производственная экономика возникает между этими точками. Агент читает документы, вызывает поиск, передаёт данные инструментам, пробует снова, создаёт промежуточные выводы и иногда привлекает человека. Каждый цикл расширяет контекст и добавляет время. Если считать только первый вызов модели, бюджет будет систематически занижен.
Пять строк полной стоимости
1. Инференс. Вход и выход каждого вызова, включая промежуточные вызовы агента. У Google в описании managed agents указано, что внутренние токены агентных циклов также тарифицируются по ставкам модели. Источник (откроется в новой вкладке).
2. Данные и инструменты. Поиск, OCR, векторное хранилище, web grounding, внешние API, хранение кэша и передачa данных. Некоторые функции тарифицируются за запрос, страницу или время хранения, поэтому токены не дают полного счета.
3. Надёжность. Повтор после тайм-аута, повторная проверка формата, восстановление после ошибочного действия, тесты и наблюдаемость.
4. Люди. Экспертная проверка, согласование, работа с исключениями, поддержка пользователей и обучение команды. Если экономия времени сотрудника не сопровождается реальным изменением процесса, она не обязательно превращается в денежную экономию.
5. Риск и управление. Доступы, журнал действий, оценка моделей после обновлений, соблюдение требований к данным, процедура остановки и ручной маршрут. Это не «накладная бюрократия»: без таких механизмов нельзя безопасно дать системе полномочия.
Иллюстрация: вызовы стоят $0.004 на случай; 20% случаев требуют проверки за $0.04; 5% — исправления за $0.20. Ожидаемые переменные затраты равны $0.022 на случай, ещё до инфраструктуры и постоянной команды. Если система обрабатывает 100 тысяч случаев в месяц, разница между $0.004 и $0.022 — $1,800. Оценки вымышлены и приведены для проверки формулы.
От идеи к бюджетному ограничителю
Возьмём агент для входящих запросов клиентов. Сначала система только определяет тему и подбирает действующую политику. Далее готовит черновик с проверяемой ссылкой на правило. Затем для стандартных случаев предлагает отправку после одобрения сотрудника. Право самостоятельно обновить заказ или обещать возврат появляется только после отдельного теста соответствующего действия, с пределом суммы и откатом. На каждом шаге сравнивают принятие ответа, время сотрудника, число исключений и полную стоимость. Это даёт экономику по ступеням полномочий, а не одну общую оценку «агент окупается».
Задайте максимальное число шагов агента, число повторов, предел входного контекста, максимальную стоимость на случай и на пользователя в день. Запишите, когда система должна остановиться и передать работу человеку. Важная метрика — не только средняя цена, но и «длинный хвост»: p95 стоимости и времени, доля случаев с превышением лимита, крупнейший ущерб от неверного действия.
В работе METR об expenditure horizon (откроется в новой вкладке) предлагается сопоставлять результат человека и агента с расходами на его получение, включая вычисление и труд. Это полезная логика для проекта, хотя её конкретные оценки относятся к исследованной задаче, а не к клиентскому сервису.
Решения о маршрутизации должны быть проверяемыми. Если дорогая модель подключается только к 8% сложных случаев, убедитесь, что маршрутизатор действительно распознаёт сложность, а не просто сокращает счёт, отправляя трудные обращения к дешёвой модели. Проверяйте отказы, новые типы документов и изменение распределения входа.
Что сказать о затратах энергии
Денежная стоимость API не равна физической энергии. На неё влияют оборудование, загрузка, пакетирование, длина входа и выхода, расположение дата-центра и граница измерения. Работа Microsoft Research (откроется в новой вкладке) подчёркивает чувствительность оценок энергии на запрос к системным предположениям и к дополнительному вычислению во время ответа. Поэтому универсальные заявления «один запрос = X энергии» плохо подходят для закупочного решения. Для собственной инфраструктуры измеряйте фактическое потребление на принятую задачу; для API фиксируйте объём работы и запрашивайте у поставщика методику.
Управленческая панель
Одна строка на неделю: число случаев, доля принятых без правки, доля эскалаций, тяжёлые ошибки, p50/p95 время, затраты на модели/инструменты/людей, стоимость принятого результата и соблюдение бюджета. Владелец процесса должен иметь право выключить автоматическое действие. Обновление модели, тарифов или источников данных — повод пересчитать эти показатели.
Почему у агента другая экономика, чем у чат-ответа
Обычный чат-вызов чаще имеет понятные вход и выход. Агент строит последовательность действий, где результат каждого шага меняет следующий запрос. Он может повторно читать историю, передавать большие результаты инструментов и менять план после ошибки. Поэтому расходы и длительность оказываются переменными и зависимыми: неудачный поиск рождает дополнительные поиски, избыточный ответ инструмента раздувает контекст, тайм-аут запускает повтор. Средняя цена одного модельного вызова здесь не объясняет цену завершённого дела.
Помогает разделить поток на этапы с бюджетами: понять запрос; найти доказательства; подготовить решение; проверить; выполнить действие; подтвердить результат. Каждый этап получает лимит времени, числа вызовов, стоимости и полномочий. Если лимит достигнут, система не должна бесконечно «стараться ещё» — она передаёт случай человеку с краткой историей и найденными источниками. Это одновременно финансовый ограничитель и защита качества.
Полномочия растут вслед за доказательствами
Уровень 1 — наблюдать и классифицировать. Уровень 2 — предложить черновик. Уровень 3 — подготовить обратимое действие, которое утверждает человек. Уровень 4 — самостоятельно выполнять ограниченные обратимые действия в известных случаях. Чем выше уровень, тем дороже становится ошибка и тем больше требований к тестам, журналу и откату. Объединять эти уровни в метрику «сколько задач агент автоматизировал» бессмысленно: подготовленный черновик и отправленный платёж не эквивалентны.
Исследование AI Index 2026 (откроется в новой вкладке) показывает улучшение агентов на структурированных бенчмарках, но также существенную долю неуспешных попыток. Публичный тест демонстрирует направление прогресса; полномочия в конкретной компании надо выдавать по собственным критериям и собственным ошибкам. Статический вопрос-ответ не проверяет последовательность действий; AgentBench (откроется в новой вкладке) был одним из исследований, специально рассматривавших интерактивные среды.
Экономика времени и очереди
Агент может сэкономить время специалиста, но ухудшить время клиента, если долго перебирает инструменты. Или наоборот: дать мгновенный черновик, который застрянет в очереди на согласование. Поэтому отдельно измеряйте активное время человека, ожидание в очереди, время исполнения и суммарное время до закрытия случая. Если проверка человеком остаётся обязательной, рост объёма может превратить её в новое узкое место; экономию от модели съест очередь.
Пакетная обработка и более дешёвый режим часто подходят для фоновой классификации или массовых отчётов. В разговоре с клиентом более дорогая, но предсказуемая скорость может быть выгоднее. Решение зависит от срока, ценности времени и доли повторных обращений. Не переносите тарифную оптимизацию из одного режима работы в другой без проверки качества обслуживания.
Что покупать, что строить и где держать правило
Модельный API обычно выгоден как заменяемый компонент. Уникальные данные, права доступа, критерии приемки и журнал действий относятся к вашей системе и должны оставаться под вашим контролем. Правила вроде «нельзя обещать возврат без статуса заказа и лимита суммы» лучше проверять детерминированно. Модель может интерпретировать сообщение и подготовить объяснение; окончательное условие действия должно быть воспроизводимым.
При выборе готовой агентной платформы спросите, доступны ли пошаговые журналы, фактические токены и затраты, ограничение числа шагов, версии модели, отключение инструментов и экспорт данных для аудита. Если платформа показывает только «стоимость задачи» без расшифровки, её трудно улучшать и безопасно сопровождать. Собственная сборка даёт контроль, но требует команды, поддержки и тестов; эти постоянные расходы тоже входят в экономику.
Контрольная схема пилота
Выберите узкий поток с частыми, проверяемыми случаями и заранее описанными исключениями. Сначала прогоните агента без действий на исторических примерах; затем в теневом режиме на новых случаях; затем разрешите предложения человеку; после проверки — ограниченные обратимые действия. На каждом этапе задайте критерий перехода по качеству, затратам, времени и тяжёлым ошибкам. Если он не выполнен, улучшайте маршрутизацию или возвращайтесь на более низкий уровень полномочий. Пилот считается успешным, когда процесс управляем в обычный день и при исключении, а не когда демонстрация выглядит убедительно.
Сквозной пример: где проходит граница окупаемости
Вернёмся к магазину. Первый проект — агент отвечает на типовые вопросы о сроке доставки, используя систему заказов и утверждённую политику. Если сотрудник принимает большинство черновиков быстро, сокращается активное время подготовки. Но это ещё не экономия денежных средств: оцените, уменьшилась ли очередь, стало ли возможным обработать рост обращений без дополнительных смен, снизилось ли число повторных вопросов. Если ответ «нет», ценность может быть в качестве и устойчивости сервиса, а не в прямой экономии труда.
Следующий проект — изменение адреса. Здесь агент может сэкономить дополнительные минуты, но ошибка способна отправить заказ не туда. Потребуются проверка личности, статус у перевозчика, предел времени и подтверждение клиента. Стоимость этих контролей следует включить в бизнес-кейс. Если ручное изменение адреса редко и быстро, полноценная автоматизация может не окупиться; подготовка фактов и черновика для сотрудника может быть лучшей точкой. Для спорного возврата высокая стоимость ошибки делает полезной сильную модель для анализа документов, но окончательное решение оставляют человеку.
Так появляется портфель задач, а не один показатель «ROI агента». На одной операции агент полностью закрывает случай, на другой делает поиск, на третьей лишь оформляет доказательства. Все три могут создавать ценность, но их экономические механизмы разные. Отчёт должен показывать это по категориям, иначе успех массовых лёгких запросов скрывает дорогие ошибки редких действий.
Типичные пути, по которым бюджет утекает
Агент может зациклиться на неудачном инструменте; повторять поиск с почти одинаковыми запросами; снова читать большой документ вместо использования проверенного результата; просить сильную модель переписать уже принятый черновик; накапливать логи и инструкции в контексте; повторять платную операцию после тайм-аута без проверки, прошла ли первая попытка. Эти сценарии создают не только счёт, но и возможность двойного действия. Для каждого нужны технические ограничения: идемпотентность инструментов, кэш результатов там, где это безопасно, предел шагов, проверка состояния перед повтором и журнал причин эскалации.
Некоторые затраты невозможно оптимизировать моделью. Плохое качество базы знаний порождает повторные поиски. Неясное право доступа требует ручного согласования. Отсутствие стабильного API заставляет агента работать через хрупкий интерфейс. Поэтому экономический аудит должен различать модельные, информационные и организационные причины потерь. Улучшение данных или процесса иногда приносит больше, чем более дешёвый токен.
Контракт между владельцем процесса и агентом
Перед выпуском опишите простой операционный контракт: какие задачи разрешены, какие источники авторитетны, какие инструменты доступны, какое действие требует подтверждения, какие лимиты действуют, как система сообщает о неопределённости и кто отвечает за инцидент. Контракт должен иметь версию. При изменении политики или API обновите его и тестовый набор. Тогда «управление ИИ» становится повседневной инженерной и операционной практикой, а не ежегодным документом, оторванным от агента.
Если организация не может назвать владельца исключений и человека, который вправе остановить автоматизацию, автономию расширять рано. Успешный агент не тот, который никогда не передаёт случай человеку, а тот, который делает это вовремя, с достаточным контекстом и без потери ответственности.
Один агент или команда агентов?
Разбиение на «исследователя», «писателя» и «проверяющего» может дать понятные роли, но каждый дополнительный агент добавляет вызовы, передачу контекста и новый источник ошибки. Две модели, проверяющие друг друга, не становятся автоматически независимыми: они могут повторить одну и ту же неверную предпосылку. Поэтому многокомпонентную схему оправдывают конкретным тестом: она должна улучшить принятый результат или снизить риск настолько, чтобы покрыть задержку и стоимость координации. Для простой задачи часто достаточно одного вызова, детерминированной проверки и человека на исключении.
Маршрут также может сочетать не только языковые модели. Правильный инструмент для статуса заказа — API системы заказов; для вычисления суммы — программа с проверяемой формулой; для поиска правила — версионированная база знаний; для вежливого объяснения — языковая модель. Такая композиция снижает нагрузку на модель и делает ответ воспроизводимее. Если в расчёте экономики всё обозначено как «токены агента», команда не увидит, какой компонент стоит улучшать.
От пилота к инвестиционному решению
Решение о масштабировании требует двух отдельных проверок. Техническая: проходит ли система критерии качества и контроля в обычных и трудных случаях? Экономическая: создаёт ли она реализуемую выгоду после всех переменных и постоянных расходов? Положительный ответ на первую не гарантирует второй; полезный и безопасный агент может пока быть слишком дорогим для массового потока. Отрицательный ответ на техническую проверку нельзя компенсировать потенциальной экономией.
Для финансовой оценки задайте горизонт, ожидаемый объём, стоимость интеграции, ежемесячную поддержку, обновление базы знаний и резерв на инциденты. Затем отделите эффекты: труд, дополнительная пропускная способность, качество, ожидание клиента. Избегайте двойного счёта. Покажите границу безубыточности по объёму и доле принятых случаев, а рядом — условия, при которых автоматизация должна быть остановлена. Даже если точные будущие цены неизвестны, такая модель показывает, какие параметры действительно решающие.
Масштабирование лучше вести по категориям. Сначала расширяйте поток знакомых случаев, затем новые каналы, затем новые действия. При каждом расширении меняются данные, исключения и полномочия, поэтому старое доказательство качества действует не целиком. Ответственный владелец должен иметь возможность вернуть процесс на предыдущий уровень без остановки обслуживания клиентов.
Итог серии: токен — хороший измеритель расхода вычисления. Контекст — управляемый ресурс. Модель — компонент. Эффективность появляется только на уровне рабочего процесса, где качество, время, стоимость и риск измерены вместе.
Начало серии: Токен — новая валюта ИИ?.