Число, которого не хватает на большинстве дашбордов агентов
Спросите инженерную команду, сколько стоит задача агента, и ответ обычно приходит в виде количества токенов, умноженного на опубликованный тариф. Эту цифру легко получить, и она почти никогда не описывает то, что важно для бизнеса. Одна завершённая задача может включать планировщик, декомпозирующий запрос, исполнителя, вызывающего инструменты, верификатора, проверяющего результат, и цикл исправления, запускаемый при неудачной верификации. Каждый из них — отдельный вызов модели, часто к другой модели, иногда к тому же промпту с немного изменённым контекстом. Счётчик токенов агрегирует всё это в одну строку и стирает структуру.
Без этой структуры решения о внедрении превращаются в догадки. Команда не может сказать, повысило ли увеличение лимита повторов долю завершённых задач достаточно, чтобы оправдать дополнительные расходы, потому что дополнительные расходы не отделены от базовых. Она не может сказать, должна ли более дешёвая модель обрабатывать класс подзадач, потому что у неё нет сигнала о качестве или стоимости по каждой подзадаче. Единица, которая имеет значение, — это стоимость успешной задачи, вычисляемая вместе со стоимостью заброшенной задачи, и единственный способ получить её — инструментировать сам запуск.
Одна задача — это множество вызовов
Многошаговый агент — это программа, поток управления которой определяется во время выполнения. Планировщик может выдать пять шагов или пятнадцать. Исполнитель может вызвать инструмент поиска один раз или зациклиться, пока не исчерпается бюджет. Верификатор может пройти с первой попытки или запустить два исправления. Учёт токенов видит сумму этих вызовов; он не видит, какая роль их породила, к какой задаче они относились и завершилась ли задача вообще. Поэтому рост общих расходов неоднозначен: это может быть больше трафика, больше повторов или изменение промпта, раздувшее контекст при каждом вызове.
Повторы и неудачные вызовы инструментов оплачиваются, но невидимы
Неудачная работа тарифицируется точно так же, как успешная. Вызов инструмента, который завершился по таймауту после того, как модель уже сгенерировала длинный payload аргументов, потратил токены и не дал ничего. Отказ верификатора, запускающий полное перепланирование, удваивает стоимость планировщика. В отчётности по токенам это выглядит как обычный объём. В реестре по задачам это отдельная категория, и именно это делает их исправимыми.
Кэширование и переиспользование контекста меняют эффективную цену
Кэширование промптов и переиспользование контекста меняют эффективную стоимость вызова в разы, и эти коэффициенты зависят от порядка, стабильности префикса и того, какая часть контекста разделяется между ролями. Система, которая сохраняет стабильный системный промпт и добавляет контекст, специфичный для задачи, может платить за вызов существенно меньше, чем та, что пересобирает промпт каждый раз, даже когда видимые счётчики токенов похожи. Любая модель затрат, игнорирующая поведение кэша, неверно оценит эти два дизайна друг относительно друга. Практическое следствие: архитектура промптов — это решение о затратах, а не только о качестве.
Инструментируйте каждый вызов идентификатором задачи и меткой роли
Основа — идентификатор корреляции, который сохраняется на протяжении всего запуска. Каждый вызов модели, каждый вызов инструмента и каждый запуск песочницы помечается id задачи и меткой роли, такой как planner, executor, verifier или repair. Это обычная распределённая трассировка, применённая к циклу агента, и именно она отличает отчёт о затратах от модели затрат.
# Псевдокод: одна запись на вызов модели, позже соединяемая по task_id
record = {
"task_id": task_id,
"role": "executor",
"model": model_name,
"input_tokens": prompt_tokens,
"cached_tokens": cached_prefix_tokens,
"output_tokens": completion_tokens,
"attempt": attempt_index,
"latency_ms": elapsed_ms,
"outcome": "ok" | "tool_error" | "verifier_reject",
}
Поле outcome — это то, что позже позволяет команде отделить стоимость выполнения работы от стоимости выполнения её дважды. Поле cached_tokens — это то, что заставляет модель честно отражать эффективную цену.
Считайте стоимость завершённой задачи и стоимость заброшенной задачи отдельно
Средние по всем задачам смешивают две популяции с разной экономикой. Завершённая задача — это актив; заброшенная задача — чистый убыток, и обычно она дороже из двух, потому что забрасывание коррелирует с циклами. Отчётность по ним вместе даёт число, которое льстит системе всякий раз, когда велика доля забрасываний, поскольку неудачные запуски тянут среднее вниз, не внося ничего.
Разделите реестр:
- Стоимость завершённой задачи — общие расходы на задачи, достигшие верифицированного терминального состояния, делённые на их количество.
- Стоимость заброшенной задачи — общие расходы на задачи, упёршиеся в бюджет, таймаут или неисправимую ошибку, делённые на их количество.
- Доля забрасываний — отношение между двумя популяциями, отслеживаемое как полноценная метрика наряду с качеством.
Система может улучшать стоимость завершённой задачи, ухудшаясь в целом, если она забрасывает больше сложных задач. Только пара чисел плюс
Вызовы моделей — не весь счёт. Вызовы инструментов имеют свою цену: внешние API-вызовы, время песочницы или контейнера, запросы к векторному хранилищу, объектное хранилище для артефактов и вычисления, потраченные на разбор и валидацию вывода инструментов. Для агентов с интенсивным использованием инструментов они часто больше расходов на модели, и почти всегда отсутствуют на дашбордах агентов. Привязывайте их к тому же id задачи и метке роли, чтобы один запрос мог ответить, сколько задача стоила от начала до конца.
Полезная дисциплина — держать схему затрат с небольшим, фиксированным набором измерений — id задачи, роль, класс ресурса, исход — и отказываться добавлять измерения, которые нельзя надёжно заполнить. Модель затрат с пробелами хуже грубой, потому что она провоцирует ложную точность.
Направляйте подзадачи туда, где измерена разница в качестве
Как только затраты атрибутированы по ролям, маршрутизация становится эмпирическим вопросом, а не делом вкуса. Паттерн — отправлять узкие, хорошо специфицированные подзадачи меньшим моделям, а большие модели резервировать для планирования, неоднозначного синтеза и верификации. Ограничение в том, что разница в качестве должна измеряться на реальном распределении задач, а не предполагаться по результатам бенчмарков. Изменение маршрутизации — это гипотеза: тот же набор задач, тот же верификатор, сравнение доли завершённых задач и стоимости завершённой задачи до и после.
Здесь же живёт честный компромисс. Агрессивная маршрутизация снижает стоимость вызова и увеличивает число циклов исправления, потому что более слабые модели дают больше отказов верификатора. Итоговый эффект может быть любым, и он виден только тогда, когда стоимость исправления атрибутирована решению о маршрутизации, которое её вызвало. Команды, пропускающие измерение, обычно колеблются между двумя конфигурациями на основе анекдотов.
Рассматривайте исчерпание бюджета как сигнал маршрутизации
Бюджет на задачу полезнее как управляющий сигнал, чем как жёсткая остановка. Когда задача исчерпывает свой бюджет, это событие несёт информацию: класс задачи сложнее, чем предполагалось, планировщик чрезмерно декомпозирует, или исполнитель зациклился на инструменте, который никогда не вернёт пригодный результат. Логирование исчерпания с разбивкой по ролям в момент исчерпания превращает сбой во входные данные для маршрутизации. Некоторые системы отвечают эскалацией к более сильной модели для этого класса; другие — ужесточением потолка шагов планировщика. Оба варианта законны; ни один не обнаруживается без реестра.
Отчитывайтесь о регрессиях затрат рядом с регрессиями качества
Качество и затраты движутся вместе, и их раздельный обзор гарантирует, что одно оптимизируется за счёт другого. Изменение промпта, повышающее долю завершённых задач на несколько пунктов при утроении стоимости исправлений, — это компромисс, а не победа, и его следует представлять именно так. Артефакт обзора — небольшая таблица на каждый релиз: доля завершённых задач, доля забрасываний, стоимость завершённой задачи, стоимость заброшенной задачи и разбивка любого изменения по ролям. Регрессии в любой из колонок блокируют релиз или явно принимаются с письменным обоснованием.
Что это меняет
Сдвиг — от учёта потребления к учёту результатов. Расход токенов остаётся полезным входом, но это ингредиент, а не единица ценности. Как только затраты атрибутированы по задаче, роли и исходу, вопросы, на которые командам действительно нужно отвечать, становятся разрешимыми: какие классы задач стоит автоматизировать, где меньшей модели достаточно, какие режимы отказа дороги и окупилось ли улучшение качества. Именно эти вопросы определяют, переживёт ли развёртывание агента столкновение с бюджетом.