Содержание, 6 разделов
Когда в агенте появляется инструмент «поручи задачу другому агенту», это выглядит как шаг к оркестрации: один думает, несколько делают, всё параллельно. У меня получилось иначе. Субагенты в моём агенте почти не работают параллельно, и скорость тут вообще вторична. Главная причина их существования это возможность купить чистый контекст.
Зачем вообще делегировать
Самое честное измерение мультиагентности, которое я знаю, опубликовала Anthropic в июне 2025 года, описывая свою исследовательскую систему. Связка из ведущего агента на Claude Opus 4 и субагентов на Claude Sonnet 4 обошла одиночный Opus 4 на 90,2% на внутренней оценке исследовательских задач. Впечатляет, пока не читаешь дальше. Агент тратит примерно в четыре раза больше токенов, чем чат, мультиагентная система примерно в пятнадцать. И расход токенов сам по себе объясняет 80% разброса в качестве на задачах поиска. Система выигрывает во многом потому, что сжигает больше, в нескольких контекстах параллельно.
Там же сказано, где это работает и где нет. Мультиагентность хороша для задач, которые распадаются на независимые направления поиска вширь. Она плохо подходит там, где нужен общий контекст и плотная координация, и авторы прямо называют примером большинство задач по программированию.
Вторая работа ещё трезвее. Джемри с соавторами разобрали больше 1 600 трасс выполнения в семи популярных мультиагентных фреймворках и построили таксономию отказов: четырнадцать режимов в трёх группах, ошибки спецификации и дизайна системы, рассогласование между агентами, провал проверки результата. Вывод в первой строке аннотации: несмотря на энтузиазм, прирост мультиагентных систем на популярных бенчмарках часто минимален.
Для агента, который в основном пишет код, из этого следует простое. Лозунг «больше агентов значит быстрее» к нему не относится. Делегирование нужно для другого, и это другое связано с контекстом.
Изоляция как цель
Каждый прочитанный файл остаётся в переписке до конца сессии, а качество модели падает по мере роста контекста. Значит, самая дорогая операция для агента это исследование: прочитать двадцать файлов, чтобы понять, что нужно поправить три строки в одном. Двадцать файлов после этого лежат в контексте мёртвым грузом до самой компакции.
Субагент решает именно это. У него отдельный контекст. Родитель формулирует задание, субагент делает всю грязную работу, читает, ищет, запускает, и возвращает одно текстовое сообщение. Промежуточные вызовы инструментов в переписку родителя не попадают вообще. Двадцать файлов прочитаны, в контексте родителя абзац с выводами и номерами строк.
У меня три встроенных субагента, и два из них существуют ровно для этого. explore это картограф: инструменты только для чтения, задача: понять устройство кода и вернуть сжатый отчёт с путями и строками. review это независимый проверяющий с теми же инструментами: ищет ошибки, граничные случаи, дыры в тестах и не имеет права ничего исправлять. Третий, worker, умеет всё и берётся по умолчанию, когда задача не укладывается в первые два.
Описание инструмента task для родителя сформулировано под тот же случай. Когда пользователь просит независимую работу по нескольким областям, выдай несколько заданий в одном ходу вместо того, чтобы читать всё самому. И отдельно для изолированного исследования, ревью, разведки.
Что субагент видит
Единственное сообщение пользователя, которое получает субагент, это текст задания. Разговор родителя ему не виден: ни исходная просьба человека, ни рассуждения, ни результаты предыдущих инструментов. Это сделано намеренно, и каждый субагент знает об этом из своего промпта первой же строкой: ты работаешь в изолированном контексте и не видишь разговора родителя; родитель увидит только твоё последнее сообщение, поэтому оно должно стоять само по себе как полный результат.
Помимо задания субагент получает системный промпт. Он собран из роли субагента и того же проектного заземления, что у родителя: файл AGENTS.md, если каталог доверенный, правила проекта, навыки, каталог подключённых MCP-серверов, рабочая директория, дата и платформа. Без этого относительный путь в задании разрешался бы неоднозначно, и субагент искал бы файл не там.
Требования к отчёту жёсткие, потому что отчёт это единственное, что доживёт до родителя. Последний ход обязан быть текстом: закончить вызовом инструмента нельзя, иначе результата не будет. Никаких любезностей и пересказа задания. Для исследования: находки с путями и номерами строк, с явным перечислением того, что не покрыто. Для правки: какие файлы изменены, что именно и как проверено: тесты, сборка, конкретная команда. Доказательства обязательны, потому что родитель не может их получить сам. Он не видел, что субагент делал.
Что возвращается
Родителю возвращается последнее непустое текстовое сообщение субагента. Если модель закончила ход вызовом инструментов или пустой строкой, берётся предыдущее содержательное сообщение, чтобы холостой финальный ход не стёр настоящий отчёт.
Дальше проверки, и каждая появилась после того, как чего-то не хватило. Если субагент завершился не штатно, прерван, отключён, упал, родитель получает ошибку с тем текстом, который успел появиться. Раньше в этом случае приходил чистый пустой результат, который легко принять за «сделано». Если завершился штатно и ничего не написал, тоже ошибка: «завершил работу, но не выдал результата». Расход токенов и деньги субагента складываются в счёт родительской сессии. Токены складывались всегда, а стоимость, которую сообщает провайдер, какое-то время пропадала, и сессия выглядела дешевле, чем была.
Полная стенограмма субагента сохраняется в базу. Раньше она жила только в памяти и терялась при смерти процесса. Сохранение сделано необязательным: одно время оно стояло внутри общего блока обработки ошибок, и любой сбой записи, диск заполнен, база заблокирована, строка сессии ещё не на диске, превращался в «субагент завершился с ошибкой: нарушение внешнего ключа» вместо ответа, за который уже заплачено. Потеря архивной копии это не повод терять результат.
Границы наследуются вниз
В части про роли я писал, что ограничение роли обязано наследоваться при делегировании, иначе оно обходится. Здесь о том, как именно.
Субагент не может делегировать дальше: инструмент task показывается только тому, у кого есть список доступных субагентов, а ребёнку этот список не передаётся. Глубина дерева: один. Роль родителя может ограничить, каких субагентов он вправе порождать, и это ограничение применяется дважды, при составлении списка в описании инструмента и при поиске субагента по имени, чтобы нельзя было попросить тип, который просто не был показан.
Если родитель в режиме планирования, ребёнок получает инспекционный bash и явный запрет на write и edit. Именно явный: сам режим планирования ребёнку не включается, потому что его промпт ссылается на инструменты работы с планом, которых у ребёнка нет, поэтому ограничения передаются по отдельности. Хуки родителя наследуются: хук, который перехватывает инструмент, действует везде, где этот инструмент может выполниться. Запросы подтверждения опасных команд от разных субагентов выстраиваются в очередь, потому что терминал один.
И про параллельность. Субагенты у меня не запускаются одновременно: task намеренно исключён из списка инструментов, которые цикл выполняет параллельно, и соседние задания в одном ответе модели идут одно за другим. Когда-то стоял семафор на десять одновременных субагентов, с тех времён, когда пакет вызовов task выполнялся через Promise.all. После того как параллельность убрали, он мог только заставить субагента одной сессии ждать субагентов десяти других. Я его удалил. Ограничение, которое ничего не ограничивает, только вводит в заблуждение.
Что из этого следует
Делегирование в моём агенте это сделка. Ты отдаёшь задачу и получаешь чистый контекст: всё, что субагент прочитал и запустил, остаётся в его переписке и не засоряет твою. Платишь за это полной потерей промежуточного. Родитель знает о работе субагента ровно столько, сколько тот написал в последнем сообщении. Что в отчёт не попало, для родителя не происходило.
Отсюда два требования, которые я считаю главными. Задание должно быть полным и самодостаточным, потому что у субагента нет другого источника контекста, и это ровно та категория отказов, которую таксономия Джемри ставит первой. И отчёт должен нести доказательства, пути, строки, вывод команд, потому что родитель не может проверить сам. Anthropic формулирует то же для своего оркестратора: каждому субагенту нужны ясная цель, формат результата, указания по инструментам и границы задачи.
Мультиагентность в брошюрах это много агентов, работающих вместе. У меня это один агент, который время от времени нанимает другого, чтобы не читать двадцать файлов самому.