В мультиагентных системах паттерн Хореографии усложняется недетерминированностью LLM. Асинхронная передача событий между независимыми агентами порождает три главные проблемы.

1. Шторм событий (Event Storm) и бесконечные циклы Агенты могут зациклить друг друга, бесконечно генерируя уточняющие запросы и сжигая бюджет на инференс.

Решение: Внедрение Event TTL (счетчик hop_count для сообщений брокера, уходящих в Dead Letter Queue при нуле). Установка жестких квот на вызовы LLM в рамках единого Correlation ID.

2. Состояние гонки (Race Condition) Несколько агентов параллельно реагируют на триггер и одновременно обновляют общий контекст (векторную БД или граф), затирая данные друг друга.

Решение: Использование Event Sourcing (добавление иммутабельных фактов через INSERT без UPDATE). Для мутаций по месту применяется Optimistic Locking: агент читает версию контекста и сохраняет результат только при условии WHERE version = X. При конфликте данные перечитываются.

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

Решение: Проброс Trace ID (OpenTelemetry) через заголовки шины данных. Использование пассивного Shadow Orchestrator — сервиса-наблюдателя, который слушает все события, строит граф выполнения в реальном времени и сигнализирует при зависании пайплайна.

В продакшен чистая хореография для MAS непредсказуема. Оптимален гибрид: строгая оркестрация (Plan & Execution) внутри локальных RAG-пайплайнов агента и асинхронная хореография на макроуровне 2-4 шага выполнения.