Оркестратор или mesh: как строить систему из LLM-агентов

Как только у вас появляется больше одного LLM-агента, встаёт вопрос: кто кем командует. Либо есть центральный процесс, который принимает запрос, раскладывает его на подзадачи и раздаёт исполнителям (оркестратор), либо агенты общаются между собой напрямую, передавая работу друг другу без единого начальника (mesh). Выбор ломает всю остальную архитектуру: логирование, обработку ошибок, стоимость запуска и то, как быстро вы найдёте баг в проде.

Что это за две модели

Централизованный оркестратор — это один управляющий узел. Он держит состояние задачи, вызывает агентов-исполнителей (планировщик, поисковик, кодогенератор, критик), собирает их ответы и решает, что делать дальше. Так устроены большинство фреймворков с явным графом: LangGraph с его state graph, OpenAI Agents SDK с handoff через координатора, temporal-подобные оркестраторы workflow. Агент-исполнитель ничего не знает о соседях — он получает вход и возвращает выход.

Decentralized multi-agent mesh — сеть равноправных агентов. У каждого есть адрес и набор навыков; агент сам решает, кому передать задачу или у кого запросить помощь. Нет единой точки, которая видит всю картину целиком. Примеры логики — брокер сообщений (агенты слушают топики и отвечают), протоколы вроде emerging agent-to-agent обмена, рой мелких специализированных процессов, координирующихся через общую шину.

Оркестратор знает всё и потому становится узким горлом. Mesh не знает ничего целиком — и потому его невозможно отладить одним взглядом. Вы выбираете, с какой болью жить.

Где кто выигрывает

Латентность

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

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

Отладка и наблюдаемость

Здесь оркестратор выигрывает почти всегда. У вас есть одно место, где видно весь путь запроса: какой агент вызван, с каким входом, что вернул, сколько токенов сжёг. Трейс линеен или хотя бы древовиден. В mesh трассировка распределённая: чтобы восстановить историю одного запроса, нужно сшивать логи нескольких процессов по correlation id.¹ Без этого дебаг превращается в археологию.

Отказоустойчивость

Оркестратор — единая точка отказа. Упал координатор — встали все задачи, которые он вёл (если состояние не персистится во внешнее хранилище). Mesh деградирует мягче: отвалился один агент — соседи могут переадресовать работу другому с тем же навыком. Но это работает только если вы заранее заложили обнаружение недоступных агентов и таймауты, иначе задача просто зависнет в ожидании ответа от мёртвого узла.

Стоимость

Токены — главная статья расходов в системах на LLM. Оркестратор даёт точку, где легко поставить бюджет: не больше N вызовов на задачу, обрежь контекст перед передачей исполнителю. В mesh агенты договариваются сами, и цепочка переспросов (агент А уточняет у Б, Б у В, В обратно у А) может незаметно раздуть счёт. Считать общую стоимость запроса в децентрализованной схеме сложнее — снова из-за распределённого трейса.

Сравнение по критериям

Как выбрать под свою задачу

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

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

Практический компромисс — гибрид. Локальный оркестратор внутри домена (одна команда, один сервис) плюс mesh-обмен между доменами. Внутри группы вы сохраняете единый трейс и бюджет, а между группами получаете горизонтальный рост и мягкую деградацию. Так устроены многие крупные внедрения: не чистая архитектура из учебника, а иерархия оркестраторов, связанных шиной.

Минимальный чек-лист перед решением

1. Сколько агентов у вас будет через полгода, а не сегодня.
2. Как вы будете читать трейс одного запроса — есть ли correlation id и сборщик логов.
3. Кто и как обрежет бесконечную цепочку переспросов между агентами.
4. Что произойдёт с задачами, если управляющий узел упадёт прямо сейчас.
5. Где хранится состояние задачи — в памяти оркестратора или во внешнем персистентном хранилище.

Если на пятый вопрос ответ «в памяти оркестратора», то формально у вас централизованная схема, но по надёжности она хуже любой из двух: единая точка отказа без плюсов персистентности. Выносите состояние наружу до того, как задумываетесь о mesh.

¹ Correlation id — сквозной идентификатор, который присваивается запросу на входе и протаскивается через все вызовы. По нему потом собирают распределённый трейс из логов разных сервисов.