Сто агентов, ноль результата
Мультиагентная оркестрация не починит отсутствие цели. Она только быстрее накапливает мусор, если пропущены два шага: проверяемая цель всей системы и явное определение каждого агента. Сто агентов на красивой диаграмме дают ноль результата, когда никто не ответил на вопрос «что они производят и как это проверить».
Сто агентов, ноль результата
Каждую неделю кто-то выкладывает схему своей оркестрации. Десяток узлов с именами: planner, researcher, critic, writer, reviewer. Стрелки между ними. Подпись «моя AI-команда из десяти агентов». Я смотрю на такую схему и ищу одну вещь: где написано, что система выдаёт на выходе и как понять, что результат верный. Обычно этого нет нигде.
Тут спутаны две разные проблемы. Оркестрация отвечает на вопрос «как не упереться в контекстное окно одного агента»: разбить работу, раздать кускам, собрать обратно. Это полезно. Но она ничего не говорит о том, как понять, что надо сделать и каким будет правильный результат. Механика в одном месте, смысл в другом. Когда их путают, получается организованный дрейф: много движения, ноль попадания.
Механизм дрейфа: почему цепочка без контракта врёт уверенно
Первый агент получает задачу «улучши онбординг» и понимает её чуть по-своему: для него улучшить значит сократить шаги. Он отдаёт результат второму. Второй принимает вывод первого за проверенный факт и достраивает в свою сторону: раз шагов меньше, надо переписать тексты. Третий берёт это как данность и идёт дальше. К пятому агенту на руках оформленный, структурированный, уверенный ответ на вопрос, который никто не задавал.
Каждый следующий агент относится к выводу предыдущего как к верифицированному факту. Никакой верификации на стыке нет. Агент без критерия правильного результата выдаёт правдоподобный результат, а правдоподобие читается глазами как качество. Ошибку не видно до самого конца.
Это не моя выдумка. Anthropic в Building Effective Agents прямо предупреждает про «higher costs, and the potential for compounding errors»: ошибки в цепочке агентов не гасятся, они накапливаются. Cognition в «Don’t Build Multi-Agents» формулирует жёстче: когда разные агенты принимают решения без общего контекста, «conflicting decisions carry bad results».
БЕЗ КОНТРАКТА С ЖЁСТКИМ КОНТРАКТОМ
───────────── ───────────────────
[Агент A] задача: «улучши» [Агент A] вход: текст задачи
│ интерпретация │ выход: JSON {repo, type, conf}
▼ ▼ проверка ✓
[Агент B] понял: «переделай» [Агент B] вход: JSON от A
│ достроил │ выход: список URL с цитатами
▼ ▼ проверка ✓
[Агент C] «сделай иначе» [Агент C] вход: список URL
│ │ выход: итоговый ответ
▼ ▼ проверка ✓
ИТОГ: красиво, неверно ИТОГ: медленнее, верно
Человеческое бутылочное горлышко
Узкое место в мультиагентной системе это не модель и не оркестратор. Это человек, который ставит задачу.
Большинство людей не умеют поставить задачу даже одному агенту. Промпт размытый, агент выдаёт мимо, человек уточняет, ещё раз, ещё. За пять итераций выходят на приемлемый результат. Для работы с одним агентом это нормально: ты сидишь в петле обратной связи и правишь курс на каждом шаге.
В оркестрации этих пяти итераций нет. Вывод первого агента сразу становится входом второго. Система едет дальше без тебя. И вот тут размытость постановки умножается на число шагов: то, что ты поправил бы на втором проходе, ушло дальше по цепочке как факт.
Агенты усиливают вашу доменную экспертизу. Заменить её они не могут. Если вы не разбираетесь в маркетинге, скилл «маркетолог» не сделает за вас классный пост по волшебству: он сгенерирует текст, который выглядит как пост, а оценить его всё равно нечем. Моё мнение: лучшие вайбкодеры часто вообще не инженеры. Инженер залипает на коде и обычно слабее понимает продукт. Вайбкодеру код безразличен, он держит в голове результат для пользователя, и поэтому ставит агенту правильную цель.
Личный опыт: почему я ушёл от готового оркестратора
Я пробовал готовые оркестраторы и ушёл от них.
Попробовал Paperclip. Это open-source control plane для AI-агентов: есть оргчарт, цели наследуются от родительских, а ты сидишь как совет директоров над всем этим. На бумаге красиво. На практике не нашёл применения. Готовые штуки хороши ровно настолько, насколько ты понимаешь свой процесс. Нет понятного бизнес-процесса под капотом, нет и пользы. Получается хаос с красивым оргчартом.
Моя система проще и поэтому работает. Файлы, правила, скилл-менеджер, который понимает, в какой репозиторий отнести задачу. Я уже писал, как вожу агентов с одной доски: такой оркестратор реально помогает управлять, но только когда роли заданы заранее. Доска не придумывает роли за меня.
Промпт скилл-менеджеру, который раскидывает задачи по репозиториям:
Factory Droid в режиме Mission: оркестратор бьёт задачу на вехи, воркеры пишут код по TDD, отдельные валидаторы со свежим контекстом проверяют каждую веху, и только потом оркестратор принимает работу или возвращает на доработку. Роли узкие. Контракт между шагами жёсткий. Никто не передаёт дальше непроверенный кусок. Вот так выглядит оркестрация, которая работает.
Честный контраргумент: multi-agent реально работает
Multi-agent реально работает, и я не собираюсь это передёргивать.
Anthropic строят мультиагентную исследовательскую систему и описывают, почему она у них взлетела. У рабочих примеров одна черта: подзадачи узкие и проверяемые, а на стыках стоит явный контракт. Один агент ищет и возвращает список URL с цитатами, другой классифицирует найденное по таксономии, третий агрегирует. Каждый кусок можно проверить отдельно.
При этом сами Anthropic честно пишут про цену: мультиагентная связка съедает примерно в пятнадцать раз больше токенов, чем обычный чат, против примерно четырёхкратного у одиночного агента. Оправдано это только на широких, распараллеливаемых, дорогих по ценности задачах. Их ранние версии спаунили по полсотни субагентов на простой запрос, и они сами называют это ошибкой дизайна.
Cognition называет свой текст «Don’t Build Multi-Agents» и при этом строит Devin. Их рекомендация по умолчанию: один линейный агент в одном потоке. Multi-agent они допускают только для изолированных, независимых друг от друга подзадач. Когда они дали Devin инструмент спаунить других Devin-ов, получился, по их словам, «a really chaotic world».
Это не спорит с моим тезисом. Это его подтверждает. Параллельная работа специализированных агентов по явным ролям выглядит ровно так, как я показывал на совете директоров из субагентов: каждый эксперт в своей рамке, никто не лезет в чужую. А когда агенты собирали мне overlay для эфира на Fable 5, они интегрировали компоненты параллельно только потому, что задачи были изолированы заранее. Multi-agent работает там, где шаги уже сделаны.
Порядок важен: цель → определения → верификация → масштаб
Четыре шага. Порядок не переставляется.
Первое: точная проверяемая цель всей системы. Пока её нет, проверить нельзя ни один стык, потому что не с чем сверять. «Улучши онбординг» это не цель. «Сократи онбординг до трёх экранов, чтобы первый платёж проходил в первой сессии» уже цель, её видно.
Второе: явное определение каждого агента. Что он принимает на вход. Какой результат обязан выдать. Что делает, когда данных не хватает. Где граница его ответственности и где начинается чужая. Сюда же относится выбор модели под роль: писал, какую модель ставить субагенту, и этот выбор входит в определение агента с самого начала. Так я определяю роль субагента-классификатора для Claude Code:
Третье: верификация на каждом стыке. Каждый выход проверяется на соответствие контракту. Под это у меня есть отдельный скилл аудита продукта с явным контрактом на каждом шаге.
Четвёртое: и только теперь масштаб. Оркестратор, Paperclip, Mission Mode, любой control plane. Инструмент оркестрации не заменяет ни один из первых трёх шагов. Он лишь позволяет запустить систему там, где эти шаги уже сделаны. А там, где не сделаны, тот же инструмент просто быстрее копит мусор: сто агентов, ноль результата.
Подписаться на обновления — @sereja_tech