Лучшие практики оркестрации ИИ-агентов: обработка сбоев, одобрений и повторных попыток

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

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

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

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

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

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

Развернуть

Давайте посмотрим, что происходит после того, как вы даете оркестратору задачу.

Рассмотрим пример из воркшопа Perplexity по Computer: создание дашборда с аналитикой по клиентам на основе данных из Salesforce, Snowflake, электронной почты, календаря и свежих новостей.

1. Понять цель и спланировать работу. Оркестратор начинает с запрошенного результата и разбивает его на задачи с явными зависимостями. В нашем примере с дашбордом это означает сбор информации из разных источников и превращение ее в готовый результат. Планировщик определяет, какие шаги зависят от других, а какие могут выполняться независимо.
2. Направить задачи подходящим агентам. Оркестратор определяет задачи, зависимости которых выполнены, и делегирует работу специализированным агентам или моделям. Зависимые задачи ждут выполнения своих предварительных условий. Perplexity Computer использует несколько передовых моделей, направляя разные части рабочего процесса системам, подходящим для этих задач. Это также позволяет выполнять независимую работу параллельно.
3. Выполнять вызовы инструментов в контролируемых средах. Агенты взаимодействуют со своей средой через инструменты, такие как веб-поиск, API, подключенные приложения, операции с файлами или выполнение кода. Уровень выполнения запускает эти действия и возвращает результаты агентам.
4. Передавать результаты и контекст между агентами. Когда агент завершает свою задачу, следующему агенту в цепочке нужен соответствующий результат, чтобы продолжить работу. Запись о передаче может содержать идентификатор задачи, ссылку на результат, версию схемы и метаданные источника. Оркестратор координирует эти передачи, сохраняя контекст, необходимый для последующих шагов. Важно, что агентам не нужно держать всю историю работы каждого другого агента в собственных контекстных окнах.
5. Записывать состояние выполнения отдельно от контекста агентов. По мере того как агенты начинают и завершают задачи или терпят в них неудачу, механизм выполнения обновляет постоянную запись рабочего процесса: статусы задач, попытки выполнения, ссылки на результаты и оставшуюся работу. Эта запись позволяет оркестратору отслеживать прогресс и возобновлять работу после прерываний, не полагаясь на LLM для восстановления рабочего процесса по истории диалога.
6. Проверять результаты и решать, что делать дальше. Когда задача возвращает результат, уровень оркестрации проверяет, соответствует ли он ожидаемому контракту и выполнены ли зависимости следующей задачи. Если обнаружена проблема, рабочий процесс может вернуться к более раннему шагу для исправления или быть приостановлен. В противном случае он продвигается к завершению.

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

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

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

Таким образом, оркестрация полезна в трех сценариях:

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

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

«Обычно я начинаю с самого простого варианта и отталкиваюсь от него. Если мы знаем шаги и они повторяемы, скорее всего, это рабочий процесс. Я вижу смысл вводить несколько агентов, только когда у них разные обязанности, права доступа или пользователи», — говорит Josh Spilker, руководитель направления поискового маркетинга в AirOps.

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

Архитектуры оркестрации ИИ-агентов и их компромиссы

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

Централизованная оркестрация

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

Развернуть

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

Децентрализованная оркестрация

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

Развернуть

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

Иерархическая оркестрация

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

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

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

Развернуть

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

Сравнение этих архитектур:

Последовательное и параллельное выполнение, а также выполнение с передачей управления

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

Вот три паттерна выполнения:

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

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

Типичные сбои оркестрации ИИ-агентов

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

• Передача между агентами с потерей информации. Оркестратор передаёт специализированному агенту сжатый план, но в этом кратком изложении теряются ограничения, зависимости или детали реализации.
• Преждевременное выполнение fan-in. Нижестоящий агент начинает агрегировать результаты до того, как завершатся все вышестоящие задачи.
• Недетерминированные обновления общего состояния. Параллельные агенты записывают данные в одни и те же ключи состояния без чётко определённой семантики слияния. В зависимости от того, как фреймворк обрабатывает обновления, это может привести к потере записей, дублированию данных, зависимости результата от порядка выполнения или конфликтующим изменениям.
• Расхождение контрольных точек и побочных эффектов. Задача выполняет внешнюю операцию, но её успешное выполнение не фиксируется надёжно до сбоя исполнителя. При восстановлении оркестратор видит незавершённую задачу и запускает её повторно.
• Гонки при возобновлении после одобрения человеком. Приостановка и возобновление выполнения порождают собственные проблемы синхронизации.
• Циклы делегирования и лавинообразные повторы. Агенты раз за разом передают работу друг другу, потому что их зоны ответственности пересекаются, зависимости цикличны или условия завершения неоднозначны.
• Средства контроля на уровне инструкций, ошибочно принимаемые за безопасность выполнения. Оркестратор может запретить агентам обращаться к определённым ресурсам или выполнять чувствительные действия, но инструкции модели не обеспечивают соблюдение разрешений операционной системы, сетевых ограничений или границ авторизации. Исследование в области инженерии безопасности от Perplexity объясняет, почему агенты могут пересекать границы безопасности, преследуя легитимные цели, даже без вредоносных инструкций

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

7 лучших практик оркестрации ИИ-агентов для надёжной работы в продакшене

1. Определите явные контракты задач, критерии приёмки и условия остановки

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

Например, вот как можно определить контракт для агента, отвечающего за исправление периодически падающего интеграционного теста:

• Цель: найти и устранить причину нестабильного интеграционного теста API оформления заказа.
• Входные данные: исходный код теста, журналы сбоев CI, последние коммиты и соответствующий код приложения.
• Ограничения: не отключать тесты, не ослаблять проверки (assertions) и не изменять несвязанное поведение приложения.
• Ожидаемый результат: патч кода, объяснение первопричины и результаты выполнения тестов.
• Критерии приёмки: ранее падавший тест проходит 10 запусков подряд, и соответствующий набор регрессионных тестов также проходит.
• Условия неудачи: не удаётся установить первопричину, исправление вызывает регрессии или нужная тестовая среда недоступна.

Но есть ещё один важный момент: когда агенту следует остановиться?

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

Вернёмся к нашему примеру с CI. Можно определить следующие условия остановки:

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

2. Не перегружайте оркестраторы и требуйте структурированной передачи задач

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

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

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

3. Сохраняйте состояние рабочего процесса и контролируйте рост контекста

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

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

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

4. Проектируйте повторные попытки с учётом сбоев и восстанавливаемое выполнение инструментов

Допустим, ваш CI-агент запускает тестовый прогон, но время ожидания ответа на API-запрос истекает. Тестовый прогон не запустился — или сервис CI поставил его в очередь, а ответ потерялся?

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

• Временные ошибки (429, 503): повторяйте попытки с ограниченной экспоненциальной задержкой и джиттером, соблюдая Retry-After, если он указан.
• Ошибки валидации или доступа (400, 403): остановитесь или устраните исходную проблему, а не повторяйте тот же запрос.
• Неоднозначные исходы (тайм-аут после возможной записи): прежде чем пробовать снова, проверьте, была ли операция успешной.

Примечание: даже для ошибок, допускающих повтор, нужны ограничения. Задайте тайм-аут для каждого вызова инструмента, ограничьте число повторных попыток и их общее время, а также установите общий дедлайн рабочего процесса, чтобы вложенные агенты не могли без конца перезапускать одну и ту же операцию. Если зависимость постоянно даёт сбой, используйте автоматический выключатель (circuit breaker), чтобы временно прекратить запросы.

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

Если не удаётся установить, что произошло, остановитесь и эскалируйте проблему.

Пример логики повторных попыток для нашего CI-агента в виде псевдокода:

Примечание к коду: в примере предполагается, что API CI поддерживает поиск запусков по идентификатору запроса. Параметр request_id предотвращает дубликаты, только если провайдер явно гарантирует идемпотентность. bounded_retry() — иллюстративный псевдокод. В продакшене повторные попытки должны ограничиваться как бюджетом повторов для каждой операции (максимальным числом попыток или затраченным временем), так и общим дедлайном рабочего процесса.

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

5. Распределяйте и распараллеливайте работу с явными бюджетами ресурсов

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

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

Например, режим Effort Mode в Perplexity Computer позволяет выбрать, сколько усилий заслуживает задача, не выбирая модель вручную. Выберите Light, Standard, High или Ultra, и Perplexity автоматически подберёт оркестрирующую модель и её уровень рассуждения. Затем этот оркестратор делегирует подзадачи вспомогательным агентам, которые могут использовать модели разных провайдеров.

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

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

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

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

6. Требуйте одобрений и изолируйте выполнение агентов

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

«Я скептически отношусь к чрезмерно сложным мультиагентным системам, особенно когда агенты проверяют и одобряют работу друг друга. В итоге несколько агентов могут уверенно передавать дальше одну и ту же ошибку, и никто её так и не заметит», — предупреждает Спилкер.

Развернуть

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

• её параметры
• её целевой ресурс
• её коммит или версию состояния
• решение проверяющего

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

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

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

7. Независимо проверяйте результаты и тестируйте поведение при восстановлении

Бывало, что агент сообщал Success, хотя на самом деле потерпел неудачу? Это раздражает, если не сказать бесит, и быстро это не исправить, ведь итоговое сообщение агента не обязательно подскажет, где что-то пошло не так.

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

Трассировка рабочего процесса для выявления проблемы

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

Семантические соглашения GenAI от OpenTelemetry обеспечивают стандартизированный способ описания этих операций. Например, invoke_workflow обозначает выполнение рабочего процесса, invoke_agent — вызов агента, а execute_tool — вызов инструмента. Каждую операцию можно записать как спан с указанием времени, статуса и соответствующих метаданных.

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

Пример трассировки выполнения.

Независимая проверка результатов

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

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

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

Внедрение сбоев для тестирования восстановления

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

Чтобы проверить это, намеренно внедряйте сбои в тестовой среде:

• Имитируйте тайм-ауты API
• Аварийно завершайте воркеры между записью во внешние системы и созданием контрольных точек
• Возвращайте результаты инструментов в неверном формате
• Имитируйте истечение срока действия одобрений

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

Допустим, ваш CI-агент отправляет запрос на запуск тестов, но ответ API не приходит до истечения тайм-аута. Агент повторяет попытку, получает успешный ответ и сообщает Success. Всё выглядит нормально, пока вы не заглянете в CI-сервис и не обнаружите, что вместо одного тестового прогона было создано два.

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

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

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

Часто задаваемые вопросы об оркестрации ИИ-агентов

Почему изолированные ИИ-агенты перестают справляться в масштабах предприятия?

Изолированные агенты могут правильно выполнять свои отдельные задачи, но вместе давать несогласованные результаты. Представьте, что агент по продажам получает условия для клиента в 10:00, агент по ценообразованию рассчитывает коммерческое предложение по обновлённым ценам в 10:05, а юридический агент проверяет договор, изменившийся в 10:07. Каждый агент работает со своим снимком состояния бизнеса, поэтому их результаты могут противоречить друг другу.

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

Как предотвратить бесконечные циклы повторных попыток у ИИ-агентов?

Устанавливайте ограничения на нескольких уровнях: максимальное число повторных вызовов инструментов, максимальное число итераций агента, глубину делегирования и общий крайний срок для рабочего процесса. Прежде чем повторять попытку, классифицируйте сбой. Для временных ответов 429 учитывайте Retry-After, если он передан. В остальных случаях используйте ограниченную экспоненциальную задержку между попытками со случайным разбросом (jitter).

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

Как возобновить рабочий процесс ИИ-агента после сбоя?

Механизм восстановления зависит от используемой среды выполнения. В LangGraph постоянное хранилище контрольных точек (checkpointer), например PostgresSaver, сохраняет состояние графа с привязкой к thread_id, что позволяет продолжить выполнение с сохранённого состояния. В Temporal другой воркер может восстановить рабочий процесс, воспроизведя историю его событий. При воспроизведении он повторно использует ранее записанные результаты активностей (activities).

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

Как проверить надёжность оркестрации ИИ-агентов?

Запускайте одни и те же репрезентативные задачи несколько раз и различайте pass@k (успешна ли хотя бы одна из k попыток) и pass^k (успешны ли все k попыток)

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