Мой дэйли дайджест

одно техническое понятие в день

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

10 июля 2026 · ~13 мин чтения

концепция ai агенты оркестрация распределённые-системы

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

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

История

У этой идеи два корня — академический и инженерный, и они долго росли
порознь.

Академический корень — теория многоагентных систем. В 1973 году Карл Хьюитт
предложил актор-модель (actor model): вычисление как множество независимых
«акторов», которые общаются только сообщениями и не лезут в память друг
друга. В 1980-е из этого выросла целая дисциплина — распределённый
искусственный интеллект (Distributed AI), а к 1990-м — многоагентные системы
(multi-agent systems) как самостоятельная область: как автономные программы
договариваются, соревнуются и кооперируются. Классический учебник Майкла
Вулдриджа «An Introduction to MultiAgent Systems» — как раз оттуда (первое
издание — 2002 год).

Инженерный корень — оркестрация процессов и задач, без всякого ИИ. Само
слово «оркестрация» пришло в IT из мира SOA (сервис-ориентированной
архитектуры) начала 2000-х: стандарт BPEL описывал, как центральный движок
дирижирует цепочкой веб-сервисов. Дальше вехи:

А потом эти два корня срослись. Осенью 2022 года выходит статья ReAct
(Yao и соавторы): языковая модель может чередовать рассуждение и действия
через инструменты — так LLM превратилась в агента. Дальше лавина: LangChain
(Харрисон Чейз, октябрь 2022), AutoGPT (весна 2023 — первый вирусный
«автономный агент»), Microsoft AutoGen (2023), CrewAI (2023–2024),
LangGraph. В 2024-м Anthropic публикует протокол MCP для подключения
инструментов к моделям, а в 2025-м выпускает Claude Code с сабагентами и
рассказывает в инженерном блоге, как устроена их мультиагентная
research-система: оркестратор на старшей модели плюс параллельные
сабагенты-исполнители на младших. По данным Anthropic, такая связка обошла
одиночную старшую модель примерно на 90% на их внутреннем
research-бенчмарке — ценой примерно пятнадцатикратного расхода токенов
по сравнению с обычным чатом.

Сегодня «оркестрация агентов» — центральный архитектурный вопрос всей
индустрии ИИ-инструментов: один большой агент или дирижёр с командой?

Что это такое

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

Формально в паттерне три роли. Оркестратор — держит в голове цель,
декомпозирует задачу, пишет задания, принимает работу. Исполнители
(workers, сабагенты) — каждый получает своё задание, свой чистый контекст и
инструменты, делает кусок работы и возвращает результат. Часто есть третья
роль — верификатор: отдельный агент со свежим взглядом, который
проверяет результат исполнителя фактами, а не на слово.

Важные пары различий:

Ключевая причина, почему это вообще нужно именно в мире LLM, — контекстное
окно (рабочая память модели). Оно конечно, и чем оно забитее, тем хуже
модель держит внимание. Десять исполнителей с чистыми контекстами прочитают
в сумме в десять раз больше, чем один агент, — и каждый будет свеж.

Аналогии из жизни

Дирижёр и оркестр. Дирижёр не играет ни на одном инструменте во время
концерта — он задаёт темп, даёт вступления, балансирует громкость. Струнные
не обязаны слышать, что там у ударных: каждый смотрит в свою партию и на
дирижёра. Так же оркестратор: сам не «играет», а координирует
специалистов, каждый из которых видит только свой кусок.
Где ломается: у музыкантов партитура написана заранее и отрепетирована,
а агенты сочиняют свою «партию» на ходу — и дирижёру в оркестре не нужно
после концерта проверять, те ли ноты сыграла валторна. Оркестратор агентов
обязан проверять: исполнитель может уверенно вернуть ерунду.

Прораб на стройке. Прораб читает проект, разбивает его на работы —
фундамент, электрика, штукатурка, — нанимает бригады, следит за сроками и
принимает каждую работу по акту. Сам он кирпичи не кладёт, и это правильно:
его час дороже, а решений, которые может принять только он, хватает.
Где ломается: бригады работают в одном физическом здании и видят работу
друг друга — электрик видит, где штукатур закончил стену. Агенты же
изолированы: исполнитель А не знает, что сделал исполнитель Б, пока
оркестратор явно не передаст ему это в задании. На стройке общее состояние
даётся бесплатно, в мультиагентной системе — только ручной передачей.

Кухня ресторана. Шеф на выдаче (экспедитор) читает заказы, раскидывает
тикеты по станциям — гриль, соусы, десерты, — а потом собирает блюда на
тарелку и смотрит на каждое перед выносом в зал. Станции узкоспециализированы
и работают параллельно: пока гриль жарит, кондитер собирает десерт.
Где ломается: кухня — общее пространство, где все слышат выкрики шефа и
видят очередь заказов, то есть контекст разделяется сам собой. И повар не
может «сгаллюцинировать» стейк — блюдо либо есть, либо нет. Агент может
вернуть текст, который выглядит как выполненная работа, но ею не является;
поэтому агентному «шефу» нужна проверка фактов, а не только взгляд на тарелку.

Как это работает

Разберём типичный цикл на примере, близком к реальности: «изучи вопрос и
подготовь отчёт».

        ┌──────────────┐
        │ Оркестратор  │  1. декомпозиция, план
        └──────┬───────┘
     ┌─────────┼─────────┐
     ▼         ▼         ▼
 ┌────────┐┌────────┐┌────────┐
 │Развед-  ││Развед-  ││Развед-  │  2. параллельные исполнители,
 │чик A    ││чик B    ││чик C    │     у каждого чистый контекст
 └───┬────┘└───┬────┘└───┬────┘
     └─────────┼─────────┘
               ▼
        ┌──────────────┐
        │ Оркестратор  │  3. сбор, синтез, новые задания
        └──────┬───────┘
               ▼
        ┌──────────────┐
        │ Верификатор  │  4. проверка фактами, свежим взглядом
        └──────────────┘

Шаг 1. Декомпозиция. Оркестратор читает задачу и решает, на какие
независимые куски она режется. Независимость — ключевое слово: куски без
пересечений можно выполнять параллельно, куски с общими файлами или
зависимостями — только последовательно, иначе исполнители затрут работу
друг друга.

Шаг 2. Задание (спека). Каждому исполнителю пишется самодостаточное
задание: цель, контекст, границы («что не трогать»), критерии готовности.
Самодостаточное — потому что исполнитель не видел предыдущего диалога.
Это самая недооценённая часть: большинство провалов мультиагентных систем —
это не «глупый исполнитель», а расплывчатое задание. Anthropic в своём
разборе research-системы прямо называла детальность инструкций сабагентам
главным рычагом качества.

Шаг 3. Диспатч и параллелизм. Оркестратор запускает исполнителей —
сколько нужно и посильнее или послабее моделью, по сложности куска: сложный
рефакторинг — старшая модель, механическая проверка — младшая. Это ещё и
экономика: зачем жечь дорогие токены на работу, с которой справится дешёвая
модель.

Шаг 4. Сбор и структура. Результаты удобно принимать не свободным
текстом, а по схеме (structured output — ответ строго в заданном
JSON-формате): тогда оркестратор не парсит прозу, а читает поля. Если
исполнитель вернул невалидный результат — автоматический повтор.

Шаг 5. Верификация и приёмка. Отдельный агент с чистым контекстом
получает только критерии готовности и проверяет их фактически: запускает
команды, читает файлы, сверяет цифры. Не доверяет отчёту исполнителя на
слово — исполнители склонны рапортовать об успехе. Провал проверки — одна
попытка доработки с конкретным списком замечаний, снова провал — эскалация
наверх, к человеку или к более сильной модели. Бесконечные ретраи —
антипаттерн: система зацикливается и жжёт деньги.

Тишина между агентами — не баг, а фича

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

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

Альтернативы и конкуренты

Когда НЕ стоит использовать

Самый частый провал — не глупые агенты, а дырявые задания

Прежде чем городить команду агентов, проверь: можешь ли ты письменно, в пяти абзацах, поставить задачу так, чтобы её понял исполнитель без контекста? Если нет — оркестрация лишь размножит непонимание на N копий.

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера этот самый дайджест писал утреннюю статью про heartbeat конвейером из
агентов: дорогая модель-диспетчер только планировала и принимала работу, а
разведку по логам, написание текста и финальную проверку по чек-листу делали
отдельные сабагенты со свежими контекстами. Днём тем же способом шло
расследование пропавших лидов с email-рассылки — так что оркестрация
оказалась самым частым понятием дня, обогнав даже сами предметы разведки.

Краткое резюме