Fan out субагентов в Claude Code, и как проверить то, что они вернули

Люди вводят в Google «claude fan out subagents», и многие добавляют в конце «command», как будто где-то есть переключатель, который достаточно щёлкнуть. Есть приём, и есть также команда. Мы проверили и то, и другое на Claude Code 2.1.301 и по документации Anthropic 16 октября 2026 года.

Остаётся часть, о которой документация говорит мало, и именно из-за неё мы пишем эту статью: что делать с результатами. Мы запускаем fan out каждую ночь. Шесть субагентов переводят каждую новую статью этого блога на семнадцать языков, а основная сессия сливает их работу. Каждый из них сообщает, что соблюдал правила. Проверка, которую мы написали до их запуска, всё равно что-то находит.

Короткий ответ

Fan out означает, что одна сессия разбивает работу на части, которые не зависят друг от друга, отдаёт каждую часть субагенту, даёт им работать одновременно и сводит воедино то, что вернулось. В Claude Code это можно сделать тремя способами.

Дальше на этой странице разобран каждый способ, а затем проверки, которые мы выполняем на собственном fan out.

Что субагент видит и чего не видит

Три факта из документации определяют, как делить работу.

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

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

Есть ограничения. По умолчанию в сессии одновременно могут работать 20 субагентов. Двадцать первый завершается ошибкой Concurrent subagent limit reached, и ошибка говорит Claude не пытаться снова. Поднять или опустить лимит можно через CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS. Субагенты могут запускать собственных субагентов, вплоть до трёх уровней ниже основного разговора, а общее число за сессию не ограничено.

Способ 1: попросить обычными словами

Самый простой fan out умещается в одно предложение. Пример из документации Anthropic:

Research the authentication, database, and API modules in parallel using separate subagents

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

Обычные слова оставляют решение за Claude. Если вы определили собственного субагента в .claude/agents/, упоминание через @ гарантирует, что он будет запущен для этой задачи. Как устроены эти файлы, объясняет наша страница о субагентах Claude Code.

Способ 2: /batch, самое близкое к команде fan out

/batch это навык, встроенный в Claude Code. Вы даёте ему инструкцию:

/batch migrate src/ from JavaScript to TypeScript

Он изучает кодовую базу, разбивает работу на независимые единицы, от 5 до 30, и показывает вам план. После вашего одобрения он запускает по одному фоновому субагенту на каждую единицу, каждого в изолированном git worktree. Каждый субагент реализует свою единицу, запускает тесты и публикует своё изменение. Нужен git-репозиторий или хук WorktreeCreate, который создаёт worktree для другой системы контроля версий.

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

Способ 3: цикл с claude -p

Когда работа представляет собой список файлов и вы хотите контролировать каждый вызов, рекомендации Anthropic описывают цикл. Сначала попросите Claude составить список (list all 2,000 Python files that need migrating and save the list to files.txt). Затем:

for file in $(cat files.txt); do
  claude -p "Migrate $file from Python 2 to Python 3. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --permission-mode dontAsk
done

Три детали этого примера стоит перенять.

• Ответ читается машиной. «Return OK or FAIL» означает, что ваш скрипт может посчитать неудачи, не читая прозу.
• Разрешения решены заранее. --allowedTools разрешает ровно то, что нужно миграции, а --permission-mode dontAsk запрещает всё остальное, вместо того чтобы ждать человека, которого рядом нет.
• Вы начинаете с двух-трёх файлов. Документация говорит прямо: доработайте промпт по тому, что пошло не так на первых файлах, а затем запускайте весь список.

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

Для CI документация рекомендует добавить --bare, который пропускает хуки, навыки, MCP-серверы и CLAUDE.md, чтобы каждая машина получала одинаковый запуск. Режим bare не использует вход по вашей подписке: ему нужен ANTHROPIC_API_KEY.

Как мы делаем fan out каждую ночь

Вот fan out, который мы запускаем на самом деле. Наша ночная SEO-команда пишет каждую новую статью на английском и французском вручную. Затем второй агент переводит её ещё на семнадцать языков с помощью субагентов Claude Code, а традиционный китайский получает из упрощённого скриптом, без перевода. С 13 сентября 2026 года через этот процесс прошли одиннадцать статей, и каждая приходит в виде двадцати файлов.

Части

Шесть субагентов, по три языка на каждого (два у последнего): испанский, португальский и итальянский; немецкий, нидерландский и польский; русский, украинский и турецкий; японский, корейский и китайский; тайский, вьетнамский и индонезийский; арабский и хинди. Ни один язык не зависит от другого, и именно это делает такой fan out чистым.

Каждый бриф содержит одни и те же пять вещей, потому что субагент больше ничего не видит:

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

Проверка пишется до запуска

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

• тот же slug и та же дата, заголовок совпадает с H1;
• то же число разделов, подразделов, изображений, ссылок и строк таблицы, и столько же ответов FAQ в тексте, сколько вопросов в метаданных;
• ссылки идентичны до байта, фрагменты кода идентичны до байта;
• названия брендов подсчитаны, их никогда не меньше, чем в английском;
• длина в границах, откалиброванных для каждого языка, потому что китайский говорит то же самое примерно в 36 % символов, нужных английскому, а японский примерно в половине;
• диакритические знаки там, где они есть в языке (польский, турецкий, вьетнамский).

Каждый субагент заканчивает какой-нибудь вариацией «готово, все проверки пройдены». Единственный вердикт, по которому мы действуем, это тот же скрипт, заново запущенный основной сессией на всех файлах сразу.

Что центральная проверка поймала, а отчёты субагентов нет

Код, переведённый внутри таблицы. 13 сентября примерно половина субагентов перевела слова, которые шли после команды внутри тех же обратных кавычек в таблице. Каждый следовал своему брифу так, как его понял. Исправление пошло в бриф, а не в субагентов: фрагмент кода содержит только команду, а слова после неё стоят вне обратных кавычек.

Ошибалась наша собственная проверка. 6 сентября проверка длины, откалиброванная по старой строке, которую мы заменяли, отметила 11 субагентов из 17. Все 11 были правы: новый текст и должен был быть длиннее. Откалиброванная по уже исправленному французскому, она не отметила ни одного. Центральная проверка тоже может ошибаться, и чтобы это увидеть, её нужно сначала запустить на поставке, про которую вы уже знаете, что она хорошая.

Согласованность между частями. 15 октября, на новой странице функции, переведённой тем же способом, проверка слияния подтвердила, что в 90 файлах изменились только ожидаемые строки. Но японский, корейский и китайский субагенты выбрали для «You may also like» каждый свой заголовок, не тот, что их язык уже использовал на соседней странице. Каждый вариант был правильным переводом. Ни один не согласовывался с сайтом. Ни один субагент не мог увидеть этого изнутри своей части: это видит только проход по объединённому результату.

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

Сообщения за пределами части. 15 октября субагент, работавший над турецким, сообщил, что сайт в 97 существующих строках писал для слова «agent» «ajans», то есть агентство. Он их не тронул, потому что бриф это запрещал. Мы открыли тикет, и исправление вышло на следующий день. Спрашивать субагентов о том, что они увидели, а не только о том, что они сделали, дёшево и окупается.

Слияние происходит в одном месте

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

Когда fan out не нужен

• Части зависят друг от друга. Если части B нужен результат части A, выполняйте их по порядку.
• Работа небольшая. Каждый субагент начинает с чистого листа и заново читает то, что ему нужно. На десятиминутной задаче новые старты стоят дороже, чем экономят.
• Вы не можете написать проверку. Если нельзя отличить хорошую часть от плохой, не перечитав всё самому, именно на слияние и уйдёт ваше время.
• Квота ограничена. Каждый субагент тратит собственные токены. Fan out экономит время и держит основной контекст чистым, но не уменьшает счёт.

Где здесь AgentsRoom

Субагенты живут внутри одной сессии Claude Code. Вы видите их результаты, а не их работу, и не можете направить одного из них посреди задачи. Когда вы хотите, чтобы каждая часть была агентом, за которым можно следить, которому можно ответить и чью работу можно проверить отдельно, запускайте вместо этого отдельные сессии: каждый тикет в своём git worktree, и Agent Teams, когда части передают работу друг другу. Шаг в команде агентов может включать команду проверки, и именно её код выхода, а не слова самого агента, решает, пойдёт ли запуск дальше. Это то же правило, что и выше, только за его соблюдением следит сам механизм запуска. Это работает с Claude Code, Codex и другими CLI агентов, которые поддерживает AgentsRoom.

Если вы ещё выбираете между субагентами и Agent Teams, это сравнение объясняет, для чего нужен каждый из них.