Теперь, когда вы знаете, как создавать подагентов, рассмотрим шаблоны, которые делают их действительно эффективными. Плохо настроенный подагент может блуждать, работать слишком долго или выдавать результаты, которые основной агент не может использовать. Решения сводятся к четырём вещам: написанию хороших описаний, определению формата вывода, отчёту о препятствиях и ограничению доступа к инструментам.
Как данные конфигурации подагентов используются
Когда вы отправляете сообщение основному агенту в контекстном окне, имя и описание каждого доступного подагента включаются в системный промт. Именно так основной агент решает, какой подагент запустить и когда. Если вы хотите лучше контролировать автоматический запуск подагента, настройте именно имя и описание.
Описание также выполняет вторую роль. Когда основной агент запускает подагент, он формирует входной промт для начала выполнения задачи. Для написания этого промта он использует описание как руководство. Таким образом, описание не только контролирует запуск подагента — оно формирует то, что подагенту поручено сделать.
Написание описаний, формирующих входные промты
Рассмотрим подагента для ревью кода. При общем описании основной агент может сформировать входной промт вроде «используй get diff, чтобы найти текущие изменения». Это слишком расплывчато. Подагенту придётся самому разбираться, какие файлы имеют значение.
Если вы добавите в описание что-то вроде «вы должны точно указать, какие файлы нужно ревьюировать», основной агент сформирует гораздо более конкретный входной промт, в котором будут перечислены сами файлы для ревью.
Этот же метод работает для разных типов подагентов. Например, добавление в описание подагента для поиска в интернете фразы «возвращайте источники, которые можно цитировать» заставит основной агент включить это указание при делегировании задачи.
Определение формата вывода
Самое важное улучшение, которое вы можете сделать для подагента, — это определение формата вывода в его системном промте. Это делает две вещи:
- Создаёт естественные точки остановки — подагент знает, что завершил работу, когда заполнил все разделы формата.
- Предотвращает слишком долгую работу подагента. Без определённого формата подагенты с трудом понимают, когда достаточно исследований проведено, и склонны работать гораздо дольше, чем нужно.
Вот пример структурированного формата вывода для подагента ревью кода:
Предоставьте ревью в структурированном формате:
- Краткое резюме: краткий обзор того, что было ревьюировано, и общая оценка
- Критические проблемы: любые уязвимости безопасности, риски целостности данных или логические ошибки, которые нужно исправить немедленно
- Серьёзные проблемы: проблемы с качеством, несоответствие архитектуры или значительные проблемы с производительностью
- Незначительные проблемы: несоответствия стиля, пробелы в документации или незначительные оптимизации
- Рекомендации: предложения по улучшению, возможности рефакторинга или лучшие практики для применения
- Статус одобрения: чёткое указание, готов ли код к слиянию/развёртыванию или требует изменений
Этот формат даёт подагенту чёткий контрольный список для работы. Как только все разделы заполнены, подагент знает, что может завершить работу.
Отчёт о препятствиях
Когда подагент обнаруживает обходной путь во время работы — например, решает проблему с зависимостями или выясняет, что для определённой команды нужны особые флаги, — эти детали должны появиться в итоговом отчёте. Если этого не сделать, основной поток вынужден будет заново искать те же решения, что тратит время и токены.
Вот что нужно выносить на поверхность:
- Проблемы настройки или особенности окружения
- Обходные пути, обнаруженные во время выполнения задачи
- Команды, для которых нужны особые флаги или конфигурации
- Зависимости или импорты, вызвавшие проблемы
Чтобы получить эту информацию, нужно явно запросить её в формате вывода. Добавление раздела «Встреченные препятствия» в шаблон вывода надёжно выводит эту информацию на поверхность.
- Встреченные препятствия: отчёт о любых препятствиях, с которыми столкнулись во время ревью. Это могут быть: проблемы настройки, обнаруженные обходные пути или особенности окружения. Укажите команды, для которых нужны особые флаги или конфигурации. Укажите зависимости или импорты, вызвавшие проблемы.
Ограничение доступа к инструментам
Не каждому подагенту нужен доступ ко всем инструментам. Подумайте, что подагент действительно должен делать, и давайте ему только те инструменты, которые необходимы для этой задачи. Это делает две вещи: предотвращает непреднамеренные побочные эффекты и делает роль каждого подагента более понятной, когда их несколько.
Вот как можно подумать о доступе к инструментам для распространённых типов подагентов:
- Исследовательский / только для чтения подагент — нужен только Glob, Grep и Read. Не может случайно изменить файлы.
- Подагент для ревью кода — нужен доступ к Bash для запуска git diff и просмотра изменений, но не нужен Edit или Write.
- Подагент для стилизации / модификации кода — здесь вы даёте доступ к Edit и Write, потому что задача подагента — действительно изменять ваш код.
Собираем всё вместе
Эффективные подагенты обладают четырьмя характеристиками:
- Конкретные описания — описание контролирует запуск подагента и инструкции, которые он получает. Пишите его так, чтобы направлять и то, и другое.
- Структурированный вывод — определите формат вывода в системном промте, чтобы подагент знал, когда завершить работу, и возвращал информацию, которую может использовать основной поток.
- Отчёт о препятствиях — включите в формат вывода раздел для обходных путей, особенностей и проблем, чтобы основной поток не пришлось искать их заново.
- Ограниченный доступ к инструментам — давайте подагенту только те инструменты, которые ему действительно нужны. Только для чтения для исследователей, Bash для ревьюеров, Edit/Write только для агентов, которые должны изменять код.
Каждый из этих шаблонов сам по себе прост, но вместе они превращают подагента из того, кто смутно пытается помочь, в сосредоточенного, предсказуемого исполнителя, который завершает работу вовремя и чётко отчитывается.