Оркестрация ИИ-агентов: как распределить работу и сохранить контроль

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

Документация и приведённые ниже цены на инфраструктуру проверены 13 октября 2026 года. Примеры из бизнеса — это предлагаемые схемы работы, а не описания внедрений или результаты замеров производительности.

Что такое оркестрация ИИ-агентов?

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

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

Выбирайте схему по тому, какую границу ответственности нужно провести:

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

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

Агент-координатор и исполнители: один ответственный за результат

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

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

1. 1

   Задайте координатору результат и границы полномочий

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

2. 2

   Распределите исследовательские задачи с чёткими границами

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

3. 3

   Сначала получите подтверждения, затем объедините выводы

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

4. 4

   Передайте материал на согласование

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

Claude Agent SDK — программируемая среда выполнения агентов от Anthropic — реализует эту схему через субагентов: отдельные экземпляры агентов со своими инструкциями, контекстом и доступом к инструментам. Их задают параметром agents, а основной агент вызывает их через инструмент Agent. Обычный субагент, созданный без форка, не получает историю диалога родительского агента, поэтому весь нужный контекст следует передать в промпте задачи. Родительский агент получает итоговый отчёт. Документация Claude по субагентам.

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

CrewAI — фреймворк для агентов с заданными ролями и задачами — предлагает иерархический процесс с manager_llm или manager_agent. Управляющий агент планирует работу, делегирует задачи и проверяет результаты. Последовательный процесс, в свою очередь, идёт по списку задач и использует предыдущие результаты как контекст. Документация CrewAI по процессам.

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

Передача управления: следующий шаг решает специалист

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

OpenAI Agents SDK, библиотека для приложений с агентами, явно разделяет эти варианты: при передаче управления контроль переходит специалисту, а при вызове агента как инструмента за ответ по-прежнему отвечает координатор. Для второго варианта в JavaScript предусмотрен agent.asTool(). При передаче управления можно передать структурированные метаданные или отфильтрованную историю. Документация OpenAI по оркестрации.

Для входящих обращений клиентов подойдёт такая последовательность:

1. Агент приёма заявок распознаёт спор по оплате и собирает ссылки на соответствующие данные клиента и счета.
2. Он передаёт заявку специалисту по расчётам вместе с запросом клиента, проверенными фактами, открытыми вопросами и перечнем разрешённых следующих действий.
3. Специалист по расчётам разбирается в ситуации и готовит вариант решения. Теперь он отвечает за следующий ответ, а не возвращает агенту приёма заявок исследовательскую записку.
4. Любой предложенный возврат денег или изменение учётной записи согласовывает человек до запуска соответствующего инструмента.

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

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

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

Граф с контрольными точками: задайте следующий шаг явно

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

LangGraph — фреймворк для агентных процессов с сохранением состояния — поддерживает явные маршруты выполнения, включая ветвление и параллельную работу. Его механизмы контрольных точек сохраняют состояние графа для конкретного потока выполнения, а interrupt() приостанавливает работу в ожидании внешних данных. Прерванный поток возобновляется через Command(resume=...). Схемы рабочих процессов в LangGraph, документация по прерываниям.

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

1. 1

   Храните заявку как структурированное состояние

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

2. 2

   Опишите допустимые маршруты

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

3. 3

   Сохраните контрольную точку и остановитесь для проверки

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

4. 4

   Продолжите по разрешённой ветке

   Согласование разрешает отправку. Запрос правок возвращает работу к черновику и отменяет прежнее согласование. Отказ закрывает заявку с зафиксированной причиной.

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

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

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

Устойчивый к сбоям процесс: заявка живёт дольше вызова агента

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

Cloudflare Workflows — сервис для устойчивого выполнения многошаговых процессов — сохраняет шаги и позволяет настраивать повторные попытки. Для работы используйте step.do, для ожидания внешнего решения — step.waitForEvent, а для передачи решения ожидающему экземпляру — instance.sendEvent. Cloudflare Workflows, документация по событиям.

Для операционной команды, которая обрабатывает нестандартный запрос на услугу:

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

Ограничение: устойчивое выполнение само по себе не делает повтор внешнего действия безопасным. Cloudflare прямо рекомендует идемпотентные API-вызовы, небольшие отдельные шаги и детерминированные имена шагов, а также предупреждает о побочных эффектах вне step.do. Если сервис принял запрос на отправку, но ответ потерялся, повтор без защиты от дубликатов может отправить сообщение ещё раз. Правила Workflows.

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

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

Согласование человеком — непосредственно перед действием

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

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

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

CrewAI Flows умеет сохранять состояние через @persist и приостанавливаться для получения обратной связи через @human_feedback. Для действий с существенными последствиями важна деталь: если настроены исходы emit, механизм обратной связи использует языковую модель, чтобы отнести комментарий в свободной форме к одному из исходов. Для разрешения действия используйте отдельное проверяемое поле согласования, а не полагайтесь только на интерпретацию комментария. Документация CrewAI Flows.

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

Что записывать в журнал и какие лимиты вводить

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

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

• Идентификаторы и связи: ID заявки, ID процесса или запуска, ID родительского и дочерних запусков, роль агента, текущий шаг и попытка. Они позволяют связать сбой исполнителя с бизнес-запросом.
• Входные данные и конфигурация: ссылки и версии входных материалов, идентификатор модели, версия промпта и конфигурации, набор разрешённых инструментов. По ним видно, что изменилось между запусками.
• Решения и подтверждения: решение о маршрутизации, выбранное направление, ссылки на источники, результаты проверок и недостающие сведения. Фиксируйте наблюдаемые решения и краткие основания; не рассчитывайте на доступ к внутренним рассуждениям модели.
• Согласование: проверяющий, решение, отметка времени, хеш материала, параметры действия и срок действия согласования. Хеш — это цифровой отпечаток проверенного содержимого.
• Действия и восстановление: имя инструмента, параметры со скрытыми чувствительными данными, ключ действия или идемпотентности, ID внешнего запроса, подтверждение, категория ошибки и запланированный повтор. Если исход неизвестен, явно сохраняйте статус неопределённости.
• Потребление ресурсов и результат: категории токенов модели, расчётные и сверенные расходы, использование платных инструментов, прошедшее время, ожидание проверки, итоговый статус и факт принятия результата человеком.

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

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

Управление ИИ-агентами требует лимитов, которые система соблюдает

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

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

Claude Agent SDK предоставляет средства контроля расходов на запрос, включая maxBudgetUsd в TypeScript и max_budget_usd в Python, а также ограничения глубины и параллелизма субагентов. Требования к установленной версии проверьте в документации по субагентам.

Здесь важно понимать границы учёта: поле usage не включает работу субагентов, а modelUsage или model_usage — включает. Значение total_cost_usd учитывает субагентов, но остаётся оценкой на стороне клиента. Лимит расходов запроса распространяется на затраты самого вызова, а не на прежние расходы, восстановленные из возобновлённой сессии. Ведите учёт по всей заявке и сверяйте оценки с официальными данными о потреблении. Документация Claude по учёту расходов.

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

Контроль расходов ИИ-агентов: считайте всю заявку целиком

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

Для месячного расчёта используйте такую модель:

Стоимость процесса = использование моделей + платные инструменты + инфраструктура выполнения процессов + хранение состояния и журналов + проверка человеком + эксплуатация.

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

Для конкретного ориентира по инфраструктуре Cloudflare публикует следующие расценки:

Источники: тарифы Workers и тарифы Workflows. Минимальный платёж за учётную запись покрывает инфраструктуру, а не полную стоимость работы агента. Запросы, процессорное время, вызовы моделей и другие сервисы нужно учитывать отдельно. В объявлении об оплате указано, что тарификация шагов и хранения начнётся не ранее 10 августа 2026 года; публичная формулировка не подтверждает её включение для конкретной учётной записи.

Наш расчёт: если разделить опубликованные $0.80 на 100,000, получится $0.000008 за дополнительный шаг без учёта остальных начислений. Это пересчёт указанного тарифа на единицу, а не оценка нагрузки или замер фактического счёта. Опубликованная стоимость шагов.

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

Фреймворки ИИ-агентов подбирают под процесс

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

В сравнении фреймворков ИИ-агентов разобран выбор между конкретными решениями. Если осталось выбрать между явным состоянием графа и командами агентов с заданными ролями, обратитесь к сравнению LangGraph и CrewAI.

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

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

Какие ожидания от мультиагентных систем завышены

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

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

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

С чего начать внедрение

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

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

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

Вопросы владельца процесса

Нужна ли платформа оркестрации ИИ-агентов, если один агент уже справляется?

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

Можно ли сочетать эти схемы в одном процессе?

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

Даёт ли согласование черновика разрешение на ещё одну платную попытку?

Только если согласование явно охватывает такие расходы. Разрешение использовать материал и разрешение оплатить ещё одну попытку следует фиксировать отдельно. Изменённый черновик также нужно проверить до выполнения действия с существенными последствиями.

Что делать, если согласующий так и не ответил?

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

Подпишитесь на рассылку, чтобы получать практические руководства по созданию и эксплуатации бизнес-процессов с ИИ.