Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Так как архитекторы и разработчики разрабатывают свою рабочую нагрузку, чтобы воспользоваться всеми преимуществами возможностей языковой модели, системы агентов ИИ становятся все более сложными. Эти системы часто превышают возможности одного агента, имеющего доступ ко многим средствам и источникам знаний. Вместо этого эти системы используют многоагентные оркестрации для надежной обработки сложных задач взаимодействия. В этом руководстве рассматриваются основные шаблоны оркестрации для архитектур с несколькими агентами и вы можете выбрать подход, соответствующий вашим требованиям.
Обзор
При использовании нескольких агентов ИИ можно разбить сложные проблемы на специализированные единицы работы или знаний. Вы назначаете каждой задаче выделенным агентам ИИ, имеющим определенные возможности. Эти подходы отражают стратегии, найденные в командной работе людей. Использование нескольких агентов обеспечивает несколько преимуществ по сравнению с монолитными решениями с одним агентом.
Специализация: Отдельные агенты могут сосредоточиться на определенном домене или возможности, что снижает сложность кода и запроса.
Масштабируемость: Агенты можно добавлять или изменять без перепроектирования всей системы.
Ремонтопригодность: Тестирование и отладка можно сосредоточить на отдельных агентах, что снижает сложность этих задач.
Оптимизация: Каждый агент может использовать различные модели, подходы к решению задач, знания, инструменты и вычисления для достижения результатов.
В этом руководстве показаны проверенные подходы к оркестрации нескольких агентов для совместной работы и достижения результата. Каждый шаблон оптимизирован для различных типов требований к координации. Эти шаблоны оркестрации агента ИИ дополняют и расширяют традиционные шаблоны облачного проектирования , устраняя уникальные проблемы координации автономных компонентов в возможностях рабочей нагрузки на основе ИИ.
Последовательная оркестрация
Последовательный шаблон оркестрации цепочек агентов ИИ в предопределенном линейном порядке. Каждый агент обрабатывает выходные данные предыдущего агента в последовательности, который создает конвейер специализированных преобразований.
Последовательный шаблон оркестрации решает проблемы, требующие пошаговой обработки, где каждый этап строится на предыдущем этапе. Он подходит для рабочих процессов, которые имеют четкие зависимости и улучшают качество выходных данных путем постепенного уточнения. Этот шаблон похож на шаблон проектирования каналов и фильтров облака, но использует агенты ИИ вместо настраиваемых компонентов обработки. Выбор того, какой агент вызывается далее, определяется детерминированным образом как часть рабочего процесса и не является выбором для агентов в процессе.
Когда следует использовать последовательную оркестрацию
Рассмотрим шаблон последовательной оркестрации в следующих сценариях:
Многоэтапные процессы, имеющие четкие линейные зависимости и прогнозируемое прогрессирование рабочих процессов
Конвейеры преобразования данных, в которых каждый этап добавляет определенное значение, от которого зависит следующий этап.
Этапы рабочего процесса, которые не могут быть параллелизованы
Прогрессивные требования к уточнению, такие как черновик, обзор, полировка рабочие процессы
Системы, в которых вы понимаете характеристики доступности и производительности каждого агента ИИ в конвейере, и где сбои или задержки в обработке одного агента ИИ доступны для выполнения общей задачи.
Когда следует избегать последовательной оркестрации
Избегайте этого шаблона в следующих сценариях:
Этапы предельно параллельные. Их можно параллелизировать, не ухудшая качество и избегая конфликта общего состояния.
Процессы, которые включают всего несколько этапов, которые один агент ИИ может эффективно выполнять.
Ранние этапы могут завершиться ошибкой или выдавать низкокачественные выходные данные, и нет разумного способа предотвратить обработку последующих шагов, используя накопленные ошибки в выходных данных.
Агенты ИИ должны сотрудничать, а не отдавать работу.
Рабочий процесс требует обратного отслеживания или итерации.
Требуется динамическая маршрутизация на основе промежуточных результатов.
Пример последовательной оркестрации
Программное обеспечение для управления документами юридической фирмы использует последовательные агенты для создания контракта. Интеллектуальные приложения обрабатывают запросы через конвейер из четырех специализированных агентов. Последовательные и предопределенные шаги конвейера гарантируют, что каждый агент работает с полными выходными данными предыдущего этапа.
Агент выбора шаблона получает спецификации клиента, такие как тип контракта, юрисдикция и стороны, участвующие, и выбирает соответствующий базовый шаблон из библиотеки фирмы.
Агент настройки предложения принимает выбранный шаблон и изменяет стандартные предложения на основе согласованных бизнес-условий, включая расписания оплаты и ограничения ответственности.
Агент соответствия нормативным требованиям проверяет настраиваемый контракт в соответствии с применимыми законами и отраслевыми правилами.
Агент оценки рисков выполняет комплексный анализ полного контракта. Он оценивает механизмы воздействия ответственности и разрешения споров при предоставлении рейтингов рисков и рекомендаций по защите языка.
Параллельная оркестрация
Шаблон параллельной оркестрации выполняет несколько агентов ИИ одновременно с одной задачей. Такой подход позволяет каждому агенту предоставлять независимый анализ или обработку с уникальной точки зрения или специализации.
В этом шаблоне рассматриваются сценарии, в которых требуется разнообразная аналитика или подходы к одной и той же проблеме. Вместо последовательной обработки все агенты работают параллельно, что сокращает общее время выполнения и обеспечивает комплексное покрытие проблемного пространства. Этот шаблон оркестрации напоминает шаблон проектирования Fan-out/Fan-in для облачных технологий. Результаты каждого агента часто агрегируются для возврата окончательного результата, но это не обязательно. Каждый агент может независимо создавать собственные результаты в рабочей нагрузке, например вызывать средства для выполнения задач или обновлять различные хранилища данных параллельно.
Агенты работают независимо и не отдают результаты друг другу. Агент может вызывать дополнительных агентов ИИ, используя собственный подход к оркестрации в рамках своей автономной обработки. Доступные агенты должны знать, какие агенты доступны для обработки. Этот шаблон поддерживает детерминированные вызовы для всех зарегистрированных агентов и динамического выбора агентов для вызова на основе требований задачи.
Использование параллельной оркестрации
Рассмотрим шаблон параллельной оркестрации в следующих сценариях:
Задачи, которые можно выполнять параллельно, с помощью фиксированного набора агентов или динамического выбора агентов ИИ на основе конкретных требований к задачам.
Задачи, которые получают преимущества от нескольких независимых перспектив или различных специализаций, таких как технические, деловые и творческие подходы, которые могут способствовать одной и той же проблеме. Эта совместная работа обычно выполняется в сценариях, которые содержат следующие методы принятия решений с несколькими агентами:
Мозговой штурм
Аргументирование ансамбля
Решения на основе кворума и голосования
Сценарии с учетом времени, в которых параллельная обработка уменьшает задержку.
Когда избежать параллельной оркестрации
Избегайте этого шаблона оркестрации в следующих сценариях:
Агенты должны основываться на работе друг друга или требовать комплексный контекст в определенной последовательности.
Задача требует определенного порядка операций или детерминированных, воспроизводимых результатов выполнения в определенной последовательности.
Ограничения ресурсов, такие как квота модели, делают параллельную обработку неэффективной или невозможной.
Агенты не могут с надежностью координировать изменения общего состояния или внешних систем при одновременной работе.
Нет четкой стратегии разрешения конфликтов для обработки противоречивых или конфликтующих результатов каждого агента.
Логика агрегирования результатов слишком сложна или снижает качество результатов.
Пример параллельной оркестрации
Компания по финансовым услугам создала интеллектуальное приложение, использующее параллельные агенты, которые специализируются на различных типах анализа для одновременной оценки одного и того же запаса. Каждый агент вносит аналитические сведения со своей специализированной точки зрения, которая обеспечивает разнообразные, чувствительные к времени входные данные для быстрых инвестиционных решений.
Система обрабатывает запросы на анализ акций путем передачи одного и того же символа тикера четырём специализированным агентам, которые выполняются параллельно.
Фундаментальный агент анализа оценивает финансовые показатели, тенденции доходов и конкурентное положение для оценки внутренней ценности.
Агент технического анализа изучает шаблоны цен, показатели объема и сигналы импульса для выявления торговых возможностей.
Агент анализа тональности обрабатывает новостные статьи, упоминания в социальных сетях и аналитические отчеты, чтобы оценить тональность рынка и уверенность инвесторов.
Агент по вопросам окружающей среды, социальных параметров и управления (ESG) проверяет влияние окружающей среды, социальную ответственность и отчеты о практике управления для оценки рисков и возможностей устойчивого развития.
Эти независимые результаты затем объединяются в комплексную рекомендацию по инвестициям, которая позволяет менеджерам портфеля быстро принимать обоснованные решения.
Оркестрация группового чата
Шаблон оркестрации группового чата позволяет нескольким агентам решать проблемы, принимать решения или проверять работу, участвуя в общем потоке бесед, где они взаимодействуют через обсуждение. Диспетчер чатов координирует поток, определяя, какие агенты могут отвечать следующим и управлять различными режимами взаимодействия, от совместной мозговой штурмовки до структурированных шлюзов качества.
В этом шаблоне рассматриваются сценарии, которые лучше всего выполняются с помощью группового обсуждения, чтобы достичь решений. Эти сценарии могут включать совместную идею, структурированную проверку или процессы контроля качества. Шаблон поддерживает различные режимы взаимодействия, от непринужденного мозгового штурма до строгих рабочих процессов проверки, имеющих фиксированные роли и этапы одобрения.
Этот шаблон хорошо подходит для сценариев с участием человека, где люди могут при необходимости взять на себя динамические обязанности управляющего чатом и направлять разговоры к продуктивным результатам. В этом оркестрационном шаблоне агенты обычно работают в режиме только для чтения. Они не используют инструменты для внесения изменений в запущенные системы.
Когда следует использовать оркестрацию группового чата
Рассмотрите возможность организации группового чата, когда ваш сценарий можно решить с помощью спонтанной или управляемой коллаборации или итеративных проверяющих циклов. Все эти подходы поддерживают контроль или участие человека в режиме реального времени. Поскольку все агенты и люди, участвующие в процессе, отправляют выходные данные в единый накапливающийся поток, этот шаблон обеспечивает прозрачность и возможность аудита.
Сценарии совместной работы
Творческие сеансы мозгового штурма, где агенты с разными перспективами и источниками знаний опираются на вклад друг друга в чат
Процессы принятия решений, которые получают выгоду от дебатов и консенсуса
Сценарии принятия решений, требующие итеративного уточнения с помощью обсуждения
Многодисциплинарные проблемы, требующие межфункционального диалога
Сценарии проверки и контроля качества
Требования к обеспечению качества, связанные с структурированным процессом проверки и итерацией
Проверка соответствия и нормативного регулирования, требующая мнения нескольких экспертов
Рабочие процессы создания контента, требующие редактирования, с четким разделением проблем между созданием и проверкой
Когда избежать оркестрации группового чата
Избегайте этого шаблона в следующих сценариях:
Достаточно простого делегирования задач или линейной обработки конвейера.
Требования к обработке в режиме реального времени делают обсуждение неприемлемым.
Более подходящими являются четкие иерархические процессы принятия решений или детерминированные рабочие процессы без обсуждения.
Диспетчер чата не имеет объективного способа определить, завершена ли задача.
Управление потоком беседы и предотвращение бесконечных циклов требует тщательного внимания, особенно если больше агентов делают управление более сложным для поддержания. Чтобы обеспечить эффективный контроль, рассмотрите возможность ограничения оркестрации группового чата до трех или меньше агентов.
Циклы проверки Maker
Цикл проверки maker — это определенный тип оркестрации группового чата, где один агент, maker, создает или предлагает что-то. Другой агент, проверяющий, оценивает результат. Этот шаблон итеративный: агент проверки отправляет беседу обратно агенту создания, чтобы вносить изменения и повторять процесс. Несмотря на то, что шаблон группового чата не требует от агентов общаться по очереди, цикл создатель-проверяющий требует формальной пошаговой последовательности, которой управляет диспетчер чата.
Пример оркестрации группового чата
Городской парк и департамент отдыха использует программное обеспечение, включающее оркестрацию групповых чатов для оценки новых предложений по развитию парка. Программное обеспечение читает проект предложения, и несколько специалистов обсуждают различные перспективы влияния сообщества и работают над консенсусом по предложению. Этот процесс возникает до того, как предложение откроется для проверки сообщества, чтобы помочь предвидеть отзывы, которые он может получить.
Система обрабатывает предложения по развитию парков, инициируя групповую консультацию со специализированными муниципальными агентами, которые рассматривают задачу с различных гражданских точек зрения.
Агент взаимодействия с сообществом оценивает требования к специальным возможностям, ожидаемые отзывы жителей и шаблоны использования, чтобы обеспечить справедливый доступ к сообществу.
Агент по планированию окружающей среды оценивает экологические последствия, меры устойчивости, смещение растительности и соответствие экологическим нормам.
Агент по бюджету и операциям анализирует затраты на строительство, текущие расходы на обслуживание, требования к персоналу и долгосрочное устойчивое функционирование.
Менеджер чатов обеспечивает структурированные дебаты, в которых агенты оспаривают рекомендации друг друга и защищают свои аргументы. Сотрудник отдела парков участвует в потоке чата, чтобы добавить аналитические сведения и ответить на запросы на знания агентов в режиме реального времени. Этот процесс позволяет сотруднику обновить исходное предложение, чтобы устранить выявленные проблемы и лучше подготовиться к отзыву сообщества.
Оркестрация передачи задач
Шаблон оркестрации передачи обеспечивает динамическое делегирование задач между специализированными агентами. Каждый агент может оценить задачу вручную и решить, следует ли обрабатывать ее непосредственно или передавать ее в более подходящий агент на основе контекста и требований.
В этом шаблоне рассматриваются сценарии, в которых оптимальный агент для задачи не известен заранее или где требования к задаче становятся понятными только во время обработки. Он обеспечивает интеллектуальную маршрутизацию и гарантирует, что задачи достигают наиболее эффективного агента. Агенты в этом шаблоне обычно не работают параллельно. Полный контроль передается от одного агента другому агенту.
Когда следует использовать оркестрацию передачи
Рассмотрим шаблон передачи агента в следующих сценариях:
Задачи, требующие специализированных знаний или инструментов, но где количество необходимых агентов или их порядок не может быть предопределен
Сценарии, в которых требования к опыту возникают во время обработки, что приводит к динамической маршрутизации задач на основе анализа содержимого
Проблемы с несколькими доменами, требующие разных специалистов, которые работают одновременно
Логические связи и сигналы, которые можно предопределить, чтобы указать, когда один агент достигает предела возможностей и какой агент должен обрабатывать задачу далее
Когда избежать оркестрации передачи
Избегайте этого шаблона в следующих сценариях:
Соответствующие агенты и их порядок всегда известны заранее.
Маршрутизация задач является простой и детерминированной на основе правил, а не на основе динамического контекстного окна или динамической интерпретации.
Неоптимальные решения по маршрутизации могут привести к плохому или разочаровывающему опыту пользователей.
Для решения задачи следует одновременно выполнять несколько операций.
Избегать бесконечного цикла передачи полномочий или чрезмерного переключения между агентами — непростая задача.
Пример шаблона передачи агента
Решение для управления отношениями с клиентами (CRM) в области телекоммуникаций использует агентов переадресации на веб-портале поддержки клиентов. Первоначальный агент начинает помогать клиентам, но обнаруживает, что он нуждается в специализированном опыте во время беседы. Первоначальный агент передает задачу наиболее подходящему агенту для решения проблем клиента. Только один агент за раз работает с исходными входными данными, а цепочка передачи приводит к одному результату.
В этой системе агент поддержки триажа интерпретирует запрос и пытается напрямую справиться с общими проблемами. Когда он достигает своих ограничений, он передает сетевые проблемы агенту технической инфраструктуры, выставлению счетов агенту финансового разрешения и т. д. Дальнейшие передачи происходят в этих агентах, когда текущий агент распознает свои собственные ограничения возможностей и знает, что другой агент может лучше поддерживать сценарий.
Каждый агент может завершить беседу, если он определяет, что успех клиента был достигнут или что другой агент не может дополнительно воспользоваться клиентом. Некоторые агенты также предназначены для передачи пользовательского интерфейса агенту поддержки человека, когда проблема важна для решения, но в настоящее время у агента ИИ нет возможностей для решения этой проблемы.
На схеме выделен пример передачи. Он начинается с агента триажа, который передает задачу агенту технической инфраструктуры. Затем агент технической инфраструктуры решает передать задачу агенту финансового разрешения, который в конечном итоге перенаправляет задачу в службу поддержки клиентов.
Магентическая оркестрация
Шаблон магнитной оркестрации разработан для открытых и сложных проблем, которые не имеют предопределенного плана подхода. Агенты в этом шаблоне обычно имеют средства, позволяющие им вносить прямые изменения во внешних системах. Внимание уделяется созданию и документированию подхода к решению проблемы так же, как и реализации этого подхода. Список задач динамически создается и уточняется в рамках рабочего процесса посредством совместной работы между специализированными агентами и магнитным менеджер-агентом. По мере развития контекста агент magnetic manager создает реестр задач для разработки плана подхода с целями и подцелями, который в конечном итоге завершается, за которым следят и который отслеживают для достижения желаемого результата.
Агент-управляющий взаимодействует непосредственно со специализированными агентами для сбора информации по мере создания и уточнения реестра задач. Он выполняет итерации, откаты и делегирование столько раз, сколько необходимо для создания полного плана, который он может успешно выполнить. Менеджер-агент часто оценивает, полностью ли удовлетворен исходный запрос или застопорился. Он обновляет реестр для настройки плана.
В некотором смысле этот шаблон оркестрации является расширением шаблона группового чата . Шаблон магнитной оркестрации фокусируется на агенте, который создает стратегию подхода, в то время как другие агенты используют средства для внесения изменений во внешние системы вместо обращения к их хранилищам знаний для достижения результата.
Когда следует использовать магнитную оркестрацию
Рассмотрим магнитный узор в следующих сценариях:
Сложный или открытый вариант использования, не имеющий предопределенного пути решения.
Требование рассмотреть возможность ввода и обратной связи с несколькими специализированными агентами для разработки допустимого пути решения.
Требование к системе ИИ создать полностью разработанный план подхода, который человек может просмотреть до или после реализации.
Агенты, оснащенные инструментами, которые взаимодействуют с внешними системами, потребляют внешние ресурсы или могут вызывать изменения в запущенных системах. Документированный план, показывающий, как упорядочены эти агенты, может быть представлен пользователю перед тем, как разрешить агентам выполнять задачи.
Когда избегать магнитной оркестрации
Избегайте этого шаблона в следующих сценариях:
Путь решения разработан или должен быть реализован детерминированно.
Нет необходимости создавать реестр.
Задача имеет низкую сложность, и более простой шаблон может решить его.
Работа срочная, так как подход фокусируется на создании и обсуждении реализуемых планов, а не на оптимизации конечных результатов.
Вы ожидаете частые остановки или бесконечные циклы, которые не имеют четкого пути к разрешению.
Пример магнитной оркестрации
Команда по инженерии надежности сайта (SRE) создала автоматизированную систему, которая применяет магнитную оркестрацию для обработки сценариев низкорисковых инцидентных реакций. При сбое службы в области автоматизации система должна динамически создавать и реализовывать план исправления. Это делается без знания конкретных шагов, необходимых заранее.
Когда автоматизация обнаруживает квалифицированный инцидент, агент диспетчера magentic начинается с создания начального реестра задач с высоким уровнем целей, таких как восстановление доступности службы и определение первопричины. Затем агент менеджера обращается к специализированным агентам для сбора информации и уточнения плана исправления.
Агент диагностики анализирует системные журналы, метрики производительности и шаблоны ошибок для выявления потенциальных причин. Он передает результаты обратно управляющему агенту.
На основе результатов диагностики агент диспетчера обновляет реестр задач с определенными этапами исследования и обращается к агенту инфраструктуры , чтобы понять текущее состояние системы и доступные варианты восстановления.
Агент коммуникации предоставляет возможности уведомления заинтересованных лиц, а агент менеджера включает контрольные точки связи и шлюзы утверждения в развивающийся план в соответствии с процедурами эскалации группы SRE.
По мере того как сценарий становится более понятным, агент диспетчера может добавить агента отката в план, если требуется реверсия развертывания, или передать дело инженерам SRE, если инцидент превышает рамки автоматизации.
На протяжении всего этого процесса агент диспетчера постоянно обновляет реестр задач на основе новых сведений. Он добавляет, удаляет или переупорядочивает задачи по мере развития инцидента. Например, если агент диагностики обнаруживает проблему подключения к базе данных, агент управления может переключить план с стратегии отката развертывания на план, который сосредоточится на восстановлении подключения к базе данных.
Агент менеджера следит за чрезмерными задержками при восстановлении службы и предотвращает бесконечные циклы устранения неисправностей. Он поддерживает полный аудит развивающегося плана и этапы реализации, обеспечивающие прозрачность для проверки после инцидента. Эта прозрачность гарантирует, что команда SRE может улучшить рабочую нагрузку и автоматизацию на основе извлеченных уроков.
Вопросы реализации
При реализации любого из этих шаблонов проектирования агента необходимо учитывать несколько важных вопросов. Проверка этих аспектов помогает избежать распространенных подводных камней и гарантирует, что оркестрация агентов надежна, безопасна и обслуживаемая.
Один агент, мультитул
При наличии достаточного доступа к средствам и источникам знаний можно устранить некоторые проблемы с одним агентом. По мере увеличения числа источников знаний и средств становится трудно обеспечить прогнозируемый интерфейс агента. Если один агент может надежно решить свой сценарий, рассмотрите возможность принятия этого подхода. Затраты на принятие решений и управление потоками часто превышают преимущества разрыва задачи на несколько агентов. Границы безопасности, обзор сети и другие факторы все еще могут сделать подход с одним агентом невозможным. Однако.
Детерминированная маршрутизация
Для некоторых шаблонов требуется маршрутизировать поток между агентами детерминированным образом. Другие полагаются на агентов, чтобы выбрать собственные маршруты. Если агенты определены в среде без кода или с низким кодом, вы можете не контролировать это поведение. Если вы определяете агенты в коде с помощью пакетов SDK, таких как Microsoft Agent Framework или семантического ядра, у вас больше управления.
Окно контекста
Агенты ИИ часто имеют ограниченные контекстные окна. Это ограничение может повлиять на их способность обрабатывать сложные задачи. При реализации этих шаблонов определите, какой контекст требуется следующему агенту для эффективной работы. В некоторых сценариях требуется полный необработанный контекст, собранный до сих пор. В других сценариях более подходящим является сводная или усеченная версия. Если агент может работать без накопленных контекстов и требует только нового набора инструкций, примите этот подход вместо предоставления контекста, который не помогает выполнить задачу агента.
Reliability
Эти шаблоны требуют правильного функционирования агентов и надежных переходов между ними. Они часто приводят к проблемам классических распределенных систем, таким как сбои узлов, сетевые секции, потери сообщений и каскадные ошибки. Стратегии устранения рисков должны применяться для решения этих проблем. Агенты и их оркестраторы должны выполнить следующие действия.
Реализуйте механизмы времени ожидания и повторных попыток.
Добавьте механизм плавной деградации для обработки одного или нескольких агентов при сбое шаблона.
Выявляйте ошибки вместо их скрытия, чтобы подчиненные агенты и логика оркестратора могли реагировать соответствующим образом.
Рассмотрим шаблоны прерывателя цепи для зависимостей агента.
Агенты должны быть изолированы друг от друга максимально, насколько это возможно, без совместных точек отказа между ними. Рассмотрим пример.
Убедитесь в обеспечении изоляции вычислений между агентами.
Оцените, как использование одной модели как службы (MaaS) или общего хранилища знаний может привести к ограничению скорости, когда агенты работают одновременно.
Используйте функции контрольных точек, доступные в вашем SDK, чтобы восстановиться после прерывания оркестрации, например, из-за сбоя или нового развертывания кода.
Безопасность
Реализация надлежащих механизмов безопасности в этих шаблонах проектирования сводит к минимуму риск предоставления системы искусственного интеллекта атакам или утечке данных. Защита взаимодействия между агентами и ограничение доступа каждого агента к конфиденциальным данным являются ключевыми стратегиями проектирования безопасности. Рассмотрим следующие меры безопасности:
Реализуйте проверку подлинности и используйте безопасную сеть между агентами.
Учитывайте последствия для конфиденциальности данных в коммуникациях с агентами.
Проектируйте аудиторские записи для соответствия нормативным требованиям.
Проектируйте агентов и их оркестраторов так, чтобы они следовали принципу наименьших привилегий.
Рассмотрим, как обрабатывать идентичность пользователя между агентами. Агенты должны иметь широкий доступ к хранилищам знаний для обработки запросов от всех пользователей, но они не должны возвращать данные, недоступные пользователю. Реализация ограничения доступа должна осуществляться каждым агентом данного шаблона.
Наблюдаемость и тестирование
Распространение системы искусственного интеллекта между несколькими агентами требует мониторинга и тестирования каждого агента по отдельности, а также системы в целом, чтобы обеспечить правильную функциональность. При разработке стратегий наблюдаемости и тестирования рассмотрите следующие рекомендации:
Инструментируйте все операции агента и их передачи. Устранение неполадок распределенных систем — это задача в области компьютерных наук, и организованные агенты ИИ не являются исключением.
Отслеживайте показатели производительности и использования ресурсов для каждого агента, чтобы можно было установить базовые показатели, найти узкие места и оптимизировать их.
Разработка тестируемых интерфейсов для отдельных агентов.
Реализуйте тесты интеграции для рабочих процессов с несколькими агентами.
Распространенные ловушки и антишаблоны
Избегайте этих распространенных ошибок при реализации шаблонов оркестрации агентов:
Создание ненужной сложности координации с помощью сложного шаблона, когда достаточно простой последовательной или параллельной оркестрации.
Добавление агентов, которые не обеспечивают значимую специализацию.
Пренебрежение влиянием задержки на многоступенчатую связь.
Совместное использование мутабельного состояния между параллельными агентами может привести к данным с транзакционными несоответствиями из-за допущения синхронных обновлений через границы агентов.
Использование детерминированных шаблонов для рабочих процессов, которые по сути недетерминированные.
Использование недетерминированных шаблонов для рабочих процессов, которые по сути детерминируются.
Игнорируя ограничения ресурсов при выборе параллельной оркестрации.
Использование избыточных ресурсов модели, так как контекстные окна растут по мере того, как агенты накапливают больше информации и советуются с их моделью, чтобы добиться прогресса в их задаче.
Объединение шаблонов оркестрации
Иногда приложениям требуется объединить несколько шаблонов оркестрации для решения своих требований. Например, можно использовать последовательную оркестрацию для начальных этапов обработки данных, а затем переключиться на параллельную оркестрацию для задач параллельного анализа. Не пытайтесь поместить один рабочий процесс в один шаблон, если разные этапы рабочей нагрузки имеют разные характеристики и могут воспользоваться каждым этапом с помощью другого шаблона.
Связь с шаблонами проектирования облака
Шаблоны оркестрации агентов ИИ расширяют и дополняют традиционные шаблоны проектирования облака , устраняя уникальные проблемы координации интеллектуальных, автономных компонентов. Шаблоны проектирования облака сосредоточены на структурных и поведенческих проблемах в распределенных системах, но шаблоны оркестрации агентов ИИ специально решают координацию компонентов с возможностями логики, поведением обучения и недетерминированными выходными данными.
Реализации на основе пакета SDK
Многие из этих шаблонов используют реализацию на основе кода для решения логики оркестрации. Пакеты SDK, поддерживающие платформу агента, часто поддерживают многие шаблоны оркестрации агента.
Microsoft Agent Framework
Пакет SDK для Microsoft Agent Framework содержит рекомендации по реализации оркестрации Agent Framework.
- Последовательная оркестрация с помощью agent Framework
- Параллельная оркестрация с помощью Agent Framework
- Оркестрация хэндовера с помощью Agent Framework
- Магнитная оркестрация с использованием Agent Framework
Для практической реализации изучите примеры декларативного рабочего процесса Agent Framework на сайте GitHub, демонстрирующие некоторые из этих шаблонов на практике.
Семантическое ядро
Пакет SDK для семантического ядра содержит рекомендации по реализации для своей платформы агента.
- Последовательная оркестрация с помощью семантического ядра
- Параллельная оркестрация с помощью семантического ядра
- Оркестрация группового чата с помощью семантического ядра
- Оркестрация передачи с помощью семантического ядра
- Семантическая оркестрация с помощью семантического ядра
Для практической реализации изучите примеры оркестрации семантического ядра с несколькими агентами на сайте GitHub, демонстрирующие эти шаблоны на практике.
Вы также можете найти многие из этих шаблонов в AutoGen, например Magentic-One.
Реализации в службе Microsoft Foundry Agent
Службу Microsoft Foundry Agent можно также использовать для цепочки агентов в относительно простых рабочих процессах с помощью функций подключенных агентов . Рабочие процессы, которые вы реализуете с помощью этой службы, в основном недетерминированные, что ограничивает, какие шаблоны можно полностью реализовать в этой среде без кода.
Соавторы
Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.
Основные авторы:
- Чад Киттель | Главный инженер по программному обеспечению — шаблоны и методики Azure
- Клейтон Сименс | Разработчик основного содержимого — шаблоны и практики Azure
Другие участники:
- Hemavathy Alaganandam | Главный инженер программного обеспечения
- Джеймс Ли | Специалист по обработке и анализу данных 2
- Ritesh Modi | Главный инженер программного обеспечения
- Махди Сетайеш | Главный инженер программного обеспечения
- Марк Тейлор | Главный инженер программного обеспечения
- Янив Вакнин | Старший технический специалист
Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.