Стоимость исходит не от модели
Общее число токенов — это результат, а не причина. Когда два запуска агента на одной и той же задаче различаются на порядок по числу вызовов инструментов, разница редко кроется в модели. Она в декомпозиции: сколько подзадач создал планировщик, насколько узко была очерчена каждая из них и сколько контекста каждому узлу было велено перечитать. План, разбивающий задачу retrieval на пять перекрывающихся подзадач, заплатит за один и тот же документ пять раз. План, разбивающий её на один хорошо очерченный узел, заплатит один раз.
Режимы отказа группируются. Повторы концентрируются на подзадачах, условие успеха которых никогда не было сформулировано. Перечитывания контекста концентрируются на узлах, которым дали слишком широкую поверхность инструментов и которым пришлось заново выводить то, что они уже знали. Избыточные шаги верификации появляются, когда планировщик не может решить, завершена ли подзадача, и добавляет узел-проверяющий, дублирующий работу. Ничего из этого не видно в общем итоге по запуску. Итог приписывает стоимость модели, потому что именно модель названа в строке биллинга. Деньги на самом деле потратил план.
Учёт по узлам плана
Механизм прост: дайте каждому узлу плана стабильный идентификатор и припишите каждый вызов модели и вызов инструмента тому узлу, который его инициировал. Идентификатор узла — это не имя спана. Это собственная единица работы планировщика, переносимая через весь запуск как поле в каждом исходящем запросе.
plan_node_id: "retrieve_policy_clauses"
parent_node: "assemble_compliance_answer"
model_calls: [...]
tool_calls: [...]
status: "retried"
Агрегируйте по запускам, и каждый узел приобретает распределение: стоимость, задержка, частота повторов, частота отказов. Распределение — это и есть суть. Средняя стоимость узла говорит вам, сколько узел обычно стоит. Длинный правый хвост говорит, какой узел иногда взрывается. Это разные инженерные задачи. Первая — вопрос бюджетирования. Вторая — дефект декомпозиции.
Здесь большинство систем observability для агентов останавливается. Трейсы собираются, спаны отрисовываются, а представление стоимости — это общий итог по запуску с разбивкой по моделям. Эта разбивка отвечает на вопрос, который никто не задавал: какая модель потратила токены. Вопрос, который имеет значение, — какая часть плана породила работу. Представление на уровне узлов отвечает на него, и отвечает по всем запускам, а это единственный способ отделить плохой план от плохого дня.
Что раскрывает распределение
Три паттерна повторяются.
Узел с низкой средней стоимостью и тяжёлым хвостом — обычно узел с недостаточно определённым условием успеха. Он успешен в большинстве случаев и иногда зацикливается. Исправление — не более дешёвая модель. Исправление — более строгий контракт на узел: что он должен вернуть и что считается завершением.
Узел с высокой средней стоимостью и низкой дисперсией выполняет реальную работу. Он кандидат на более узкую поверхность инструментов или более дешёвую модель, потому что его поведение достаточно предсказуемо, чтобы оптимизировать его без риска для запуска.
Узел с высокой частотой повторов и ровной стоимостью — это узел, который всегда отказывает одинаково и повторяется планировщиком, у которого нет лучшего варианта. Добавление бюджета здесь делает отказ дороже. Переписывание узла устраняет его.
Ни одно из этих различий не выживает при агрегации до итога по запуску. Они требуют узла как единицы учёта.
Превращение в входные данные для планирования
Как только стоимость приписана узлам, принудительное исполнение может прикрепляться к узлу, а не к запуску. Ограничение на запуск — грубый инструмент: когда оно срабатывает, вся траектория умирает, включая узлы, которые вели себя нормально. Ограничение на узел позволяет остановить вышедшую из-под контроля подзадачу, пометить её как неуспешную и сообщить об этом планировщику, который затем может перепланировать с учётом этого. Остальной запуск продолжается.
Это меняет работу планировщика. Планировщик, получающий обратную связь о стоимости на уровне узлов, может выбирать декомпозиции на основе ожидаемой стоимости, а не только ожидаемой корректности. Узлы с высокой дисперсией получают более узкие поверхности инструментов, потому что меньшая поверхность сокращает пространство того, что узел может сделать неправильно. Узлы, которые всегда повторяются, переписываются до того, как им дадут больше бюджета, потому что бюджет — не ограничение. Узлам, которые дёшевы и надёжны, можно дать больше свободы,
Принудительное исполнение бюджета становится входными данными для планирования. Вместо ежемесячного сюрприза ограничение доступно во время планирования и на каждой границе узла. Планировщик не гадает, может ли он позволить себе декомпозицию; у него есть априорное распределение стоимости узлов по предыдущим запускам.
Компромисс реален. Учёт на уровне узлов требует, чтобы планировщик выдавал стабильные идентификаторы узлов, а значит, декомпозиция планировщика должна быть наблюдаемой и воспроизводимой. Планировщики, генерирующие свободную декомпозицию при каждом запуске, производят идентификаторы, которые не агрегируются. Инструментирование вынуждает сделать выбор: либо декомпозиция достаточно стабильна, чтобы её измерять, либо нет, и стоимость остаётся неатрибутируемой. Команды, которые хотят планировщик второго рода — полностью свободный, максимально адаптивный, — платят за это отказом от контура управления. Это законный выбор. Но не бесплатный.
Что это заменяет
Дашборды стоимости постфактум — это отчётный артефакт. Они говорят вам, что произошло в прошлом месяце, в агрегате, после того как деньги потрачены. Они полезны для финансов и бесполезны для инженерии, потому что к моменту, когда число видно, запуск завершён, а план, который его вызвал, исчез.
Учёт по узлам плана — это контур управления. Он измеряет на той единице, которой планировщик действительно управляет, агрегирует по запускам, так что дисперсия видна, и подаёт обратную связь в следующую декомпозицию. Разница не в гранулярности графика. Она в том, может ли измерение изменить следующий запуск.
Практическая форма
Минимальная реализация состоит из четырёх частей.
- Планировщик выдаёт идентификаторы узлов как часть своей декомпозиции, а среда исполнения переносит их в каждом вызове модели и инструмента.
- Коллектор агрегирует стоимость, задержку, число повторов и статус отказа по каждому узлу across runs.
- Слой политик читает распределение по узлам и применяет ограничения, выбор модели и ограничения поверхности инструментов на границе узла.
- Планировщик использует априорные распределения слоя политик при выборе следующей декомпозиции.
Сложная часть — не инфраструктура. Это принятие того, что декомпозиция — инженерный артефакт с сигнатурой стоимости, и что её измерение — единственный способ сделать бюджетирование проектным решением, а не бухгалтерским событием.