Создание агентов: Когда следует включать субагентов в основной цикл агентов?

При создании агентов в Claude Platform использование меньшего количества субагентов в пользу постепенно раскрываемого контекста и инструментов может повысить качество, одновременно снижая затраты и задержку. Вот когда и как следует перейти на эту платформу.

Если вы создали агента в Claude Platform, который включает в себя несколько подагентов, посмотрите, какие из них целесообразнее интегрировать в основной цикл агента, используя наш комплект для миграции . Он запускает пошаговый рабочий процесс для выявления ваших шаблонов, оценки альтернатив и проверки наилучшего подхода. В комплект входит демонстрационная версия, которую вы можете протестировать на тестовой системе, прежде чем запускать ее на своем агенте.

Субагенты — агенты со своим собственным контекстным окном, инструментами и инструкциями, управляемые координатором , — являются ключевым компонентом проектирования агентов. Они эффективны для проверки, параллельной работы и модульного распределения прав доступа. Мы используем их во многих наших собственных агентах, которые мы создаем с помощью платформы Claude, например, в нашей многоагентной исследовательской системе .

Однако недавно команда Applied AI обнаружила закономерность в развертывании корпоративных агентов, которые выигрывают от включения маршрутизаторов, планировщиков и субагентов домена в основной цикл работы агентов. В наших сравнениях в нескольких корпоративных развертываниях один агент с определенными навыками часто превосходил как схему с одним запросом для всего , так и схему с субагентами по качеству, причем зачастую с меньшими затратами и задержкой на задачу.

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

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

В таких случаях часто поступает обратная связь о том, что большая часть этой структуры выполняла работу, которая больше не требовалась для модели, и что одной четкой системной подсказки, 4-5 простых инструментов для работы с данными и четких ограничений по выводу данных будет достаточно для большинства вариантов использования.

Следует уточнить, что суб-агенты по-прежнему востребованы, в том числе и на переднем крае научных исследований. Используйте их, когда:

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

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

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

Примеры ошибок при создании агентов в крупных организациях

Компании часто стремятся создать агента, который объединяет множество продуктов и возможностей в единый пользовательский интерфейс.

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

Это кажется самым простым решением, но сразу же вносит сложности в следующие аспекты:

• Управление контекстом: Вам необходимо определить, какой контекст будет использоваться для обмена данными между агентами, и часто при обмене данными теряются некоторые детали.
• Разрастание субагентов : Каждая команда отправляет своего собственного субагента, поэтому в итоге у компаний оказываются сотни пересекающихся субагентов без установленных стандартов и без конкретного владельца.
• «Франкенподсказка» : каждая команда добавляет предложение к системной подсказке, что приводит к противоречивым правилам и отсутствию единого стиля речи.
• Непроверенные, чрезмерно локализованные оценки : каждый добавляет свои собственные оценки, которые чрезмерно оптимизированы для его подзадачи. Никто не владеет и не поддерживает весь набор оценок, и руководство принимает решения, основываясь на заниженных, чрезмерно локализованных оценках.
• Задержка : Сложная архитектура многоагентной системы увеличивает задержку. Один из клиентов, сравнивший свою многоагентную систему с системой на основе одного агента, отметил примерно в 2 раза более быстрое время выполнения в последнем случае.

Использование агентского цикла с поэтапным раскрытием информации.

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

Существует три причины, по которым такой подход может быть целесообразным:

• Общий контекст обеспечивает лучшие результаты: для агентов, работающих в течение длительного времени, нам нужен контекст из нескольких разных задач, который будет находиться в главном окне контекста. Агент, который видел результаты каждого предыдущего шага, может связать их, что приводит к более полным результатам и лучшему пониманию, чем набор сводок, передаваемых субагентами. Это также означает меньшее количество окон контекста и меньшее количество потерь при передаче данных .
• Постепенное раскрытие информации предотвращает раздувание контекста: этот метод позволяет командам создавать отдельных агентов, способных выполнять широкий спектр задач, без необходимости немедленной загрузки всего контекста в один длинный системный запрос. Это устраняет основную причину, по которой команды ранее разделяли работу между субагентами. Фактически, мы сократили системный запрос Клода Кода для более сложных моделей более чем на 80%, включая сокращения, связанные с постепенным раскрытием навыков и инструментов.
• Модели стали более функциональными: начиная с Opus 4.5, модели смогли обрабатывать гораздо больше задач за один цикл, чем ожидало большинство команд. В Opus 5.5 и Fable 5.1 невозможно отключить мыслительный процесс, а новые модели все чаще описывают свой прогресс и проверяют свою работу по ходу выполнения, что делает некоторые элементы среды разработки избыточными. Каждая новая модель позволяет перенести большую часть принятия решений из среды разработки в саму модель. Более простой цикл также облегчает переход к следующей модели; в миграциях, в которых мы помогали клиентам, жесткие многоагентные структуры часто мешали новой модели выполнять большую часть работы.

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

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

Если вы выберете многоагентную модель, начните с самой простой схемы (генератор-верификатор, оркестратор-субагент или другая), которая может сработать. Эффективно разложите границы, разделив систему по контексту: дайте каждому субагенту задачу, которая мало что требует от остальной системы, и пусть он возвращает компактный результат (хорошими кандидатами являются независимые пути исследования, отдельные компоненты с понятными интерфейсами или проверка методом «черного ящика»). Когда агенты разделены по типу задачи, они участвуют в «испорченном телефоне», передавая информацию туда и обратно, при этом каждая передача ухудшает точность.

Как интегрировать субагентов в основной цикл работы агентов

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

• Одна модель и одно контекстное окно, в которых выполняется цикл обработки данных без ограничений, с настройками ограничений (бюджеты оборотов и затрат, пороги записи), заданными в программном обеспечении.
• На каждом этапе модель генерирует пакет вызовов инструментов. Система обрабатывает их параллельно и возвращает необработанные результаты той же модели, которая принимает решение о следующем шаге: следующий пакет, вопрос пользователю или ответ.
• Цикл останавливается, когда модель отвечает или достигает заданного бюджета . После ответа может быть дополнительно выполнена проверка цели или верификатора.
• Модель составляет свой план в контексте первого хода и корректирует его по мере поступления результатов. Это главное отличие от схемы с оркестратором и специализированными агентами: модель, которая составляет план, также его и выполняет, поэтому она может изменить план в середине хода.
• Контекст по-прежнему загружается и управляется самим агентом:
  • Шаг кода, переписывающий план на основе каталога правил, больше не нужен, поскольку модель принимает решения на каждом шаге.
  • Порядок и процедуры предметной области переходят в область навыков.
  • Жесткие ограничения (проверка данных, контрольные точки подтверждения) и все остальное, что возникает в процессе обсуждения (например, поиск в памяти), переносятся в соответствующие инструменты.
  • Код по-прежнему можно использовать для загрузки чего угодно недорогого и почти всегда актуального (например, этапа разрешения сущностей), а также для обработки любых механических частей (построение полезной нагрузки, анализ потока, возобновление уточнения) внутри инструментов, вызываемых циклом.

Такая конструкция с одним циклом также помогает достичь конечного результата, к которому стремятся многие команды (агент, который понимает основные цели пользователя и действует от его имени), поскольку она объединяет все полученные агентом знания в одном контексте.

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

Оценка выполнения заданий

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

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

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

Сокращение числа субагентов с течением времени.

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

Объединение доменных агентов

Перед первым слиянием проведите небольшую сквозную оценку. Затем выполните объединение по общему контексту, начиная с субагентов, которые наиболее полезны.

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

Суб-агенты, называемые инструментами

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

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

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

Однако некоторые виды отказов сохранятся:

• У каждого специалиста свои задачи, контекст, команда ответственных лиц и критерии оценки.
• Каждый звонок по-прежнему возвращает сводку с потерями.
• Каждый вызов представляет собой вложенный цикл модели, который увеличивает задержку.

Интеграция субагентов в основного агента посредством навыков и инструментов.

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

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

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

Как несколько команд могут вносить свой вклад в работу одного агента.

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

Инструменты MCP

Инструменты идеально подходят, когда агенту необходимо выполнить действие, считать данные в реальном времени из системы или вернуть результат в фиксированном формате. Вы также можете использовать инструменты для постоянного вызова субагентов во время миграции. Мы рекомендуем группировать инструменты по намерениям пользователя (а не использовать один инструмент на каждый API), поскольку при превышении 30-50 определений инструментов в системном запросе выбор инструментов, как правило, уменьшается.

Используйте поиск инструментов с отложенной загрузкой, ограничьте жесткие предварительные условия и переместите все необходимые в инструменты. Например, если Y требует вывода X, инструмент Y проверяет его и возвращает инструкцию, которую модель может выполнить. Разрешения для каждого пользователя работают аналогично. Каждый инструмент проверяет, что может видеть или делать вызывающий пользователь, и возвращает простой отказ, который модель может прочитать, поэтому один цикл может обслуживать пользователей с разным уровнем доступа без отдельного агента для каждого уровня разрешений.

Навыки

Навыки необходимы, когда агенту нужно знать, как работает команда, например, этапы, правила и решения, которые раньше принимал специалист-субъект.

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

Чтобы предотвратить разрозненность навыков, можно назначить ответственных за разработку навыков (DRI) в каждой команде, которые будут отвечать за свои навыки, следить за тем, чтобы они были хорошо проработаны, отличались друг от друга и поставлялись с соответствующими оценками.

• /skill-creator позволяет создавать новые навыки с нуля, а также проводить аудит существующих, чтобы их оптимизировать, удалить дубликаты и реструктурировать.
• Команда /skill-doctor позволяет увидеть стоимость каждого навыка в вашей библиотеке и частоту его фактического использования, а также удалить ненужные навыки.

Базы знаний

Базы знаний идеально подходят для справочных материалов, которые агенту нужны лишь иногда. Факты и справочные материалы (политики, определения метрик, спецификации продуктов) могут храниться за инструментом поиска или поиска, который вызывает модель, или поставляться в виде справочных файлов внутри навыка. Избегайте использования кода для извлечения и вставки этого контекста в подсказки .

Инструменты для ускорения этой работы

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

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

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

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

Телеграм: t.me/ainewsline

Источник: claude.com

Комментарии: