Какие паттерны оркестрации ИИ-агентов подходят вашей задаче?

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

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

Выбирайте по неопределенности, связанности и риску

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

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

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

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

Риск меняет выбор. Управление опасными действиями надо переносить в код, даже если LLM помогает с диагностикой. Агент может предложить возврат денег, миграцию базы или откат в промышленной среде, но программная политика должна проверить лимиты и запросить подтверждение человека. В документации OpenAI Agents SDK тоже проводится широкое различие между оркестрацией через LLM и оркестрацией через код. Я формулирую правило жестче: модель пусть трактует неоднозначные данные, а код контролирует права, бюджеты и необратимые переходы.

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

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

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

Маршрутизатор должен принимать одно ограниченное решение

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

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

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

{
  "route": "billing",
  "confidence": 0.91,
  "reason_code": "duplicate_charge",
  "needs_clarification": false
}

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

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

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

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

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

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

Супервизор отвечает за план и результат

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

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

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

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

1. Создать или обновить план задач с зависимостями.
2. Отправить готовые задачи исполнителям, параллельно там, где нет общего изменяемого состояния.
3. Проверить каждый результат по контракту и критерию приемки.
4. Завершить работу, запросить подтверждение или назначить еще одну ограниченную задачу.

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

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

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

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

Рой меняет предсказуемость на адаптивные передачи

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

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

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

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

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

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

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

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

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

Самые полезные системы сочетают подходы с ограничениями

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

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

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

entry: intake_router
agents:
  intake_router:
    can_call: [defect_supervisor, product_workflow, human_queue]
    max_handoffs: 1
  defect_supervisor:
    can_call: [reproducer, code_reader, test_runner]
    max_rounds: 4
  code_reader:
    can_handoff: [database_specialist]
    max_handoffs: 1
  database_specialist:
    tools: [read_schema, explain_query]
policies:
  write_production: human_approval
  total_model_calls: 18
  deadline_seconds: 240
terminal_states: [resolved, needs_human, budget_exhausted, failed]

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

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

Фреймворк должен воплощать ваш граф управления, а не определять его. Представление агентов как инструментов в OpenAI Agents SDK естественно соответствует супервизору, а handoff соответствует передаче. Групповые чаты AutoGen могут организовать работу по очереди. Другие графовые среды кодируют ту же топологию узлами и ребрами. Когда схема управления ясна, сравнивайте долговечность выполнения, трассировку, хранение состояния, подтверждения и соответствие вашей эксплуатации.

Контракты состояния важнее промптов агентов

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

Отделяйте разговор от рабочего состояния. Разговор объясняет ход рассуждения людям и моделям. Рабочее состояние управляет исполнением. Запись задачи может содержать статус, владельца, зависимости, идентификаторы артефактов, число попыток, срок и статус подтверждения. Супервизор должен читать эти поля, а не выводить готовность из фразы «по-моему, все хорошо».

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

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

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

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

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

Бюджеты, завершение и права задаются кодом

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

Завершение надо описать набором состояний, которые читает код. resolved, needs_human, budget_exhausted и failed полезнее ожидания, пока агент скажет TERMINATE. В примерах AutoGen текстовое завершение сочетается с ограничением числа сообщений. Это верный подход: смысловому признаку завершения нужна механическая страховка.

Назначайте права инструментам и удостоверениям, а не описаниям ролей. Фраза «ты аналитик, которому разрешено только чтение» в промпте не меняет права учетной записи базы данных. Дайте агенту подключение только для чтения, ограничьте сетевые адреса и проверяйте аргументы инструментов. При передаче управления не передавайте учетные данные автоматически.

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

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

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

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

Оценивайте решения и готовую работу раздельно

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

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

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

Записывайте один запуск как структурированные события:

00 route.selected      target=defect_supervisor confidence=0.94
01 task.dispatched     agent=reproducer task=T1 budget_calls=17
02 artifact.created    agent=reproducer artifact=A7 kind=test_case
03 task.completed      agent=reproducer task=T1 verdict=reproduced
04 approval.requested  action=deploy_patch target=staging
05 run.terminated      state=needs_human calls_used=9

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

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

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

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

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

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

Team & AI Audit применяет ту же дисциплину в масштабе компании: работа, права, стоимость и передачи отображаются до покупки новых вызовов моделей или сокращения ролей. Полезный результат - более компактная операционная схема с измеримыми границами, а не прежняя оргструктура с именами агентов.

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

Перед утверждением топологии ответьте на короткий список вопросов:

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

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