Меньше субагентов, больше контекста: что Anthropic и Рэй Амджад советуют менять в мультиагентных схемах

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

Когда субагенты Claude Code действительно нужны

Субагент — это агент со своим контекстным окном, инструментами и инструкциями. Его можно описать заранее или создать по запросу оркестратора. Anthropic выделяет три ситуации, где он оправдан:

• Измеримая деградация. Один агент демонстрирует падение качества, подтверждённое оценками (evals), а не ощущением.
• Независимые параллельные задачи. У каждой своё окно, которое можно выбросить после завершения.
• Перегруженный агент. Ему сложно выбирать из множества инструментов, а системный промпт содержит противоречащие друг другу инструкции.

Обратите внимание на слово «измеримая». Если вы просто чувствуете, что один агент работает хуже, это ещё не повод плодить дочерние.

Закон Конвея для агентов: откуда берутся лишние субагенты

Команда прикладного ИИ в Anthropic заметила: компании раздают каждой команде или типу проблемы своего субагента, и архитектура становится копией оргструктуры. Это закон Конвея в чистом виде. За одним чатом поддержки скрываются агенты доставки, заказов, возвратов и платежей, а сверху сидит оркестратор от платформенной команды.

Статья называет пять типичных проблем:

1. Управление контекстом. Детали теряются при передаче между агентами.
2. Битва субагентов. Появляются агенты «возврат денег», «возврат товара» и «возврат и обмен», потому что никто не проверил, что уже есть. Координатор тратит токены на вопрос «кому это отдать?».
3. Задание для Франкенштейна. Каждая команда дописывает правила в системный промпт, правила противоречат друг другу, единого голоса нет.
4. Тестирование по частям. Каждый агент проверен отдельно, система целиком — никем.
5. Задержка. Многоагентная система медленнее, а результат часто хуже, чем у одного цикла.

Что делать вместо этого: навыки и прогрессивное раскрытие

Альтернатива, которую предлагает Anthropic, — один агент с постепенным раскрытием информации. Он видит краткие описания навыков и загружает полное содержимое только при необходимости. С инструментами то же самое: в Claude Code есть отложенная загрузка и поиск по инструментам. Вместо «агента доставки» вы получаете навык по логистике, а вызовы API превращаются в инструменты с нужными разрешениями. Жёсткие шаги согласования можно вынести в шлюз MCP, где политика определяет, что одобряется автоматически, что требует подтверждения, а что заблокировано.

Почему это работает:

• Общий контекст даёт более богатые выводы. Агент видит результат каждого шага, а не серию пересказов от субагентов.
• Опасения про 150 000 токенов устарели. Амджад регулярно работает с окном в 400–500 тысяч токенов на Opus 5.5 без заметной деградации. Если навык на тысячу строк, его стоит разбить на файлы поменьше.
• Модели стали сильнее. Они справляются с большим числом задач в одном цикле и сами проверяют результат, если дать инструмент: например, статус возврата больше не нужно проверять отдельным правилом.

Персоны не окупились, а тикеты ухудшили результат

Автор проверил идеи на собственной «фабрике ПО»: начальник штаба, агент контроля качества, аналитик, разработчик, ревьюер, агент роста. Затем попытался сократить число ролей. Анализ прошлых сессий показал: качество PR не выросло, стоимость осталась прежней, а новые слои добавили издержки на координацию. Вывод Амджада: персоны не стоят усилий, а в будущем агент-начальник штаба, возможно, сам будет создавать и удалять их по необходимости.

Теоретическую рамку он находит в статье Тоби Орда «Масштабирование роя». Если n исполнителей достигают того же, что один за время n^λ, то λ описывает степень распараллеливаемости. Для задач вроде Terminal Bench оценка λ около 0,5: сто агентов дают прирост примерно в десять раз, не в сто. Это похоже на убывающую отдачу в человеческих командах. Пока модели плохо определяют, насколько задача параллелизуема, так что координаторы работают посредственно. Если λ вырастет до 0,8–0,9, конфигурацию имеет смысл пересмотреть.

Делить по контексту, а не по типу задачи

Центральная идея видео: сегментировать работу нужно не по тому, что это за задача (фронтенд, бэкенд, безопасность), а по тому, какой контекст нужен. Пример с приглашением в команду: бэкенд-, фронтенд- и тест-агенты вынуждены знать одно и то же — формат токена, срок действия в семь дней, регистр email. Один агент из-за потери информации сохранит адреса в нижнем регистре, другой не узнает об этом, и «Ray» с «ray» станут двумя разными пользователями. Исполнитель, который делает всё в одном окне, такой ошибки избегает.

Зато отдельное окно полезно там, где контекст исполнителя вредит:

• Ревью кода. Агент видит спецификацию и diff, но не унаследует слепые пятна автора.
• Проверка в браузере. Отдельный верификатор прогоняет тестовую матрицу пользовательских маршрутов со сбросом базы между проверками; независимые маршруты можно запускать параллельно в форках песочницы.
• Исследование. Агенту, который выясняет, как другие приложения делают magic link, не нужен ваш проект.

Два антипаттерна

Первый — нарезка спецификации на тикеты, каждый из которых реализует отдельный субагент с пустым окном. Агент №7 не знает, что понял агент №3, и всем приходится заново разбираться в коде. По опыту автора, один исполнитель, ведущий всю спецификацию целиком (с одним-двумя сжатиями контекста), выдаёт заметно лучший результат, а на Opus 5 и 5.5 тикеты уже не обязательны. Он даже ставит порог автокомпакта на 400–500 тысяч токенов вместо миллиона.

Второй — параллельный запуск тикетов под координатором. Тикеты кажутся независимыми, но связаны неочевидными зависимостями, а координатор плохо это определяет.

Рабочая схема автора: исполнитель в полном контексте → ревью в свежем окне по спецификации и diff → правки возвращаются тому же исполнителю → верификация по тестовой матрице. Состязательное давление проверяющих ловит то, что исполнитель упустил.

Вывод

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