Cost, latency, and failure containment

Мультиагентную систему нельзя проектировать без калькулятора. Базовые множители из данных Anthropic: агент ≈ ×4 токенов от чата, мультиагентная система ≈ ×15. Причём в их исследовании расход токенов объяснил около 80% дисперсии качества на research-задачах — то есть вы буквально покупаете качество за токены, и надо знать цену покупки.

Возьмём supervisor и трёх воркеров; цены — условные, но типичного порядка: вход 3 $/млн токенов, выход 15 $/млн.

супервизор: 120K вход, 8K выход   → 0.36 + 0.12 = 0.48 $
воркер ×3:  200K вход, 12K выход  → (0.60 + 0.18) × 3 = 2.34 $
итого прогон ......................................  ~2.82 $
одиночный агент на той же задаче ..................  ~0.70 $

Четырёхкратная разница за один прогон. При 100 прогонах в день это 282 $ против 70 $ — и вопрос «даёт ли мультиагентность здесь прирост качества, оправдывающий 212 $ в день» должен быть задан ДО релиза.

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

Стоимость и время — разные оси, и оптимизируются они разными приёмами; путать их — типовая ошибка архитектуры. Последовательная цепочка агентов складывает задержки: пять этапов по 40 секунд — это 200 секунд без вариантов, сколько бы вы ни платили. Параллельный веер делит время: те же пять подзадач через Send идут одновременно, и этап занимает столько, сколько самая медленная ветка. Anthropic для своей research-системы называет сокращение времени сложных исследований до 90% именно за счёт параллелизма — ведущий агент раскладывает запрос, суб-агенты читают источники одновременно, и десятки источников обрабатываются за время двух-трёх.

Но веер не бесплатен: стоимость всех веток суммируется. Параллелизм — это обмен денег на время; цепочка — обмен времени на контроль (каждый следующий этап видит результат предыдущего). Отсюда правило выбора: параллельте то, что независимо по данным, и только то, что реально выигрывает от скорости.

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

В системе из пяти агентов вероятность, что хотя бы один шаг сорвётся, растёт экспоненциально: при надёжности шага 95% и пятнадцати LLM-вызовах шанс полностью чистого прогона — 0.95^15 ≈ 46%. Отказы — не исключение, а режим работы, и проектировать нужно не «чтобы не падало», а «чтобы падение одного не убивало всё».

Первый слой — ретраи на уровне узла. В LangGraph политика повторов задаётся при добавлении узла:

from langgraph.pregel import RetryPolicy

builder.add_node(
    "researcher",
    researcher,
    retry=RetryPolicy(max_attempts=3, initial_interval=1.0),
)

Ретраить стоит транзиентные ошибки — таймауты сети, rate limit, 5xx провайдера — с экспоненциальной паузой. Ретраить ошибку рассуждения бессмысленно: агент, неверно понявший задачу, повторит ошибку за ваши деньги.

Второй слой — таймаут и бюджет на каждый узел и на прогон целиком: потолок времени, токенов и итераций. Третий — bulkhead-изоляция: отказ одной ветки веера не отменяет остальные; reduce-узел собирает успешные результаты и явно помечает недостающие, а не падает целиком. Четвёртый — checkpointer из второго урока как механизм восстановления: упавший на шаге 14 прогон возобновляется с шага 14, а не с нуля — при цене прогона в доллары это прямая экономия. И пятый — идемпотентность инструментов с побочными эффектами: ретрай узла, который уже отправил письмо, не должен отправить его дважды.

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

Circuit breaker — предохранитель уровня системы: если узел или провайдер отказал N раз подряд, перестаём слать ему запросы на время cooldown, вместо того чтобы обстреливать ретраями упавший сервис. Для мультиагентной системы это означает и деградацию маршрута: если research-веер недоступен, supervisor переключается на запасной план — один агент с поиском, меньше источников, честная пометка о сниженном покрытии. Graceful degradation до одиночного агента почти всегда лучше отказа: пользователь получает 70% ценности вместо нуля.

И финальный элемент — наблюдаемость. Мультиагентную систему без трассировки невозможно ни отлаживать, ни оптимизировать: нужны трейсы всех вызовов с разбивкой по агентам (LangSmith, Langfuse или свой OpenTelemetry), стоимость на прогон по агентам и главная бизнес-метрика — cost per successful task: полная стоимость, делённая на число УСПЕШНЫХ задач. Она честно учитывает и цену ретраев, и цену отказов, и именно её сравнивают между топологиями: дешёвая по прайсу система с низкой долей успеха проигрывает дорогой и надёжной.