Что такое субагенты?
В мире разработки систем на основе больших языковых моделей (LLM), таких как Claude, часто возникает необходимость выполнять сложные задачи, которые требуют нескольких шагов, специализированных знаний или доступа к различным инструментам. Для решения этой проблемы используются субагенты — это специализированные AI-агенты, каждый из которых предназначен для выполнения конкретной функции или подзадачи в рамках более крупной системы. Представьте себе главного агента как менеджера проекта, который делегирует задачи команде экспертов (субагентам), каждый из которых обладает уникальными навыками.
Создание субагента обычно включает в себя определение его роли, предоставление ему набора инструкций (через системный промпт) и, при необходимости, доступа к определенным инструментам (например, для поиска в интернете, выполнения кода, чтения или записи файлов). Однако простое создание субагентов не гарантирует их эффективности. Чтобы они работали слаженно, предсказуемо и приносили реальную пользу, необходимо применять определенные паттерны проектирования.
Как главный агент взаимодействует с субагентами
В основе эффективного взаимодействия между главным агентом и его субагентами лежит их правильная конфигурация. Когда главный агент получает запрос, он должен решить, какой субагент (если таковой имеется) лучше всего подходит для выполнения текущей задачи. Это решение принимается на основе имени и описания каждого доступного субагента, которые включаются в системный промпт главного агента. Таким образом, эти элементы являются вашими основными рычагами управления тем, когда и какой субагент будет запущен автоматически.
Описание субагента играет двойную роль. Во-первых, оно помогает главному агенту определить, когда следует делегировать задачу именно этому субагенту. Во-вторых, когда главный агент запускает субагента, он формирует входной промпт для начала работы. Описание субагента служит руководством для создания этого промпта. Это означает, что описание не только контролирует, когда субагент запускается, но и что именно ему будет поручено делать.
Четыре ключа к эффективным субагентам
Плохо сконфигурированный субагент может "блуждать", работать слишком долго или выдавать результаты, которые главный агент не сможет использовать. Чтобы избежать этих проблем, сосредоточьтесь на четырех ключевых аспектах:
- Написание четких и информативных описаний.
- Определение структурированного формата вывода.
- Отчетность о препятствиях.
- Ограничение доступа к инструментам.
1. Четкие и информативные описания
Как уже упоминалось, описание субагента — это не просто метка; это мощный инструмент, который направляет как главного агента, так и самого субагента. Хорошо написанное описание гарантирует, что субагент будет вызван в нужный момент и получит точные инструкции для выполнения своей задачи.
Рассмотрим пример субагента для Code Review (проверки кода). С общим описанием главный агент может создать входной промпт вроде: "используй get diff, чтобы найти текущие изменения". Это слишком расплывчато. Субагенту придется самостоятельно выяснять, какие файлы важны для анализа, что может привести к неэффективности или ошибкам.
Однако, если вы обновите описание, включив в него что-то вроде: "Вы должны точно указать агенту, какие файлы вы хотите, чтобы он проверил", главный агент теперь создаст гораздо более конкретный входной промпт, который будет содержать список актуальных файлов для проверки. Этот же принцип работает для различных типов субагентов. Например, добавление фразы "возвращай источники, которые можно цитировать" в описание субагента для Web Search заставит главного агента включить эту инструкцию при делегировании задачи, обеспечивая получение более качественных и проверяемых результатов.
2. Определение структурированного формата вывода
Самое важное улучшение, которое вы можете внести в работу субагента, — это определение четкого и структурированного формата вывода в его системном промпте. Это решает две ключевые проблемы:
- Создает естественные точки остановки: Субагент знает, что его работа завершена, когда он заполнил все разделы определенного формата. Это предотвращает излишнюю генерацию и "блуждание".
- Предотвращает слишком долгую работу: Без определенного формата вывода субагенты часто испытывают трудности с решением, когда достаточно исследований было проведено, и, как правило, работают гораздо дольше, чем необходимо, потребляя лишние
token'ы и время.
Вот пример структурированного формата вывода для субагента Code Review:
Предоставьте свой обзор в структурированном формате:
1. Резюме: Краткий обзор того, что было проверено, и общая оценка.
2. Критические проблемы: Любые уязвимости безопасности, риски целостности данных или логические ошибки, которые должны быть немедленно исправлены.
3. Серьезные проблемы: Проблемы качества, несоответствие архитектуре или значительные проблемы с производительностью.
4. Мелкие проблемы: Несоответствия стилю, пробелы в документации или незначительные оптимизации.
5. Рекомендации: Предложения по улучшению, возможности рефакторинга или лучшие практики для применения.
6. Статус одобрения: Четкое заявление о том, готов ли код к слиянию/развертыванию или требует изменений.
Этот формат предоставляет субагенту четкий контрольный список для работы. Как только каждый раздел заполнен, субагент знает, что может остановиться, и главный агент получает предсказуемый и легко обрабатываемый результат.
3. Отчетность о препятствиях
Когда субагент обнаруживает обходное решение или сталкивается с проблемой во время своей работы — например, решает проблему с зависимостями или выясняет, что определенная команда требует особых флагов — эти детали должны быть включены в возвращаемое им резюме. Если они не будут сообщены, главному агенту придется самостоятельно заново открывать те же решения, что приводит к потере времени и token'ов.
Типы информации, которую вы хотите получить на поверхность, включают:
- Проблемы с настройкой или особенности среды.
- Обходные пути, обнаруженные во время выполнения задачи.
- Команды, которым требовались специальные флаги или конфигурация.
- Зависимости или импорты, вызвавшие проблемы.
Лучший способ получить эту информацию — явно запросить ее в формате вывода. Добавление раздела "Возникшие препятствия" в ваш шаблон вывода надежно выведет эту информацию на поверхность.
...
6. Статус одобрения: Четкое заявление о том, готов ли код к слиянию/развертыванию или требует изменений.
7. Возникшие препятствия: Сообщите о любых препятствиях, возникших в процессе проверки. Это могут быть: проблемы с настройкой, обнаруженные обходные пути или особенности среды. Сообщите о командах, которым требовался специальный флаг или конфигурация. Сообщите о зависимостях или импортах, вызвавших проблемы.
4. Ограничение доступа к инструментам
Не каждому субагенту нужен доступ ко всем инструментам. Подумайте о том, что субагент на самом деле должен делать, и предоставьте ему только те инструменты, которые необходимы для этой работы. Это дает два преимущества: предотвращает непреднамеренные побочные эффекты и делает роль каждого субагента более ясной, особенно когда у вас их несколько.
Вот как можно подходить к вопросу доступа к инструментам для распространенных типов субагентов:
- Субагент для исследования / только для чтения (Research / read-only subagent): Ему нужен доступ только к инструментам для чтения информации (например,
web_search,read_file). Он не может случайно изменить файлы или выполнить деструктивные действия. - Субагент для проверки кода (Code Review agent): Может нуждаться в доступе к инструментам для чтения файлов, просмотра изменений (например,
git diff), но, как правило, не должен иметь возможности изменять код напрямую. - Субагент для стилизации / модификации кода (Styling / code modification agent): Именно здесь вы предоставляете доступ к инструментам для записи и изменения файлов (например,
write_file,apply_patch), потому что задача этого субагента — фактически изменять ваш код.
Тщательно контролируя доступ к инструментам, вы повышаете безопасность, предсказуемость и надежность вашей системы агентов.
Заключение: Создание предсказуемых и целенаправленных субагентов
Эффективные субагенты обладают четырьмя общими характеристиками, которые, хотя и просты по отдельности, вместе превращают субагента из чего-то, что смутно пытается помочь, в сфокусированного, предсказуемого работника, который завершает работу вовремя и четко отчитывается:
- Специфические описания: Описание контролирует, когда субагент запускается и какие инструкции он получает. Пишите его так, чтобы направлять оба этих аспекта.
- Структурированный вывод: Определите формат вывода в системном промпте, чтобы субагент знал, когда он закончил, и возвращал информацию, которую главный агент может использовать.
- Отчетность о препятствиях: Включите раздел в формат вывода для обходных путей, особенностей и проблем, чтобы главному агенту не приходилось заново их обнаруживать.
- Ограниченный доступ к инструментам: Предоставляйте субагенту только те инструменты, которые ему действительно необходимы. Только для чтения для исследований,
bashдля проверяющих, редактирование/запись только для агентов, которые должны изменять код.
Применяя эти принципы, вы сможете создавать мощные, надежные и легко управляемые системы AI-агентов на базе Claude, способные эффективно решать сложные задачи.