Разработка AI-оркестратора агентов (Agent Orchestration)

Разработка оркестратора AI-агентов: где ломается процесс

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

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

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

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

Что меняется после внедрения управляемых агентных систем

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

• Время выполнения сценария. Цепочка из 5–8 шагов выполняется без пауз на передачу между людьми; ожидание согласования остаётся только там, где оно нужно по регламенту.
• Доля обращений без оператора. Считается по каждому типу запроса отдельно: рутинные уходят в автономный режим, человек подключается на исключениях и нетиповых случаях.
• Сокращение ручных операций. Сверка данных, выгрузки, подготовка документов и постановка задач переводятся в шаги агента с фиксированным результатом, а не в инструкции для сотрудника.
• Устойчивость к отказам. Ретраи, таймауты и жёсткое ограничение числа шагов снимают класс отказов «цикл без выхода» и «потеря контекста» — они видны в метриках, а не всплывают у клиента.
• Наблюдаемость. Каждый шаг агента оставляет след: вход, вызванный инструмент, ответ, длительность. Трассировка строится на открытом стандарте OpenTelemetry, поэтому данные не запираются в формате одного поставщика.
• Восстановление. Откат на предыдущую конфигурацию оркестратора занимает минуты и не требует пересборки связок между агентами.
• Расход ресурсов. Простые запросы маршрутизируются на лёгкие модели, тяжёлые — на сильные; нагрузка перестаёт расти линейно вместе с числом обращений.

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

Варианты построения агентной системы: сравнение режимов

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

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

Этапы внедрения: от аудита процессов до передачи

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

1. Аудит процессов — разбираем, какие операции повторяются, где решение принимается по правилам, а где нужна модель. На выходе карта сценариев, список источников данных и точки, где человек обязательно подтверждает действие.
2. Проектирование схемы контура — определяем состав агентов, их роли, порядок передачи задачи, место хранения состояния и границы полномочий. Здесь же описываем правила обмена: формат сообщений, предельное время ожидания ответа, повторы при сбое.
3. Настройка и сборка — подключаем источники и инструменты, настраиваем маршрутизацию задач, лимиты, журналирование и трассировку, чтобы каждый шаг агента можно было восстановить.
4. Тестовые сценарии отказов — проверяем поведение при недоступном источнике, пустом ответе, конфликте двух агентов. Контур не должен уходить в цикл или выполнять одно действие дважды.
5. Пробный запуск на одном сценарии — выводим процесс на ограниченную группу, сверяем результат с ручным исполнением и правим правила обмена по факту.
6. Передача и обучение команды — отдаём схемы, регламенты, доступы и журналы, проводим обучение и остаёмся на сопровождении, пока команда не начнёт менять сценарии сама.

После этого новые роли и ветки логики добавляются силами заказчика — без повторного захода с нашей стороны.

Регламенты, схемы и конфигурации: что остаётся у вас

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

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

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

Кейс: как управляемый контур убрал ручные шаги

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

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

Что именно изменили

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

После запуска время обработки сократилось с 18–20 до 4–6 минут. Доля обращений, закрытых без ручного вмешательства, вышла на 78%; оставшиеся 22% — не отказы, а осознанная эскалация там, где цена ошибки выше скорости. Сбои, которые раньше приводили к повторному разбору — потеря контекста между шагами, неверная категория, дубль записи в учётной системе, — на тысячу операций упали с 34 до 3. Этот класс отказов закрыт архитектурно: правила проверки живут в самом контуре, а не в инструкции для оператора.

Чем оркестратор отличается от набора скриптов и очередей?

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

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

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

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

Технические вопросы: надёжность, доступы, контроль

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

Как ограничиваются доступы агентов к данным?

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

Как отлаживать сценарий, который падает не всегда?

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

Встроится ли это в наши существующие шаги и какие есть лимиты?

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

Обсудим задачу и вернёмся с оценкой и планом

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

По итогу обсуждения возвращаемся не с описанием «на словах», а с инженерным планом внедрения:

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

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