Когда вливать сабагентов в основной agent loop: гайд Anthropic

Команда Applied AI в Anthropic заметила устойчивый паттерн: корпоративные внедрения выигрывают, когда роутеры, планировщики и доменные сабагенты вливают в основной agent loop. В сравнениях на нескольких внедрениях один агент со скиллами обгонял по качеству и дизайн «один промпт на всё», и дизайн с сабагентами — часто при меньших цене и задержке. Пример: дюжина сабагентов в клиентском агенте мешала держать единый стиль и добавляла задержку, портившую пользовательский опыт.

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

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

Сабагенты оправданы в трёх случаях — Anthropic сама использует их, например в своей мультиагентной исследовательской системе:

• Одиночный agent loop упирается в измеримую деградацию качества из-за переполнения контекста.
• Задач много, их можно решать параллельно, и каждой нужен свежий одноразовый контекст.
• Один агент плохо выбирает инструменты или системный промпт содержит конфликтующие инструкции.

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

Как ломаются многоагентные системы в больших компаниях

Типовой сценарий: каждый продукт принадлежит своей команде, каждая команда строит своего агента, а центральная платформенная команда ставит сверху оркестратор. Выглядит просто, но сразу появляются проблемы:

• Потеря контекста. Детали теряются при каждом обмене между агентами.
• Размножение сабагентов. Каждая команда поставляет своего агента — в итоге сотни пересекающихся сабагентов без стандартов и ответственных.
• Франкенпромпт. Каждая команда добавляет предложение в системный промпт. Получаются конфликтующие правила и отсутствие единого голоса.
• Разбегающиеся eval. Каждая команда приносит свои оценки, заточенные под её подзадачу. Никто не поддерживает набор целиком, а руководство решает по размытым локальным цифрам.
• Задержка. Сложность мультиагентной архитектуры стоит времени: один из клиентов Anthropic сравнил свой многоагентный каркас с одиночным agent loop — второй был примерно в два раза быстрее.

Прогрессивная загрузка вместо оркестрации

Альтернатива оркестратору — прогрессивная загрузка: агент видит только короткие описания скиллов и инструментов, а полные версии подгружаются по мере надобности. Контекст раскрывается через скиллы, инструменты — через tool search.

У подхода три опоры:

• Общий контекст даёт лучшие ответы. Результаты ранних шагов остаются в главном окне контекста, и агент связывает их между собой. Это даёт более богатые выводы, чем набор пересказов от сабагентов, и убирает потери при передачах.
• Прогрессивная загрузка убирает переполнение контекста. Один агент покрывает много задач без длинного системного промпта — именно поэтому команды раньше и делили работу между сабагентами. Anthropic сократила системный промпт Claude Code для новых моделей более чем на 80%, в том числе за счёт прогрессивной загрузки.
• Модели стали сильнее. Начиная с Opus 4.5 модели управляют в одном цикле гораздо большим, чем ожидают команды. У Opus 5.5 и Fable 5.1 режим рассуждений вообще нельзя выключить: модели сами проговаривают прогресс и проверяют свою работу, из-за чего часть каркаса становится лишней. Простой цикл и мигрирует проще: на практике именно жёсткие многоагентные структуры мешали новой модели раскрыться.

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

Если мультиагентность всё же нужна, начинайте с самого простого паттерна (generator-verifier, orchestrator-subagent) и делите работу по контексту: сабагент получает кусок работы, которому мало что нужно от остальной системы, и возвращает компактный результат. Деление же по типу задач превращает обмены в «испорченный телефон», где каждая передача искажает информацию.

Целевая архитектура: один цикл

Вот дизайн, к которому предлагает идти Anthropic:

• Одна модель и одно окно контекста в открытом инструментальном цикле. Ограничения — бюджеты на шаги и стоимость, «шлюзы» на запись — задаёт каркас (harness).
• На каждом шаге модель выдаёт пакет вызовов инструментов. Каркас запускает их параллельно и возвращает сырые результаты той же модели. Она решает: ещё пакет, вопрос пользователю или финальный ответ.
• Цикл останавливается, когда модель ответила или упёрлась в бюджет; после ответа опционально запускается проверка цели или верификатор.
• План модель пишет в контексте на первом шаге и правит по мере поступления результатов. Главное отличие от оркестратора: тот, кто пишет план, сам его исполняет — и может менять на ходу.
• Контекст по-прежнему загружается, но управляет им сам агент: порядок действий и доменные процедуры уходят в скиллы, жёсткие ограничения — валидация, шлюзы одобрения — в инструменты. Код остаётся для дешёвых и почти всегда нужных загрузок и механики внутри инструментов: сборка payload, разбор потока, возобновление уточняющего диалога.

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

Миграция по шагам

Переход не обязан быть резким.

1. Сначала eval на завершение задач

Рабочая структура: один общий сквозной набор eval во владении центральной команды плюс маленькие наборы, которые каждая команда поставляет вместе со своим скиллом. Хватит даже десяти «золотых» примеров.

Хороший старт — оценивать финальный ответ по рубрике. Пока жив оркестратор, отслеживайте и точность маршрутизации; после вливания — загрузил ли агент правильный скилл или инструмент. Если системы сложно воспроизвести, помогает запись таймстемпов важных событий — их потом переигрывают как точечные eval.

2. Слияние доменных агентов

Перед первым слиянием соберите небольшой сквозной eval. Затем вливайте по общему контексту, начиная с самых востребованных сабагентов. Сливайте специалистов, которые передают результат друг другу, трогают одни и те же данные или часто вызываются вместе. Если заметная доля продакшн-трафика — это два специалиста подряд, это кандидат на слияние в одного доменного агента.

3. Сабагенты как инструменты

Если сабагент остаётся, сделайте его инструментом для основного агента — так агент продолжает держать диалог с пользователем. Полная передача управления оправдана, только если сабагенту нужно говорить с пользователем напрямую; всё остальное — скилл плюс инструменты в основном цикле.

Этот шаг не требует переписывания сабагентов, даёт общую схему ответа и проверку вывода против реальных данных. Заодно — базовая линия на eval.

Часть проблем остаётся: у каждого специалиста свой промпт, контекст, команда-владелец и свои eval; каждый вызов возвращает пересказ с потерями; каждый вызов — вложенный модельный цикл, который добавляет задержку.

4. Вливание через скиллы и инструменты

Вливайте сабагентов по одному: промпты — в скиллы, вызовы API — в MCP-инструменты, каждый раз сравнивая eval с сабагентом и без. Смотрите не только на итоговый счёт, но и на то, какие задачи перевернулись. На тестовом агенте поддержки вливание одного сабагента в другой снизило задержку, но сломало проходивший процесс: основной агент сам отвечал по инструменту поиска заказа, не спросив у логистического специалиста дату доставки.

Поэтому перед каждым изменением проверяйте, что в eval есть задача на каждую продовую цепочку агентов и на каждое правило, которое нарушать нельзя. И прогоняйте каждую задачу больше одного раза — этот сбой проявился только в одном прогоне из двух.

Как несколько команд живут с одним агентом

Доменное знание теперь достаётся из баз знаний, скиллов и MCP-инструментов. Команды переносят владение с агентов на скиллы и инструменты, а центральная команда держит промпт и сквозное качество.

MCP-инструменты — правильный выбор, когда агенту нужно действие, чтение живых данных из системы или результат фиксированной формы. Группируйте инструменты по намерению пользователя, а не по одному инструменту на API: после 30–50 определений в системном промпте выбор начинает деградировать. Используйте tool search с отложенной загрузкой. Жёсткие предусловия переносите внутрь инструментов: если для Y нужен вывод X, инструмент Y сам это проверит и вернёт инструкцию, которую модель может исполнить. Права пользователя работают так же: инструмент проверяет, что вызывающему можно, и возвращает понятный отказ — один цикл обслуживает пользователей с разными правами.

Скиллы — правильный выбор, когда агенту нужно знать, как команда делает работу: шаги, правила, оценочные суждения из промпта бывшего специалиста. Anthropic возвращает поддержку тем, кто пишет скиллы, а Claude сам может собирать, тестировать и чистить их. У каждой команды — свой DRI по скиллам. От размножения спасают два инструмента: /skill-creator создаёт новые скиллы и аудитирует существующие, а /skill-doctor показывает стоимость и частоту использования каждого и помогает удалить мёртвый груз.

Базы знаний — для справочного материала, который нужен лишь иногда: политики, определения метрик, спецификации продуктов. Они живут за поисковым инструментом или как справочные файлы внутри скилла. Антипаттерн — когда код достаёт контекст и вставляет его в промпты.

Инструменты для миграции

Anthropic выпустила миграционный набор — single-agent-loop-kit на GitHub: рабочий процесс по оценке и переводу мультиагентной системы на один цикл, с демо для обкатки на макетной системе. Внутри — несколько скиллов для Claude API:

• /claude-api build-eval — создание первого сквозного набора eval или маленьких наборов под каждый скилл.
• /claude-api prompt-audit — находит в промптах, скиллах и описаниях инструментов инструкции, написанные для старых моделей, и предлагает правки диффом.
• /claude-api hillclimb — итеративно улучшает приложение против существующего eval, в том числе сравнение «влитый вариант против сабагента».
• /claude-api cost-optimize — профилирует, куда уходят вызовы, и предлагает экономию: кэширование промптов, обрезка лишних токенов, выбор усилий и модели.

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