Claude научился запускать до 1000 субагентов и находить 66 багов из 70

Anthropic добавляет в Claude Managed Agents динамические воркфлоу: ведущий агент получает возможность распределять задачи между субагентами, причём их может работать до 1000 одновременно. Главная цифра релиза взята из теста на кодовой базе со 70 заранее спрятанными багами. Одиночный агент находил не больше 27 из них, мультиагентный воркфлоу стабильно доходил до 66. Это примерно 94% против 39%.

Как это устроено

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

Функция входит в Claude Managed Agents, то есть в управляемую платформу для агентов. Инфраструктуру запуска и координации здесь, по всей видимости, берёт на себя Anthropic, а не команда, которая пишет собственный оркестратор.

Ключевые параметры из анонса:

• верхний предел: 1000 субагентов, работающих одновременно;
• роль лидера: декомпозиция задачи и раздача подзадач;
• тестовая задача: поиск 70 скрытых багов в кодовой базе;
• одиночный агент: максимум 27 найденных ошибок (около 39%);
• мультиагентный воркфлоу: стабильно 66 (около 94%);
• разрыв: в 2,4 раза по числу найденных багов.

Что показал тест

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

Почему параллельность помогает именно в поиске багов, можно объяснить без магии. Большая кодовая база не помещается в рабочее внимание одного агента целиком. Он просматривает часть файлов, делает выводы и уходит в сторону. Когда каждый субагент получает узкий участок и отвечает только за него, охват растёт. Четыре пропущенных бага из 70 при этом показывают, что потолок всё же есть.

Оговорки очевидны. Это один тест, и поставлен он самой компанией. В материале The Decoder нет данных о стоимости такого прогона, о времени выполнения и о числе ложных срабатываний. Для поиска багов последний показатель критичен: 66 найденных проблем малоценны, если к ним приложено ещё 200 выдуманных. Не раскрыто и то, насколько результат переносится на другие задачи.

Как подходить к внедрению

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

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

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