Половина твоих Claude Code-агентов занята ерундой: тест на 30 секунд из 4 пунктов
Каждую неделю кто-то хвастается «у меня 50 параллельных Claude». Открываю проект - половина генерит мусор. Тест на 30 секунд ставит границу.
На стриме на прошлой неделе пришёл вопрос: «у меня в чате говорят, что у них 50 агентов параллельно работают. Я отстал или они выдумывают?». Не отстал. Когда я открываю такой проект и спрашиваю «а что они делают?», оказывается, что эти 50 параллельных Claude генерируют кучу ненужного. Я это на стримах называю так: «50 агентов ерундой занимаются». Без проверки, без задачи, просто потому что появилась возможность.
Это центральный антипаттерн multi-agent в 2026 году. Человек узнал, что в Claude Code можно запустить 16 агентов одновременно и 1000 за один Dynamic Workflow, сел и запустил. Эффекта - ноль. Расход токенов - x10 от обычной сессии. Удивление через неделю - почему кончился лимит.
Дальше - четыре вопроса, после которых половина параллельных Claude уходит в /dev/null. Один готовый rubric для grader-агента. И минимальная связка multi-agent на 30 минут, которой хватает на 80% реальных задач.
«50 параллельных Claude»: откуда это и почему сразу провал
Цифра «1000 параллельных агентов» - не выдумка. Это реальный лимит одного Dynamic Workflow в Claude Code. В официальной документации Anthropic, в таблице Behavior and limits, две строки задают границу:
Up to 16 concurrent agents, fewer on machines with limited CPU cores.
1,000 agents total per run. Prevents runaway loops.
«1000 агентов параллельно» - это потолок защиты от runaway-цикла. Не план развития, не рекомендуемая нагрузка.
В реальной работе 95% задач закрываются 2-8 параллельными потоками. Аудит безопасности по всем endpoints проекта - 6-8 параллельных. Параллельный фронтенд+бэкенд - 2. Прогон гайда через QA - 5-6 субагентов. Когда я вижу проект с «50 параллельных» - я почти всегда вижу 50 ходов в пустоту.
В Claude Code четыре примитива для разнести работу: субагенты в одной сессии, skills с инструкциями, agent teams с лидером в отдельных окнах, Dynamic Workflows как JS-скрипт от рантайма. У каждого свой потолок параллелизма. У каждого свои уместные сценарии. Полная карта - в моём гайде про multi-agent в Claude Code.
Главное отличие осознанного multi-agent от антипаттерна - это не количество агентов. Это умение объяснить за 30 секунд, что делает каждый из них.
Тест на 30 секунд: 4 вопроса, после которых половина агентов уходит в /dev/null
Возьми лист бумаги. Нарисуй прямоугольники под каждого своего параллельного агента (включая субагентов, агентов команды, workflow-агентов - всех). В каждом прямоугольнике напиши:
Засекаешь 30 секунд на один прямоугольник. Если на хотя бы один из четырёх вопросов не отвечаешь за это время - агента у тебя быть не должно. Закрывай.
Это работает на любом уровне. На субагентах внутри одной сессии. На agent teams в нескольких окнах. На Dynamic Workflows-скрипте. Если рантайм запускает 50 параллельных воркеров, а ты не можешь объяснить, чем занят каждый - значит, ты запустил generator мусора, а не оркестратор.
Скриншот: чек-лист на бумаге, 6 прямоугольников, в 3 заполнены ответы на 4 вопроса, в 3 - пусто. Подпись: «Три агента закрываем».
Конкретный пример из моего стандартного прогона текстов через QA. Изначально я запускал 8 субагентов:
- Анти-ИИ чекер (что делает: ищет симметрии, длинные тире, штампы. Файлы: один .md черновика. Возвращает: список нарушений. Проверяет: руками).
- Юр-словарь чекер (ищет образовательную лексику, гарантии результата, англицизмы с русским аналогом).
- Тон голоса (сверяется с эфирами автора).
- Факт-чек через WebFetch (открывает каждую URL и сверяет цитату verbatim).
- SEO-структура (H1, H2, lead, meta).
- Кросс-ссылки (правильные UTM, не более 3 на свой домен).
- ~~Универсальный «общий ревью»~~ (что делает - не могу объяснить за 30 секунд → закрыл).
- ~~«Дополнительная проверка качества»~~ (что возвращает - не могу объяснить → закрыл).
Из 8 субагентов остались 6. Расход токенов упал на 25%. Качество прогона не изменилось - потому что 7 и 8 пересекались с другими и ничего нового не находили.
Этот же тест я гоняю на чужих проектах, когда меня зовут разобрать setup Claude Code. Средний показатель после теста - 3-4 живых агента из 8. Половина закрывается, потому что человек запустил их по принципу «больше = круче», а не «нужен для конкретной задачи».
Сколько на самом деле стоит multi-agent: Uber, x10 токенов и история про годовой бюджет
В мае-июне 2026 индустрия одновременно столкнулась с тем, что ИИ-кодинг стоит дороже, чем казалось. Три истории за две недели, все про multi-agent.
27 мая Simon Willison написал, что Anthropic и OpenAI наконец нашли product-market fit через agentic coding - компании начали жечь токены как никогда. На следующий день Pragmatic Engineer выпустил The Pulse про тренд: инженерные департаменты массово урезают ИИ-бюджеты. 3 июня Uber официально ввёл лимит $1500 на инструмент на разработчика в месяц - после того, как годовой ИИ-бюджет 2026 года сожгли за 4 месяца.
Все три истории - не про обычный ИИ-чат. Про multi-agent.
Грубая математика расхода токенов относительно одной сессии Claude Code:
- Субагенты в одной сессии: x2-x4. Каждый субагент проедает свой контекст отдельно, но они шарят рут-промпт.
- Agent teams в разных окнах: x3-x6. Каждое окно держит свой контекст, плюс координация через общий task-list.
- Dynamic Workflows: x10-x30. Рантайм запускает десятки параллельных агентов, каждый со своим контекстным окном, плюс grader-агенты сверху.
Когда инженер Uber открывает один Claude Code и работает в нём 8 часов - это $50-100 в день. Когда тот же инженер запускает Dynamic Workflow на «проверь весь проект на безопасность» - один такой запуск может закрыть половину месячного лимита.
Из официальной документации Anthropic про Workflows, вкладка Cost:
A workflow spawns many agents, so a single run can use meaningfully more tokens than working through the same task in conversation.
И там же прямое указание, как этим управлять:
To gauge the spend before committing to a large task, run the workflow on a small slice first.
«Small slice» - это не весь src/. Это src/auth/. Посмотри счёт. Если ок - тогда расширяешь на остальное.
Четыре правила экономии, которые работают в продакшене:
- Жёстко указывай файлы каждому агенту в инструкции. Не «посмотри проект и найди проблемы». А «посмотри src/auth/*.ts, найди функции без проверки userId, верни список». Без glob-pattern или конкретных путей в промпте Claude перечитает всё.
- Workflow всегда сначала на одной директории. Не на всём src/. Сначала на src/auth/. Только когда понял цену - раскатывай.
- /effort high по умолчанию, /effort ultracode только осознанно. Ultracode - это xhigh плюс автоматическая оркестрация. Дорого. Включай, когда задача реально требует нескольких параллельных потоков.
- Субагентов на не-Opus задачах переключай на Sonnet. Если у тебя 6 субагентов на проверке гайда, анти-ИИ чекер и cross-link checker не требуют Opus. Sonnet справится. Расход падает в 3-5 раз.
Глубокий разбор того, куда конкретно уходят токены - в моём гайде про расход токенов в Claude Code.
Скриншот: вывод claude /cost за неделю. Два слота: «обычная работа» $87, «один Dynamic Workflow на весь репозиторий» $312. Подпись: «28 минут одного workflow».
Параллельно ≠ быстрее: что режет CPU и почему 6 - это практический потолок
Главный миф про multi-agent звучит так: «запустил 10 параллельных Claude - получил 10-кратное ускорение». Не так.
Параллельные агенты, которые работают на одной машине, делят CPU. Один обычный Claude Code в активной работе - это 1-1.5 ядра. Шесть параллельных - 6-9 ядер, и на восьмиядерном ноутбуке начинается throttle. Каждый агент работает медленнее, плюс рантайм тратит время на координацию.
Практический потолок на современном ноутбуке - 4-6 одновременных Claude Code в активной работе. Дальше система начинает заикаться. Я лично работаю в двух worktree почти всегда. Иногда три - один основной, один резервный для срочного hotfix, один экспериментальный. Больше - редко и только под конкретный аудит.
Второй слой проблемы - зависимости между задачами. Параллельно можно запускать только независимые задачи. Если бэкенд нужен раньше фронтенда, потому что фронтенд читает API-схему, - не параллель их. Сначала бэкенд, потом фронтенд. Если ты разнёс их параллельно «для скорости» - один из агентов всё равно будет ждать другого, плюс ты потратишь токены на ходы в пустоту.
Третий слой - физический конфликт за файлы. Когда субагенты живут в одной сессии, Claude сам разводит их по очереди записи. Когда у тебя два полноценных Claude Code в разных терминалах на одном репозитории - они начинают править один и тот же файл. Один сохраняет первым, второй накатывает поверх. В одном чате на прошлой неделе мне прислали дословную формулировку: «5 параллельных Claude перетирают друг друга».
Решение - встроенный git worktree. Один origin, несколько рабочих копий на разных ветках, файлы не пересекаются. Команды на пять минут:
Каждая копия на своей ветке, каждый Claude Code пишет в свою директорию. Когда задача закрыта - git push из своей ветки, потом git worktree remove. Глубокий разбор worktree - в отдельном гайде про git worktree в Claude Code.
Скриншот: htop в момент работы шести параллельных Claude Code на восьмиядерном MacBook. CPU 95%, температура 91°. Подпись: «Это уже throttle, седьмой агент тормозит всю систему».
Outcomes-паттерн: как заставить grader-агента проверять своих коллег
Cамая опасная штука в multi-agent - доверие к выводам агентов. Каждый твой агент выдаёт текст, который выглядит как сделанная работа. Цитата похожа на правду. Отчёт похож на полный. Миграция похожа на закрытую.
Когда у тебя один агент - ты сам это проверишь руками. Когда у тебя десять - не проверишь, не успеешь. И тут включается классический сценарий: ты считаешь себя многоруким, на самом деле у тебя десять параллельно врущих агентов.
Anthropic закрыла эту проблему 6 мая 2026 фичей Outcomes в Managed Agents. Идея простая. У сессии появляется второй агент-проверщик (grader), чья единственная работа - сверять выводы первого по жёсткому своду критериев (rubric).
В Anthropic Cookbook это сформулировано так:
Agents are good at producing things that look done. Ask one for a cited research brief and you'll get a tidy document with footnotes. Look closer and there's usually room to improve: a topic gets thin coverage, a quote drifts from the source, a citation leans on a press release instead of the original filing.
Переводя на инженерный русский: агенты умеют выдавать то, что ВЫГЛЯДИТ сделанным. Попросишь одного написать research-отчёт со ссылками - получишь аккуратный документ со сносками. Посмотришь ближе - тема раскрыта поверхностно, цитата плывёт от источника, ссылка опирается на пресс-релиз вместо оригинального документа.
Реальные цифры эффекта в продакшене:
- У ИИ-юридической компании Harvey, после интеграции Outcomes, task completion вырос примерно в 6 раз.
- У Wisedocs (медицинская документация) время на ручной review одного документа сократилось на 50%.
Главное - этот паттерн работает и без официальной фичи Managed Agents. Это шаблон, не только продукт Anthropic. Ты можешь сам сделать grader-агента руками: положи в .claude/agents/grader.md инструкцию проверять выводы по rubric и попроси главного агента запускать его после каждой попытки.
Готовый rubric, который у меня живёт в .claude/agents/grader.md:
Главное правило из Anthropic Cookbook про написание rubric: формулируй проверяемое. «Проверь, что в брифе раскрыта тема billing» - под такое grader просто пробежит глазами и поставит галочку. «Открой бриф, найди раздел про billing, подтверди, что там указана конкретная сумма в $ или процент от выручки» - заставит открыть документ и найти конкретное число.
Этот rubric ставится в любой проект Claude Code за 5 минут. Расход - один лишний прогон Sonnet после каждой попытки writer-агента. Эффект - писатель перестаёт выдавать «выглядит готово» вместо «готово».
Скриншот: вывод grader-агента в JSON. Три red_flags про цифры без источника, два yellow про объём. Подпись: «Writer был уверен, что закрыл задачу».
Минимальная связка multi-agent: 2 worktree и 1 grader на 30 минут
Не нужно сразу прыгать в Dynamic Workflows и фреймворки оркестрации. Базовая связка multi-agent, которой хватает на 80% реальных задач, ставится за полчаса. Шесть шагов.
Шаг 1. Обнови Claude Code до v2.1.154+. Это минимальная версия с Dynamic Workflows (даже если ты их пока не используешь - этот же релиз чинит несколько багов worktree). Команда claude update в терминале.
Шаг 2. Включи Dynamic Workflows в /config. На Pro-плане они выключены по умолчанию. На Max, Team и Enterprise - уже включены. Зайди в /config, найди строку «Dynamic workflows», переключи на on. Не включай /effort ultracode сразу - сначала освойся с обычным /effort high.
Шаг 3. Создай первый worktree. В директории основного проекта запусти git worktree add ../<project>-experiment <branch>. Открой второе окно терминала в этой директории. Запусти claude. Теперь у тебя два Claude Code в двух разных директориях на одной кодовой базе.
Шаг 4. Положи общий план в tasks.md. В корне проекта создай tasks.md с задачами на сегодня. Оба Claude Code будут смотреть в один файл и понимать, что делает другой.
Шаг 5. Положи grader-агента в .claude/agents/grader.md. Текст rubric из секции выше. Готов за 5 минут. После каждой попытки писать «прогони grader на этот вывод».
Шаг 6. Работай неделю в этом режиме руками. Не ставь GUI-обвязку сразу. Из готовых на 2026 год есть Superset (mac, бесплатный, мой первый выбор), Conductor (mac-native, платный), CCManager (терминальный, htop-style), Crystal (electron, кросс-платформенный). Все они под капотом - тот же git worktree плюс tmux. Через неделю ручной работы ты поймёшь, чего тебе не хватает в интерфейсе, и выберешь обвязку под конкретную боль. До этого момента любой GUI - это лишнее звено.
Скриншот: терминал, два окна. В левом claude в my-app-auth, в правом - в my-app-billing. Между ними tasks.md с тремя задачами, две помечены [x], одна [ ].
После этого недельного прогона по реальным проектам обычно остаётся 2-3 worktree (а не 5+), 1 grader-субагент и одна-две команды для Dynamic Workflow на конкретные сценарии вроде аудита безопасности. Если нужно больше - значит, задачи стали сложнее, и многоязычные оркестраторы будут оправданы. Если меньше не получается обходиться - значит, ты ещё не закрыл первый уровень и пора вернуться к 30-секундному тесту.
Что забирать с собой
Multi-agent в Claude Code на середину 2026 года - это набор примитивов разной зрелости. Subagents и git worktree стабильны. Agent teams автоматизированы наполовину. Dynamic Workflows в research preview, активно меняются. Managed Agents v2 - энтерпрайзная штука. Оптимальная связка под твою задачу - минимально нужная, а не последний релиз.
Что забирать:
- 30-секундный тест: 4 вопроса (что делает, какие файлы, что возвращает, кто проверяет). Гоняй раз в две недели по всем своим параллельным агентам. Половина закроется. Это нормально.
- Жёстко фиксируй файлы в промпте каждого агента. Без src/auth/*.ts или конкретных путей - Claude перечитает весь проект. Это главная статья расхода токенов.
- Grader-агент с rubric проверяемых пунктов, а не общих фраз. Шаблон из секции выше копируется в любой проект за 5 минут. Это страховка от «выглядит готовым».
- Параллельно запускай только независимые задачи. Зависимые - последовательно. Иначе один из агентов будет ждать другого, и multi-agent превратится в дорогой single-agent.
- CPU - это физический потолок. 4-6 параллельных Claude Code на ноутбуке. Дальше throttle. Если нужно больше - облако (Boxes.dev) или машина с 16 ядер.
Прогноз на ближайшие 6 месяцев: количество готовых rubric и grader-шаблонов в open source вырастет на порядок, и собирать свою связку multi-agent станет не сложнее, чем поставить плагин. Главный навык, который надо нарабатывать, - отделять задачи, которые реально распадаются на независимые потоки, от задач, которые лучше делать в одной сессии. «Уметь запустить 50 параллельных» - это побочка, не навык. Сам по себе тоже не появится - нарабатывается через 30-секундный тест и три недели работы в режиме «2 worktree плюс grader».
Вопрос к читателю. Сколько у тебя сейчас параллельных Claude Code или субагентов в активной работе? Прогони на каждом из них тест на 30 секунд: что делает, какие файлы, что возвращает, кто проверяет. Сколько закрыл? Жду в комментариях - интересно, у кого половина выживает, а у кого - больше.