Теперь архитектура — это оркестрация

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

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

Координация — не сантехника. Это и есть система.

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

У этого слоя есть имя: оркестрация. И это не провод, а набор настоящих обязанностей — декомпозиция задачи, маршрутизация, управление состоянием, агрегация результатов и обработка ошибок с эскалацией. Доминирующая форма в проде — паттерн orchestrator-worker (оркестратор-воркер), примерно 70% развёртываний — где одна способная модель получает задачу, разбивает её, рассылает каждый кусок дешёвому воркеру-специалисту и собирает результаты. (Это разделение — умный планировщик над дешёвыми исполнителями — заодно и источник большой части экономии — 40–60% в задокументированных случаях.) Этот оркестратор — не клей. Это самый важный компонент, который ты напишешь.

Это распределённая система, и падает она как распределённая

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

• Каскады. Один агент галлюцинирует, передаёт свой неверный ответ следующему как факт, и ошибка накапливается вниз по цепочке — испорченное сообщение, идущее через пайплайн.
• Убегающие циклы. Два агента гоняют задачу туда-сюда, или один ретраит вечно, тихо накручивая твой API-счёт — неограниченный повтор со счётчиком на боку.
• Тихая потеря сообщений. Передача переполняет окно контекста, критичная информация усекается так, что никто не замечает, и агент ниже по потоку действует по полу-сообщению — потерянные пакеты без всякой ошибки.
• Мёртвая эскалация. Путь «эскалировать человеку», который все спроектировали и никто не протестировал, на деле так и не срабатывает — обработчик ошибок, которого никогда не было на счастливом пути.

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

Не тянись к этому, пока не можешь назвать узкое место

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

Консенсус, который её заменил и к которому сошлись пять крупных вендоров — Anthropic, OpenAI, Cognition, LangChain, AutoGen, — полезное правило: бремя доказательства лежит на мульти-агенте, а не на одно-агентном. Начни с одного агента. Добавь второго, только когда можешь назвать конкретное узкое место, которое его требует, — изоляция домена, по-настоящему параллельная работа, граница комплаенса. «Ощущается солиднее» — не узкое место. Каждый добавленный агент покупает возможности и платит за них координацией, и этот обмен оправдан, лишь когда его требует что-то конкретное.

Настоящий провал — делать это случайно

Сложи две ловушки вместе — и проступает настоящая проблема. Большинство команд не решают строить мульти-агентную систему; они её выращивают. Они прикручивают агента к агенту, чтобы залатать дыру, потом ещё одного, и оркестрация возникает неявно — без выбранного паттерна, без контрактов, без обработки ошибок, просто накопленная обвязка, которую никто не проектировал. Ровно так и попадаешь в колонку 86%. Запросы по мульти-агентным системам взорвались, но координация по большей части импровизированная, а импровизированные распределённые системы падают.

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

Когда строительство подешевело и ты разбил работу на специалистов, ты не убрал архитектуру — ты её переселил. Раньше она жила внутри промпта одного агента; теперь она живёт в координации между многими. Спроектируй эту координацию как распределённую систему, какой она и является, — осознанно — или смотри, как она падает, как та, которую ты притворялся простой сантехникой.