Взрыв интеллекта: почему выигрывает не одна модель, а мультиагентная оркестрация LLM

За одну неделю августа вышло больше пяти значимых релизов моделей — Deepseek V4 Flash и Pro, Gemini 3.7 Flash, Quinn 3.8, GLM 5.3, Kimi K3, Grok 4.6. Инженер и автор канала IndyDevDan называет это «взрывом интеллекта» и делает из него неожиданный вывод: в такой момент проигрывает тот, кто ищет одну «лучшую» модель. Выигрывает мультиагентная оркестрация LLM — подход, при котором несколько моделей работают над задачей параллельно и их результаты сводятся воедино через гибкий agent harness.

Идея не новая — комбинировать модели пробовали и раньше. Но на практике показан рабочий инструмент, кастомный вариант Pi Agent под названием fusion harness, и три конкретных команды, которые превращают идею в повторяемый рабочий процесс.

Три паттерна мультиагентной оркестрации LLM

Первый — opinion: один и тот же вопрос параллельно уходит к нескольким моделям (в демо — Fable 5, Gemini 3.7 Flash и Deepseek V4 Pro), и харнес показывает не просто ответы, а перформанс, скорость и стоимость каждого рядом друг с другом. Второй — debate: модели по очереди читают ответы друг друга и в несколько раундов защищают или меняют позицию по спорному утверждению из документации DuckDB v2. Важная деталь реализации: модели не должны знать имена друг друга — иначе, по наблюдению автора, начинают вести себя странно, конкурировать или саботировать соседей. Третий, самый мощный — collaborate: каждая модель предлагает свой план, одна из них назначается архитектором, остальные — исполнителями с явным распределением задач и зависимостей, а архитектор в конце собирает и валидирует общий результат.

Combine compute, не select compute

Ключевая фраза харнеса — «комбинируй вычисления, а не выбирай их». За ней стоит экономика: state-of-the-art модель вроде Fable 5 в демонстрации стоит на порядок дороже Gemini 3.7 Flash или Deepseek V4 Pro при сопоставимом качестве на большинстве задач. Для рутинной работы это довод в пользу «рабочих лошадок» A-уровня — именно там сейчас концентрируется реальная выгода инженеров, а не в гонке за самой мощной моделью. Автор также напоминает о скрытых деталях ценообразования: у части моделей после порога контекста цена входных и выходных токенов резко растёт, и модель, которая выглядит дешёвой в маркетинге, на практике может стоить иначе.

Почему харнес важнее конкретной модели

Главный тезис — в момент, когда модели меняются местами лидера каждую неделю, ценность смещается от выбора модели к владению гибким инструментом её использования. Готовые агентские продукты жёстко привязывают к одному провайдеру и одному способу работы; кастомный harness на открытом или закрытом коде позволяет подключать любую новую модель как только она выходит, не переписывая рабочий процесс заново. Это прямое продолжение принципа «побеждает самая гибкая система» — из инженерной практики, а не из хайпа вокруг конкретного релиза.

Дальше — software factory

Автор проводит границу между «in-loop» agentic coding, где инженер по-прежнему сидит в терминале и подталкивает агента шаг за шагом, и «out-loop» подходом, где выстраивается система из агентов и кода, работающая без постоянного присутствия человека — то, что он называет software factory. Мультиагентная оркестрация LLM здесь не самоцель, а фундамент: чтобы выйти из цикла ручного управления, сначала нужно научиться параллельно задействовать разные модели и доверять их совместному результату.

Вывод

Ценность ролика не в списке новых моделей — он устареет за месяц, — а в подходе. Если ваша команда уже использует Claude Code или другой agentic-инструмент, стоит спросить не «какая модель лучше», а «насколько легко наш harness подключит следующую модель, когда появится очередной релиз». Именно это умение, а не подписка на конкретного поставщика, становится долгосрочным преимуществом в период, когда модели обновляются быстрее, чем успевают устояться привычки работы с ними.