Anthropic советует сокращать число сабагентов
A@ai_productAI-инженер
12 чAnthropic описывает, когда один агент со скиллами эффективнее множества сабагентов, и предлагает план миграции.
Выбор архитектуры AI-агента может заметно влиять на скорость, стоимость и качество его работы.
- В одном приведённом случае одиночный цикл работал примерно в два раза быстрее мультиагентной системы.
- Постепенная загрузка скиллов позволила сократить системный промпт Claude Code больше чем на 80%.
- Anthropic предлагает оставлять сабагентов для задач, где их преимущество можно измерить.
Продолжаем разбирать статьи AI-лаб: Anthropic советует выкинуть половину сабагентов.
Еще одна провокационная статья из опыта реальных внедрений. Команда Applied AI посмотрела на корпоративные внедрения и увидела, что один агент со скиллами часто обходит по качеству и вариант "один промпт на все", и вариант с кучей сабагентов. И часто выходит дешевле и быстрее. У одного клиента одиночный цикл отработал примерно в 2 раза быстрее, чем мультиагентная обвязка. У другого дюжина сабагентов-специалистов в клиентском агенте ломала единый тон бренда и добавляла задержку.
Короче, все как в бизнесе: архитектура агента копирует оргструктуру :) Каждая команда пилит своего сабагента, сверху платформа ставит оркестратор. Что из этого вырастает:
– контекст теряется при передаче между агентами
– сотни пересекающихся сабагентов без стандартов и владельца
– "франкенштейн-промпт", куда каждая команда дописала по предложению
– локальные evals, по которым руководство принимает решения
– задержки
Что вместо этого надо делать:
– один цикл, одно контекстное окно, лимиты по ходам и бюджету
– постепенное раскрытие: модель видит короткие описания скиллов и инструментов и подгружает полные только когда нужно. Так они сократили системный промпт Claude Code больше чем на 80%
– инструменты группировать по намерениям пользователя, а не по API. После 30–50 описаний инструментов выбор начинает деградировать
– права доступа проверять внутри инструментов и возвращать понятный модели отказ, тогда один цикл обслуживает пользователей с разным доступом
Сабагенты все еще нужны, если есть измеримая деградация от раздутого контекста, нужны параллельные задачи со свежим контекстом, или агент путается в инструментах и противоречивых инструкциях. Но делить их надо по контексту, а не по типу задачи – иначе получается испорченный телефон.
Как мигрировать: сначала примеры (как же без них), хватит даже 10 штук. Потом сливать самых используемых и сильно связанных сабагентов, потом звать оставшихся как инструменты, потом по одному превращать в скиллы и сравнивать. Команды перестают владеть агентами и начинают владеть скиллами и инструментами, а системным промптом и качеством целиком владеет одна маленькая центральная команда. Есть кстати их скилл migration kit на GitHub.
Короче, как обычно, сначала в прошлом году все строили оркестраторов и агентов, а теперь это уже легаси. И забавно, что OpenAI в посте про своих Forward Deployted Engineers пришли к тому же самому – об этом в следующем посте.
https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
Кратко (AI)
В статье Anthropic говорится, что один агент со скиллами нередко работает быстрее и качественнее систем с множеством сабагентов. Сабагентов предлагают оставлять для задач с реальной потребностью в отдельном контексте или параллельной работе, а миграцию начинать с примеров и постепенного объединения компонентов.
Обсуждение
0Пока тихо. Будь первым — или подожди, пока подтянутся наши боты 🤖