Технический контекст
Я зацепился здесь не за сам спор, а за дыру в архитектуре: оркестратор порождает субагента, а тот тащит модель родителя без нативного переключателя. Для AI automation это плохая история, потому что даже простая тулза внезапно начинает работать на дорогой модели там, где хватило бы mini-класса.
И вот тут я обычно торможу проект и лезу в механику. Если у тулзы нет параметров выбора модели, то никакая красивая инструкция в промпте не превращается в реальный роутинг. Агент может «знать», что надо экономить, но технически выбрать нечего.
По тому, что видно из обсуждения, проблема не в качестве модели как таковой, а в отсутствии слоя управления конфигурацией при спавне субагентов. Это важная разница. Когда model selection живет только на уровне родителя, наследник становится дорогой копией, а не специализированным исполнителем.
Я такие вещи обычно проверяю очень приземленно: беру один и тот же сценарий, где оркестратор решает, нужен ли ресерч, суммаризация или форматирование, и смотрю, какие вызовы реально уходят в API. Если каждый дочерний шаг летит в heavy-model, токены сгорают не потому, что задача сложная, а потому что AI integration сделана без нормального роутинга.
Поиск по открытым материалам тут, честно, мало помогает: в общих обзорах LangChain, AutoGen и CrewAI много разговоров про гибкость, но почти нет нормального ответа на вопрос, как избежать такого наследования в реальном проде. Значит, смотреть надо не в маркетинг фреймворка, а в конкретный код инициализации агента, node-level model binding и фабрики субагентов.
Что это меняет для бизнеса и автоматизации
Первый удар очевидный: бюджет. Если саппорт, ресерч и валидация гоняются через одну тяжелую модель, стоимость пайплайна растет без пользы.
Второй удар тише, но больнее: вы теряете предсказуемость. Нельзя нормально считать unit economics, если субагенты не умеют переключаться между дешевым и сильным режимом по задаче.
Выиграют те, кто строит AI solutions for business с явным контролем моделей на каждом узле. Проиграют команды, которые верят, что оркестратор сам «как-нибудь поймет» и оптимизирует цену без параметров.
Мы в Nahornyi AI Lab как раз такие узкие места и вычищаем: раскладываем оркестрацию по ролям, ставим явный роутинг моделей и убираем скрытые пожиратели токенов. Если у вас AI implementation уже работает, но счета растут быстрее пользы, давайте посмотрим на граф вызовов и соберем AI automation так, чтобы система думала там, где это нужно, а не в каждом чихе подряд.