Несколько агентов на одну задачу: fan-out, ревью, верификация

За последний год одиночный агент перестал быть чем-то экзотическим. Инструменты Claude Code-класса стали рабочей нормой: ты описываешь задачу, агент читает репозиторий, правит файлы, запускает тесты, объясняет, что сделал. И вот ровно в тот момент, когда к этому привыкли, поверх одиночного агента вырос следующий слой — мульти-агентные workflows. Идея простая на словах: задача раскладывается на части, несколько агентов работают параллельно (fan-out), один генерирует решение, другой его ревьюит, третий верифицирует, а оркестратор детерминированно сводит всё вместе. Звучит как очевидный следующий шаг. И во многом он действительно очевидный.

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

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

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

Что на самом деле меняется при переходе от одного агента к нескольким

Одиночный агент — это, по сути, один контур «понял задачу → сделал → проверил себя сам». Проблема такого контура хорошо знакома любому, кто работал с агентами в 2025 году: он плохо умеет ловить собственные ошибки. Тот же контекст, который привёл к неверному решению, обычно приводит и к неверной самопроверке. Агент уверенно пишет код и так же уверенно объясняет, почему этот код правильный, даже когда он не правильный. Это не злой умысел, это структурное свойство: генератор и проверяющий — один и тот же процесс, с одними и теми же слепыми зонами.

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

Параллельно появляется второй приём — fan-out. Если задача распадается на независимые части, нет смысла делать их последовательно одним агентом. Можно запустить несколько агентов, каждый возьмёт свою часть, а потом результаты сведутся вместе. Здесь важно подчеркнуть слово «независимые»: fan-out даёт выигрыш ровно в той мере, в какой части задачи действительно не зависят друг от друга. Как только между ними появляются скрытые связи, параллельность превращается из ускорителя в источник рассогласования.

Почему верификация дешевле генерации — и почему это центр всей идеи

Стоит остановиться на этом подробнее, потому что это не лозунг, а несущая конструкция всего подхода. На разложимых, проверяемых задачах с чёткими критериями приёмки проверить результат почти всегда дешевле, чем его получить. Это касается далеко не только AI. Компилятор проверяет типы дешевле, чем человек их выводит. Тесты подтверждают поведение дешевле, чем разработчик его проектирует. Линтер находит проблему дешевле, чем автор её осознанно избегает. Асимметрия между «сделать» и «проверить» — фундаментальное свойство многих инженерных задач, и мульти-агентные workflows просто эксплуатируют его на новом уровне.

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

Это и есть фигура «не A, а B» в чистом виде. Мощь мульти-агентных workflows не в том, что «несколько агентов сами всё сделают», а в том, что проверяемую работу можно распараллелить, а проверку — формализовать. Если убрать из этой фразы слова «проверяемую» и «формализовать», от ценности подхода почти ничего не остаётся. Они не украшение, они условие.

Анатомия workflow: fan-out, генерация, ревью, верификация, сведение

Если приземлить всё это до конкретики, типичный мульти-агентный workflow состоит из нескольких хорошо различимых ролей. Полезно перечислить их явно, потому что путаница ролей — частый источник разочарования в подходе:

Декомпозиция. Кто-то разбивает задачу на части и решает, какие из них независимы и могут идти параллельно. Это может делать оркестратор по заранее заданной структуре, но саму структуру задаёт человек.
Генерация (fan-out). Несколько агентов параллельно решают свои части или предлагают несколько вариантов одной части.
Ревью. Отдельный агент или несколько агентов критически читают результат генерации: ищут ошибки, нарушения требований, расхождения с конвенциями кодовой базы.
Верификация. Прогон результата через объективные проверки — тесты, типизацию, схемы, критерии приёмки. Это самый «глупый» и самый ценный шаг, потому что он не рассуждает, а проверяет.
Сведение. Оркестратор детерминированно собирает прошедшие верификацию части в единый результат и решает, что делать с теми, что не прошли.

Ключевое слово здесь — «детерминированно». Хорошая оркестрация не отдаёт сведение результата на откуп ещё одному вероятностному агенту, который «как-нибудь договорится». Чем больше в системе вероятностных шагов, нанизанных друг на друга, тем выше шанс, что ошибки не гасятся, а накапливаются. Поэтому в зрелых workflows сведение, маршрутизация и решение «принять/отклонить/переделать» стараются делать обычным детерминированным кодом, опирающимся на объективный результат верификации, а не ещё одним слоем «попроси модель решить».

Здесь же на сцену выходит инфраструктура, которая в 2025 году уже стала привычной: суб-агенты как способ изолировать роль и контекст, MCP как способ дать агентам доступ к инструментам и данным по единому протоколу, оркестратор как код, который удерживает весь этот процесс в рамках. Это важно не как перечисление модных слов, а как напоминание: мульти-агентный workflow — это в первую очередь инженерная система, а не «несколько чатов рядом». И проектируется она по инженерным правилам.

Где fan-out реально даёт прирост, а где только его имитирует

Параллельность соблазнительна, и именно поэтому стоит проговорить, где она работает честно. Fan-out даёт реальный прирост на задачах, которые одновременно разложимы и проверяемы. Разложимы — значит части действительно независимы и не делят между собой неявное состояние. Проверяемы — значит у каждой части есть свой критерий, по которому можно сказать «готово» без долгих переговоров. Классические примеры: сгенерировать несколько независимых реализаций и отобрать ту, что проходит тесты; параллельно покрыть тестами несколько модулей; обработать пачку однотипных файлов по одинаковому правилу; предложить несколько вариантов решения и отфильтровать их верификацией.

А вот где fan-out лишь имитирует прирост. Если части задачи на самом деле связаны — меняют общие структуры, зависят от решений друг друга, требуют согласованного дизайна, — то параллельные агенты начинают тихо расходиться. Каждый по отдельности делает осмысленную работу, но вместе они дают несовместимые куски, и вся сэкономленная параллельностью энергия уходит на сведение конфликтов. В таких случаях честнее признать, что задача последовательная, и не распиливать её ради красивого слова «параллельно». Не всякое деление на части — декомпозиция; иногда это просто рассинхрон, оформленный как workflow.

Поэтому первый вопрос перед любым fan-out — не «на сколько агентов это разбить», а «действительно ли эти части независимы и есть ли у каждой свой объективный критерий приёмки». Если ответ «нет», количество агентов не поможет. Оно лишь умножит число мест, где система может разойтись сама с собой.

Чем больше агентов, тем дороже стоит одна неточная фраза на входе

Теперь о цене, без которой разговор был бы нечестным. Может показаться, что чем больше агентов и чем умнее оркестрация, тем меньше нужен человек. На практике зависимость обратная, и это самый важный, самый контринтуитивный пункт всей темы.

Чем больше агентов ты запускаешь, тем важнее становится человек, который задал декомпозицию, критерии приёмки и рамки. Оркестрация не убирает инженера из контура — она поднимает цену его ошибки на входе. В одиночном диалоге неточная формулировка задачи стоит одного неверного ответа, который ты тут же поправишь. В мульти-агентном workflow та же неточность размножается: кривая декомпозиция означает, что пять агентов параллельно и уверенно сделают не то; слабый критерий приёмки означает, что верификатор пропустит мусор; размытые рамки означают, что ревью не на что опереться. Ошибка инженера на входе больше не локальна — она масштабируется вместе с системой.

Это переворачивает наивную картину «рой делает всё сам». Человек не исчезает, он смещается выше по течению. Его работа теперь не в том, чтобы писать каждую строчку, а в том, чтобы правильно разрезать задачу на независимые части, сформулировать для каждой проверяемый критерий и выставить рамки, внутри которых агентам разрешено действовать. Это работа архитектора и постановщика, а не наблюдателя. И она тем ответственнее, чем мощнее машинерия, которую она запускает.

Три счёта, которые приходят за оркестрацию: токены, иллюзия проверки, отладка

Стоит назвать и остальные издержки, чтобы не оставлять подход в розовом свете. Во-первых, координационный оверхед. Несколько агентов, ревью, верификация, сведение — это не бесплатно: больше вызовов, больше контекста, больше времени и денег на токены. На простой задаче, которую одиночный агент закрывает за один проход, вся эта оркестрация — чистый убыток. Подход окупается только тогда, когда выигрыш от распараллеленной проверяемой работы больше, чем стоимость самой координации.

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

В-третьих, отладка. Когда что-то пошло не так в одиночном диалоге, понять причину относительно просто. Когда сбой произошёл в системе из fan-out, нескольких ревьюеров и оркестратора, разобраться, на каком шаге и почему всё развалилось, заметно сложнее. Поэтому наблюдаемость workflow — логирование решений, сохранение промежуточных результатов, трассировка, кто что сгенерировал и почему было принято или отклонено, — не приятное дополнение, а условие, при котором систему вообще можно эксплуатировать всерьёз.

Когда лишний агент только мешает: неразложимая задача без объективного критерия

Честная граница работает в обе стороны, поэтому полезно прямо назвать случаи, где мульти-агентный подход скорее навредит. Если задача неразложима — её нельзя честно разбить на независимые части, — fan-out не даст ничего, кроме рассинхрона. Если у задачи нет дешёвого объективного критерия приёмки, верификация превращается в декорацию. Если задача маленькая и одиночный агент закрывает её за проход, оркестрация — это оверинжиниринг ради красивого слова. И если «правильность» по сути определяется человеческим вкусом, продуктовым контекстом или вещами, которые ты не смог выразить критерием, то проверять нечем, и никакая армия агентов это не заменит.

Это не повод отказываться от подхода. Это повод применять его там, где сходятся два условия: разложимость и проверяемость. Ровно на их пересечении мульти-агентные workflows перестают быть модной картинкой и становятся честным инструментом, дающим реальный прирост. За пределами этого пересечения они в лучшем случае нейтральны, в худшем — добавляют сложности и ложной уверенности.

Как это меняет developer workflow инженера

Если посмотреть на всё это с точки зрения повседневной работы, сдвиг получается вполне конкретный и спокойный, без эйфории. Раньше время инженера уходило в основном на генерацию: написать, отладить, проверить вручную. Теперь, на разложимых и проверяемых задачах, центр тяжести смещается к постановке и к проектированию проверки. Хорошо сформулированный критерий приёмки становится более ценным активом, чем ещё одна написанная руками реализация, потому что критерий можно переиспользовать как арбитр для любого числа агентов.

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

Так что это не революция и не автопилот. Это сдвиг: ещё один слой инструментов, который усиливает инженера там, где он сам задал хорошую структуру, и так же усиливает его ошибки там, где структура плохая. Он не думает за инженера. Он масштабирует последствия того, насколько хорошо инженер подумал.

Что со всем этим делать инженеру на практике

Если собрать всё сказанное в рабочую оптику, несколько агентов на одну задачу стоит держать в голове как ещё один слой над одиночным агентом — и относиться к нему трезво. На разложимых, проверяемых задачах с чёткими критериями приёмки fan-out, разделение ролей на генерацию, ревью и верификацию и детерминированное сведение дают реальный прирост — потому что опираются на старую и надёжную асимметрию: верификация дешевле генерации. Это не про рой AI, который сам всё сделает. Это про то, что проверяемую работу можно распараллелить, а проверку — формализовать. Убери из этой формулы проверяемость и формализацию, и подход рассыплется.

Практический вывод, если сформулировать его совсем прямо: оркестрация не выводит инженера из контура, а поднимает цену его решений на входе — чем больше агентов ты запускаешь, тем дороже стоит каждая неточность в декомпозиции, критериях и рамках, которые задал именно человек. Это инструмент инженера, а не автопилот. И, как у любого хорошего инструмента, его польза прямо пропорциональна тому, насколько ясно держит руку тот, кто его запустил.