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

Оркестратор держит план. Каждый шаг он отдаёт исполнителю с чистым контекстом и получает обратно короткий отчёт.

Глава собрана из того, что происходило у автора книги и у участников трёх потоков Personal Corp, и из публичных эфиров автора. Почти каждый приём ниже появился после конкретного провала: сожжённого недельного лимита, ванной, которую разнесли десять миньонов, или семидесяти задач, которые никто не обновлял.

Сначала один агент: у оркестрации есть налог

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

«у оркестрации есть большой налог на старт... Поэтому я рекомендую вам не начинать с оркестрации»

Источник: эфир «Claude Opus 5.5: тест в прямом эфире», 1:20:24. Там же сказано, где оркестрация окупается: в долгом процессе, который работает сам. Задача «сделать один раз и забыть» налог не окупает.

Как это выглядит на практике:

• Участник первого потока попросил агентов сделать сценарий и раскадровку ролика: шесть глубоких исследований, четыре роли, «сам всё сделай». Агенты сожгли больше миллиона токенов, и раскадровка не попала в задачу. Один промпт с картинкой в генераторе изображений дал результат, который он оценил на восемь из десяти. Сборку отдела под разовую задачу он назвал новым видом прокрастинации. Автор ответил, что отдел ему точно не нужен, первая ступень это скилл.
• Участник третьего потока за день после сброса сжёг 65% недельного лимита: около двадцати параллельных чатов и скилл, который гонял карточки плана субагентами. Совет был попробовать ту же работу без оркестрации.
• Участник второго потока спросил, как собрать схему «старший агент, второй смотрит, третий ищет». Автор сначала спросил, зачем.

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

Сначала план, потом исполнители

Субагенты без плана мешают друг другу. Автор объяснял это на седьмом уроке первого потока: одного мастера можно позвать ремонтировать ванную, он разберётся сам. Десять миньонов без плана ванную разнесут. В Claude Code у него бывало так, что второй субагент переделывал работу первого, потому что плана не было.

Участник того же потока написал подробный PRD и отдал его сети субагентов. Сеть работала час двадцать и вернула скудную заготовку с багами, часть требований агенты пропустили. Разбирать такой результат нужно с агентом, ретроспективой: где именно план не дошёл до исполнителя.

Рабочий порядок автора на том же уроке: гриллинг, из него PRD, из PRD отдельные issue. Только после этого агент получает команду распараллелить. Генератор коммерческих предложений так собрался за семь коммитов.

Те задачи, которые можно делать параллельно, делай субагентами.

Источник: урок 7 первого потока Personal Corp, 08.06. Фраза сказана после того, как работа разбита на issue.

Источник ответа: пример ответа, написан для главы.

Сами агенты субагентов почти не запускают, поэтому просить нужно явно. И просить только тогда, когда части уже разделены. Менти автора на личной сессии получил аудит с 58 проблемами и хотел починить их одним промптом. Автор велел разложить находки в независимые issue и на каждую дать отдельного субагента в своей ветке.

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

Оркестратор не работает руками

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

Эту настройку автор вносит один раз в начале чата.

Ты оркестратор, ты не делаешь работу руками, ты даёшь задачи субагентам. Веди трек задач в GitHub, в этом приватном репозитории.

Источник: урок 5 третьего потока Personal Corp, 20.10. Вторая фраза нужна, если задачи ведутся в GitHub.

Источник ответа: тот же урок: ведущий пересказывает экран оркестратора.

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

Обратная ошибка тоже бывает. Первая версия скилла оркестрации на эфире отдавала субагентам вместе с работой и решения. Скилл переписали: думает и решает оркестратор, исполнители только делают. Источник: эфир «Claude Fable 5, день 4: карта агентов», 1:05:02.

Дорогая модель планирует, дешёвая делает

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

используй для реализации субагентов на Sonnet, после проверяй субагентом на Opus

Источник: эфир «Claude Fable 5, день 3: оркестратор на Fable, исполнители на Sonnet», 1:10:02. Оркестратором в этом эфире был Fable.

Источник ответа: тот же эфир, 1:16:35–1:21:08: ведущий читает ответы оркестратора.

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

Исполнитель знает только то, что в брифе

Субагент стартует с чистым контекстом. Он ничего не знает о задаче, кроме того, что ему передал оркестратор.

«субагенты получают чистый контекст они стартуют чистым контекстом они ничего не знают поэтому оркестратор должен вниз агенту передать какое-то описание»

Источник: эфир «Claude Fable 5, день 4: карта агентов», 0:09:45.

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

• главная цель;
• контекст: что нужно сделать и зачем;
• якоря на файлы, где лежит нужное;
• границы: что делать не надо;
• критерий готовности: чем проверить, что задача сделана.

ты не пишешь код, ты оркестрируешь субагентами на Sonnet, ты пишешь спеки и формируешь подробные задачи для субагентов через GitHub Issues

Источник: эфир «Claude Fable вернулся: как экономить токены», 0:23:11.

Источник ответа: тот же эфир, 0:32:01: ведущий читает ответ оркестратора вслух.

Узкий бриф и узкий результат держат и пайплайны. Участник первого потока собрал мультиагентный конвейер, который реально принёс бизнесу деньги. Заработал он, когда у каждого агента появились свой узкий вход, свой узкий выход и измеримый результат, как у маленькой шестерёнки. Схема из двадцати действий сжалась до пяти: три агента и два вызова API.

Участник третьего потока заметил, что агент при постановке задачи не знает о его готовых сервисах и предлагает писать всё заново. Теперь он сначала отправляет субагентов вычитать диск и описать, что умеет каждый сервис, и только потом ставит задачу со ссылками на готовое. Разведка тоже работа для исполнителей, а итог разведки становится частью брифа.

Если задач много и они похожи, промпты исполнителям стоит записать заранее туда же, где живёт задача. Так их можно прочитать до запуска и повторить.

Мне нужно 10 версий, поэтому это будет делать 10 субагентов. Зафиксируй вначале эту задачу в issue. Issue веди на русском языке. И в issue должны быть промпты, которые ты будешь отдавать субагентам.

Источник: эфир «Claude Fable 5, день 2: Convex вместо Supabase, карма-бот и 10 агентов в параллели», 1:00:31. Речь о десяти вариантах дизайна сайта.

Источник ответа: тот же эфир, 1:10:00–1:11:01: ведущий читает с экрана промпт, который оркестратор отдал исполнителю.

Потолок на число агентов и запрет на вложенность

Без ограничения модель охотно запускает десятки субагентов. На одном эфире Fable сам запустил больше тридцати субагентов на той же дорогой модели и за пару минут съел 20–30% пятичасового лимита старшего тарифа. Источник: эфир «Claude Fable 5, день 2», 0:29:39. На другом эфире автор нашёл в отчёте 133 субагента и понял, куда ушли деньги.

«Всегда указывайте максимум... Начинайте с двух, трёх, потом растите по мере»

Источник: эфир «DeepSeek V4.1 Flash в 80 раз дешевле Claude и GPT», 1:27:04.

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

Ты оркестратор, ты не делаешь, ты только планируешь и раздаёшь задачи. Используй beads для коммуникации, максимум три агента.

Источник: эфир «Claude Opus 5.5: тест в прямом эфире», 0:41:55, в автоматической расшифровке beads записано как «Bits». Сразу после промпта автор добавляет, что уровень вложенности нужно ограничивать тоже: иначе агент, которому разрешено три исполнителя, позовёт ещё десять на помощь.

Источник ответа: тот же эфир, 0:47:40–1:00:05: ведущий читает ответы оркестратора.

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

Каждому исполнителю своя копия проекта

Два агента в одной папке правят одни файлы и переключают ветки друг у друга. Участник второго потока описал, как это обнаруживается: в соседней сессии агент спрашивает, кто полез в его файлы и что с этим делать.

Обратная крайность тоже ломается. Участник второго потока открывал ветку на каждую идею, параллельно висели десять–двадцать веток. Раз в неделю он просил модель слить всё, и через три–четыре дня узнавал, что что-то отвалилось. Когда несколько веток трогали один файл, агент сам решал, чьё изменение выживет, и получался гибрид с ошибкой. Ещё один участник того же потока включил «всегда открывать новое рабочее дерево», неделю разбирал 79 веток с конфликтами и вернулся к работе почти целиком в main.

Порядок, к которому пришёл автор:

1. Одна задача, одно рабочее дерево на каждый затронутый репозиторий. Копия делается от свежей версии main на GitHub.
2. Ветку называют по задаче, чтобы по имени было видно, чья это работа.
3. Два агента в одном рабочем дереве не работают.
4. Исполнитель сам коммитит свои файлы и присылает pull request. В main работа попадает после проверки.
5. После слияния рабочее дерево и ветку удаляют. Ветку с неслитыми изменениями не удаляют.

Четвёртый пункт появился после разбора команды агентов третьего потока. В части брифов стояло «не коммитишь, коммитит оркестратор». За сутки главная сессия сделала 27 коммитов чужой работы, а 32 файла остались без коммита. Главной потерей оказалась очередь на коммит у оркестратора, не гонка исполнителей. Там же один агент бросил незавершённое перебазирование в общей папке, а следующий потратил десятки вызовов на разбор и обвинил не того. С тех пор в брифе стоит правило: коммитить только свои пути.

Запишите это в правила штаба, и оркестратор будет давать такое указание каждому исполнителю сам.

Задачи живут в одном месте

Без общего списка задач агенты берут одно и то же, а вы не знаете, что сделано. Вот что случилось у участников:

• У участника второго потока задачи жили и в штабе, и в проекте. Статус не подтягивался, и он сводил всё вручную.
• Менти автора попросил агента завести проект и задачи в GitHub. Агент наделал около семидесяти задач, которые никто не обновлял. На вопрос «что сегодня» приходило семьдесят пунктов.
• Участник первого потока держал по три–пять сессий на одну задачу и в какой-то момент насчитал около четырёхсот незакрытых. Неделю разбирал и вывел себе правило: у каждой сессии должна быть логичная точка, на которой её закрывают.

Цель в том, чтобы задача была описана в одном месте и агент точно знал, что в ней написано. Цена галлюцинации исполнителя большая. Задачи нужны ещё и затем, чтобы прерванную работу можно было продолжить с того же места.

Автор шёл по ступеням: задачи в файле штаба, потом GitHub issues, потом граф задач Beads. На третью ступень он перешёл, когда агентов стало много: около сотни мелких задач в день на одном проекте, и лимиты GitHub заканчивались за полчаса. Одна задача в Beads называется бид. Issue остаются для крупного уровня, который вы обсуждаете сами.

«важная вещь для оркестрации, чтобы у агента был свой Inbox. Я, например, для этого использую такую штуку, как beads»

Источник: эфир «DeepSeek V4.1 Flash в 80 раз дешевле Claude и GPT», 0:34:40.

Задачи раздаёт одна роль

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

Почему роль одна, автор выяснил на своей команде. Главная сессия дважды за день сама наняла исполнителя в обход продюсера, и у задач появилась вторая точка входа. Два источника новых задач и два арбитра приоритетов дали дубли и пропуски, у которых не было виноватого. Вопросы к автору тоже копились в двух местах: у продюсера и у главной сессии. Их свели в один список.

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

Проверяет другой агент, принимаете вы

Автор работы оценивает её предвзято. На Office Hours второго потока автор разложил роли так: менеджер ставит задачи и сам не делает, исполнитель отчитывается через pull request, проверяющий говорит «сделано» или «не сделано» и сам ничего не чинит. У каждого свой контекст, иначе агент скажет, что починил, и не увидит свежих ошибок. Проверяющим может быть субагент с чистым контекстом в любом харнесе.

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

У проверки есть предел. Попросите агента найти ошибку в чужом плане, и он найдёт её даже там, где ошибки нет. Поэтому цепочка «одна модель пишет план, вторая проверяет, третья исполняет» качество не утраивает. Автор предпочитает сам прочитать план. И отчёт исполнителя сверяют с первоисточником: в команде третьего потока исполнитель написал, что pull request готов к слиянию, а GitHub показывал конфликт.

Когда агент ошибся, проверку стоит превратить в правило, чтобы ошибка не повторилась.

Прогони через критиков это решение и обнови, пожалуйста, правила. Правила для работы в этой папке. И запиши ADR. Чтобы так больше не делать.

Источник: эфир «GPT-5.6: Sol, Terra, Luna, кого ставлю основным», 1:39:05. Сказано после ошибки агента в SEO-задаче.

Источник ответа: в эфире ответ не читали; ответ собран по коммиту c5182d1 в sereja.tech того же вечера: ADR docs/adr/0001-protect-organic-winners.md, правило в AGENTS.md, откат описания статьи.

Узкое место: ваш фокус

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

«самое сложное в управлении этим всем делом – это держать фокус, трекать задачи, проверять результат»

Источник: эфир «GLM + Orca: мой AI-сетап разработчика 2026», 0:06:29.

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

Бриф исполнителю начинается с вашего контекста: зачем задача и как понять, что она сделана. Достать этот контекст из вас помогает гриллинг. Когда понятно, как проверить, что задача сделана, агента можно оставить работать в цикле до этой проверки, об этом следующая глава.