Мультиагентные системы: архитектура и оркестрация
Автор: Ai Flowi · Опубликовано
Мультиагентные системы распределяют задачу между агентами с разными обязанностями и координируют их работу. Архитектура определяет, кто вправе действовать, что получает каждый агент и как результаты передаются на следующий этап. Оркестрация агентов управляет этими передачами, включая остановку и отклонение результата; делегирование поручает другому агенту ограниченную задачу.
Сначала определите передачу результатов между этапами, которую один агент не может чётко организовать. Упражнение с исследованием, подготовкой текста и проверкой полезно тем, что у каждого этапа своё условие приёмки. Дополнительные агенты увеличивают число передач, которые нужно проверить; их согласие само по себе не доказывает более высокую точность.
Выберите мультиагентную архитектуру
| Схема | Зависимость, при которой подходит схема | Необходимое правило контроля |
|---|---|---|
| Последовательные задачи | Для черновика нужен завершённый результат исследования. | Отклоняйте неполные подтверждающие материалы до подготовки текста. |
| Координатор и специалисты | Для задачи нужен выбранный специалист. | Определите, кто может делегировать задачи и какие инструменты получает специалист. |
| Независимая параллельная работа | На отдельные вопросы можно ответить без общих промежуточных результатов. | Определите, как согласовываются противоречащие друг другу результаты. |
| Один агент с ограниченной задачей | Одни и те же инструкции и инструменты подходят для всей задачи. | Сохраните ясное условие завершения и проверьте ответ. |
Это архитектурные решения, а не список протестированных режимов продукта. В предлагаемой ниже схеме подготовки отчёта Sequential Crew используется для изучения зависимости черновика от исследования; остальные схемы помогают решить, нужна ли для этой зависимости команда вообще. Запись в каталоге не подтверждает надёжное восстановление после сбоев или успешную координацию.
Что нужно до настройки агентов
Подготовьте тестовый набор исходных материалов, исследовательский вопрос и ожидаемый план итогового отчёта. Настройте доступ к модели через учётную запись и API-ключ выбранного поставщика, который отдельно выставляет счета за использование.
В упражнении ниже используются только компоненты каталога; этапа записи во внешнюю систему нет. Исходные материалы можно передать в тексте задачи, поэтому для первой схемы поисковый сервис не нужен. Любому добавленному позднее инструменту понадобятся собственные учётные данные, требования к входам и проверка сбоев. Терминология платформы объясняется в сравнении агента, рабочего процесса и чат-бота.
Шаг 1. Определите требования к передаче данных
Для исследования требуйте вывод, идентификатор источника, подтверждающий фрагмент и нерешённые вопросы. Этап подготовки текста получает принятые выводы и создаёт текст, в котором идентификаторы источников остаются привязаны к утверждениям. Этап проверки получает черновик и исходный набор материалов, затем возвращает решение с указанием конкретных неподтверждённых утверждений или пропусков.
Для доступа к источникам на этапе проверки используйте правило проверки цепочки запросов.
Дайте каждому участнику пакет с явно указанным названием: исследование получает вопрос и набор источников; подготовка текста — идентификаторы принятых выводов и задание на отчёт; проверка — предложенный отчёт и соответствующую версию набора источников. Проверяющий возвращает решение о принятии или отклонении, идентификаторы затронутых выводов и причину каждого отклонения. Если в исследовании пропущен обязательный идентификатор источника, не передавайте этот пункт на этап подготовки текста, даже с пометкой о неполноте.
Шаг 2. Настройте отдельные обязанности для задач
пример конфигурации, а не зафиксированный тест
| Задача | Настраиваемые входы | Условие приёмки |
|---|---|---|
| Исследование | role: проверяющий источники; goal: собрать подтверждённые выводы; task_description: изучить предоставленный пакет; expected_output: выводы с подтверждающими фрагментами и указанием недостающих сведений. | Для каждого вывода указан предоставленный источник, который его подтверждает. |
| Черновик | role: составитель отчёта; goal: ответить на вопрос; task_description: использовать принятые результаты исследования; expected_output: черновик со ссылками на источники и отмеченными нерешёнными вопросами. | Утверждения не добавляются лишь для того, чтобы отчёт выглядел полным. |
| Проверка | role: проверяющий подтверждающие материалы; goal: найти неподтверждённые утверждения; task_description: сравнить черновик с исходным пакетом; expected_output: решение и его причины. | Неподтверждённые утверждения препятствуют приёмке. |
Для каждого Sequential Task Agent предлагаются allow_code_execution=false, allow_delegation=false, async_execution=false и memory=false. Эти явные настройки ограничивают задуманное упражнение; их соблюдение при выполнении ещё нужно проверить. Подключите model_output настроенного Language Model к llm, который принимает тип LanguageModel.
Шаг 3. Изучите требования к оркестрации
Перечень входов последовательных компонентов и типы соединений объектов задач приведены в справочнике интеграции CrewAI.
Для упражнения с отчётом задайте в Sequential Crew memory=false, share_crew=false и use_cache=false; прежде чем передавать что-либо помимо тестового пакета, проверьте, что именно исключают эти настройки. До проверки выберите бюджет запросов, подходящий для поставщика. Эти значения не определяют поведение по умолчанию и не подтверждают работоспособность соединения нескольких задач.
Проверяйте каждую передачу на соответствие требованиям этапа, который получает данные: может ли составитель текста определить принятые выводы и имеет ли проверяющий доступ к той же версии источников, что использовалась при исследовании? Соединение, передающее текст без этих различий, не удовлетворяет предложенной архитектуре. Перед продолжением проверяйте содержимое пакетов и сохраняйте отклонённые выводы с причинами отдельно от принятых материалов для черновика.
Шаг 4. Задайте условия остановки и пределы делегирования
Останавливайтесь, когда обязательные подтверждающие материалы отсутствуют, проверяющий отклоняет черновик или поставщик даёт сбой. Передайте нерешённый вопрос человеку вместо повторных обращений к другому агенту за более уверенным ответом. Задайте предел повторных попыток до запуска. Повторная попытка модели может вновь использовать ту же ошибочную предпосылку.
Требования к инструментам при вызове функций объясняют Flow as Tool; для делегирования дополнительно нужны явно указанный получатель и ограниченный по содержанию пакет результата.
Например, делегируйте только вопрос о положении об отмене, а не весь отчёт. Специалист получает этот вопрос, разрешённые идентификаторы источников и требуемый формат вывода. Он возвращает вывод с подтверждающим фрагментом либо нерешённый пункт, не поручая работу другому участнику. До передачи следующего пакета координатор должен решить, удовлетворяет ли результат исходной задаче.
Предположим, исследование возвращает вывод F1 из версии A набора материалов, а составитель использует положение из версии B. Проверяющий должен отклонить смешанный пакет и указать несоответствие. Не включайте предложенный отчёт в итоговый результат; заново сформируйте передаваемый пакет из одного проверенного набора источников. Инструкция об отклонении в запросе не обеспечивает принудительную остановку: убедитесь, что дальнейшая работа не может начаться с отклонённым пакетом. Каталог не подтверждает наличие такого условного запрета выполнения в Sequential Crew, поэтому первое упражнение завершается ручной проверкой каждой передачи.
Шаг 5. Сравните с одним агентом с ограниченной задачей
Передайте одному Agent тот же вопрос, исходный пакет, инструменты только для чтения и требования к итоговому отчёту. Используйте input_value для задачи и system_prompt для правила подтверждения источниками; до тестирования задайте конечное значение max_iterations. Полный перечень полей приведён в справочнике Agent.
В обеих схемах изучите подтверждённые утверждения, недостающие материалы, отклонённые случаи, сбои поставщиков и наблюдаемое использование узлов. Используйте учётные данные с эквивалентными правами и одинаковый доступ к источникам. Не сравнивайте команду с инструментами с одиночным агентом, которому недоступны те же источники. Зафиксируйте реальные вызовы и неудачные попытки, прежде чем делать выводы о стоимости или полезности.
Какой результат и какие ограничения ожидать от мультиагентной системы?
Предполагаемый результат — отчёт с выводами, связанными с источниками, и отдельным решением по итогам проверки, с явно отмеченными пробелами в данных. Отчёт из этой предложенной конфигурации не зафиксирован. Последовательные компоненты описаны в каталоге; Ai Flowi не проводила их тестирование в производственной среде. Типизированные порты подтверждают совместимость интерфейсов, а не успешное выполнение или независимость суждений.
Не используйте эту схему, когда на вопрос отвечает фиксированное правило, когда достаточно одного вызова модели и проверки человеком или когда внешнее действие требует этапа одобрения, отсутствующего в предложенном графе. О принятии решений о действиях в заданных пределах читайте в материале про автономных ИИ-агентов. Раздел сценариев использования предлагает существующие начальные схемы с собственными пределами подтверждённых результатов.
Использование рабочего процесса
Тарифы: Go от USD8 в месяц при годовой оплате (USD10 помесячно), Plus от USD16 (USD20 помесячно), Pro 100 от USD80 (USD100 помесячно), Pro 200 от USD160 (USD200 помесячно) и Pro 500 от USD400 (USD500 помесячно), от 5,000 до 250,000 Flowi Tokens в месяц с возможностью пополнения; 1 токен за каждый запуск узла; использование сторонних API и моделей не включено.