# Теперь архитектура — это оркестрация Разбей god-агента на десять сфокусированных — и ты меняешь проблему модели на проблему системы: теперь им надо работать вместе, а координация тяжелее любого отдельного агента. Большинство относятся к этой обвязке как к сантехнике. Это не сантехника — это архитектура, это распределённая система, и падает она как распределённая. Вот что такое оркестрация на самом деле, как она ломается и почему не стоит тянуться к ней, пока не можешь назвать узкое место. - **Author:** Фёдор Чищин - **Published:** 2026-06-03 - **Tags:** agents, architecture, methodology - **Source:** https://fedorthinks.com/ru/blog/orchestration-is-the-architecture --- В прошлый раз я доказывал, что нужно [разбить god-агента](/blog/one-agent-that-does-everything) на маленьких сфокусированных агентов, каждый из которых делает одно хорошо, — и закончил подвохом: это не удаляет твою проблему, а меняет её на новую. Теперь у тебя десять агентов, которым надо работать вместе, и заставить их это делать оказывается тяжелее всего, с чем мучился любой отдельный агент. Эта координация — и есть тема поста, потому что то, как большинство команд с ней обращаются, и есть тихая причина, по которой их мульти-агентные системы заваливаются. ## Координация — не сантехника. Это и есть система. Когда люди строят мульти-агентную связку, они думают об агентах как о системе, а об обвязке между ними — как о сантехнике: соедини выходы со входами, и готово. Это наоборот. Как только работа разбита по специалистам, агенты — лёгкая часть. **Теперь архитектура — это координация** — и именно её почти никто не проектирует осознанно. У этого слоя есть имя: оркестрация. И это не провод, а набор настоящих обязанностей — [декомпозиция задачи, маршрутизация, управление состоянием, агрегация результатов и обработка ошибок с эскалацией](https://atlan.com/know/multi-agent-system-orchestration/). Доминирующая форма в проде — паттерн **orchestrator-worker** (оркестратор-воркер), примерно [70% развёртываний](https://medium.com/@Micheal-Lanham/multi-agent-in-production-in-2026-what-actually-survived-f86de8bb1cd1) — где одна способная модель получает задачу, разбивает её, рассылает каждый кусок дешёвому воркеру-специалисту и собирает результаты. (Это разделение — умный планировщик над дешёвыми исполнителями — заодно и [источник большой части экономии](/blog/cheap-model-most-of-the-work) — 40–60% в задокументированных случаях.) Этот оркестратор — не клей. Это самый важный компонент, который ты напишешь. ## Это распределённая система, и падает она как распределённая Вот ментальный сдвиг, который делает всё решаемым: мульти-агентная система — это _и есть_ распределённая система. Независимые компоненты, передающие сообщения, держащие состояние, отказывающие частично. И в тот миг, когда ты так на неё смотришь, её пугающие режимы отказа перестают быть загадочными «ИИ-проблемами» и становятся классическими проблемами распределённых систем, которые ты уже знаешь: - **Каскады.** Один агент галлюцинирует, передаёт свой неверный ответ следующему как факт, и ошибка накапливается вниз по цепочке — испорченное сообщение, идущее через пайплайн. - **Убегающие циклы.** Два агента гоняют задачу туда-сюда, или один ретраит вечно, [тихо накручивая твой API-счёт](https://www.digitalapplied.com/blog/multi-agent-orchestration-5-patterns-that-work) — неограниченный повтор со счётчиком на боку. - **Тихая потеря сообщений.** Передача переполняет окно контекста, критичная информация усекается так, что никто не замечает, и агент ниже по потоку действует по полу-сообщению — потерянные пакеты без всякой ошибки. - **Мёртвая эскалация.** Путь «эскалировать человеку», который все спроектировали и никто не протестировал, на деле так и не срабатывает — обработчик ошибок, которого никогда не было на счастливом пути. И это не гипотетическая хрупкость. Мульти-агентные системы измеренно падают в проде с частотой [от 41% до почти 87%](https://www.augmentcode.com/guides/why-multi-agent-llm-systems-fail-and-how-to-fix-them), причём **на сбои координации приходится 36.9%** всех отказов — не модели тупые, а _координация_ неуправляема. Починка — привнести дисциплину, которую режимы отказа буквально вымаливают: явные контракты между агентами, ограниченные циклы и ретраи, наблюдаемое состояние и пути ошибок и эскалации, которые ты реально прогоняешь. Проблемам распределённых систем нужны ответы распределённых систем. ## Не тянись к этому, пока не можешь назвать узкое место Есть и вторая ловушка, противоположная «координация — это сантехника»: тянуться к мульти-агенту, потому что это звучит мощно. Это мощно — и это _дорого_. У координации есть реальная цена: мульти-агентные системы могут сжигать [**в 15 раз больше токенов**, чем одно-агентное взаимодействие](https://www.augmentcode.com/guides/why-multi-agent-llm-systems-fail-and-how-to-fix-them), плюс большие накладные расходы просто на перекладывание состояния. Мечта 2024-го «больше агентов = больше интеллекта» по большей части умерла в проде. Консенсус, который её заменил и к которому сошлись пять крупных вендоров — [Anthropic, OpenAI, Cognition, LangChain, AutoGen](https://towardsdatascience.com/the-multi-agent-trap/), — полезное правило: **бремя доказательства лежит на мульти-агенте, а не на одно-агентном.** Начни с одного агента. Добавь второго, только когда можешь назвать конкретное узкое место, которое его требует, — изоляция домена, по-настоящему параллельная работа, граница комплаенса. «Ощущается солиднее» — не узкое место. Каждый добавленный агент покупает возможности и платит за них координацией, и этот обмен оправдан, лишь когда его требует что-то конкретное. ## Настоящий провал — делать это случайно Сложи две ловушки вместе — и проступает настоящая проблема. Большинство команд не _решают_ строить мульти-агентную систему; они её _выращивают_. Они прикручивают агента к агенту, чтобы залатать дыру, потом ещё одного, и оркестрация возникает неявно — без выбранного паттерна, без контрактов, без обработки ошибок, просто накопленная обвязка, которую никто не проектировал. Ровно так и попадаешь в колонку 86%. Запросы по мульти-агентным системам [взорвались](https://towardsdatascience.com/the-multi-agent-trap/), но координация по большей части импровизированная, а импровизированные распределённые системы падают. Починка — не фреймворк. Это позиция: относись к оркестрации как к первоклассному артефакту проектирования. Выбери паттерн осознанно. Запиши контракт, который соблюдает каждый агент. Реши, что происходит, когда шаг зацикливается, усекается или падает, — до того, как это случится. Оркестратор заслуживает того же намеренного проектирования, что ты дал бы любой критичной системе, потому что он ею и является. Когда строительство подешевело и ты разбил работу на специалистов, ты не убрал архитектуру — ты её переселил. Раньше она жила внутри промпта одного агента; теперь она живёт в координации между многими. Спроектируй эту координацию как распределённую систему, какой она и является, — осознанно — или смотри, как она падает, как та, которую ты притворялся простой сантехникой.