Шаблоны оркестрации агентов ИИ

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

Начните с правильного уровня сложности

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

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

Обзор

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

• Специализация: Отдельные агенты могут сосредоточиться на определенном домене или возможности, что снижает сложность кода и запроса.

• Масштабируемость: Агенты можно добавлять или изменять без перепроектирования всей системы.

• Ремонтопригодность: Тестирование и отладка можно сосредоточить на отдельных агентах, что снижает сложность этих задач.

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

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

Последовательная оркестрация

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

Также известен как пайплайн, цепочка подсказок, линейное делегирование.

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

Когда следует использовать последовательную оркестрацию

Рассмотрим шаблон последовательной оркестрации в следующих сценариях:

• Многоэтапные процессы, имеющие четкие линейные зависимости и прогнозируемое прогрессирование рабочих процессов

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

• Этапы рабочего процесса, которые не могут быть параллелизованы

• Прогрессивные требования к уточнению, такие как черновик, обзор, полировка рабочие процессы

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

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

Избегайте этого шаблона в следующих сценариях:

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

• Процессы, которые включают всего несколько этапов, которые один агент ИИ может эффективно выполнять.

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

• Агенты ИИ должны сотрудничать, а не отдавать работу.

• Рабочий процесс требует обратного отслеживания или итерации.

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

Пример последовательной оркестрации

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

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

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

3. Агент соответствия нормативным требованиям проверяет настраиваемый контракт в соответствии с применимыми законами и отраслевыми правилами.

4. Агент оценки рисков выполняет комплексный анализ полного контракта. Он оценивает механизмы воздействия ответственности и разрешения споров при предоставлении рейтингов рисков и рекомендаций по защите языка.

Параллельная оркестрация

Шаблон параллельной оркестрации выполняет несколько агентов ИИ одновременно с одной задачей. Такой подход позволяет каждому агенту предоставлять независимый анализ или обработку с уникальной точки зрения или специализации.

Также известно: parallel, fan-out/fan-in, точечная сборка, map-reduce.

В этом шаблоне рассматриваются сценарии, в которых требуется разнообразная аналитика или подходы к одной и той же проблеме. Вместо последовательной обработки все агенты работают параллельно, что сокращает общее время выполнения и обеспечивает комплексное покрытие проблемного пространства. Этот шаблон оркестрации напоминает шаблон проектирования Fan-out/Fan-in для облачных технологий. Результаты каждого агента часто агрегируются для возврата окончательного результата, но это не обязательно. Каждый агент может независимо создавать собственные результаты в рабочей нагрузке, например вызывать средства для выполнения задач или обновлять различные хранилища данных параллельно. Если требуется агрегирование, выберите стратегию, которая соответствует задаче: голосование или правило большинства для классификации, взвешенное слияние для оцененных рекомендаций, или сводка, синтезированная моделью LLM, когда результаты должны быть согласованы в целостное повествование.

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

Когда использовать параллельную оркестрацию.

Рассмотрим шаблон параллельной оркестрации в следующих сценариях:

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

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

  • Мозговой штурм

  • Аргументирование ансамбля

  • Решения на основе кворума и голосования

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

Когда следует избегать параллельной оркестрации

Избегайте этого шаблона оркестрации в следующих сценариях:

• Агенты должны основываться на работе друг друга или требовать комплексный контекст в определенной последовательности.

• Задача требует определенного порядка операций или детерминированных, воспроизводимых результатов выполнения в определенной последовательности.

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

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

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

• Логика агрегирования результатов слишком сложна или снижает качество результатов.

Пример параллельной оркестрации

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

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

• Фундаментальный агент анализа оценивает финансовые показатели, тенденции доходов и конкурентное положение для оценки внутренней ценности.

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

• Агент анализа тональности обрабатывает новостные статьи, упоминания в социальных сетях и аналитические отчеты, чтобы оценить тональность рынка и уверенность инвесторов.

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

Эти независимые результаты затем объединяются в комплексную рекомендацию по инвестициям, которая позволяет менеджерам портфеля быстро принимать обоснованные решения.

Оркестрация группового чата

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

Также известен как круглый стол, совместные, многоагентные дебаты, совет.

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

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

Когда следует использовать оркестрацию группового чата

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

Сценарии совместной работы

• Творческие сеансы мозгового штурма, где агенты с разными перспективами и источниками знаний опираются на вклад друг друга в чат

• Процессы принятия решений, которые получают выгоду от дебатов и консенсуса

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

• Многодисциплинарные проблемы, требующие межфункционального диалога

Сценарии проверки и контроля качества

• Требования к обеспечению качества, связанные с структурированным процессом проверки и итерацией

• Проверка соответствия и нормативного регулирования, требующая мнения нескольких экспертов

• Рабочие процессы создания контента, требующие редактирования, с четким разделением проблем между созданием и проверкой

Когда избежать оркестрации группового чата

Избегайте этого шаблона в следующих сценариях:

• Достаточно простого делегирования задач или линейной обработки конвейера.

• Требования к обработке в режиме реального времени делают обсуждение неприемлемым.

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

• Диспетчер чата не имеет объективного способа определить, завершена ли задача.

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

Циклы проверки Maker

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

Также известный как: оценщик-оптимизатор, генератор-проверяющий, цикл критика, цикл отражения.

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

Пример оркестрации группового чата

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

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

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

• Агент по планированию окружающей среды оценивает экологические последствия, меры устойчивости, смещение растительности и соответствие экологическим нормам.

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

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

Оркестрация передачи задач

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

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

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

Когда следует использовать оркестрацию передачи

Рассмотрим шаблон передачи агента в следующих сценариях:

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

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

• Проблемы с несколькими доменами, требующие разных специалистов, которые работают одновременно

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

Когда избегать оркестрации передачи управления

Избегайте этого шаблона в следующих сценариях:

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

• Маршрутизация задач детерминирована и основана на правилах, а не на основе динамического окна контекста или динамической интерпретации.

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

• Для решения задачи следует одновременно выполнять несколько операций.

• Избегать бесконечного цикла передачи полномочий или чрезмерного переключения между агентами — непростая задача.

Пример шаблона передачи агента

Решение для управления отношениями с клиентами (CRM) в области телекоммуникаций использует агентов переадресации на веб-портале поддержки клиентов. Первоначальный агент начинает оказывать помощь клиентам, но обнаруживает, что ему требуется специфический опыт во время беседы. Первоначальный агент передает задачу наиболее подходящему агенту для решения проблем клиента. Только один агент за раз работает с исходными входными данными, а цепочка передачи приводит к одному результату.

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

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

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

Магентическая оркестрация

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

Также называется: динамическая оркестрация, оркестрация на основе реестра задач, адаптивное планирование.

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

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

Когда следует использовать магнитную оркестрацию

Рассмотрим магнитный узор в следующих сценариях:

• Сложный или открытый вариант использования, не имеющий предопределенного пути решения.

• Требование рассмотреть возможность ввода и обратной связи с несколькими специализированными агентами для разработки допустимого пути решения.

• Требование к системе ИИ создать полностью разработанный план подхода, который человек может просмотреть до или после реализации.

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

Когда избегать магнитной оркестрации

Избегайте этого шаблона в следующих сценариях:

• Путь решения разработан или должен быть реализован детерминированно.

• Нет необходимости создавать реестр.

• Задача имеет низкую сложность, и более простой шаблон может решить его.

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

• Вы ожидаете частые остановки или бесконечные циклы, которые не имеют четкого пути к разрешению.

Пример магнитной оркестрации

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

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

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

2. На основе результатов диагностики агент диспетчера обновляет реестр задач с определенными этапами исследования и обращается к агенту инфраструктуры , чтобы понять текущее состояние системы и доступные варианты восстановления.

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

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

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

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

Выбор шаблона

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

Вопросы реализации

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

Один агент, мультитул

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

Детерминированная маршрутизация

Для некоторых шаблонов требуется маршрутизировать поток между агентами детерминированным образом. Другие полагаются на агентов, чтобы выбрать собственные маршруты. Если агенты определены в среде без кода или с низким кодом, вы можете не контролировать это поведение. Если вы определяете агенты в коде с помощью пакетов SDK, таких как Microsoft Agent Framework или Semantic Kernel, у вас есть больше управления.

Управление контекстом и состоянием

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

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

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

Reliability

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

• Реализуйте механизмы времени ожидания и повторных попыток.

• Добавьте механизм плавной деградации для обработки одного или нескольких агентов при сбое шаблона.

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

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

• Рассмотрим шаблоны прерывателя цепи для зависимостей агента.

• Агенты должны быть изолированы друг от друга максимально, насколько это возможно, без совместных точек отказа между ними. Рассмотрим пример.

  • Убедитесь в обеспечении изоляции вычислений между агентами.

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

• Используйте функции контрольных точек, доступные в вашем SDK, чтобы восстановиться после прерывания оркестрации, например, из-за сбоя или нового развертывания кода.

Безопасность

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

• Реализуйте проверку подлинности и используйте безопасную сеть между агентами.

• Учитывайте последствия для конфиденциальности данных в коммуникациях с агентами.

• Проектируйте аудиторские записи для соответствия нормативным требованиям.

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

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

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

Оптимизация затрат

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

Чтобы управлять затратами в многоагентных оркестрациях:

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

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

• Применение контекстного сжатия между агентами для уменьшения объема маркеров, передаваемого через оркестрацию, как описано в разделе "Контекст" и "Управление состоянием".

Наблюдаемость и тестирование

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

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

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

• Разработка тестируемых интерфейсов для отдельных агентов.

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

Участие человека

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

Распространенные ловушки и антишаблоны

Избегайте этих распространенных ошибок при реализации шаблонов оркестрации агентов:

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

• Добавление агентов, которые не обеспечивают значимую специализацию.

• Пренебрежение влиянием задержки на многоступенчатую связь.

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

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

• Использование недетерминированных шаблонов для рабочих процессов, которые по сути детерминируются.

• Игнорируя ограничения ресурсов при выборе параллельной оркестрации.

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

Объединение шаблонов оркестрации

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

Связь с шаблонами проектирования облака

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

Реализации

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

Microsoft Agent Framework

Microsoft Agent Framework — это пакет SDK с открытым кодом для создания оркестрации с несколькими агентами на платформе Майкрософт. Agent Framework обеспечивает встроенную поддержку шаблонов оркестрации, описанных в этой статье в качестве оркестрации рабочих процессов.

• Последовательная оркестрация
• Параллельная оркестрация
• Оркестрация группового чата
• Оркестрация передачи задач
• Магентическая оркестрация

Для практической реализации изучите примеры декларативного рабочего процесса Agent Framework на GitHub.

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

Служба агента Foundry

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

Другие платформы

Шаблоны оркестрации, описанные в этой статье, не относятся к пакетам SDK Майкрософт. Другие платформы, поддерживающие оркестрацию с несколькими агентами, включают LangChain, CrewAI и пакет SDK для агентов OpenAI. Каждая платформа имеет собственный подход к реализации этих шаблонов, и вы можете применить архитектурные рекомендации в этой статье независимо от выбранного пакета SDK.

Соавторы

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Основные авторы:

• Chad Kittel | Главный инженер по разработке программного обеспечения — Azure Patterns & Practices
• Clayton Siemens | Ведущий разработчик контента — Azure Шаблоны и Практики

Другие участники:

• Hemavathy Alaganandam | Главный инженер программного обеспечения
• James Ли | Data Scientist 2
• Ritesh Modi | Главный инженер программного обеспечения
• Махди Сетайеш | Главный инженер программного обеспечения
• Марк Тейлор | Главный инженер программного обеспечения
• Янив Вакнин | Старший технический специалист

Чтобы просмотреть закрытые профили LinkedIn, войдите в LinkedIn.

Следующий шаг