Глава 2. Паттерны оркестрации: каталог архитектур роя

Паттерн оркестрации — это не источник дополнительного интеллекта, а механизм параллельной траты токенов и разделения контекста под структуру конкретной задачи. В анализе Anthropic на BrowseComp объём потраченных токенов сам по себе объясняет 80% вариативности качества (Anthropic, 2025), поэтому главный вопрос при выборе архитектуры — не «какая топология умнее», а «декомпозируется ли задача и на чтение или на запись она работает». Ниже — каталог паттернов с честными границами применимости, включая те, что не пережили репликаций 2025–2026 годов.

Лестница сложности: правило нулевого паттерна

Прежде чем выбирать топологию роя, стоит проверить, нужен ли рой вообще. Канонический принцип Anthropic из Building Effective Agents (декабрь 2024): «добавляйте сложность только тогда, когда она доказуемо улучшает результат». Там же — базовая таксономия из пяти workflow-паттернов, на которую до сих пор ссылается вся индустрия: prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer. Azure Architecture Center (обновление 2026-02) формулирует это как лестницу эскалации: прямой вызов модели → одиночный агент с инструментами → мультиагентная система, и «используйте самый низкий уровень сложности, который надёжно закрывает требования».

Экономика подкрепляет осторожность: одиночный агент тратит ~4× токенов относительно чата, мультиагентная система — ~15× (Anthropic). Рой окупается только там, где ценность задачи покрывает этот множитель.

Orchestrator-worker: паттерн с лучшими production-доказательствами

Research-фича Anthropic — эталонная реализация: lead-агент (Opus 4) планирует, декомпозирует запрос и запускает 3–5+ параллельных субагентов (Sonnet 4), каждый в собственном контекстном окне; отдельный CitationAgent расставляет цитаты в конце. Результат: +90,2% к single-agent Opus 4 на внутреннем research-эвале, а два уровня параллелизма (субагенты плюс параллельные tool-вызовы внутри каждого) сократили время исследования до 90% на сложных запросах (Anthropic, 2025-06-13).

flowchart TD
    U[Запрос пользователя] --> L[Lead-агент планирует и декомпозирует]
    L --> S1[Subagent 1 свой контекст]
    L --> S2[Subagent 2 свой контекст]
    L --> S3[Subagent N свой контекст]
    S1 --> R[Синтез одним агентом]
    S2 --> R
    S3 --> R
    R --> C[CitationAgent добавляет ссылки]

Критерии применимости у Anthropic заданы явно: широкая параллелизация, объём информации сверх одного контекстного окна, много сложных инструментов. Явно плохой fit — кодинг и задачи с тесными взаимозависимостями. Важная практика: правила масштабирования усилий вшиты прямо в промпт оркестратора — простой факт-чек: 1 агент и 3–10 tool-вызовов; сравнение: 2–4 субагента по 10–15 вызовов; сложное исследование: 10+ субагентов с чётким разделением зон. Без таких правил ранние версии «плодили 50 субагентов на простые запросы».

Две честные оговорки. Во-первых, 90,2% — внутренний непубличный эвал без описанной методологии. Во-вторых, сравнение не выровнено по компьюту: compute-controlled исследования 2026 года (Tran & Kiela) показывают, что при равном бюджете «thinking»-токенов одиночные агенты догоняют или обгоняют мультиагентные системы на multi-hop reasoning. Оба утверждения совместимы: рой — это способ потратить больше токенов параллельно и обойти лимит одного контекстного окна, а не умножитель интеллекта.

Каталог: девять паттернов и их границы

Отдельно — стигмергия (координация через общий артефакт вместо сообщений): CodeCRDT показал 100% сходимость и ноль merge-конфликтов на 600 прогонах параллельного кодинга через CRDT-документ, но с разбросом от +21,1% ускорения до −39,4% замедления в зависимости от задачи. Структура задачи снова решает всё.

Десятый паттерн: внешний цикл (Ralph-loop)

За пределами каталога — паттерн, где оркестратором служит не агент, а обычный while-цикл: одна задача за итерацию, свежий контекст на каждом заходе, файл с планом как разделяемое состояние. Фольклорный первоисточник — «Ralph Wiggum» loop Джеффри Хантли (ghuntley.com/ralph, июль 2025): по его собственным отчётам, контракт на $50 000 сдан как MVP («delivered, tested + reviewed») за $297 API-затрат (Amp, 2025-07-11), а на хакатоне YC ночной while-цикл выдал 1 100+ коммитов в 6 репозиториях — включая почти полный порт Browser Use с Python на TypeScript — менее чем за $800 за весь ночной прогон. Оба факта self-reported (скриншот переписки и анекдот с хакатона), независимого аудита нет — цитируйте их как свидетельство существования паттерна, а не как бенчмарк.

К 2026 году паттерн вендоризован. Claude Managed Agents / Dynamic Workflows (анонс 2026-05-19, релиз с Opus 4.8 — 2026-05-28): lead-агент пишет JS-скрипт и разворачивает от десятков-сотен до ~1 000 параллельных субагентов в одной сессии (docs), а Outcomes-грейдер оценивает вывод каждого субагента по рубрике в отдельном контекстном окне и возвращает на доработку — заявленный прирост task success до +10 п.п. (+8,4% docx / +10,1% pptx) (Anthropic). Оговорка прежняя: цифры вендора о собственном продукте. И главная граница применимости внешнего цикла — не топологическая, а процедурная: без явных терминальных состояний и правила «ошибка — не успех» (подробно — в главе о режимах отказов) цикл превращается в генератор правдоподобных мусорных коммитов.

Что не пережило проверку: дебаты, панели судей, авто-топологии

Дебаты. Оригинальная работа Du et al., 2023 показала снижение галлюцинаций через многораундовые дебаты, но репликации 2025–2026 в основном негативны: Zhang et al. (5 методов × 9 бенчмарков × 4 модели) — MAD «часто не превосходит простые одноагентные baselines вроде CoT и Self-Consistency даже при значительно большем inference-компьюте». Debate or Vote (NeurIPS 2025 Spotlight) доказывает: дебаты — мартингал, сами по себе они не меняют ожидаемую корректность; большую часть приписываемого им прироста даёт обычное голосование большинством. Единственный устойчивый рычаг — гетерогенность моделей: разнообразие, а не разговор, является активным ингредиентом.

Панели судей. PoLL (2024) показала, что панель малых судей из 3 семейств моделей бьёт одного судью GPT-4 при в 7+ раз меньшей цене. Коррекция 2026 года: Nine Judges, Two Effective Votes — у 9 frontier-судей коррелированные ошибки съедают ~75% номинальной независимости, панель несёт информацию лишь ~2 независимых голосов, и лучший одиночный судья не уступает всей панели. Вывод: масштабируйте разнообразие профилей ошибок (семейства, промпты, рубрики), а не количество судей.

Автоматический поиск топологий. AFlow, ADAS, GPTSwarm, DyLAN отчитывались о двузначных приростах, но абляции MASS (arXiv, февр. 2025) показали: оптимизация промптов блоков даёт ≈+6%, добавление оптимизации топологии — лишь ≈+3%, а «выгодные топологии составляют лишь малую долю всего пространства дизайна». Жёстче — The Illusion of Multi-Agent Advantage (июнь 2026): авто-сгенерированные MAS «стабильно уступают CoT-SC, будучи до 10× дороже», диагноз — «архитектурный блоат»: поисковые пространства вознаграждают раздувание, потому что бенчмарки не тарифицируют токены. Оба результата — препринты, но тренд однонаправленный: промпты важнее топологии.

Обвязка важнее модели: harness engineering

Если промпты важнее топологии, то следующий шаг честности — признать, что обвязка (harness: инструменты, контекст, циклы верификации) часто важнее самой модели. Эксперимент LangChain с зафиксированной моделью (gpt-5.2-codex) показал это в чистом виде: одни только harness-изменения подняли deepagents-cli с 52,8% до 66,5% на Terminal-Bench 2.0 — +13,7 п.п. без единого нового веса (LangChain, 2026-02-17). Среди находок — «reasoning sandwich»: максимум размышлений на планировании и верификации, экономия в середине (профиль xhigh-high-xhigh даёт 63,6% против 53,9% у постоянного xhigh). Продолжение серии переворачивает и ценовую логику: Nemotron 3 Ultra с настроенной под него обвязкой набирает 0,86 против 0,87 у Opus 4.8 на Deep Agents-эвале при ~10× меньшей цене прогона ($4.48 против $43.48), стартуя с baseline ~0,80 без профиля; принцип авторов — «evals — это обучающие данные для harness-инженерии» (LangChain, 2026-07-08).

Продакшен-масштаб той же идеи — Azure SRE Agent: 35 000+ инцидентов, митигированных автономно силами 1 300+ агентов, время до митигации Azure App Service срезано с 40,5 ч до 3 мин, экономия оценивается в 20 000+ инженеро-часов в месяц (цифры Microsoft о собственном продукте; Microsoft, 2026-03). Самый переносимый их урок — контекст-инженерия: замена 100+ узких инструментов на файловый доступ (read_file/grep/find/shell) подняла метрику Intent Met с 45% до 75% на новых инцидентах. Тот же принцип «меньше инструментов, больше кода» Anthropic довела до предела: если агент пишет код, вызывающий MCP-серверы, вместо прямых tool-вызовов, контекст задачи сжимается со 150 000 до 2 000 токенов — экономия 98,7% (пример Google Drive + Salesforce; определения тулов подгружаются с файловой системы по требованию) (Anthropic, 2025-11-04).

Harness-инженерия уже автоматизируется: RHO (Retrospective Harness Optimization) — self-supervised метод, у которого один раунд оптимизации обвязки из неразмеченных прошлых траекторий поднял pass-rate на SWE-Bench Pro с 59% до 78% без внешней разметки, с проверкой на трёх доменах — software engineering, technical и knowledge work (Pan et al., arXiv:2606.05922, 2026-06-04). Для выбора паттерна оркестрации это задаёт порядок работ: прежде чем добавлять агентов — и даже прежде чем менять модель — выжмите обвязку: цикл верификации, файловый контекст, профиль рассуждений.

Правило read/write и почему рои падают

Публичный конфликт июня 2025 года задал рамку всей дискуссии: Cognition опубликовала Don't Build Multi-Agents (12 июня) — «действия несут неявные решения, а конфликтующие решения дают плохой результат»; Anthropic на следующий день — пост про свой мультиагентный research. Примирение сформулировал LangChain: системы, которые преимущественно «читают», строить проще, чем те, что «пишут». Исследование параллелится; синтез, письмо и кодинг должны оставаться однопоточными. К 2026 году сама Cognition смягчила позицию до «мультиагентность работает, когда записи однопоточны, а дополнительные агенты добавляют интеллект, а не действия».

Эмпирика отказов подтверждает, что узкое место — оркестрация, а не модели. Таксономия MAST (NeurIPS 2025, 1600+ аннотированных трейсов, 7 фреймворков, κ=0,88) выделяет 14 режимов отказа в трёх кластерах: ошибки спецификации и дизайна системы — 44,2%, межагентная рассогласованность — 32,3%, отказы верификации — 23,5% (v3; в ранней v2: 41,8 / 36,9 / 21,3); end-to-end частота отказов SOTA open-source фреймворков — 41–86,7%. Большинство провалов роя — это баги спецификации оркестрации и отсутствие проверки результата, поэтому maker-checker циклы и явные контракты на формат вывода окупаются быстрее, чем добавление агентов.

Критерий новой информации: когда второй агент оправдан

Правило read/write дополняет рамка из книги Bojie Li ai-agent-book (гл. 10, табл. 10-2): у критерия «рой против одного агента» единственная опора — вводит ли коллаборация новую информацию, недоступную одиночному агенту в момент генерации. «Разные агенты спорят над одним и тем же текстом» — новой информации нет, и при равном компьюте это паритет с одиночным агентом; reviewer с исполнением кода, визуальным рендером или внешней проверкой — новая информация есть, и прирост существенный. Это редакторская рамка вторичного источника, но она опирается на верифицируемые первичные работы, и одна из них показательна: WebGen-Agent (Lu et al., arXiv:2509.22644, 2025-09-26) добавил многоуровневый визуальный фидбэк — скриншот плюс описание визуально-языковой модели — и поднял точность Claude-3.5-Sonnet на бенчмарке WebGen-Bench с 26,4% до 51,9% (appearance-score с 3,0 до 3,9), а обучение Step-GRPO подняло Qwen2.5-Coder-7B-Instruct с 38,9% до 45,4%.

Второе следствие для оркестрации — асимметрия ролей. Plan-and-Act (Erdogan et al., arXiv:2503.09572, ICML 2025) показывает, что качество планирования — решающий рычаг связки Planner–Executor: архитектура достигла SOTA 57,58% на WebArena-Lite и text-only SOTA 81,36% на WebVoyager, причём даже нетюнингованный Base Executor при качественном плане прибавляет +34,39 п.п. — до 44,24%. Практический вывод для любого orchestrator-worker: сильнейшую модель и лучший промпт отдавайте планировщику, а не исполнителям.

Что применить завтра

1. Классифицируйте задачу по оси read/write: чтение (research, сбор данных) — параллельте через orchestrator-worker; запись (код, синтез текста) — оставьте однопоточной или оберните в reflect+executor цикл.
2. Поднимайтесь по лестнице Azure — прямой вызов → одиночный агент → рой — и фиксируйте на каждом шаге, что усложнение доказуемо улучшает метрику, прежде чем идти дальше.
3. Вшейте в промпт оркестратора явные правила масштабирования усилий по образцу Anthropic: 1 агент для простых фактов, 2–4 для сравнений, 10+ только для действительно сложных исследований.
4. Прежде чем экспериментировать с топологией, оптимизируйте промпты блоков — по данным MASS это даёт вдвое больший прирост (+6% против +3%).
5. Добавьте верификацию как отдельный контур: maker-checker с жёстким лимитом итераций, определённым fallback и не более 3 агентов в цикле; проверяйте выходные контракты — на это приходится 23,5% отказов по MAST.