Оркестрация vs хореография: от микросервисов к AI-агентам

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

Немного контекста: откуда это всё пришло

В начале 2010-х индустрия массово распиливала монолиты. Netflix, Amazon, Uber показали, что сотни маленьких сервисов работают лучше одного большого. Но как только ты разбиваешь систему на части, всплывает вопрос: а кто теперь управляет бизнес-процессом, который раньше жил в одной транзакции?

Представим простой процесс оформления заказа:

1. Проверить наличие товара (Inventory Service)
2. Списать деньги (Payment Service)
3. Создать доставку (Shipping Service)
4. Отправить уведомление (Notification Service)

В монолите это одна функция и одна транзакция. Упало что-то в середине, откатываем всё. В распределённой системе такой роскоши нет. И тут появляются два философски разных ответа.

Оркестрация: центральный дирижёр

Идея простая: есть один компонент-оркестратор, который знает весь процесс. Он по очереди вызывает сервисы, собирает ответы, решает, что делать дальше. Сервисы сами ничего не знают про общий процесс.

BPMN и Camunda

Если один продукт и определяет индустрию оркестрации, это Camunda. Немецкая компания, которая взяла стандарт BPMN 2.0 (Business Process Model and Notation) и превратила его в рабочий инструмент для production. Не академическую игрушку, а движок, на котором банки обрабатывают миллионы транзакций в день, телеком провайдеры управляют подключением абонентов, а ритейл гоняет заказы через десятки сервисов.

Предыстория: первой попыткой стандартизировать оркестрацию был BPEL (Business Process Execution Language) из мира SOA конца 2000-х. XML-язык, BPEL-серверы (Oracle, IBM, JBoss). К 2015 году выглядел как динозавр, но задал шаблон мышления: процесс как отдельный артефакт, отделённый от кода сервисов.

На смену пришли движки нового поколения:

• Camunda 7 - король enterprise-оркестрации. BPMN 2.0, Java-native, встроенный в Spring Boot. Cockpit для мониторинга, Tasklist для human tasks, Modeler для визуального проектирования. До сих пор стандарт де-факто в enterprise. На смену приходит Camunda 8 (движок Zeebe), распределённый и cloud-native, но 7-ка всё ещё доминирует в production. Плюс DMN-движок для бизнес-правил: условия тарификации, правила скоринга, пороги одобрения - всё это описывается в таблицах решений, отдельно от кода процесса.
• Activiti и форк Flowable - BPMN 2.0, Java-центричные, легче Camunda, популярны в Alfresco-экосистеме
• Netflix Conductor - JSON-based workflows, изначально для видео-пайплайнов Netflix, сейчас у Tesla и eBay
• Temporal (fork Cadence от Uber) - workflow как код, не визуальный. Другая философия: вместо BPMN-диаграммы пишешь обычный код с гарантиями durable execution
• Apache Airflow - DAG на Python для data pipelines, тоже по сути оркестратор, но для аналитики

BPMN-диаграмма как исполняемый артефакт

Camunda выделяется тем, что BPMN-диаграмма это исполняемый артефакт. Ты не просто рисуешь схему для презентации, ты рисуешь схему, которая деплоится на движок и начинает вызывать сервисы. Бизнес-аналитик видит визуальный процесс, разработчик мапит задачи на Java-делегаты, DevOps мониторит через Cockpit. Все говорят на одном языке.

Что движок делает под капотом

Оркестратор это не просто цикл вызовов. Промышленный движок обеспечивает: persistence состояния (упал сервер - процесс подхватится с того же шага, это "durable execution"), автоматические retries с exponential backoff, компенсирующие транзакции при ошибке, параллелизм через BPMN-конструкции, human tasks (процесс "засыпает" в БД и ждёт решения человека), версионирование (старые процессы живут на v1, новые на v2), observability через UI (Cockpit, Temporal Web).

Пример: Temporal (workflow как код)

Temporal описывает процесс как обычный код, но гарантирует durable execution, если сервер упадёт, после рестарта процесс продолжится с той же строки:

public class OrderWorkflowImpl implements OrderWorkflow {
    @Override
    public void processOrder(Order order) {
        Saga saga = new Saga(new Saga.Options.Builder().build());
        try {
            String reservationId = inventory.reserve(order);
            saga.addCompensation(inventory::releaseReservation, reservationId);
            String paymentId = payment.charge(order);
            saga.addCompensation(payment::refund, paymentId);
            shipping.createShipment(order);
        } catch (ActivityFailure e) {
            saga.compensate();  // Откат в обратном порядке
            throw e;
        }
    }
}

Camunda идёт другим путём: процесс описывается визуальной BPMN-диаграммой, каждая задача мапится на Java-делегат. Диаграмма, отдельный артефакт, её можно показать бизнес-аналитику, изменить, задеплоить через hot-reload. Camunda, визуальный подход, Temporal, кодовый. Оба, оркестраторы.

Плюсы и минусы оркестрации

Плюсы: наглядность процесса (BPMN-диаграмма), простой debugging (видишь точную точку остановки), централизованный error handling, версионирование, audit trail для compliance, встроенные human tasks.

Минусы: single point of failure (лечится кластеризацией), связанность через центр, боттлнек при высоком throughput, god object антипаттерн при разрастании BPMN, порог входа в Camunda/Temporal.

Хореография: танец без дирижёра

Идея противоположная: никто никем не управляет. Сервисы слушают события и реагируют. Один сервис сделал свою работу, опубликовал событие "я закончил", другой услышал и начал своё.

Как это выглядело в микросервисах

Хореография, это event-driven архитектура. Инструменты: Apache Kafka, RabbitMQ, AWS EventBridge, NATS.

Тот же процесс заказа:

• OrderService публикует OrderCreated
• InventoryService слушает → резервирует → публикует InventoryReserved
• PaymentService слушает → списывает → публикует PaymentCharged
• ShippingService слушает → создаёт → публикует ShipmentCreated
• NotificationService слушает → отправляет письмо

Нигде нет центрального кода, который знает всю последовательность. Каждый сервис подписан на нужные топики Kafka и живёт сам по себе. На Java это выглядит как @KafkaListener + KafkaTemplate.send() в каждом сервисе, но важен не код, а принцип: nobody knows the whole process.

Плюсы и минусы хореографии

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

Минусы: процесс размазан по коду (надо читать десяток сервисов), сложный debugging (distributed tracing обязателен), циклические зависимости возникают незаметно, eventual consistency (система всегда в промежуточном состоянии).

Где хореография реально живёт, а где её нет

На бумаге хореография выглядит элегантно: слабая связанность, масштабируемость, никакого SPOF. На практике в enterprise её почти не встретишь как способ выполнять бизнес-процесс. Я много лет проработал в финтехе и не видел ни одного кейса, где перевод, открытие счёта или выдача кредита были реализованы чистой хореографией. Причины простые.

Регулятор требует показать ход транзакции одним артефактом. SLA живёт на процессе, а не на сервисе, и должен кому-то принадлежать. При инциденте надо за минуты понять, где застряло, в распределённой цепочке подписчиков это часы.

Там, где хореография действительно работает в финтехе, это интеграционная шина для fan-out уведомлений о свершившемся факте. Core banking опубликовал TransactionPosted, дальше слушают antifraud, CRM, BI, пуши. Но сам TransactionPosted пришёл из оркестрированного процесса. Хореография живёт после саги, не внутри неё.

Отсюда простое правило: хореография, для распространения событий, оркестрация, для выполнения процессов. Как только пытаешься исполнять сагу через события, строишь оркестратор, просто размазанный и без UI.

В 2014-2018 Java-мир жил на Spring Cloud поверх Netflix OSS (Eureka, Hystrix, Zuul). Saga на Camunda с Spring Boot Starter стала стандартом оркестрации. Сегодня в AI та же картина: роль Spring Cloud играют LangGraph, AutoGen, CrewAI, а паттерны всплывают заново, только внутри узлов сидит LLM.

Распределённые транзакции: сага-паттерн

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

Если шаг 3 из 5 упал, запускаются компенсации для шагов 1 и 2 в обратном порядке.

В оркестрации сага реализуется явно. Оркестратор знает последовательность, при ошибке вызывает compensating actions.

В хореографии каждый сервис сам знает, на какие события отвечать откатом. Получается "цепочка откатов".

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

А вот хореография лучше для простых потоков с большим количеством независимых подписчиков. Классический пример: событие UserRegistered, и его слушают Email Service, Analytics, CRM, Recommendation Engine.

Матрица выбора

Sam Newman в "Building Microservices" даёт хороший эвристический совет: хореография по умолчанию, оркестрация там, где процесс важнее сервисов. В enterprise-практике, особенно в финтехе и телекоме, чаще встречается обратная позиция: оркестрация по умолчанию, потому что SLA, compliance и audit trail перевешивают гибкость. Обе позиции обоснованы, выбор зависит от домена.

А теперь главное: агенты

Проматываем десять лет. Появляются LLM, за ними агенты. И внезапно те же вопросы всплывают заново.

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

Звучит знакомо? Это те же проблемы распределённых систем, только с LLM внутри каждого узла.

Оркестрация в мире агентов

Самый яркий пример, LangGraph от команды LangChain (Python SDK). Явный оркестратор: граф с узлами-агентами и рёбрами-переходами. Состояние, супервизор, детерминированные переходы.

workflow = StateGraph(AgentState)
workflow.add_node("researcher", researcher_agent)
workflow.add_node("writer", writer_agent)
workflow.add_node("reviewer", reviewer_agent)

workflow.add_edge("researcher", "writer")
workflow.add_conditional_edges(
    "reviewer",
    lambda state: "writer" if state["needs_revision"] else END
)

Другие примеры:

• AutoGen от Microsoft с GroupChatManager
• CrewAI с ролями и иерархическими процессами
• OpenAI Agents SDK (заменил Swarm в марте 2025) - handoffs и маршрутизация между агентами

Хореография в мире агентов

• OpenAI Agents SDK (заменил устаревший Swarm в марте 2025) - handoffs без центрального менеджера
• Multi-agent на A2A (Agent-to-Agent protocol от Google) - прямое общение между агентами. Протокол пока ранней стадии, но направление ясное. Вместе с MCP (Model Context Protocol, Anthropic) закрывает два уровня: A2A для "агент ↔ агент", MCP для "агент ↔ инструмент"
• Mesh-архитектуры типа AutoGen в режиме free-form group chat

Академические работы по emergent behavior в multi-agent системах идут похожим путём. Stanford'овский "Generative Agents: Interactive Simulacra of Human Behavior" интересен как пример: агенты живут в общей среде и реагируют на события друг друга. Это не хореография в Kafka-смысле (там шедулер и shared memory, а не event bus), но принцип "никто не управляет потоком сверху" тот же.

Те же плюсы-минусы, только с LLM-спецификой

Оркестрация даёт предсказуемость и контроль. Критично для production, где нужно SLA, логи, compliance. Но ограничивает гибкость.

Хореография даёт emergent capabilities. Агенты самоорганизуются, находят неожиданные решения. Но отлаживать мучение, и в production выкатывать страшно.

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

Отсюда три режима координации, а не два:

1. Жёсткая оркестрация (LangGraph с фиксированными переходами, CrewAI sequential), по сути workflow с LLM-узлами. Подходит для SDLC-пайплайнов, обработки документов. Camunda с LLM-делегатами.
2. Управляемая хореография (OpenAI Agents SDK, AutoGen GroupChat, A2A), агенты сами решают, к кому обратиться, в очерченной песочнице. Работает лучше, чем в микросервисах, потому что "решение, кого позвать" - ровно то, что LLM делает нативно.
3. Гибрид с наблюдателем (Jarvis), оркестратор не управляет потоком, а задаёт контур и наблюдает. Аналог service mesh + policy engine, а не BPMN-движки. Роль центрального компонента сдвигается от дирижёра к надзирателю.

Что меняет LLM: почему агентные системы другие

Микросервисы детерминированы. При одинаковых входах сервис вернёт одинаковый результат. Агенты нет. LLM может по-разному интерпретировать одну и ту же задачу, выбрать другой инструмент, уйти в рассуждения на 500 токенов или 5000. Это фундаментально меняет выбор паттерна координации.

Недетерминизм. В микросервисной саге шаг 3 всегда вызывает шаг 4. В агентной системе шаг 3 (Critic) может решить, что нужно вернуться к шагу 1 (Writer), или вообще вызвать новый агент, которого не было в плане. Жёсткая оркестрация с этим борется, ограничивая агента рёбрами графа. Хореография это нативно поддерживает, агент сам решает, что дальше.

Стоимость токенов как фактор архитектуры. В микросервисах вызов сервиса стоит миллисекунды процессора. В агентах каждый вызов LLM стоит реальные деньги. При оркестрации с пятью агентами один бизнес-процесс может сожрать $0.50 на токенах. При хореографии с emergent поведением бюджет может уйти в небо, потому что агенты будут "дискутировать" через события. Это новый тип constraint, которого в микросервисах не было.

Контекстные окна. Агент не может держать в голове состояние всего процесса. У современных моделей контекст 128-200K токенов (Claude Sonnet, GPT-4o), но это с учётом входа, промпта и истории. В сложном процессе с десятью агентами контекст быстро переполняется. В оркестрации оркестратор управляет тем, какой контекст передать каждому агенту. В хореографии каждый агент сам решает, что ему нужно знать, и часто решает неправильно.

Handoffs и галлюцинации. Когда агент A передаёт задачу агенту B, возможны потери и искажения. Агент A резюмировал результат в трёх предложениях, агент B интерпретировал их иначе. В оркестрации оркестратор контролирует формат передачи. В хореографии это зона риска: нет единого контракта между агентами, только "естественный язык" как протокол.

Это четыре фактора, которые делают агентные системы качественно сложнее микросервисных, и которые нужно учитывать при выборе паттерна.

Human-in-the-loop. Ещё одно отличие от микросервисов: в BPMN human task это исключение, а в агентных системах эскалация к человеку должна быть правилом. LLM может быть уверена в ошибочном решении. Если агент публикует событие с confidence < порога, observer эскалирует человеку. Это не баг оркестрации, а фича, которую микросервисам не нужны.

Матрица выбора для агентных систем

Микросервисная матрица выше не работает для агентов. Вот агентная версия:

Мой кейс: Jarvis как гибрид

Когда я проектировал Jarvis, я прошёл через обе крайности.

Первая итерация: чистая оркестрация: Creator-Critic-Kernel пайплайн с кворумом из пяти LLM. Работало, но дорого и медленно. Для простых задач дикий оверхед.

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

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

Сейчас роли разделены так:

Оркестратор занимается:

• Конфигурацией агентов и их скиллов
• Распределением задач на этапе диспетчеризации
• Мониторингом через логи и события
• Анализом постфактум: какие скиллы устарели, где проблемы
• Рекомендациями: "агент X давно не используется", "скилл Z избыточен"

Агенты работают в хореографии:

• Принимают задачу и выполняют автономно
• Дёргают других агентов через A2A-подобные вызовы
• Публикуют события в общую шину
• Используют семантическую память как общий контекст

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

Event bus как кровеносная система

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

1. Слабую связанность. Агент не знает, кто конкретно будет использовать его результат. Он публикует ResearchComplete с payload, и любой подписчик может его обработать.
2. Audit trail. Все события логируются. Когда что-то пошло не так, можно воспроизвести цепочку: какой агент что опубликовал, кто на что отреагировал, где произошло отклонение.
3. Наблюдаемость без вторжения. Оркестратор не должен перехватывать каждый вызов. Он подписан на event bus как наблюдатель, видит поток событий, но не вмешивается в горячий путь.

В микросервисной терминологии это consumer-driven contract testing + event sourcing + CQRS, только вместо топиков Kafka у агентов семантическая память и event callbacks.

Наблюдаемость: от чёрного ящика к прозрачной системе

Самая большая боль второй итерации (чистая хореография) была в том, что при ошибке я не мог быстро ответить на вопрос "что случилось?". В распределённой хореографии микросервисов та же проблема решается distributed tracing (Jaeger, Zipkin). В агентных системах distributed tracing не работает, потому что "вызов" это не HTTP-реквест, а LLM-инференс с непредсказуемой длительностью и результатом.

Решение в Jarvis трёхуровневое:

1. Структурный лог каждого вызова. Агент логирует: какую задачу получил, какой инструмент вызвал, сколько токенов потратил, какой результат вернул. Формат единый, оркестратор парсит автоматически.
2. Семантические чекпоинты. После значимых действий агент публикует не только результат, но и свою "уверенность" (confidence score) и флаги: нужен ли human review, есть ли неопределённость.
3. Постфактум анализ. Оркестратор раз в N минут пробегает по логам и ищет паттерны: агент X постоянно fallback-ится, скилл Y не используется, агент Z тратит в три раза больше токенов чем ожидается. Это не real-time мониторинг, а аналитика, которая приходит с отчётом.

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

Выводы

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

Хореография агентов работает лучше, чем в микросервисах, потому что LLM нативно умеет решать "что делать дальше". Это не тупой сервис с хардкод-обработчиком, а рефлексирующий агент. Но рефлексия не равна надёжности: LLM может рефлексировать и всё равно принять плохое решение. Именно поэтому observer, а не автопилот.

Production-система придёт к гибриду. Не потому что это компромисс, а потому что правильная архитектура для агентов это хореография на горячем пути и надзор на холодном.

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

Литература

Микросервисы и паттерны:

• Sam Newman, «Building Microservices», 2nd edition, O'Reilly, 2021
• Chris Richardson, «Microservices Patterns», Manning, 2018 (есть сайт книги с примерами и 2-е издание в MEAP)
• Martin Fowler, «What do you mean by Event-Driven?» и подборка статей в теге event architectures
• Gregor Hohpe, Bobby Woolf, «Enterprise Integration Patterns», Addison-Wesley, 2003
• Wil van der Aalst et al., Workflow Patterns Initiative

Оркестрация:

• Bernd Rücker, «Practical Process Automation», O'Reilly, 2021
• Документация Temporal
• Camunda BPMN Reference

Хореография и event-driven:

• Ben Stopford, «Designing Event-Driven Systems», O'Reilly, 2018 (бесплатный PDF от Confluent)
• Martin Kleppmann, «Designing Data-Intensive Applications», O'Reilly (1-е изд. 2017, 2-е изд. с Chris Riccomini, 2026)
• Gwen Shapira, Todd Palino, Rajini Sivaram, Krit Petty, «Kafka: The Definitive Guide», 2nd edition, O'Reilly, 2021

Агентные системы:

• LangGraph documentation
• Q. Wu et al., «AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation», Microsoft Research, 2023
• J.S. Park et al., «Generative Agents: Interactive Simulacra of Human Behavior», Stanford, 2023
• Anthropic, «Building effective agents», 2024
• A2A Protocol — изначально Google (апрель 2025), передан в Linux Foundation в июне 2025
• Model Context Protocol — Anthropic, ноябрь 2024 (спецификация)