Шаблоны и лучшие практики многоагентной оркестрации

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

Встроенные агенты

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

Лучшая методика: встроенные агенты должны быть сосредоточены на одной задаче и хорошо тестироваться.

Подключенные агенты

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

Однако использование подключенных агентов требует тщательного управления:

  • Оркестрация: родительский оркестратор должен иметь четкие критерии для делегирования задач подключенному агенту. Оркестратор обычно делегирует выполнение, когда намерение пользователя совпадает с областью работы подключенного агента. Для облегчения этого процесса четко опишите назначение подключенного агента в конфигурации родительского. С точки зрения родительского агента весь подключенный агент должен рассматриваться как агентный "инструмент" с описанием.

  • Передача данных: вы должны управлять передачей данных. Решите, какой контекст от родительского агента передавать подключенному. Когда один агент вызывает другого, Copilot Studio по умолчанию передает историю разговора, чтобы подключенный агент понимал предыдущий контекст разговора. Вам также, возможно, придется передать определенные параметры. Например, если основной агент уже знает имя пользователя, он может отправить его подключенному агенту, чтобы не спрашивать снова.

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

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

Когда следует разделять агентов

Не создавайте отдельного агента для каждой подзадачи. Используйте отдельного агента, если подзадача:

  • Достаточно сложна, чтобы иметь собственный набор инструментов или знаний (другая предметная область)
  • Требует других правил управления или контроля доступа, чем основной агент
  • Может использоваться во многих основных агентах (то есть это как сервисный агент)

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

Лучшие практики для многоагентной оркестрации

Следующие лучшие практики применяются при написании инструкций для родительского агента и субагентов в многоагентной системе.

1. Принцип одного ответа

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

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

2. В инструкциях субагента должна быть объявлена его роль

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

  • Правильно: добавьте в инструкции каждого субагента: "Ты — субагент. НЕ отвечай пользователю напрямую. Твоя задача — искать информацию и возвращать свои результаты родительскому агенту. Родительский агент отвечает за всю коммуникацию с пользователем".
  • Неправильно: предполагать, что субагенты сами определяют схему оркестрации.

3. Используйте четкие, прямые формулировки в инструкциях

Всегда используйте директивные формулировки. Избегайте мягких или вежливых формулировок. Платформа внедряет системные инструкции, используя однозначные формулировки (ОБЯЗАТЕЛЬНО, НЕЛЬЗЯ, НИКОГДА). Инструкции, написанные мягко ("постарайся", "тебе стоит", "было бы хорошо"), теряют приоритет в случае конфликта.

  • Правильно: "НИКОГДА не отвечай пользователю напрямую. ТОЛЬКО возвращай свои выводы".
  • Правильно: "На каждый вопрос пользователя должен быть ровно один итоговый ответ".
  • Неправильно: "Старайся не отправлять сообщения пользователю, а вместо этого возвращай свои выводы."
  • Неправильно:: "В идеале нам нужно получить единый комбинированный ответ".

4. Используйте один источник знаний для каждого субагента (без пересечения)

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

  • Правильно: CA-1 выполняет поиск в источнике знаний A (например, HR-политиках). CA-2 выполняет поиск в источнике знаний Б (например, в ИТ-документации).
  • Неправильно: предоставлять обоим субагентам доступ к одним и тем же документам, таблицам Dataverse или сайтам SharePoint.
  • Примечание. Если у вас только один источник знаний, следует использовать одного агента с доступом к знаниям вместо разделения на двух субагентов. Многоагентная система приносит ценность только тогда, когда источники действительно разные.

5. Используйте точные и четкие описания для субагентов

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

  • Правильно: CA-1: "Ищет в документах по кадровой политике ответы на вопросы, связанные с сотрудниками". CA-2: "Ищет в базе знаний по ИТ ответы на вопросы по технической поддержке".
  • Неправильно давать обоим агентам одинаковое описание, если они обслуживают разные области знаний.
  • Неправильно: использовать универсальные описания вроде "Этот агент отвечает на вопросы".

6. Инструкции для родительского агента должны определять шаблон оркестрации

Скажите родительскому агенту, как оркестрировать субагентов. Не ограничивайтесь фразой "используй дочерних агентов". Родительскому агенту нужны четкие инструкции по схеме: вызвать агентов, дождаться результатов, объединить их, затем ответить.

  • Правильно: "Когда пользователь задает вопрос: 1. Вызови обоих дочерних агентов для сбора информации. 2. Дождись, пока оба дочерних агента вернут свои выводы. 3. Объедини результаты в единый ответ. 4. Предоставь пользователю ровно один ответ. Дочерние агенты не должны отвечать пользователю напрямую".
  • Неправильно: "Когда пользователь задает вопрос, вызови дочерних агентов, получи ответ из обоих источников и дай один объединенный ответ". (Слишком расплывчато. Инструкция не дает субагентам указания молчать.)

7. Включайте директиву "без прямого ответа" в делегирование задачи

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

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

8. Тестирование с использованием запросов из разных областей знаний

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

  • Правильно: использовать при тестировании запросы, не относящиеся ни к одной из областей знаний субагентов (например, спросить о погоде, когда агенты обрабатывают HR и ИТ).
  • Правильно: проверять, правильно ли родительский агент обрабатывает ситуацию, когда оба агента ничего не нашли.
  • Неправильно: использовать для тестирования только простейшие запросы, которые четко соответствуют области знаний одного из субагентов.

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

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

  • Правильно: писать инструкции вроде: "Если нужно разъяснение, задай пользователю вопрос и жди его ответа".
  • Неправильно: писать инструкции вроде "Информируй пользователя о возможных вариантах и дай ему возможность выбрать один из них." "Информируй" предполагает одностороннее сообщение, а "задай вопрос" — двустороннее взаимодействие.

Краткий контрольный список

# Проверка
1 В инструкциях родительского агента явно указано: "только я отвечаю пользователю"
2 В инструкциях каждого субагента указано: "не отвечай пользователю напрямую"
3 В инструкциях используются строгие директивные формулировки (ОБЯЗАТЕЛЬНО, НИКОГДА, ТОЛЬКО)
4 У каждого субагента уникальный, непересекающийся с другими субагентами источник знаний
5 Описания субагентов точные, четкие и конкретные
6 В инструкциях родительского агента определена вся схема оркестрации (вызвать → ждать → объединить → ответить)
7 Родительский агент передает "без прямого ответа" в контексте делегированной задачи
8 Тестирование с использованием запросов из разных областей знаний
9 В инструкциях субагентов корректно проведено различие между задаванием вопросов и информирование
  • Last updated on